快捷導(dǎo)航

分析Swift性能高效的原因

更新時(shí)間：2020年10月27日 11:44:24 作者：louis_wang

絕大多數(shù)公司選擇Swift語(yǔ)言開發(fā)iOS應(yīng)用，主要原因是因?yàn)镾wift相比Objc有更快的運(yùn)行效率，更加安全的類型檢測(cè)，更多現(xiàn)代語(yǔ)言的特性提升開發(fā)效率；這一系列的優(yōu)點(diǎn)使Swift語(yǔ)言的熱度越來(lái)越高。

自從2014年Apple發(fā)布Swift語(yǔ)言以來(lái)，歷時(shí)六年多，Swift已經(jīng)發(fā)布到5.3版本，在5.0版本已經(jīng)ABI stability，5.2版本也已經(jīng)module stability，不管是語(yǔ)言還是基礎(chǔ)庫(kù)都日趨穩(wěn)定，目前國(guó)內(nèi)外大廠也都積極擁抱Swift陣營(yíng)。

絕大多數(shù)公司選擇Swift語(yǔ)言開發(fā)iOS應(yīng)用，主要原因是因?yàn)镾wift相比Objc有更快的運(yùn)行效率，更加安全的類型檢測(cè)，更多現(xiàn)代語(yǔ)言的特性提升開發(fā)效率；這一系列的優(yōu)點(diǎn)使Swift語(yǔ)言的熱度越來(lái)越高。

大多數(shù)人知道Swift語(yǔ)言相比于Objc語(yǔ)言運(yùn)行效率更高，但是卻不知道為什么效率更高，在這里我們Swift編譯層探討一下Swift語(yǔ)言高效的原因。

更加高效的數(shù)據(jù)類型

在開始討論Swift數(shù)據(jù)類型之前，我們先討論一下Swift的函數(shù)派發(fā)機(jī)制；

靜態(tài)派發(fā)、動(dòng)態(tài)派發(fā)、消息派發(fā)(static dispatch、dynamic dispatch、message dispatch)
動(dòng)態(tài)派發(fā)(dynamic dispatch): 動(dòng)態(tài)派發(fā)是指編譯期無(wú)法確定應(yīng)該調(diào)用哪個(gè)方法，需要在運(yùn)行時(shí)才能確定方法的調(diào)用。

靜態(tài)派發(fā)(static dispatch)：是在編譯期就能確定的調(diào)用方法的派發(fā)方式。

除了上面兩種方式之外，在Swift里面還會(huì)使用Objc的消息派發(fā)(message dispatch))機(jī)制；Objc采用了運(yùn)行時(shí)采用obj_msgsend進(jìn)行消息派發(fā)，所以O(shè)bjc的一些動(dòng)態(tài)特性在Swift里面也可以被限制的使用。

靜態(tài)派發(fā)相比于動(dòng)態(tài)派發(fā)更快，而且靜態(tài)派發(fā)還會(huì)進(jìn)行內(nèi)聯(lián)等一些優(yōu)化，減少函數(shù)的尋址及內(nèi)存地址的偏移計(jì)算等一系列操作，使函數(shù)的執(zhí)行速度更快，性能更高。

數(shù)據(jù)類型(struct/class)

我們都知道，內(nèi)存分配可以分為堆區(qū)(Heap)和棧區(qū)(Stack)。由于棧區(qū)內(nèi)存是連續(xù)的，內(nèi)存的分配和銷毀是通過(guò)入棧和出棧操作進(jìn)行的，速度要高于堆區(qū)。堆區(qū)存儲(chǔ)高級(jí)數(shù)據(jù)類型，在數(shù)據(jù)初始化時(shí)，查找沒有使用的內(nèi)存，銷毀時(shí)再?gòu)膬?nèi)存中清除，所以堆區(qū)的數(shù)據(jù)存儲(chǔ)不一定是連續(xù)的。

類(class)和結(jié)構(gòu)體(struct)在內(nèi)存分配上是不同的，基本數(shù)據(jù)類型和結(jié)構(gòu)體默認(rèn)分配在棧區(qū)，而像類這種高級(jí)數(shù)據(jù)類型存儲(chǔ)在堆區(qū)，且堆區(qū)數(shù)據(jù)存儲(chǔ)不是線程安全的，在頻繁的數(shù)據(jù)讀寫操作時(shí)，要進(jìn)行加鎖操作。

