文檔中的一些技巧可以幫助提升您的 Swift 程序質(zhì)量，使您的代碼不容易出錯(cuò)且可讀性更好。顯式地標(biāo)記最終類和類協(xié)議是兩個(gè)顯而易見(jiàn)的例子。 然而文檔中還有一些技巧是不符合規(guī)矩的，扭曲的，僅僅解決一些比編譯器或語(yǔ)言的特殊的臨時(shí)性需求。文檔中的很多建議來(lái)自于多方面的權(quán)衡，例如：運(yùn)行時(shí)、字 節(jié)大小、代碼可讀性等等。

啟用優(yōu)化

第一個(gè)應(yīng)該做的事情就是啟用優(yōu)化。Swift 提供了三種不同的優(yōu)化級(jí)別：

• -Onone: 這意味著正常的開(kāi)發(fā)。它執(zhí)行最小優(yōu)化和保存所有調(diào)試信息。

• -O: 這意味著對(duì)于大多數(shù)生產(chǎn)代碼。編譯器執(zhí)行積極地優(yōu)化，可以大大改變提交代碼的類型和數(shù)量。調(diào)試信息將被省略但還是會(huì)有損害的。

• -Ounchecked: 這是一個(gè)特殊的優(yōu)化模式，它意味著特定的庫(kù)或應(yīng)用程序，這是以安全性來(lái)交換的。編譯器將刪除所有溢出檢查以及一些隱式類型檢查。這不是在通常情況下使用 的，因?yàn)樗赡軙?huì)導(dǎo)致內(nèi)存安全問(wèn)題和整數(shù)溢出。如果你仔細(xì)審查你的代碼，那么對(duì)整數(shù)溢出和類型轉(zhuǎn)換來(lái)說(shuō)是安全的。

在 Xcode UI 中，可以修改的當(dāng)前優(yōu)化級(jí)別如下：
…

整個(gè)組件優(yōu)化

默認(rèn)情況下 Swift 單獨(dú)編譯每個(gè)文件。這使得 Xcode 可以非?？焖俚牟⑿芯幾g多個(gè)文件。然而，分開(kāi)編譯每個(gè)文件可以預(yù)防某些編譯器優(yōu)化。Swift 也可以猶如它是一個(gè)文件一樣編譯整個(gè)程序，猶如就好像它是一個(gè)單一的編譯單元一樣優(yōu)化這個(gè)程序。這個(gè)模式可以使用命令行 flag-whole-module-optimization 來(lái)激活。在這種模式下編譯的程序?qū)⒆钭钣锌赡苄枰L(zhǎng)時(shí)間來(lái)編譯，單可以運(yùn)行得更快。

這個(gè)模式可以通過(guò) XCode 構(gòu)建設(shè)置中的“Whole Module Optimization”來(lái)激活。

降低動(dòng)態(tài)調(diào)度

Swift 在默認(rèn)情況下是一個(gè)類似 Objective-C 的非常動(dòng)態(tài)的語(yǔ)言。與 Objective-C 不同的是，Swift 給了程序員通過(guò)消除和減少這種特性來(lái)提供運(yùn)行時(shí)性能的能力。本節(jié)提供幾個(gè)可被用于這樣的操作的語(yǔ)言結(jié)構(gòu)的例子。

動(dòng)態(tài)調(diào)度

類使用動(dòng)態(tài)調(diào)度的方法和默認(rèn)的屬性訪問(wèn)。因此在下面的代碼片段中，a.aProperty、a.doSomething() 和 a.doSomethingElse() 都將通過(guò)動(dòng)態(tài)調(diào)度來(lái)調(diào)用：

class A {
  var aProperty: [Int]
  func doSomething() { ... }
  dynamic doSomethingElse() { ... }
}

class B : A {
  override var aProperty {
    get { ... }
    set { ... }
  }

  override func doSomething() { ... }
}

func usingAnA(a: A) {
  a.doSomething()
  a.aProperty = ...
}

