iOS啓動速度優化

背景

7月26號咱們阿里數據iOS端發佈了4.4.0版本，此次版本主要是優化了性能，其中main()階段的啓動耗時優化成果比較明顯，從以前的0.5-0.7秒，下降爲目前的0.1-0.2秒（main()第一行代碼到didFinishLaunchingWithOptions最後一行代碼的耗時），用戶體驗提高明顯。在這裏梳理一下優化的一些經驗，歡迎你們一塊兒交流。

應用啓動流程

iOS應用的啓動可分爲pre-main階段和main()階段，其中系統作的事情依次是：

1. pre-main階段

1.1. 加載應用的可執行文件

1.2. 加載動態連接庫加載器dyld（dynamic loader）

1.3. dyld遞歸加載應用全部依賴的dylib（dynamic library 動態連接庫）

2. main()階段

2.1. dyld調用main() 

2.2. 調用UIApplicationMain() 

2.3. 調用applicationWillFinishLaunching

2.4. 調用didFinishLaunchingWithOptions

啓動耗時的測量

在進行優化以前，咱們首先應該能測量各階段的耗時。

1. pre-main階段

對於pre-main階段，Apple提供了一種測量方法，在 Xcode 中 Edit scheme -> Run -> Auguments 將環境變量DYLD_PRINT_STATISTICS 設爲1 ：

pre-main階段啓動耗時測量.png

設置好後把程序跑起來，控制檯會有以下輸出，pre-main階段各過程的耗時盡收眼底(Apple這個Demo有點過於誇張...)

pre-main階段啓動耗時測量.png

2. main()階段

對於main()階段，主要是測量main()函數開始執行到didFinishLaunchingWithOptions執行結束的耗時，就須要本身插入代碼到工程中了。先在main()函數裏用變量StartTime記錄當前時間：

1 2 3

