APP啟動時間優(yōu)化
WWDC 2016 Session 406 內(nèi)容概括，講述如何優(yōu)化 App 的啟動時間。
App 運(yùn)行理論
main（） 執(zhí)行之前的事情
Mach-O 格式
虛擬內(nèi)存
Mach-O二進(jìn)制的加載
理論
Mach-O 虛擬內(nèi)存
Mach-O 術(shù)語
文件類型：
1.Executable - 應(yīng)用的主二進(jìn)制
2.Dylib - 動態(tài)庫 （稱為 DSO或者 DLL）
3.Bundle - 不能被鏈接的Dylib，只能在蕓像是使用 dlopen()加載，或者作為插件
Image - Executable ，Dylib 或者 Bundle
Framework - Dylib 中包含 resources and headers
Mach-O Image File
File 被或分為一些segments ，每個 segment 又被劃分成一些 section。
segment的名字是大寫，且控件大小為頁的整數(shù)。頁的大小和硬件有關(guān)， arm64 架構(gòu)一頁是 16KB，其余為 4KB。
section 雖然沒有整數(shù)倍頁大小的限制，但是 section 之間不會有重疊。
幾乎所有 Mach-O 都包含這三個段（segment）：
__TEXT,__DATA 和 __LINKEDIT.
__TEXT 包含 Mach header，被執(zhí)行的代碼和只讀常量（如C 字符串）。只讀可執(zhí)行（r-x）。
__DATA 包含全局變量，靜態(tài)變量等?？勺x寫（rw-）。
__LINKEDIT 包含了加載程序的『元數(shù)據(jù)』，比如函數(shù)的名稱和地址。只讀（r–）。
Mach-O Universal Files
FAT 二進(jìn)制文件，將多種架構(gòu)的 Mach-O 文件合并而成。它通過 Fat Header 來記錄不同架構(gòu)在文件中的偏移量，F(xiàn)at Header 占一頁的空間。
按分頁來存儲這些 segment 和 header 會浪費(fèi)空間，但這有利于虛擬內(nèi)存的實(shí)現(xiàn)。
虛擬內(nèi)存
虛擬內(nèi)存就是一層間接尋址（indirection）。軟件工程中有句格言就是任何問題都能通過添加一個間接層來解決。虛擬內(nèi)存解決的是管理所有進(jìn)程使用物理 RAM 的問題。通過添加間接層來讓每個進(jìn)程使用邏輯地址空間，它可以映射到 RAM 上的某個物理頁上。這種映射不是一對一的，邏輯地址可能映射不到 RAM 上，也可能有多個邏輯地址映射到同一個物理 RAM 上。針對第一種情況，當(dāng)進(jìn)程要存儲邏輯地址內(nèi)容時會觸發(fā) page fault；第二種情況就是多進(jìn)程共享內(nèi)存。
對于文件可以不用一次性讀入整個文件，可以使用分頁映射（mmap()）的方式讀取。也就是把文件某個片段映射到進(jìn)程邏輯內(nèi)存的某個頁上。當(dāng)某個想要讀取的頁沒有在內(nèi)存中，就會觸發(fā) page fault，內(nèi)核只會讀入那一頁，實(shí)現(xiàn)文件的懶加載。
也就是說 Mach-O 文件中的 __TEXT 段可以映射到多個進(jìn)程，并可以懶加載，且進(jìn)程之間共享內(nèi)存。__DATA 段是可讀寫的。這里使用到了 Copy-On-Write 技術(shù)，簡稱 COW。也就是多個進(jìn)程共享一頁內(nèi)存空間時，一旦有進(jìn)程要做寫操作，它會先將這頁內(nèi)存內(nèi)容復(fù)制一份出來，然后重新映射邏輯地址到新的 RAM 頁上。也就是這個進(jìn)程自己擁有了那頁內(nèi)存的拷貝。這就涉及到了 clean/dirty page 的概念。dirty page 含有進(jìn)程自己的信息，而 clean page 可以被內(nèi)核重新生成（重新讀磁盤）。所以 dirty page 的代價大于 clean page。
Mach-O 鏡像 加載
所以在多個進(jìn)程加載 Mach-O 鏡像時 __TEXT 和 __LINKEDIT 因為只讀，都是可以共享內(nèi)存的。而 __DATA 因為可讀寫，就會產(chǎn)生 dirty page。當(dāng) dyld 執(zhí)行結(jié)束后，__LINKEDIT 就沒用了，對應(yīng)的內(nèi)存頁會被回收。
安全
ASLR（Address Space Layout Randomization）：地址空間布局隨機(jī)化，鏡像會在隨機(jī)的地址上加載。這其實(shí)是一二十年前的舊技術(shù)了。
代碼簽名：可能我們認(rèn)為 Xcode 會把整個文件都做加密 hash 并用做數(shù)字簽名。其實(shí)為了在運(yùn)行時驗證 Mach-O 文件的簽名，并不是每次重復(fù)讀入整個文件，而是把每頁內(nèi)容都生成一個單獨(dú)的加密散列值，并存儲在 __LINKEDIT 中。這使得文件每頁的內(nèi)容都能及時被校驗確并保不被篡改。
從 exec() 到 main()
exec() 是一個系統(tǒng)調(diào)用。系統(tǒng)內(nèi)核把應(yīng)用映射到新的地址空間，且每次起始位置都是隨機(jī)的（因為使用 ASLR）。
并將起始位置到 0x000000 這段范圍的進(jìn)程權(quán)限都標(biāo)記為不可讀寫不可執(zhí)行。
如果是 32 位進(jìn)程，這個范圍至少是 4KB；
對于 64 位進(jìn)程則至少是 4GB。
NULL 指針引用和指針截斷誤差都是會被它捕獲。
dyld 加載 dylib 文件
Unix 的前二十年很安逸，因為那時還沒有發(fā)明動態(tài)鏈接庫。有了動態(tài)鏈接庫后，一個用于加載鏈接庫的幫助程序被創(chuàng)建。在蘋果的平臺里是 dyld，其他 Unix 系統(tǒng)也有 ld.so。 當(dāng)內(nèi)核完成映射進(jìn)程的工作后會將名字為 dyld 的Mach-O 文件映射到進(jìn)程中的隨機(jī)地址，它將 PC 寄存器設(shè)為 dyld 的地址并運(yùn)行。dyld 在應(yīng)用進(jìn)程中運(yùn)行的工作是加載應(yīng)用依賴的所有動態(tài)鏈接庫，準(zhǔn)備好運(yùn)行所需的一切，它擁有的權(quán)限跟應(yīng)用一樣。
下面的步驟構(gòu)成了 dyld 的時間線：
Load dylibs -> Rebase -> Bind -> ObjC -> Initializers
加載 Dylib
從主執(zhí)行文件的 header 獲取到需要加載的所依賴動態(tài)庫列表，而 header 早就被內(nèi)核映射過。
然后它需要找到每個 dylib，然后打開文件讀取文件起始位置，確保它是 Mach-O 文件。
接著會找到代碼簽名并將其注冊到內(nèi)核。
然后在 dylib 文件的每個 segment 上調(diào)用 mmap()。
遞歸加載
應(yīng)用所依賴的 dylib 文件可能會再依賴其他 dylib，所以 dyld 所需要加載的是動態(tài)庫列表一個遞歸依賴的集合。一般應(yīng)用會加載 100 到 400 個 dylib 文件，但大部分都是系統(tǒng) dylib，它們會被預(yù)先計算和緩存起來，加載速度很快。
Fix-ups
在加載所有的動態(tài)鏈接庫之后，它們只是處在相互獨(dú)立的狀態(tài)，需要將它們綁定起來，這就是 Fix-ups。代碼簽名使得我們不能修改指令，那樣就不能讓一個 dylib 的調(diào)用另一個 dylib。這時需要加很多間接層。
現(xiàn)代 code-gen 被叫做動態(tài) PIC（Position Independent Code），意味著代碼可以被加載到間接的地址上。當(dāng)調(diào)用發(fā)生時，code-gen 實(shí)際上會在 __DATA 段中創(chuàng)建一個指向被調(diào)用者的指針，然后加載指針并跳轉(zhuǎn)過去。
所以 dyld 做的事情就是修正（fix-up）指針和數(shù)據(jù)。Fix-up 有兩種類型，rebasing 和 binding。
Rebasing 和 Binding
Rebasing：在鏡像內(nèi)部調(diào)整指針的指向
Binding：將指針指向鏡像外部的內(nèi)容
可以通過命令行查看 rebase 和 bind 等信息：
xcrun dyldinfo -rebase -bind -lazy_bind myapp.app/myapp
通過這個命令可以查看所有的 Fix-up。rebase，bind，weak_bind，lazy_bind 都存儲在 __LINKEDIT 段中，并可通過 LC_DYLD_INFO_ONLY 查看各種信息的偏移量和大小。
建議用 MachOView 查看更加方便直觀。
Rebasing
在過去，會把 dylib 加載到指定地址，所有指針和數(shù)據(jù)對于代碼來說都是對的，dyld 就無需做任何 fix-up 了。如今用了 ASLR 后悔將 dylib 加載到新的隨機(jī)地址(actual_address)，這個隨機(jī)的地址跟代碼和數(shù)據(jù)指向的舊地址(preferred_address)會有偏差，dyld 需要修正這個偏差(slide)，做法就是將 dylib 內(nèi)部的指針地址都加上這個偏移量，偏移量的計算方法如下：
Slide = actual_address - preferred_address
然后就是重復(fù)不斷地對 __DATA 段中需要 rebase 的指針加上這個偏移量。這就又涉及到 page fault 和 COW。這可能會產(chǎn)生 I/O 瓶頸，但因為 rebase 的順序是按地址排列的，所以從內(nèi)核的角度來看這是個有次序的任務(wù)，它會預(yù)先讀入數(shù)據(jù)，減少 I/O 消耗。
Binding
Binding 是處理那些指向 dylib 外部的指針，它們實(shí)際上被符號（symbol）名稱綁定，也就是個字符串。之前提到 __LINKEDIT 段中也存儲了需要 bind 的指針，以及指針需要指向的符號。dyld 需要找到 symbol 對應(yīng)的實(shí)現(xiàn)，這需要很多計算，去符號表里查找。找到后會將內(nèi)容存儲到 __DATA 段中的那個指針中。Binding 看起來計算量比 Rebasing 更大，但其實(shí)需要的 I/O 操作很少，因為之前 Rebasing 已經(jīng)替 Binding 做過了。
ObjC Runtime
Objective-C 中有很多數(shù)據(jù)結(jié)構(gòu)都是靠 Rebasing 和 Binding 來修正（fix-up）的，比如 Class 中指向超類的指針和指向方法的指針。
ObjC 是個動態(tài)語言，可以用類的名字來實(shí)例化一個類的對象。這意味著 ObjC Runtime 需要維護(hù)一張映射類名與類的全局表。當(dāng)加載一個 dylib 時，其定義的所有的類都需要被注冊到這個全局表中。
C++ 中有個問題叫做易碎的基類（fragile base class）。ObjC 就沒有這個問題，因為會在加載時通過 fix-up 動態(tài)類中改變實(shí)例變量的偏移量。
在 ObjC 中可以通過定義類別（Category）的方式改變一個類的方法。有時你想要添加方法的類在另一個 dylib 中，而不在你的鏡像中（也就是對系統(tǒng)或別人的類動刀），這時也需要做些 fix-up。
ObjC 中的 selector 必須是唯一的。
Initializers
C++ 會為靜態(tài)創(chuàng)建的對象生成初始化器。而在 ObjC 中有個叫 +load 的方法，然而它被廢棄了，現(xiàn)在建議使用 +initialize。對比詳見：
http://stackoverflow.com/questions/13326435/nsobject-load-and-initialize-what-do-they-do
現(xiàn)在有了主執(zhí)行文件，一堆 dylib，其依賴關(guān)系構(gòu)成了一張巨大的有向圖，那么執(zhí)行初始化器的順序是什么？自頂向上！按照依賴關(guān)系，先加載葉子節(jié)點(diǎn)，然后逐步向上加載中間節(jié)點(diǎn)，直至最后加載根節(jié)點(diǎn)。這種加載順序確保了安全性，加載某個 dylib 前，其所依賴的其余 dylib 文件肯定已經(jīng)被預(yù)先加載。
最后 dyld 會調(diào)用 main() 函數(shù)。main() 會調(diào)用 UIApplicationMain()。
改善啟動時間
從點(diǎn)擊 App 圖標(biāo)到加載 App 閃屏之間會有個動畫，我們希望 App 啟動速度比這個動畫更快。
雖然不同設(shè)備上 App 啟動速度不一樣，但啟動時間最好控制在 400ms。
需要注意的是啟動時間一旦超過 20s，系統(tǒng)會認(rèn)為發(fā)生了死循環(huán)并殺掉 App 進(jìn)程。
當(dāng)然啟動時間最好以 App 所支持的最低配置設(shè)備為準(zhǔn)。
直到 applicationWillFinishLaunching 被調(diào)動，App 才啟動結(jié)束。
測量啟動時間
Warm launch: App 和數(shù)據(jù)已經(jīng)在內(nèi)存中
Cold launch: App 不在內(nèi)核緩沖存儲器中
冷啟動（Cold launch）耗時才是我們需要測量的重要數(shù)據(jù)，為了準(zhǔn)確測量冷啟動耗時，測量前需要重啟設(shè)備。
在 main() 方法執(zhí)行前測量是很難的，好在 dyld 提供了內(nèi)建的測量方法：在 Xcode 中 Edit scheme -> Run -> Auguments 將環(huán)境變量 DYLD_PRINT_STATISTICS 設(shè)為 1。
控制臺輸出的內(nèi)容如下：
優(yōu)化啟動時間
可以針對 App 啟動前的每個步驟進(jìn)行相應(yīng)的優(yōu)化工作。
加載 Dylib
之前提到過加載系統(tǒng)的 dylib 很快，因為有優(yōu)化。但加載內(nèi)嵌（embedded）的 dylib 文件很占時間，所以盡可能把多個內(nèi)嵌 dylib 合并成一個來加載，或者使用 static archive。使用 dlopen() 來在運(yùn)行時懶加載是不建議的，這么做可能會帶來一些問題，并且總的開銷更大。
Rebase/Binding
之前提過 Rebaing 消耗了大量時間在 I/O 上，而在之后的 Binding 就不怎么需要 I/O 了，而是將時間耗費(fèi)在計算上。所以這兩個步驟的耗時是混在一起的。
之前說過可以從查看 __DATA 段中需要修正（fix-up）的指針，所以減少指針數(shù)量才會減少這部分工作的耗時。
對于 ObjC 來說就是減少 Class,selector 和 category 這些元數(shù)據(jù)的數(shù)量。
從編碼原則和設(shè)計模式之類的理論都會鼓勵大家多寫精致短小的類和方法，并將每部分方法獨(dú)立出一個類別，其實(shí)這會增加啟動時間。
對于 C++ 來說需要減少虛方法，因為虛方法會創(chuàng)建 vtable，這也會在 __DATA 段中創(chuàng)建結(jié)構(gòu)。
雖然 C++ 虛方法對啟動耗時的增加要比 ObjC 元數(shù)據(jù)要少，但依然不可忽視。
最后推薦使用 Swift 結(jié)構(gòu)體，它需要 fix-up 的內(nèi)容較少。
ObjC Setup
針對這步所能事情很少，幾乎都靠 Rebasing 和 Binding 步驟中減少所需 fix-up 內(nèi)容。因為前面的工作也會使得這步耗時減少。
Initializer
顯式初始化
使用 +initialize 來替代 +load
不要使用 atribute((constructor)) 將方法顯式標(biāo)記為初始化器，而是讓初始化方法調(diào)用時才執(zhí)行。
比如使用
dispatch_once(),
pthread_once() 或
std::once()。
也就是在第一次使用時才初始化，推遲了一部分工作耗時。
隱式初始化
對于帶有復(fù)雜（non-trivial）構(gòu)造器的 C++ 靜態(tài)變量：
在調(diào)用的地方使用初始化器。
只用簡單值類型賦值（POD:Plain Old Data），這樣靜態(tài)鏈接器會預(yù)先計算 __DATA 中的數(shù)據(jù)，無需再進(jìn)行 fix-up 工作。
使用編譯器 warning 標(biāo)志 -Wglobal-constructors 來發(fā)現(xiàn)隱式初始化代碼。
使用 Swift 重寫代碼，因為 Swift 已經(jīng)預(yù)先處理好了，強(qiáng)力推薦。
不要在初始化方法中調(diào)用 dlopen()，對性能有影響。因為 dyld 在 App 開始前運(yùn)行，由于此時是單線程運(yùn)行所以系統(tǒng)會取消加鎖，但 dlopen() 開啟了多線程，系統(tǒng)不得不加鎖，這就嚴(yán)重影響了性能，還可能會造成死鎖以及產(chǎn)生未知的后果。所以也不要在初始化器中創(chuàng)建線程。
相關(guān)鏈接
Optimizing App Startup Time
https://developer.apple.com/videos/play/wwdc2016/406/