在 Swift 中，動(dòng)態(tài)調(diào)度默認(rèn)通過(guò)一個(gè) vtable[1]（虛函數(shù)表）間接調(diào)用。如果使用一個(gè) dynamic 關(guān)鍵字來(lái)聲明，Swift 將會(huì)通過(guò)調(diào)用 Objective-C 通知來(lái)發(fā)送呼叫代替。這兩種情況中，這種情況會(huì)比直接的函數(shù)調(diào)用較慢，因?yàn)樗乐沽藢?duì)間接呼叫本身之外程序開(kāi)銷的許多編譯器優(yōu)化[2]。在性能關(guān)鍵的代碼 中，人們常常會(huì)想限制這種動(dòng)態(tài)行為。

建議：當(dāng)你知道聲明不需要被重寫(xiě)時(shí)使用“final”。

final 關(guān)鍵字是一個(gè)類、一個(gè)方法、或一個(gè)屬性聲明中的一個(gè)限制，使得這樣的聲明不得被重寫(xiě)。這意味著編譯器可以呼叫直接的函數(shù)調(diào)用代替間接調(diào)用。例如下面的 C.array1 和 D.array1 將會(huì)被直接[3]訪問(wèn)。與之相反，D.array2 將通過(guò)一個(gè)虛函數(shù)表訪問(wèn)：

final class C {
  // No declarations in class 'C' can be overridden.
  var array1: [Int]
  func doSomething() { ... }
}

class D {
  final var array1 [Int] // 'array1' cannot be overridden by a computed property.
  var array2: [Int]      // 'array2' *can* be overridden by a computed property.
}

func usingC(c: C) {
   c.array1[i] = ... // Can directly access C.array without going through dynamic dispatch.
   c.doSomething() = ... // Can directly call C.doSomething without going through virtual dispatch.
}

func usingD(d: D) {
   d.array1[i] = ... // Can directly access D.array1 without going through dynamic dispatch.
   d.array2[i] = ... // Will access D.array2 through dynamic dispatch.
}

建議：當(dāng)聲明的東西不需要被文件外部被訪問(wèn)到的時(shí)候，就用“private”

將 private 關(guān)鍵詞用在一個(gè)聲明上，會(huì)限制對(duì)其進(jìn)行了聲明的文件的可見(jiàn)性。這會(huì)讓編輯器有能力甄別出所有其它潛在的覆蓋聲明。如此，由于沒(méi)有了任何這樣的聲明，使得編 譯器可以自動(dòng)地推斷出 final 關(guān)鍵詞，并據(jù)此去掉對(duì)方面的間接調(diào)用和屬性的訪問(wèn)。例如在如下的 e.doSomething()  和 f.myPrivateVar 中，就將可以被直接訪問(wèn)，假定在同一個(gè)文件中，E, F 并沒(méi)有任何覆蓋的聲明：

private class E {
  func doSomething() { ... }
}

class F {
  private var myPrivateVar : Int
}

func usingE(e: E) {
  e.doSomething() // There is no sub class in the file that declares this class.
                  // The compiler can remove virtual calls to doSomething()
                  // and directly call A’s doSomething method.
}

func usingF(f: F) -> Int {
  return f.myPrivateVar
}

高效的使用容器類型

通用的容器 Array 和 Dictionary 是有 Swift 標(biāo)準(zhǔn)庫(kù)提供的一個(gè)重要的功能特性。本節(jié)將介紹如何用一種高性能的方式使用這些類型。

建議：在數(shù)組中使用值類型

在 Swift 中，類型可以分為不同的兩類：值類型（結(jié)構(gòu)體，枚舉，元組）和引用類型（類）。一個(gè)關(guān)鍵的區(qū)分是 NSArray 不能含有值類型。因此當(dāng)使用值類型時(shí)，優(yōu)化器就不需要去處理對(duì) NSArray 的支持，從而可以在數(shù)組上省去大部分消耗。

此外，相比引用類型，如果值類型遞歸地含有引用類型，那么值類型僅僅需要引用計(jì)數(shù)器。而如果使用沒(méi)有引用類型的值類型，就可以避免額外的開(kāi)銷，從而釋放數(shù)組內(nèi)的流量。

