原文: Method Dispatch in Swift
作者: Brain King
譯者: kemchenj
譯者注:
之前看了很多關(guān)于 Swift 派發(fā)機(jī)制的內(nèi)容, 但感覺(jué)沒(méi)有一篇能夠徹底講清楚這件事情, 看完了這篇文章之后我對(duì) Swift 的派發(fā)機(jī)制才建立起了初步的認(rèn)知.
正文
一張表總結(jié)引用類(lèi)型, 修飾符和它們對(duì)于 Swift 函數(shù)派發(fā)方式的影響.
函數(shù)派發(fā)就是程序判斷使用哪種途徑去調(diào)用一個(gè)函數(shù)的機(jī)制. 每次函數(shù)被調(diào)用時(shí)都會(huì)被觸發(fā), 但你又不會(huì)太留意的一個(gè)東西. 了解派發(fā)機(jī)制對(duì)于寫(xiě)出高性能的代碼來(lái)說(shuō)很有必要, 而且也能夠解釋很多 Swift 里"奇怪"的行為.
編譯型語(yǔ)言有三種基礎(chǔ)的函數(shù)派發(fā)方式: 直接派發(fā)(Direct Dispatch), 函數(shù)表派發(fā)(Table Dispatch) 和 消息機(jī)制派發(fā)(Message Dispatch), 下面我會(huì)仔細(xì)講解這幾種方式. 大多數(shù)語(yǔ)言都會(huì)支持一到兩種, Java 默認(rèn)使用函數(shù)表派發(fā), 但你可以通過(guò) final 修飾符修改成直接派發(fā). C++ 默認(rèn)使用直接派發(fā), 但可以通過(guò)加上 virtual 修飾符來(lái)改成函數(shù)表派發(fā). 而 Objective-C 則總是使用消息機(jī)制派發(fā), 但允許開(kāi)發(fā)者使用 C 直接派發(fā)來(lái)獲取性能的提高. 這樣的方式非常好, 但也給很多開(kāi)發(fā)者帶來(lái)了困擾,
譯者注: 想要了解 Swift 底層結(jié)構(gòu)的人, 極度推薦這段視頻
派發(fā)方式 (Types of Dispatch )
程序派發(fā)的目的是為了告訴 CPU 需要被調(diào)用的函數(shù)在哪里, 在我們深入 Swift 派發(fā)機(jī)制之前, 先來(lái)了解一下這三種派發(fā)方式, 以及每種方式在動(dòng)態(tài)性和性能之間的取舍.
直接派發(fā) (Direct Dispatch)
直接派發(fā)是最快的, 不止是因?yàn)樾枰{(diào)用的指令集會(huì)更少, 并且編譯器還能夠有很大的優(yōu)化空間, 例如函數(shù)內(nèi)聯(lián)等, 但這不在這篇博客的討論范圍. 直接派發(fā)也有人稱(chēng)為靜態(tài)調(diào)用.
然而, 對(duì)于編程來(lái)說(shuō)直接調(diào)用也是最大的局限, 而且因?yàn)槿狈?dòng)態(tài)性所以沒(méi)辦法支持繼承.
函數(shù)表派發(fā) (Table Dispatch )
函數(shù)表派發(fā)是編譯型語(yǔ)言實(shí)現(xiàn)動(dòng)態(tài)行為最常見(jiàn)的實(shí)現(xiàn)方式. 函數(shù)表使用了一個(gè)數(shù)組來(lái)存儲(chǔ)類(lèi)聲明的每一個(gè)函數(shù)的指針. 大部分語(yǔ)言把這個(gè)稱(chēng)為 "virtual table"(虛函數(shù)表), Swift 里稱(chēng)為 "witness table". 每一個(gè)類(lèi)都會(huì)維護(hù)一個(gè)函數(shù)表, 里面記錄著類(lèi)所有的函數(shù), 如果父類(lèi)函數(shù)被 override 的話(huà), 表里面只會(huì)保存被 override 之后的函數(shù). 一個(gè)子類(lèi)新添加的函數(shù), 都會(huì)被插入到這個(gè)數(shù)組的最后. 運(yùn)行時(shí)會(huì)根據(jù)這一個(gè)表去決定實(shí)際要被調(diào)用的函數(shù).
舉個(gè)例子, 看看下面兩個(gè)類(lèi):
class ParentClass {
func method1() {}
func method2() {}
}
class ChildClass: ParentClass {
override func method2() {}
func method3() {}
}
在這個(gè)情況下, 編譯器會(huì)創(chuàng)建兩個(gè)函數(shù)表, 一個(gè)是 ParentClass 的, 另一個(gè)是 ChildClass的:
這張表展示了 ParentClass 和 ChildClass 虛數(shù)表里 method1, method2, method3 在內(nèi)存里的布局.
let obj = ChildClass()
obj.method2()
當(dāng)一個(gè)函數(shù)被調(diào)用時(shí), 會(huì)經(jīng)歷下面的幾個(gè)過(guò)程:
- 讀取對(duì)象
0xB00的函數(shù)表. - 讀取函數(shù)指針的索引. 在這里,
method2的索引是1(偏移量), 也就是0xB00 + 1. - 跳到
0x222(函數(shù)指針指向 0x222)
查表是一種簡(jiǎn)單, 易實(shí)現(xiàn), 而且性能可預(yù)知的方式. 然而, 這種派發(fā)方式比起直接派發(fā)還是慢一點(diǎn). 從字節(jié)碼角度來(lái)看, 多了兩次讀和一次跳轉(zhuǎn), 由此帶來(lái)了性能的損耗. 另一個(gè)慢的原因在于編譯器可能會(huì)由于函數(shù)內(nèi)執(zhí)行的任務(wù)導(dǎo)致無(wú)法優(yōu)化. (如果函數(shù)帶有副作用的話(huà))
這種基于數(shù)組的實(shí)現(xiàn), 缺陷在于函數(shù)表無(wú)法拓展. 子類(lèi)會(huì)在虛數(shù)函數(shù)表的最后插入新的函數(shù), 沒(méi)有位置可以讓 extension 安全地插入函數(shù). 這篇提案很詳細(xì)地描述了這么做的局限.
消息機(jī)制派發(fā) (Message Dispatch )
消息機(jī)制是調(diào)用函數(shù)最動(dòng)態(tài)的方式. 也是 Cocoa 的基石, 這樣的機(jī)制催生了 KVO, UIAppearence 和 CoreData 等功能. 這種運(yùn)作方式的關(guān)鍵在于開(kāi)發(fā)者可以在運(yùn)行時(shí)改變函數(shù)的行為. 不止可以通過(guò) swizzling 來(lái)改變, 甚至可以用 isa-swizzling 修改對(duì)象的繼承關(guān)系, 可以在面向?qū)ο蟮幕A(chǔ)上實(shí)現(xiàn)自定義派發(fā).
舉個(gè)例子, 看看下面兩個(gè)類(lèi):
class ParentClass {
dynamic func method1() {}
dynamic func method2() {}
}
class ChildClass: ParentClass {
override func method2() {}
dynamic func method3() {}
}
Swift 會(huì)用樹(shù)來(lái)構(gòu)建這種繼承關(guān)系:
這張圖很好地展示了 Swift 如何使用樹(shù)來(lái)構(gòu)建類(lèi)和子類(lèi).
當(dāng)一個(gè)消息被派發(fā), 運(yùn)行時(shí)會(huì)順著類(lèi)的繼承關(guān)系向上查找應(yīng)該被調(diào)用的函數(shù). 如果你覺(jué)得這樣做效率很低, 它確實(shí)很低! 然而, 只要緩存建立了起來(lái), 這個(gè)查找過(guò)程就會(huì)通過(guò)緩存來(lái)把性能提高到和函數(shù)表派發(fā)一樣快. 但這只是消息機(jī)制的原理, 這里有一篇文章很深入的講解了具體的技術(shù)細(xì)節(jié).
Swift 的派發(fā)機(jī)制
那么, 到底 Swift 是怎么派發(fā)的呢? 我沒(méi)能找到一個(gè)很簡(jiǎn)明扼要的答案, 但這里有四個(gè)選擇具體派發(fā)方式的因素存在:
- 聲明的位置
- 引用類(lèi)型
- 特定的行為
- 顯式地優(yōu)化(Visibility Optimizations)
在解釋這些因素之前, 我有必要說(shuō)清楚, Swift 沒(méi)有在文檔里具體寫(xiě)明什么時(shí)候會(huì)使用函數(shù)表什么時(shí)候使用消息機(jī)制. 唯一的承諾是使用 dynamic 修飾的時(shí)候會(huì)通過(guò) Objective-C 的運(yùn)行時(shí)進(jìn)行消息機(jī)制派發(fā). 下面我寫(xiě)的所有東西, 都只是我在 Swift 3.0 里測(cè)試出來(lái)的結(jié)果, 并且很可能在之后的版本更新里進(jìn)行修改.
聲明的位置 (Location Matters)
在 Swift 里, 一個(gè)函數(shù)有兩個(gè)可以聲明的位置: 類(lèi)型聲明的作用域, 和 extension. 根據(jù)聲明類(lèi)型的不同, 也會(huì)有不同的派發(fā)方式.
class MyClass {
func mainMethod() {}
}
extension MyClass {
func extensionMethod() {}
}
上面的例子里, mainMethod 會(huì)使用函數(shù)表派發(fā), 而 extensionMethod 則會(huì)使用直接派發(fā). 當(dāng)我第一次發(fā)現(xiàn)這件事情的時(shí)候覺(jué)得很意外, 直覺(jué)上這兩個(gè)函數(shù)的聲明方式并沒(méi)有那么大的差異. 下面是我根據(jù)類(lèi)型, 聲明位置總結(jié)出來(lái)的函數(shù)派發(fā)方式的表格.
這張表格展示了默認(rèn)情況下 Swift 使用的派發(fā)方式.
總結(jié)起來(lái)有這么幾點(diǎn):
- 值類(lèi)型總是會(huì)使用直接派發(fā), 簡(jiǎn)單易懂
- 而協(xié)議和類(lèi)的 extension 都會(huì)使用直接派發(fā)
-
NSObject的 extension 會(huì)使用消息機(jī)制進(jìn)行派發(fā) -
NSObject聲明作用域里的函數(shù)都會(huì)使用函數(shù)表進(jìn)行派發(fā). - 協(xié)議里聲明的, 并且?guī)в心J(rèn)實(shí)現(xiàn)的函數(shù)會(huì)使用函數(shù)表進(jìn)行派發(fā)
引用類(lèi)型 (Reference Type Matters)
引用的類(lèi)型決定了派發(fā)的方式. 這很顯而易見(jiàn), 但也是決定性的差異. 一個(gè)比較常見(jiàn)的疑惑, 發(fā)生在一個(gè)協(xié)議拓展和類(lèi)型拓展同時(shí)實(shí)現(xiàn)了同一個(gè)函數(shù)的時(shí)候.
protocol MyProtocol {
}
struct MyStruct: MyProtocol {
}
extension MyStruct {
func extensionMethod() {
print("結(jié)構(gòu)體")
}
}
extension MyProtocol {
func extensionMethod() {
print("協(xié)議")
}
}
let myStruct = MyStruct()
let proto: MyProtocol = myStruct
myStruct.extensionMethod() // -> “結(jié)構(gòu)體”
proto.extensionMethod() // -> “協(xié)議”
剛接觸 Swift 的人可能會(huì)認(rèn)為 proto.extensionMethod() 調(diào)用的是結(jié)構(gòu)體里的實(shí)現(xiàn). 但是, 引用的類(lèi)型決定了派發(fā)的方式, 協(xié)議拓展里的函數(shù)會(huì)使用直接調(diào)用. 如果把 extensionMethod 的聲明移動(dòng)到協(xié)議的聲明位置的話(huà), 則會(huì)使用函數(shù)表派發(fā), 最終就會(huì)調(diào)用結(jié)構(gòu)體里的實(shí)現(xiàn). 并且要記得, 如果兩種聲明方式都使用了直接派發(fā)的話(huà), 基于直接派發(fā)的運(yùn)作方式, 我們不可能實(shí)現(xiàn)預(yù)想的 override 行為. 這對(duì)于很多從 Objective-C 過(guò)渡過(guò)來(lái)的開(kāi)發(fā)者是反直覺(jué)的.
Swift JIRA(缺陷跟蹤管理系統(tǒng)) 也發(fā)現(xiàn)了幾個(gè) bugs, Swfit-Evolution 郵件列表里有一大堆討論, 也有一大堆博客討論過(guò)這個(gè). 但是, 這好像是故意這么做的, 雖然官方文檔沒(méi)有提過(guò)這件事情
指定派發(fā)方式 (Specifying Dispatch Behavior)
Swift 有一些修飾符可以指定派發(fā)方式.
final
final 允許類(lèi)里面的函數(shù)使用直接派發(fā). 這個(gè)修飾符會(huì)讓函數(shù)失去動(dòng)態(tài)性. 任何函數(shù)都可以使用這個(gè)修飾符, 就算是 extension 里本來(lái)就是直接派發(fā)的函數(shù). 這也會(huì)讓 Objective-C 的運(yùn)行時(shí)獲取不到這個(gè)函數(shù), 不會(huì)生成相應(yīng)的 selector.
dynamic
dynamic 可以讓類(lèi)里面的函數(shù)使用消息機(jī)制派發(fā). 使用 dynamic, 必須導(dǎo)入 Foundation 框架, 里面包括了 NSObject 和 Objective-C 的運(yùn)行時(shí). dynamic 可以讓聲明在 extension 里面的函數(shù)能夠被 override. dynamic 可以用在所有 NSObject 的子類(lèi)和 Swift 的原聲類(lèi).
@objc & @nonobjc
@objc 和 @nonobjc 顯式地聲明了一個(gè)函數(shù)是否能被 Objective-C 的運(yùn)行時(shí)捕獲到. 使用 @objc 的典型例子就是給 selector 一個(gè)命名空間 @objc(abc_methodName), 讓這個(gè)函數(shù)可以被 Objective-C 的運(yùn)行時(shí)調(diào)用. @nonobjc 會(huì)改變派發(fā)的方式, 可以用來(lái)禁止消息機(jī)制派發(fā)這個(gè)函數(shù), 不讓這個(gè)函數(shù)注冊(cè)到 Objective-C 的運(yùn)行時(shí)里. 我不確定這跟 final 有什么區(qū)別, 因?yàn)閺氖褂脠?chǎng)景來(lái)說(shuō)也幾乎一樣. 我個(gè)人來(lái)說(shuō)更喜歡 final, 因?yàn)橐鈭D更加明顯.
譯者注: 我個(gè)人感覺(jué), 這這主要是為了跟 Objective-C 兼容用的,
final等原生關(guān)鍵詞, 是讓 Swift 寫(xiě)服務(wù)端之類(lèi)的代碼的時(shí)候可以有原生的關(guān)鍵詞可以使用.
final @objc
可以在標(biāo)記為 final 的同時(shí), 也使用 @objc 來(lái)讓函數(shù)可以使用消息機(jī)制派發(fā). 這么做的結(jié)果就是, 調(diào)用函數(shù)的時(shí)候會(huì)使用直接派發(fā), 但也會(huì)在 Objective-C 的運(yùn)行時(shí)里注冊(cè)響應(yīng)的 selector. 函數(shù)可以響應(yīng) perform(selector:) 以及別的 Objective-C 特性, 但在直接調(diào)用時(shí)又可以有直接派發(fā)的性能.
@inline
Swift 也支持 @inline, 告訴編譯器可以使用直接派發(fā). 有趣的是, dynamic @inline(__always) func dynamicOrDirect() {} 也可以通過(guò)編譯! 但這也只是告訴了編譯器而已, 實(shí)際上這個(gè)函數(shù)還是會(huì)使用消息機(jī)制派發(fā). 這樣的寫(xiě)法看起來(lái)像是一個(gè)未定義的行為, 應(yīng)該避免這么做.
修飾符總結(jié) (Modifier Overview)
這張圖總結(jié)這些修飾符對(duì)于 Swift 派發(fā)方式的影響.
如果你想查看上面所有例子的話(huà), 請(qǐng)看這里.
可見(jiàn)的都會(huì)被優(yōu)化 (Visibility Will Optimize)
Swift 會(huì)盡最大能力去優(yōu)化函數(shù)派發(fā)的方式. 例如, 如果你有一個(gè)函數(shù)從來(lái)沒(méi)有 override, Swift 就會(huì)檢車(chē)并且在可能的情況下使用直接派發(fā). 這個(gè)優(yōu)化大多數(shù)情況下都表現(xiàn)得很好, 但對(duì)于使用了 target / action 模式的 Cocoa 開(kāi)發(fā)者就不那么友好了. 例如:
override func viewDidLoad() {
super.viewDidLoad()
navigationItem.rightBarButtonItem = UIBarButtonItem(
title: "登錄", style: .plain, target: nil,
action: #selector(ViewController.signInAction)
)
}
private func signInAction() {}
這里編譯器會(huì)拋出一個(gè)錯(cuò)誤: Argument of '#selector' refers to a method that is not exposed to Objective-C (Objective-C 無(wú)法獲取 #selector 指定的函數(shù)). 你如果記得 Swift 會(huì)把這個(gè)函數(shù)優(yōu)化為直接派發(fā)的話(huà), 就能理解這件事情了. 這里修復(fù)的方式很簡(jiǎn)單: 加上 @objc 或者 dynamic 就可以保證 Objective-C 的運(yùn)行時(shí)可以獲取到函數(shù)了. 這種類(lèi)型的錯(cuò)誤也會(huì)發(fā)生在UIAppearance 上, 依賴(lài)于 proxy 和 NSInvocation 的代碼.
另一個(gè)需要注意的是, 如果你沒(méi)有使用 dynamic 修飾的話(huà), 這個(gè)優(yōu)化會(huì)默認(rèn)讓 KVO 失效. 如果一個(gè)屬性綁定了 KVO 的話(huà), 而這個(gè)屬性的 getter 和 setter 會(huì)被優(yōu)化為直接派發(fā), 代碼依舊可以通過(guò)編譯, 不過(guò)動(dòng)態(tài)生成的 KVO 函數(shù)就不會(huì)被觸發(fā).
Swift 的博客有一篇很贊的文章描述了相關(guān)的細(xì)節(jié), 和這些優(yōu)化背后的考慮.
派發(fā)總結(jié) (Dispatch Summary)
這里有一大堆規(guī)則要記住, 所以我整理了一個(gè)表格:
這張表總結(jié)引用類(lèi)型, 修飾符和它們對(duì)于 Swift 函數(shù)派發(fā)的影響
NSObject 以及動(dòng)態(tài)性的損失 (NSObject and the Loss of Dynamic Behavior)
不久之前還有一群 Cocoa 開(kāi)發(fā)者討論動(dòng)態(tài)行為帶來(lái)的問(wèn)題. 這段討論很有趣, 提了一大堆不同的觀點(diǎn). 我希望可以在這里繼續(xù)探討一下, 有幾個(gè) Swift 的派發(fā)方式我覺(jué)得損害了動(dòng)態(tài)性, 順便說(shuō)一下我的解決方案.
NSObject 的函數(shù)表派發(fā) (Table Dispatch in NSObject)
上面, 我提到 NSObject 子類(lèi)定義里的函數(shù)會(huì)使用函數(shù)表派發(fā). 但我覺(jué)得很迷惑, 很難解釋清楚, 并且由于下面幾個(gè)原因, 這也只帶來(lái)了一點(diǎn)點(diǎn)性能的提升:
- 大部分
NSObject的子類(lèi)都是在obj_msgSend的基礎(chǔ)上構(gòu)建的. 我很懷疑這些派發(fā)方式的優(yōu)化, 實(shí)際到底會(huì)給 Cocoa 的子類(lèi)帶來(lái)多大的提升. - 大多數(shù) Swift 的
NSObject子類(lèi)都會(huì)使用 extension 進(jìn)行拓展, 都沒(méi)辦法使用這種優(yōu)化.
最后, 有一些小細(xì)節(jié)會(huì)讓派發(fā)方式變得很復(fù)雜.
派發(fā)方式的優(yōu)化破壞了 NSObject 的功能 (Dispatch Upgrades Breaking NSObject Features)
性能提升很棒, 我很喜歡 Swift 對(duì)于派發(fā)方式的優(yōu)化. 但是, UIView 子類(lèi)顏色的屬性理論上性能的提升破壞了 UIKit 現(xiàn)有的模式.
原文: However, having a theoretical performance boost in my
UIViewsubclass color property breaking an established pattern in UIKit is damaging to the language.
NSObject 作為一個(gè)選擇 (NSObject as a Choice)
使用靜態(tài)派發(fā)的話(huà)結(jié)構(gòu)體是個(gè)不錯(cuò)的選擇, 而使用消息機(jī)制派發(fā)的話(huà)則可以考慮 NSObject. 現(xiàn)在, 如果你想跟一個(gè)剛學(xué) Swift 的開(kāi)發(fā)者解釋為什么某個(gè)東西是一個(gè) NSObject 的子類(lèi), 你不得不去介紹 Objective-C 以及這段歷史. 現(xiàn)在沒(méi)有任何理由去繼承 NSObject 構(gòu)建類(lèi), 除非你需要使用 Objective-C 構(gòu)建的框架.
目前, NSObject 在 Swift 里的派發(fā)方式, 一句話(huà)總結(jié)就是復(fù)雜, 跟理想還是有差距. 我比較想看到這個(gè)修改: 當(dāng)你繼承 NSObject 的時(shí)候, 這是一個(gè)你想要完全使用動(dòng)態(tài)消息機(jī)制的表現(xiàn).
顯式的動(dòng)態(tài)性聲明 (Implicit Dynamic Modification)
另一個(gè) Swift 可以改進(jìn)的地方就是函數(shù)動(dòng)態(tài)性的檢測(cè). 我覺(jué)得在檢測(cè)到一個(gè)函數(shù)被 #selector 和 #keypath 引用時(shí)要自動(dòng)把這些函數(shù)標(biāo)記為 dynamic, 這樣的話(huà)就會(huì)解決大部分 UIAppearance 的動(dòng)態(tài)問(wèn)題, 但也許有別的編譯時(shí)的處理方式可以標(biāo)記這些函數(shù).
Error 以及 Bug (Errors and Bugs)
為了讓我們對(duì) Swift 的派發(fā)方式有更多了解, 讓我們來(lái)看一下 Swift 開(kāi)發(fā)者遇到過(guò)的 error.
SR-584
這個(gè) Swift bug 是 Swift 函數(shù)派發(fā)的一個(gè)功能. 存在于 NSObject 子類(lèi)聲明的函數(shù)(函數(shù)表派發(fā)), 以及聲明在 extension 的函數(shù)(消息機(jī)制派發(fā))中. 為了更好地描述這個(gè)情況, 我們先來(lái)創(chuàng)建一個(gè)類(lèi):
class Person: NSObject {
func sayHi() {
print("Hello")
}
}
func greetings(person: Person) {
person.sayHi()
}
greetings(person: Person()) // prints 'Hello'
greetings(person:) 函數(shù)使用函數(shù)表派發(fā)來(lái)調(diào)用 sayHi(). 就像我們看到的, 期望的, "Hello" 會(huì)被打印. 沒(méi)什么好講的地方, 那現(xiàn)在讓我們繼承 Persion:
class MisunderstoodPerson: Person {}
extension MisunderstoodPerson {
override func sayHi() {
print("No one gets me.")
}
}
greetings(person: MisunderstoodPerson()) // prints 'Hello'
可以看到, sayHi() 函數(shù)是在 extension 里聲明的, 會(huì)使用消息機(jī)制進(jìn)行調(diào)用. 當(dāng)greetings(person:) 被觸發(fā)時(shí), sayHi() 會(huì)通過(guò)函數(shù)表被派發(fā)到 Person 對(duì)象, 而misunderstoodPerson 重寫(xiě)之后會(huì)是用消息機(jī)制, 而 MisunderstoodPerson 的函數(shù)表依舊保留了 Person 的實(shí)現(xiàn), 緊接著歧義就產(chǎn)生了.
在這里的解決方法是保證函數(shù)使用相同的消息派發(fā)機(jī)制. 你可以給函數(shù)加上 dynamic 修飾符, 或者是把函數(shù)的實(shí)現(xiàn)從 extension 移動(dòng)到類(lèi)最初聲明的作用域里.
理解了 Swift 的派發(fā)方式, 就能夠理解這個(gè)行為產(chǎn)生的原因了, 雖然 Swift 不應(yīng)該讓我們遇到這個(gè)問(wèn)題.
SR-103
這個(gè) Swift bug 觸發(fā)了定義在協(xié)議拓展的默認(rèn)實(shí)現(xiàn), 即使是子類(lèi)已經(jīng)實(shí)現(xiàn)這個(gè)函數(shù)的情況下. 為了說(shuō)明這個(gè)問(wèn)題, 我們先定義一個(gè)協(xié)議, 并且給里面的函數(shù)一個(gè)默認(rèn)實(shí)現(xiàn):
protocol Greetable {
func sayHi()
}
extension Greetable {
func sayHi() {
print("Hello")
}
}
func greetings(greeter: Greetable) {
greeter.sayHi()
}
現(xiàn)在, 讓我們定義一個(gè)遵守了這個(gè)協(xié)議的類(lèi). 先定義一個(gè) Person 類(lèi), 遵守 Greetable 協(xié)議, 然后定義一個(gè)子類(lèi) LoudPerson, 重寫(xiě) sayHi() 方法.
class Person: Greetable {
}
class LoudPerson: Person {
func sayHi() {
print("HELLO")
}
}
你們發(fā)現(xiàn) LoudPerson 實(shí)現(xiàn)的函數(shù)前面沒(méi)有 override 修飾, 這是一個(gè)提示, 也許代碼不會(huì)像我們?cè)O(shè)想的那樣運(yùn)行. 在這個(gè)例子里, LoudPerson 沒(méi)有在 Greetable 的協(xié)議記錄表(Protocol Witness Table)里成功注冊(cè), 當(dāng) sayHi() 通過(guò) Greetable 協(xié)議派發(fā)時(shí), 默認(rèn)的實(shí)現(xiàn)就會(huì)被調(diào)用.
解決的方法就是, 在類(lèi)聲明的作用域里就要提供所有協(xié)議里定義的函數(shù), 即使已經(jīng)有默認(rèn)實(shí)現(xiàn). 或者, 你可以在類(lèi)的前面加上一個(gè) final 修飾符, 保證這個(gè)類(lèi)不會(huì)被繼承.
Doug Gregor 在 Swift-Evolution 郵件列表里提到, 通過(guò)顯式地重新把函數(shù)聲明為類(lèi)的函數(shù), 就可以解決這個(gè)問(wèn)題, 并且不會(huì)偏離我們的設(shè)想.
其它 bug (Other bugs)
Another bug that I thought I’d mention is SR-435. It involves two protocol extensions, where one extension is more specific than the other. The example in the bug shows one un-constrained extension, and one extension that is constrained to Equatable types. When the method is invoked inside a protocol, the more specific method is not called. I’m not sure if this always occurs or not, but seems important to keep an eye on.
另外一個(gè) bug 我在 SR-435 里已經(jīng)提過(guò)了. 當(dāng)有兩個(gè)協(xié)議拓展, 而其中一個(gè)更加具體時(shí)就會(huì)觸發(fā). 例如, 有一個(gè)不受約束的 extension, 而另一個(gè)被 Equatable 約束, 當(dāng)這個(gè)方法通過(guò)協(xié)議派發(fā), 約束比較多的那個(gè) extension 的實(shí)現(xiàn)則不會(huì)被調(diào)用. 我不太確定這是不是百分之百能復(fù)現(xiàn), 但有必要留個(gè)心眼.
If you are aware of any other Swift dispatch bugs, drop me a line and I’ll update this blog post.
如果你發(fā)現(xiàn)了其它 Swift 派發(fā)的 bug 的話(huà), @一下我我就會(huì)更新到這篇博客里.
有趣的 Error (Interesting Error)
有一個(gè)很好玩的編譯錯(cuò)誤, 可以窺見(jiàn)到 Swift 的計(jì)劃. 就像之前說(shuō)的, 類(lèi)拓展使用直接派發(fā), 所以你試圖 override 一個(gè)聲明在 extension 里的函數(shù)的時(shí)候會(huì)發(fā)生什么?
class MyClass {
}
extension MyClass {
func extensionMethod() {}
}
class SubClass: MyClass {
override func extensionMethod() {}
}
上面的代碼會(huì)觸發(fā)一個(gè)編譯錯(cuò)誤 Declarations in extensions can not be overridden yet(聲明在 extension 里的方法不可以被重寫(xiě)). 這可能是 Swift 團(tuán)隊(duì)打算加強(qiáng)函數(shù)表派發(fā)的一個(gè)征兆. 又或者這只是我過(guò)度解讀, 覺(jué)得這門(mén)語(yǔ)言可以?xún)?yōu)化的地方.
致謝 Thanks
我希望了解函數(shù)派發(fā)機(jī)制的過(guò)程中你感受到了樂(lè)趣, 并且可以幫助你更好的理解 Swift. 雖然我抱怨了 NSObject 相關(guān)的一些東西, 但我還是覺(jué)得 Swift 提供了高性能的可能性, 我只是希望可以有足夠簡(jiǎn)單的方式, 讓這篇博客沒(méi)有存在的必要.
