原文鏈接:http://www.reibang.com/p/f29b59f4c2b9
背景
7月26號我們阿里數(shù)據(jù)iOS端發(fā)布了4.4.0版本，這次版本主要是優(yōu)化了性能胯盯，其中main()階段的啟動耗時優(yōu)化成果比較明顯，從之前的0.5-0.7秒桑寨，降低為目前的0.1-0.2秒（main()第一行代碼到didFinishLaunchingWithOptions最后一行代碼的耗時）梦染，用戶體驗提升明顯侵贵。在這里梳理一下優(yōu)化的一些經(jīng)驗，歡迎大家一起交流贴彼。
應(yīng)用啟動流程
iOS應(yīng)用的啟動可分為pre-main階段和main()階段潜腻，其中系統(tǒng)做的事情依次是：
- pre-main階段
1.1. 加載應(yīng)用的可執(zhí)行文件
1.2. 加載動態(tài)鏈接庫加載器dyld（dynamic loader）
1.3. dyld遞歸加載應(yīng)用所有依賴的dylib（dynamic library 動態(tài)鏈接庫）
- main()階段
2.1. dyld調(diào)用main()
2.2. 調(diào)用UIApplicationMain()
2.3. 調(diào)用applicationWillFinishLaunching
2.4. 調(diào)用didFinishLaunchingWithOptions
啟動耗時的測量
在進(jìn)行優(yōu)化之前，我們首先應(yīng)該能測量各階段的耗時器仗。
1. pre-main階段
對于pre-main階段砾赔，Apple提供了一種測量方法，在 Xcode 中 Edit scheme -> Run -> Auguments 將環(huán)境變量DYLD_PRINT_STATISTICS 設(shè)為1 ：
設(shè)置好后把程序跑起來青灼，控制臺會有如下輸出暴心，pre-main階段各過程的耗時一覽無余(Apple這個Demo有點過于夸張...)
2. main()階段
對于main()階段，主要是測量main()函數(shù)開始執(zhí)行到didFinishLaunchingWithOptions執(zhí)行結(jié)束的耗時杂拨，就需要自己插入代碼到工程中了专普。先在main()函數(shù)里用變量StartTime記錄當(dāng)前時間：
CFAbsoluteTime StartTime;
int main(int argc, char * argv[]) {
StartTime = CFAbsoluteTimeGetCurrent();
再在AppDelegate.m文件中用extern聲明全局變量StartTime
extern CFAbsoluteTime StartTime;
最后在didFinishLaunchingWithOptions里，再獲取一下當(dāng)前時間弹沽，與StartTime的差值即是main()階段運行耗時檀夹。
double launchTime = (CFAbsoluteTimeGetCurrent() - StartTime);
pre-main階段的優(yōu)化
要對pre-main階段的耗時做優(yōu)化，需要再學(xué)習(xí)下dyld加載的過程策橘，根據(jù)Apple在WWDC上的介紹炸渡，dyld的加載主要分為4步：
1. Load dylibs
這一階段dyld會分析應(yīng)用依賴的dylib，找到其mach-o文件丽已，打開和讀取這些文件并驗證其有效性蚌堵，接著會找到代碼簽名注冊到內(nèi)核，最后對dylib的每一個segment調(diào)用mmap()沛婴。
一般情況下吼畏，iOS應(yīng)用會加載100-400個dylibs，其中大部分是系統(tǒng)庫嘁灯，這部分dylib的加載系統(tǒng)已經(jīng)做了優(yōu)化泻蚊。
所以，依賴的dylib越少越好丑婿。在這一步性雄，我們可以做的優(yōu)化有：
盡量不使用內(nèi)嵌（embedded）的dylib没卸，加載內(nèi)嵌dylib性能開銷較大
合并已有的dylib和使用靜態(tài)庫（static archives），減少dylib的使用個數(shù)
懶加載dylib秒旋，但是要注意dlopen()可能造成一些問題约计，且實際上懶加載做的工作會更多
2. Rebase/Bind
在dylib的加載過程中，系統(tǒng)為了安全考慮滩褥，引入了ASLR（Address Space Layout Randomization）技術(shù)和代碼簽名病蛉。由于ASLR的存在，鏡像（Image瑰煎，包括可執(zhí)行文件铺然、dylib和bundle）會在隨機的地址上加載，和之前指針指向的地址（preferred_address）會有一個偏差（slide）酒甸，dyld需要修正這個偏差魄健，來指向正確的地址。
Rebase在前插勤，Bind在后沽瘦，Rebase做的是將鏡像讀入內(nèi)存，修正鏡像內(nèi)部的指針农尖，性能消耗主要在IO析恋。Bind做的是查詢符號表，設(shè)置指向鏡像外部的指針盛卡，性能消耗主要在CPU計算助隧。
所以，指針數(shù)量越少越好滑沧。在這一步并村，我們可以做的優(yōu)化有：
減少ObjC類（class）、方法（selector）滓技、分類（category）的數(shù)量
減少C++虛函數(shù)的的數(shù)量（創(chuàng)建虛函數(shù)表有開銷）
使用Swift structs（內(nèi)部做了優(yōu)化哩牍，符號數(shù)量更少）
3. Objc setup
大部分ObjC初始化工作已經(jīng)在Rebase/Bind階段做完了，這一步dyld會注冊所有聲明過的ObjC類令漂，將分類插入到類的方法列表里膝昆，再檢查每個selector的唯一性。
在這一步倒沒什么優(yōu)化可做的洗显，Rebase/Bind階段優(yōu)化好了外潜，這一步的耗時也會減少。
4. Initializers
到了這一階段挠唆，dyld開始運行程序的初始化函數(shù)，調(diào)用每個Objc類和分類的+load方法嘱吗，調(diào)用C/C++ 中的構(gòu)造器函數(shù)（用attribute((constructor))修飾的函數(shù)）玄组，和創(chuàng)建非基本類型的C++靜態(tài)全局變量滔驾。Initializers階段執(zhí)行完后，dyld開始調(diào)用main()函數(shù)俄讹。
在這一步哆致，我們可以做的優(yōu)化有：
少在類的+load方法里做事情，盡量把這些事情推遲到+initiailize
減少構(gòu)造器函數(shù)個數(shù)患膛，在構(gòu)造器函數(shù)里少做些事情
減少C++靜態(tài)全局變量的個數(shù)
main()階段的優(yōu)化
這一階段的優(yōu)化主要是減少didFinishLaunchingWithOptions方法里的工作摊阀，在didFinishLaunchingWithOptions方法里，我們會創(chuàng)建應(yīng)用的window踪蹬，指定其rootViewController胞此，調(diào)用window的makeKeyAndVisible方法讓其可見。由于業(yè)務(wù)需要跃捣，我們會初始化各個二方/三方庫漱牵，設(shè)置系統(tǒng)UI風(fēng)格，檢查是否需要顯示引導(dǎo)頁疚漆、是否需要登錄酣胀、是否有新版本等，由于歷史原因娶聘，這里的代碼容易變得比較龐大闻镶，啟動耗時難以控制。
所以丸升，滿足業(yè)務(wù)需要的前提下铆农，didFinishLaunchingWithOptions在主線程里做的事情越少越好。在這一步发钝，我們可以做的優(yōu)化有：
梳理各個二方/三方庫顿涣，找到可以延遲加載的庫，做延遲加載處理酝豪，比如放到首頁控制器的viewDidAppear方法里涛碑。
梳理業(yè)務(wù)邏輯，把可以延遲執(zhí)行的邏輯孵淘，做延遲執(zhí)行處理蒲障。比如檢查新版本、注冊推送通知等邏輯瘫证。
避免復(fù)雜/多余的計算揉阎。
避免在首頁控制器的viewDidLoad和viewWillAppear做太多事情，這2個方法執(zhí)行完背捌，首頁控制器才能顯示毙籽，部分可以延遲創(chuàng)建的視圖應(yīng)做延遲創(chuàng)建/懶加載處理。
采用性能更好的API毡庆。
首頁控制器用純代碼方式來構(gòu)建坑赡。
阿里數(shù)據(jù)iOS端優(yōu)化實踐
在以上的認(rèn)知指導(dǎo)下烙如，阿里數(shù)據(jù)iOS端開始著手優(yōu)化，在pre-main階段和main()階段分別做了一系列優(yōu)化毅否，取得了一定的成果亚铁。
1. pre-main階段的優(yōu)化
1.1. 排查無用的dylib，移除不再使用的libicucore.tbd
1.2. 刪除無用文件&庫螟加，合并重復(fù)文件（多個重復(fù)的分類）徘溢。移除不再使用的庫UMSocial、PSTCollectionView捆探、MCSwipeTableViewCell然爆，移除功能重復(fù)的庫Mantle。
1.3. 梳理各個類的+load方法徐许，將多個類中+load方法做的事延遲到+initiailize里去做施蜜。
優(yōu)化前pre-main階段耗時:
優(yōu)化后pre-main階段耗時：
測試環(huán)境：Xcode8.3.3 iOS10.2的模擬器，熱啟動雌隅。
備注：測試發(fā)現(xiàn)翻默，pre-main階段耗時有一定波動，冷啟動時波動更大恰起，這里截圖貼的是一個中位數(shù)水平修械。
可以看到熱啟動下，pre-main階段耗時有一定下降检盼。
2. main()階段的優(yōu)化
2.1. 去掉其中100ms的dispatch_after...檢查代碼發(fā)現(xiàn)之前會故意讓啟動圖多顯示100ms肯污，不知道是什么邏輯...
2.2. 將多個二方/三方庫延遲加載。包括TBCrashReporter吨枉、TBAccsSDK蹦渣、UT、TRemoteDebugger貌亭、ATSDK等柬唯。
2.3. 將若干系統(tǒng)UI配置、業(yè)務(wù)邏輯延遲執(zhí)行圃庭。包括注冊推送锄奢、檢查新版本、更新Orange配置等剧腻。
2.4. 避免多余的計算拘央。之前會前后兩次獲取是否要顯示廣告圖，每次獲取都需要反序列化Orange中的配置信息书在，再比較配置中的開始/結(jié)束時間灰伟，大約耗時20ms。目前的解決方案是第一次計算后儒旬，用一個BOOL屬性緩存起來袱箱，下次直接取用遏乔。
2.5. 延遲加載&懶加載部分視圖义矛》⒈剩快捷密碼驗證頁是啟動圖消失后用戶看到的第一個頁面，這個頁面由于涉及到圖片的解碼凉翻、多個視圖的創(chuàng)建&布局了讨，viewDidLoad階段會耗時100ms左右。目前的解決方案是把其中密碼輸入框視圖延遲到viewDidAppear里加載制轰，對密碼錯誤提示視圖做成懶加載前计，耗時降低到30m左右。
通過instruments的Time Profiler分析垃杖，優(yōu)化后啟動速度有明顯提升男杈，didFinishLaunchingWithOptions耗時在75ms左右（iPhone6s iOS10.3.3）
其中目前耗時最多的是快捷密碼驗證頁（PAPasscodeViewController）的創(chuàng)建&布局，其次是DTLaunchViewControlle里對是否要顯示廣告頁的判斷代碼调俘×姘簦可以看到PAPasscodeViewController的viewDidAppear耗時了78ms，但已經(jīng)沒有太大關(guān)系彩库，此時用戶已經(jīng)看到了頁面肤无，準(zhǔn)備去驗證指紋/密碼了。
總結(jié)&后續(xù)規(guī)劃
1. 總結(jié)
總結(jié)起來骇钦，好像啟動速度優(yōu)化就一句話：讓系統(tǒng)在啟動期間少做一些事宛渐。當(dāng)然我們得先清楚工程里做的哪些事是在啟動期間做的、對啟動速度的影響有多大眯搭，然后case by case地分析工程代碼窥翩，通過放到子線程、延遲加載鳞仙、懶加載等方式讓系統(tǒng)在啟動期間更輕松些寇蚊。
2. 后續(xù)規(guī)劃
2.1. 替代部分龐大的庫，采用更輕量級的解決方案繁扎。
2.2. 整理代碼幔荒，去除重復(fù)的實現(xiàn)，避免出現(xiàn)功能重復(fù)的類&分類&方法梳玫。
2.3. 梳理和移除已經(jīng)下線的業(yè)務(wù)涉及的類&分類&方法爹梁。
2.4. 監(jiān)控好灰度版本啟動速度的變化趨勢，盡早發(fā)現(xiàn)&解決拖慢啟動速度的問題提澎。
參考資料