CFAbsoluteTime StartTime; int  main( int  argc, char * argv[]) {        StartTime = CFAbsoluteTimeGetCurrent();

再在AppDelegate.m文件中用extern聲明全局變量StartTime

1	extern CFAbsoluteTime StartTime;

最後在didFinishLaunchingWithOptions裏，再獲取一下當前時間，與StartTime的差值便是main()階段運行耗時。

1	double launchTime = (CFAbsoluteTimeGetCurrent() - StartTime);

pre-main階段的優化

要對pre-main階段的耗時作優化，須要再學習下dyld加載的過程，根據Apple在WWDC上的介紹，dyld的加載主要分爲4步：

1. Load dylibs

這一階段dyld會分析應用依賴的dylib，找到其mach-o文件，打開和讀取這些文件並驗證其有效性，接着會找到代碼簽名註冊到內核，最後對dylib的每個segment調用mmap()。

通常狀況下，iOS應用會加載100-400個dylibs，其中大部分是系統庫，這部分dylib的加載系統已經作了優化。

因此，依賴的dylib越少越好。在這一步，咱們能夠作的優化有：

1. 儘可能不使用內嵌（embedded）的dylib，加載內嵌dylib性能開銷較大

2. 合併已有的dylib和使用靜態庫（static archives），減小dylib的使用個數

3. 懶加載dylib，可是要注意dlopen()可能形成一些問題，且實際上懶加載作的工做會更多

2. Rebase/Bind

在dylib的加載過程當中，系統爲了安全考慮，引入了ASLR（Address Space Layout Randomization）技術和代碼簽名。因爲ASLR的存在，鏡像（Image，包括可執行文件、dylib和bundle）會在隨機的地址上加載，和以前指針指向的地址（preferred_address）會有一個誤差（slide），dyld須要修正這個誤差，來指向正確的地址。

Rebase在前，Bind在後，Rebase作的是將鏡像讀入內存，修正鏡像內部的指針，性能消耗主要在IO。Bind作的是查詢符號表，設置指向鏡像外部的指針，性能消耗主要在CPU計算。

因此，指針數量越少越好。在這一步，咱們能夠作的優化有：

1. 減小ObjC類（class）、方法（selector）、分類（category）的數量

2. 減小C++虛函數的的數量（建立虛函數表有開銷）

3. 使用Swift structs（內部作了優化，符號數量更少）

3. Objc setup

大部分ObjC初始化工做已經在Rebase/Bind階段作完了，這一步dyld會註冊全部聲明過的ObjC類，將分類插入到類的方法列表裏，再檢查每一個selector的惟一性。

在這一步倒沒什麼優化可作的，Rebase/Bind階段優化好了，這一步的耗時也會減小。

4. Initializers

到了這一階段，dyld開始運行程序的初始化函數，調用每一個Objc類和分類的+load方法，調用C/C++ 中的構造器函數（用attribute((constructor))修飾的函數），和建立非基本類型的C++靜態全局變量。Initializers階段執行完後，dyld開始調用main()函數。

在這一步，咱們能夠作的優化有：

1. 少在類的+load方法裏作事情，儘可能把這些事情推遲到+initiailize

2. 減小構造器函數個數，在構造器函數裏少作些事情

3. 減小C++靜態全局變量的個數

main()階段的優化

這一階段的優化主要是減小didFinishLaunchingWithOptions方法裏的工做，在didFinishLaunchingWithOptions方法裏，咱們會建立應用的window，指定其rootViewController，調用window的makeKeyAndVisible方法讓其可見。因爲業務須要，咱們會初始化各個二方/三方庫，設置系統UI風格，檢查是否須要顯示引導頁、是否須要登陸、是否有新版本等，因爲歷史緣由，這裏的代碼容易變得比較龐大，啓動耗時難以控制。

因此，知足業務須要的前提下，didFinishLaunchingWithOptions在主線程裏作的事情越少越好。在這一步，咱們能夠作的優化有：

1. 梳理各個二方/三方庫，找到能夠延遲加載的庫，作延遲加載處理，好比放到首頁控制器的viewDidAppear方法裏。

2. 梳理業務邏輯，把能夠延遲執行的邏輯，作延遲執行處理。好比檢查新版本、註冊推送通知等邏輯。

3. 避免複雜/多餘的計算。

4. 避免在首頁控制器的viewDidLoad和viewWillAppear作太多事情，這2個方法執行完，首頁控制器才能顯示，部分能夠延遲建立的視圖應作延遲建立/懶加載處理。

5. 採用性能更好的API。

6. 首頁控制器用純代碼方式來構建。

阿里數據iOS端優化實踐

在以上的認知指導下，阿里數據iOS端開始着手優化，在pre-main階段和main()階段分別作了一系列優化，取得了必定的成果。

1. pre-main階段的優化

1.1. 排查無用的dylib，移除再也不使用的libicucore.tbd

1.2. 刪除無用文件&庫，合併重複文件（多個重複的分類）。移除再也不使用的庫UMSocial、PSTCollectionView、MCSwipeTableViewCell，移除功能重複的庫Mantle。

1.3. 梳理各個類的+load方法，將多個類中+load方法作的事延遲到+initiailize裏去作。

優化前pre-main階段耗時:

優化前pre-main階段耗時.png

優化後pre-main階段耗時：

優化後pre-main階段耗時.png

測試環境：Xcode8.3.3 iOS10.2的模擬器，熱啓動。

備註：測試發現，pre-main階段耗時有必定波動，冷啓動時波動更大，這裏截圖貼的是一箇中位數水平。

能夠看到熱啓動下，pre-main階段耗時有必定降低。

2. main()階段的優化

2.1. 去掉其中100ms的dispatch_after...檢查代碼發現以前會故意讓啓動圖多顯示100ms，不知道是什麼邏輯...

2.2. 將多個二方/三方庫延遲加載。包括TBCrashReporter、TBAccsSDK、UT、TRemoteDebugger、ATSDK等。

2.3. 將若干系統UI配置、業務邏輯延遲執行。包括註冊推送、檢查新版本、更新Orange配置等。

2.4. 避免多餘的計算。以前會先後兩次獲取是否要顯示廣告圖，每次獲取都須要反序列化Orange中的配置信息，再比較配置中的開始/結束時間，大約耗時20ms。目前的解決方案是第一次計算後，用一個BOOL屬性緩存起來，下次直接取用。

2.5. 延遲加載&懶加載部分視圖。快捷密碼驗證頁是啓動圖消失後用戶看到的第一個頁面，這個頁面因爲涉及到圖片的解碼、多個視圖的建立&佈局，viewDidLoad階段會耗時100ms左右。目前的解決方案是把其中密碼輸入框視圖延遲到viewDidAppear里加載，對密碼錯誤提示視圖作成懶加載，耗時下降到30m左右。

經過instruments的Time Profiler分析，優化後啓動速度有明顯提高，didFinishLaunchingWithOptions耗時在75ms左右（iPhone6s iOS10.3.3）

啓動耗時..png

其中目前耗時最多的是快捷密碼驗證頁（PAPasscodeViewController）的建立&佈局，其次是DTLaunchViewControlle裏對是否要顯示廣告頁的判斷代碼。能夠看到PAPasscodeViewController的viewDidAppear耗時了78ms，但已經沒有太大關係，此時用戶已經看到了頁面，準備去驗證指紋/密碼了。

總結&後續規劃

1. 總結

總結起來，好像啓動速度優化就一句話：讓系統在啓動期間少作一些事。固然咱們得先清楚工程裏作的哪些事是在啓動期間作的、對啓動速度的影響有多大，而後case by case地分析工程代碼，經過放到子線程、延遲加載、懶加載等方式讓系統在啓動期間更輕鬆些。

2. 後續規劃

2.1. 替代部分龐大的庫，採用更輕量級的解決方案。

2.2. 整理代碼，去除重複的實現，避免出現功能重複的類&分類&方法。

2.3. 梳理和移除已經下線的業務涉及的類&分類&方法。

2.4. 監控好灰度版本啓動速度的變化趨勢，儘早發現&解決拖慢啓動速度的問題。

參考資料

• WWDC Optimizing App Startup Time

• attribute 總結

• dyld 加載 Mach-O

• 優化 App 的啓動時間

• 今日頭條iOS客戶端啓動速度優化