// Don't use a class here.
struct PhonebookEntry {
  var name : String
  var number : [Int]
}

var a : [PhonebookEntry]

記住要在使用大值類型和使用引用類型之間做好權(quán)衡。在某些情況下，拷貝和移動(dòng)大值類型數(shù)據(jù)的消耗要大于移除橋接和持有/釋放的消耗。

建議：當(dāng) NSArray 橋接不必要時(shí)，使用 ContiguousArray 存儲(chǔ)引用類型。如果你需要一個(gè)引用類型的數(shù)組，而且數(shù)組不需要橋接到 NSArray 時(shí)，使用 ContiguousArray 替代 Array：

class C { ... }
var a: ContiguousArray<C> = [C(...), C(...), ..., C(...)]

建議：使用適當(dāng)?shù)母淖兌皇菍?duì)象分配。

在 Swift 中所有的標(biāo)準(zhǔn)庫(kù)容器都使用 COW(copy-on-write) 執(zhí)行拷貝代替即時(shí)拷貝。在很多情況下，這可以讓編譯器通過(guò)持有容器而不是深度拷貝，從而省掉不必要的拷貝。如果容器的引用計(jì)數(shù)大于 1 并容器時(shí)被改變時(shí)，就會(huì)拷貝底層容器。例如：在下面這種情況：當(dāng) d 被分配給 c 時(shí)不拷貝，但是當(dāng) d 經(jīng)歷了結(jié)構(gòu)性的改變追加 2，那么 d 將會(huì)被拷貝，然后 2 被追加到 b：

var c: [Int] = [ ... ]
var d = c        // No copy will occur here.
d.append(2)      // A copy *does* occur here.

如果用戶不小心時(shí)，有時(shí) COW 會(huì)引起額外的拷貝。例如，在函數(shù)中，試圖通過(guò)對(duì)象分配執(zhí)行修改。在 Swift 中，所有的參數(shù)傳遞時(shí)都會(huì)被拷貝一份，例如，參數(shù)在調(diào)用點(diǎn)之前持有一份，然后在調(diào)用的函數(shù)結(jié)束時(shí)釋放。也就是說(shuō)，像下面這樣的函數(shù)：

func append_one(a: [Int]) -> [Int] {
  a.append(1)
  return a
}

var a = [1, 2, 3]
a = append_one(a)

盡管由于分配，a 的版本沒(méi)有任何改變 ，在 append_one 后也沒(méi)有使用 ，  但 a 也許會(huì)被拷貝。這可以通過(guò)使用 inout 參數(shù)來(lái)避免這個(gè)問(wèn)題：

func append_one_in_place(inout a: [Int]) {
  a.append(1)
}

var a = [1, 2, 3]
append_one_in_place(&a)

未檢查操作

Swift 通過(guò)在執(zhí)行普通計(jì)算時(shí)檢查溢出的方法解決了整數(shù)溢出的 bug。這些檢查在已確定沒(méi)有內(nèi)存安全問(wèn)題會(huì)發(fā)生的高效的代碼中，是不合適的。

建議：當(dāng)你確切的知道不會(huì)發(fā)生溢出時(shí)使用未檢查整型計(jì)算。

在對(duì)性能要求高的代碼中，如果你知道你的代碼是安全的，那么你可以忽略溢出檢查。

a : [Int]
b : [Int]
c : [Int]

// Precondition: for all a[i], b[i]: a[i] + b[i] does not overflow!
for i in 0 ... n {
  c[i] = a[i] &+ b[i]
}

泛型

Swift 通過(guò)泛型類型的使用，提供了一個(gè)非常強(qiáng)大的抽象機(jī)制 。Swift 編譯器發(fā)出一個(gè)可以對(duì)任何 T 執(zhí)行 MySwiftFunc<T> 的具體的代碼塊。生成的代碼需要一個(gè)函數(shù)指針表和一個(gè)包含 T 的盒子作為額外的參數(shù)。MySwiftFunc<Int> 和 MySwiftFunc<String> 之間的不同的行為通過(guò)傳遞不同的函數(shù)指針表和通過(guò)盒子提供的抽象大小來(lái)說(shuō)明。一個(gè)泛型的例子：

