背景
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階段各過程的耗時一覽無余(Apple這個Demo有點過于夸張...)
2. main()階段
對于main()階段，主要是測量main()函數開始執行到didFinishLaunchingWithOptions執行結束的耗時，就需要自己插入代碼到工程中了。先在main()函數里用變量StartTime記錄當前時間：
CFAbsoluteTime StartTime;
int main(int argc, char * argv[]) {
StartTime = CFAbsoluteTimeGetCurrent();
再在AppDelegate.m文件中用extern聲明全局變量StartTime
extern CFAbsoluteTime StartTime;
最后在didFinishLaunchingWithOptions里，再獲取一下當前時間，與StartTime的差值即是main()階段運行耗時。
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越少越好。在這一步，我們可以做的優化有：
- 盡量不使用內嵌（embedded）的dylib，加載內嵌dylib性能開銷較大
- 合并已有的dylib和使用靜態庫（static archives），減少dylib的使用個數
- 懶加載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計算。
所以，指針數量越少越好。在這一步，我們可以做的優化有：
- 減少ObjC類（class）、方法（selector）、分類（category）的數量
- 減少C++虛函數的的數量（創建虛函數表有開銷）
- 使用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()函數。
在這一步，我們可以做的優化有：
- 少在類的+load方法里做事情，盡量把這些事情推遲到+initiailize
- 減少構造器函數個數，在構造器函數里少做些事情
- 減少C++靜態全局變量的個數
main()階段的優化
這一階段的優化主要是減少didFinishLaunchingWithOptions方法里的工作，在didFinishLaunchingWithOptions方法里，我們會創建應用的window，指定其rootViewController，調用window的makeKeyAndVisible方法讓其可見。由于業務需要，我們會初始化各個二方/三方庫，設置系統UI風格，檢查是否需要顯示引導頁、是否需要登錄、是否有新版本等，由于歷史原因，這里的代碼容易變得比較龐大，啟動耗時難以控制。
所以，滿足業務需要的前提下，didFinishLaunchingWithOptions在主線程里做的事情越少越好。在這一步，我們可以做的優化有：
- 梳理各個二方/三方庫，找到可以延遲加載的庫，做延遲加載處理，比如放到首頁控制器的
viewDidAppear方法里。 - 梳理業務邏輯，把可以延遲執行的邏輯，做延遲執行處理。比如檢查新版本、注冊推送通知等邏輯。
- 避免復雜/多余的計算。
- 避免在首頁控制器的
viewDidLoad和viewWillAppear做太多事情，這2個方法執行完，首頁控制器才能顯示，部分可以延遲創建的視圖應做延遲創建/懶加載處理。 - 采用性能更好的API。
- 首頁控制器用純代碼方式來構建。
阿里數據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階段耗時：
測試環境：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）
其中目前耗時最多的是快捷密碼驗證頁（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客戶端啟動速度優化