我們?cè)趕wift文檔里面能看到對(duì)結(jié)構(gòu)的描述，結(jié)構(gòu)體是值類型(Value Type)，當(dāng)值類型的數(shù)據(jù)賦值給一個(gè)變量或常量，或者傳遞給一個(gè)函數(shù)時(shí)，是值拷貝；

例如：

struct Resolution {
  var width = 0
  var height = 0
}

let hd = Resolution(width: 1920, height: 1080)
var cinema = hd
cinema.width = 2048

print("cinema is now \(cinema.width) pixels wide")
// Prints "cinema is now 2048 pixels wide"

print("hd is still \(hd.width) pixels wide")
// Prints "hd is still 1920 pixels wide"

通過(guò)這個(gè)例子我們能清楚的看到，當(dāng)hd賦值給cinema時(shí)，是將hd中存儲(chǔ)的值拷貝給cinema,所以當(dāng)給cinema的width屬性賦值的時(shí)候，并不會(huì)改變hd中的屬性值，如下圖所示：

結(jié)構(gòu)體除了屬性的存儲(chǔ)更安全、效率更高之外，其函數(shù)的派發(fā)也更高效。由于結(jié)構(gòu)體不能被繼承，也就是結(jié)構(gòu)體的類型被final修飾，根據(jù)我們對(duì)于動(dòng)態(tài)派發(fā)及靜態(tài)派發(fā)的描述，那么其內(nèi)部函數(shù)應(yīng)該是屬于靜態(tài)派發(fā)，在編譯期就確定了函數(shù)的執(zhí)行方式，其函數(shù)的調(diào)用通過(guò)內(nèi)聯(lián)(inline)的方式進(jìn)行優(yōu)化，其內(nèi)存連續(xù)，減少了函數(shù)的尋址及內(nèi)存地址的偏移計(jì)算，其運(yùn)行相比于動(dòng)態(tài)派發(fā)更加高效。

協(xié)議類型(protocol type)

多態(tài)是面向?qū)ο蟮囊淮筇匦?，在結(jié)構(gòu)體中不能通過(guò)繼承或者引用語(yǔ)言的多態(tài)，swift就引入了協(xié)議(protocol)，通過(guò)協(xié)議來(lái)實(shí)現(xiàn)了結(jié)構(gòu)體的多態(tài)特性，這也是swift面向協(xié)議編程的核心所在。

對(duì)于類(class)來(lái)說(shuō)，每個(gè)類都會(huì)創(chuàng)建一個(gè)虛擬函數(shù)表指針，這個(gè)指針則指向一個(gè)v-table表，也就是虛函數(shù)表，表內(nèi)存儲(chǔ)著該類的函數(shù)指針數(shù)組，擁有繼承關(guān)系的子類會(huì)在虛函數(shù)表內(nèi)通過(guò)繼承順序(C++可以實(shí)現(xiàn)多繼承)去展示虛函數(shù)表指針。類里面方法的派發(fā)則是根據(jù)v-table表里面函數(shù)指針來(lái)進(jìn)行派發(fā)。

而結(jié)構(gòu)體(struct)沒有繼承，也就是說(shuō)結(jié)構(gòu)體并沒有v-table表用于函數(shù)的派發(fā)。為了實(shí)現(xiàn)這一特性，在結(jié)構(gòu)體的協(xié)議(protocol)的實(shí)現(xiàn)里添加了Protocol Witness Table用于管理協(xié)議類型的方法派發(fā)。

編譯過(guò)程

上面介紹了一些swift在數(shù)據(jù)結(jié)構(gòu)上的一些優(yōu)化，除了數(shù)據(jù)結(jié)構(gòu)優(yōu)化之外，swift在編譯過(guò)程也進(jìn)行了大量的優(yōu)化，其中最核心的優(yōu)化，是在編譯過(guò)程中引入SIL。

SIL，Swift Intermediate Language，是為了優(yōu)化swift編譯過(guò)程而設(shè)計(jì)的中間語(yǔ)言，主要包含了以下功能：

一系列的高級(jí)別優(yōu)化保障，用于對(duì)運(yùn)行時(shí)和診斷行為提供可預(yù)測(cè)的基線；
對(duì)swift語(yǔ)言數(shù)據(jù)流分析強(qiáng)制要求，對(duì)不滿足強(qiáng)制要求的問(wèn)題產(chǎn)生診斷。例如變量和結(jié)構(gòu)體必須明確初始化，代碼可達(dá)性即方法return的檢測(cè)，switch的覆蓋率；
確保高級(jí)別優(yōu)化。包含retain/release優(yōu)化，動(dòng)態(tài)方法的去虛擬化，閉包內(nèi)聯(lián)，內(nèi)存初始化提升和泛型方法實(shí)例化.
可用于分配"脆弱"內(nèi)聯(lián)的穩(wěn)定分配格式，將Swift庫(kù)組件的泛型優(yōu)化為二進(jìn)制。