class MySwiftFunc<T> { ... }

MySwiftFunc<Int> X    // Will emit code that works with Int...
MySwiftFunc<String> Y // ... as well as String.

當(dāng)優(yōu)化器啟用時(shí)，Swift 編譯器尋找這段代碼的調(diào)用，并試著確認(rèn)在調(diào)用中具體使用的類型（例如：非泛型類型）。如果泛型函數(shù)的定義對(duì)優(yōu)化器來(lái)說(shuō)是可見(jiàn)的，并知道具體類 型，Swift 編譯器將生成一個(gè)有特殊類型的特殊泛型函數(shù)。那么調(diào)用這個(gè)特殊函數(shù)的這個(gè)過(guò)程就可以避免關(guān)聯(lián)泛型的消耗。一些泛型的例子：

class MyStack<T> {
  func push(element: T) { ... }
  func pop() -> T { ... }
}

func myAlgorithm(a: [T], length: Int) { ... }

// The compiler can specialize code of MyStack[Int]
var stackOfInts: MyStack[Int]
// Use stack of ints.
for i in ... {
  stack.push(...)
  stack.pop(...)
}

var arrayOfInts: [Int]
// The compiler can emit a specialized version of 'myAlgorithm' targeted for
// [Int]' types.
myAlgorithm(arrayOfInts, arrayOfInts.length)

建議：將泛型的聲明放在使用它的文件中

只有在泛型聲明在當(dāng)前模塊可見(jiàn)的情況下優(yōu)化器才能執(zhí)行特殊化。這只有在使用泛型的代碼和聲明泛型的代碼在同一個(gè)文件中才能發(fā)生。注意標(biāo)準(zhǔn)庫(kù)是一個(gè)例外。在標(biāo)準(zhǔn)庫(kù)中聲明的泛型對(duì)所有模塊可見(jiàn)并可以進(jìn)行特殊化。

建議：允許編譯器進(jìn)行特殊化

只有當(dāng)調(diào)用位置和被調(diào)函數(shù)位于同一個(gè)編譯單元的時(shí)候編譯器才能對(duì)泛型代碼進(jìn)行特殊化。我們可以使用一個(gè)技巧讓編譯器對(duì)被調(diào)函數(shù)進(jìn)行優(yōu)化，這個(gè)技巧就 是在被調(diào)函數(shù)所在的編譯單元中執(zhí)行類型檢查。執(zhí)行類型檢查的代碼會(huì)重新分發(fā)這個(gè)調(diào)用到泛型函數(shù)—可是這一次它攜帶了類型信息。在下面的代碼中，我們?cè)诤瘮?shù) play_a_game 中插入了類型檢查，使得代碼的速度提高了幾百倍。

//Framework.swift:

protocol Pingable { func ping() -> Self }
protocol Playable { func play() }

extension Int : Pingable {
  func ping() -> Int { return self + 1 }
}

class Game<T : Pingable> : Playable {
  var t : T

  init (_ v : T) {t = v}

  func play() {
    for _ in 0...100_000_000 { t = t.ping() }
  }
}

func play_a_game(game : Playable ) {
  // This check allows the optimizer to specialize the
  // generic call 'play'
  if let z = game as? Game<Int> {
    z.play()
  } else {
    game.play()
  }
}

/// -------------- >8

// Application.swift:

play_a_game(Game(10))

大的值對(duì)象的開(kāi)銷

在 swift 語(yǔ)言中，值類型保存它們數(shù)據(jù)獨(dú)有的一份拷貝。使用值類型有很多優(yōu)點(diǎn)，比如值類型具有獨(dú)立的狀態(tài)。當(dāng)我們拷貝值類型時(shí)（相當(dāng)于復(fù)制，初始化參數(shù)傳遞等操作），程序會(huì)創(chuàng)建值類型的一個(gè)拷貝。對(duì)于大的值類型，這種拷貝時(shí)很耗費(fèi)時(shí)間的，可能會(huì)影響到程序的性能。

