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