Clang編譯流程

Clang編譯過(guò)程有以下幾個(gè)缺點(diǎn)：

與代碼與LLVM IR之間有巨大的抽象鴻溝(Wide abstraction gap between source and LLVM IR );
IR不適合源碼級(jí)別的分析(IR isn't suitable for source-level analysis );
CFG(Control Flow Graph)缺少精準(zhǔn)度(CFG lacks fidelity );
CFG偏離主道(CFG is off the hot path );
在CFG和IR降級(jí)中會(huì)出現(xiàn)重復(fù)分析(Duplicated effort in CFG and IR lowering)。

由于以上這些缺點(diǎn)，swift語(yǔ)言開發(fā)團(tuán)隊(duì)在開發(fā)過(guò)程中進(jìn)行了一系列的優(yōu)化，其中最關(guān)鍵的是引入SIL.

swift編譯流程

Swift作為一個(gè)高級(jí)別和安全的語(yǔ)言具有以下特點(diǎn)：

高級(jí)別語(yǔ)言

通過(guò)代碼充分的展示語(yǔ)言的特性(Move more of the language into code)
支持基于協(xié)議的泛型(Protocol-based generics)

安全語(yǔ)言

充分的數(shù)據(jù)流檢查：未初始化變量，函數(shù)返回處理檢測(cè)，這些項(xiàng)在檢測(cè)不合格時(shí)會(huì)產(chǎn)生對(duì)應(yīng)的編譯錯(cuò)誤(Uninitialized vars, unreachable code should be compiler errors)
邊界和溢出的檢測(cè)(Bounds and overflflow checks)

swift編譯流程：

Swift 源碼到IR之間的流程：

Swift 編譯過(guò)程引入SIL有幾個(gè)優(yōu)點(diǎn)：

完成的變數(shù)程序的語(yǔ)義(Fully represents program semantics );
既能進(jìn)行代碼的生成，又能進(jìn)行代碼分析(Designed for both code generation and analysis );
處在編譯管線的主通道(Sits on the hot path of the compiler pipeline );
架起橋梁連接源碼與LLVM，減少源碼與LLVM之間的抽象鴻溝(Bridges the abstraction gap between source and LLVM)

Swift編譯器的流程

Swift編譯器作為高級(jí)編譯器，具有以下嚴(yán)格的傳遞流程結(jié)構(gòu)。

Swift編譯器的流程如下：

Parse: 語(yǔ)法分析組件從Swift源碼構(gòu)成AST
語(yǔ)義分析組件對(duì)AST進(jìn)行類型檢查，并對(duì)其進(jìn)行類型信息注釋。
SILGen組件從AST形成"原始(raw)"SIL
一系列在生 SIL上運(yùn)行的,用于確定優(yōu)化和診斷合格，對(duì)不合格的代碼嵌入特定的語(yǔ)言診斷。這些操作一定會(huì)執(zhí)行,即使在-Onone選項(xiàng)下也不例外。之后產(chǎn)生正式(canonical) SIL.
一般情況下,是否在正式SIL上運(yùn)行SIL優(yōu)化是可選的,這個(gè)檢測(cè)可以提升結(jié)果可執(zhí)行文件的性能.可以通過(guò)優(yōu)化級(jí)別來(lái)控制,在-Onone模式下不會(huì)執(zhí)行.
IRGen會(huì)將正式SIL降級(jí)為L(zhǎng)LVM IR.
LLVM后端提供LLVM優(yōu)化,執(zhí)行LLVM代碼生成器并產(chǎn)生二進(jìn)制碼.

在上面的流程中，SIL對(duì)Swift的編譯過(guò)程進(jìn)行了一系列的優(yōu)化,即保證的代碼執(zhí)行的安全性,又提升了代碼執(zhí)行的效率.

結(jié)尾

上面從Swift語(yǔ)言設(shè)計(jì)的數(shù)據(jù)結(jié)構(gòu)及編譯流程等方面進(jìn)行了簡(jiǎn)單的分析，中間有很多細(xì)節(jié)沒有在文章里闡述特別清晰，如果有興趣了解更多，可以參考以下資料。