讓我們看一下下面這段代碼。這段代碼使用值類型的節(jié)點(diǎn)定義了一個(gè)樹(shù)，樹(shù)的節(jié)點(diǎn)包含了協(xié)議類型的其他節(jié)點(diǎn)，計(jì)算機(jī)圖形場(chǎng)景經(jīng)常由可以使用值類型表示的實(shí)體以及形態(tài)變化，因此這個(gè)例子很有實(shí)踐意義

protocol P {}
struct Node : P {
  var left, right : P?
}

struct Tree {
  var node : P?
  init() { ... }
}

當(dāng)樹(shù)進(jìn)行拷貝時(shí)（參數(shù)傳遞，初始化或者賦值）整個(gè)樹(shù)都需要被復(fù)制.這是一項(xiàng)花銷很大的操作，需要很多的 malloc/free 調(diào)用以及以及大量的引用計(jì)數(shù)操作

然而，我們并不關(guān)系值是否被拷貝，只要在這些值還在內(nèi)存中存在就可以。

對(duì)大的值類型使用 COW（copy-on-write，寫(xiě)時(shí)復(fù)制和數(shù)組有點(diǎn)類似）

減少?gòu)?fù)制大的值類型數(shù)據(jù)開(kāi)銷的辦法時(shí)采用寫(xiě)時(shí)復(fù)制行為（當(dāng)對(duì)象改變時(shí)才進(jìn)行實(shí)際的復(fù)制工作）。最簡(jiǎn)單的實(shí)現(xiàn)寫(xiě)時(shí)復(fù)制的方案時(shí)使用已經(jīng)存在的寫(xiě)時(shí)復(fù)制 的數(shù)據(jù)結(jié)構(gòu)，比如數(shù)組。Swift 的數(shù)據(jù)是值類型，但是當(dāng)數(shù)組作為參數(shù)被傳遞時(shí)并不每次都進(jìn)行復(fù)制，因?yàn)樗哂袑?xiě)時(shí)復(fù)制的特性。

在我們的 Tree 的例子中我們通過(guò)將 tree 的內(nèi)容包裝成一個(gè)數(shù)組來(lái)減少?gòu)?fù)制的代價(jià)。這個(gè)簡(jiǎn)單的改變對(duì)我們 tree 數(shù)據(jù)結(jié)構(gòu)的性能影響時(shí)巨大的，作為參數(shù)傳遞數(shù)組的代價(jià)從 O(n) 變?yōu)?O(1)。

struct tree : P {
  var node : [P?]
  init() {
    node = [ thing ]
  }
}

但是使用數(shù)組實(shí)現(xiàn) COW 機(jī)制有兩個(gè)明顯的不足，第一個(gè)問(wèn)題是數(shù)組暴露的諸如 append 以及 count 之類的方法在值包裝的上下文中沒(méi)有任何作用，這些方法使得引用類型的封裝變得棘手。也許我們可以通過(guò)創(chuàng)建一個(gè)封裝的結(jié)構(gòu)體并隱藏這些不用的 API 來(lái)解決這個(gè)問(wèn)題，但是卻無(wú)法解決第二個(gè)問(wèn)題。第二個(gè)問(wèn)題就是數(shù)組內(nèi)部存在保證程序安全性的代碼以及和 OC 交互的代碼。Swift 要檢查給出的下表是否摟在數(shù)組的邊界內(nèi)，當(dāng)保存值的時(shí)候需要檢查是否需要擴(kuò)充存儲(chǔ)空間。這些運(yùn)行時(shí)檢查會(huì)降低速度。

