直接派發(fā)

C++ 默認使用的是直接派發(fā)，加上 virtual 修飾符可以改成函數(shù)表派發(fā)。直接派發(fā)是最快的，原因是調(diào)用指令會少，還可以通過編譯器進行比如內(nèi)聯(lián)等方式的優(yōu)化。缺點是由于缺少動態(tài)性而不支持繼承。

struct DragonFirePosition {
var x:Int64
var y:Int32
func land() {}
}
 
func DragonWillFire(_ position:DragonFirePosition) {
position.land()
}
let position = DragonFirePosition(x: 342, y: 213)
DragonWillFire(position)

編譯 inline 后 DragonWillFire(DragonFirePosition(x: 342, y: 213)) 會直接跳到方法實現(xiàn)的地方，結(jié)果就變成 position.land()。

函數(shù)表派發(fā)

Java 默認就是使用的函數(shù)表派發(fā)，通過 final 修飾符改成直接派發(fā)。函數(shù)表派發(fā)是有動態(tài)性的，在 Swift 里函數(shù)表叫 witness table，大部分語言叫 virtual table。一個類里會用數(shù)組來存儲里面的函數(shù)指針，override 父類的函數(shù)會替代以前的函數(shù)，子類添加的函數(shù)會被加到這個數(shù)組里。舉個例子：

class Fish {
func swim() {}
func eat() {
//normal eat
}
}
 
class FlyingFish: Fish {
override func eat() {
//flying fish eat
}
func fly() {}
}

編譯器會給 Fish 類和 FlyingFish 類分別創(chuàng)建 witness table。在 Fish 的函數(shù)表里有 swim 和 eat 函數(shù)，在 FlyingFish 函數(shù)表里有父類 Fish 的 swim，覆蓋了父類的 eat 和新增加的函數(shù) fly。

一個函數(shù)被調(diào)用時會先去讀取對象的函數(shù)表，再根據(jù)類的地址加上該的函數(shù)的偏移量得到函數(shù)地址，然后跳到那個地址上去。從編譯后的字節(jié)碼這方面來看就是兩次讀取一次跳轉(zhuǎn)，比直接派發(fā)還是慢了些。

消息機制派發(fā)

這種機制是在運行時可以改變函數(shù)的行為，KVO 和 CoreData 都是這種機制的運用。OC 默認就是使用的消息機制派發(fā)，使用 C 來直接派發(fā)獲取高性能。Swift 可以通過 dynamic 修飾來支持消息機制派發(fā)。

當(dāng)一個消息被派發(fā)，運行時就會按照繼承關(guān)系向上查找被調(diào)用的函數(shù)。但是這樣效率不高，所以需要通過緩存來提高效率，這樣查找性能就能和函數(shù)派發(fā)差不多了。

具體派發(fā)

聲明

值類型都會采用直接派發(fā)。無論是 class 還是協(xié)議 的 extension 也都是直接派發(fā)。class 和協(xié)議是函數(shù)表派發(fā)。

指定派發(fā)方式

• final：讓類里的函數(shù)使用直接派發(fā)，這樣該函數(shù)將會沒有動態(tài)性，運行時也沒法取到這個函數(shù)。
• dynamic：可以讓類里的函數(shù)使用消息機制派發(fā)，可以讓 extension 里的函數(shù)被 override。

派發(fā)優(yōu)化

Swift 會在這上面做優(yōu)化，比如一個函數(shù)沒有 override，Swift 就可能會使用直接派發(fā)的方式，所以如果屬性綁定了 KVO 它的 getter 和 setter 方法可能會被優(yōu)化成直接派發(fā)而導(dǎo)致 KVO 的失效，所以記得加上 dynamic 的修飾來保證有效。后面 Swift 應(yīng)該會在這個優(yōu)化上去做更多的處理。

以上就是淺談Swift派發(fā)機制的詳細內(nèi)容，更多關(guān)于Swift派發(fā)機制的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論