一個(gè)替代的方案是實(shí)現(xiàn)一個(gè)專門(mén)的使用 COW 機(jī)制的數(shù)據(jù)結(jié)構(gòu)代替采用數(shù)組作為值的封裝。構(gòu)建這樣一個(gè)數(shù)據(jù)結(jié)構(gòu)的示例如下所示：

final class Ref<T> {
  var val : T
  init(_ v : T) {val = v}
}

struct Box<T> {
    var ref : Ref<T>
    init(_ x : T) { ref = Ref(x) }

    var value: T {
        get { return ref.val }
        set {
          if (!isUniquelyReferencedNonObjC(&ref)) {
            ref = Ref(newValue)
            return
          }
          ref.val = newValue
        }
    }
}

類型 Box 可以代替上個(gè)例子中的數(shù)組

不安全的代碼

Swift 語(yǔ)言的類都是采用引用計(jì)數(shù)進(jìn)行內(nèi)存管理的。Swift 編譯器會(huì)在每次對(duì)象被訪問(wèn)的時(shí)候插入增加引用計(jì)數(shù)的代碼。例如，考慮一個(gè)遍歷使用類實(shí)現(xiàn)的一個(gè)鏈表的例子。遍歷鏈表是通過(guò)移動(dòng)引用到鏈表的下一個(gè)節(jié)點(diǎn)來(lái)完 成的：elem = elem.next，每次移動(dòng)這個(gè)引用，Swift 都要增加 next 對(duì)象的引用計(jì)數(shù)并減少前一個(gè)對(duì)象的引用計(jì)數(shù)，這種引用計(jì)數(shù)代價(jià)昂貴但是只要使用 swift 類就無(wú)法避免

final class Node {
 var next: Node?
 var data: Int
 ...
}

建議：使用未托管的引用避免引用計(jì)數(shù)的負(fù)荷

在效率至上的代碼中你可以選擇使用未托管的引用。Unmanaged<T>結(jié)構(gòu)體允許開(kāi)發(fā)者對(duì)特別的引用關(guān)閉引用計(jì)數(shù)

var Ref : Unmanaged<Node> = Unmanaged.passUnretained(Head)

while let Next = Ref.takeUnretainedValue().next {
  ...
  Ref = Unmanaged.passUnretained(Next)
}

協(xié)議

建議：將只有類實(shí)現(xiàn)的協(xié)議標(biāo)記為類協(xié)議

Swift 可以指定協(xié)議只能由類實(shí)現(xiàn)。標(biāo)記協(xié)議只能由類實(shí)現(xiàn)的一個(gè)好處是編譯器可以基于這一點(diǎn)對(duì)程序進(jìn)行優(yōu)化。例如，ARC 內(nèi)存管理系統(tǒng)能夠容易的持有（增加該對(duì)象的引用計(jì)數(shù)）如果它知道它正在處理一個(gè)類對(duì)象。如果編譯器不知道這一點(diǎn)，它就必須假設(shè)結(jié)構(gòu)體也可以實(shí)現(xiàn)協(xié)議，那么 它就必須準(zhǔn)備好持有或者釋放不同的數(shù)據(jù)結(jié)構(gòu)，而這代價(jià)將會(huì)十分昂貴。

如果限制只能由類實(shí)現(xiàn)某協(xié)議那么就標(biāo)記該協(xié)議為類協(xié)議以獲得更好的性能

protocol Pingable : class { func ping() -> Int }

腳注

【1】虛擬方法表或者 vtable 是被一個(gè)實(shí)例引用的一種包含類型方法地址的類型約束表。進(jìn)行動(dòng)態(tài)分發(fā)時(shí)，首先從對(duì)象中查找這張表然后查找表中的方法
【2】這是因?yàn)榫幾g器并不知道那個(gè)具體的方法要被調(diào)用
【3】例如，直接加載一個(gè)類的字段或者直接調(diào)用一個(gè)方法
【4】解釋 COW 是什么
【5】在特定情況下優(yōu)化器能夠通過(guò)內(nèi)聯(lián)和 ARC 優(yōu)化技術(shù)移除 retain，release 因?yàn)闆](méi)有引起復(fù)制