應(yīng)用啟動(dòng)時(shí)間郎哭，直接影響用戶對(duì)一款應(yīng)用的判斷和使用體驗(yàn)垢村。頭條主app本身就包含非常多并且復(fù)雜度高的業(yè)務(wù)模塊（如新聞、視頻等）湃累，也接入了很多第三方的插件，這勢(shì)必會(huì)拖慢應(yīng)用的啟動(dòng)時(shí)間碍讨，本著精益求精的態(tài)度和對(duì)用戶體驗(yàn)的追求治力，我們希望在業(yè)務(wù)擴(kuò)張的同時(shí)最大程度的優(yōu)化啟動(dòng)時(shí)間。
技術(shù)調(diào)研
先說結(jié)論勃黍，t(App總啟動(dòng)時(shí)間) = t1(main()之前的加載時(shí)間) + t2(main()之后的加載時(shí)間)宵统。 t1 = 系統(tǒng)dylib(動(dòng)態(tài)鏈接庫)和自身App可執(zhí)行文件的加載；?
t2 = main方法執(zhí)行之后到AppDelegate類中的-?(BOOL)Application:(UIApplication *)Application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions方法執(zhí)行結(jié)束前這段時(shí)間覆获，主要是構(gòu)建第一個(gè)界面马澈，并完成渲染展示。
main()調(diào)用之前的加載過程
App開始啟動(dòng)后弄息，系統(tǒng)首先加載可執(zhí)行文件（自身App的所有.o文件的集合）痊班，然后加載動(dòng)態(tài)鏈接庫dyld，dyld是一個(gè)專門用來加載動(dòng)態(tài)鏈接庫的庫摹量。 執(zhí)行從dyld開始涤伐，dyld從可執(zhí)行文件的依賴開始, 遞歸加載所有的依賴動(dòng)態(tài)鏈接庫。?
動(dòng)態(tài)鏈接庫包括：iOS 中用到的所有系統(tǒng) framework缨称，加載OC runtime方法的libobjc凝果，系統(tǒng)級(jí)別的libSystem，例如libdispatch(GCD)和libsystem_blocks (Block)睦尽。
其實(shí)無論對(duì)于系統(tǒng)的動(dòng)態(tài)鏈接庫還是對(duì)于App本身的可執(zhí)行文件而言器净，他們都算是image（鏡像），而每個(gè)App都是以image(鏡像)為單位進(jìn)行加載的骂删，那么image究竟包括哪些呢掌动？
什么是image
1.executable可執(zhí)行文件 比如.o文件。?
2.dylib 動(dòng)態(tài)鏈接庫 framework就是動(dòng)態(tài)鏈接庫和相應(yīng)資源包含在一起的一個(gè)文件夾結(jié)構(gòu)宁玫。?
3.bundle 資源文件 只能用dlopen加載粗恢，不推薦使用這種方式加載。
除了我們App本身的可行性文件欧瘪，系統(tǒng)中所有的framework比如UIKit眷射、Foundation等都是以動(dòng)態(tài)鏈接庫的方式集成進(jìn)App中的。
系統(tǒng)使用動(dòng)態(tài)鏈接有幾點(diǎn)好處：
代碼共用：很多程序都動(dòng)態(tài)鏈接了這些 lib，但它們?cè)趦?nèi)存和磁盤中中只有一份妖碉。 易于維護(hù)：由于被依賴的 lib 是程序執(zhí)行時(shí)才鏈接的涌庭，所以這些 lib 很容易做更新，比如libSystem.dylib 是 libSystem.B.dylib 的替身欧宜，哪天想升級(jí)直接換成libSystem.C.dylib 然后再替換替身就行了坐榆。 減少可執(zhí)行文件體積：相比靜態(tài)鏈接，動(dòng)態(tài)鏈接在編譯時(shí)不需要打進(jìn)去冗茸，所以可執(zhí)行文件的體積要小很多席镀。
如上圖所示，不同進(jìn)程之間共用系統(tǒng)dylib的_TEXT區(qū)夏漱，但是各自維護(hù)對(duì)應(yīng)的_DATA區(qū)豪诲。
所有動(dòng)態(tài)鏈接庫和我們App中的靜態(tài)庫.a和所有類文件編譯后的.o文件最終都是由dyld(the dynamic link editor)，Apple的動(dòng)態(tài)鏈接器來加載到內(nèi)存中挂绰。每個(gè)image都是由一個(gè)叫做ImageLoader的類來負(fù)責(zé)加載（一一對(duì)應(yīng)）屎篱，那么ImageLoader又是什么呢？
什么是ImageLoader
image 表示一個(gè)二進(jìn)制文件(可執(zhí)行文件或 so 文件)葵蒂，里面是被編譯過的符號(hào)交播、代碼等，所以 ImageLoader 作用是將這些文件加載進(jìn)內(nèi)存刹勃，且每一個(gè)文件對(duì)應(yīng)一個(gè)ImageLoader實(shí)例來負(fù)責(zé)加載堪侯。?
兩步走： 在程序運(yùn)行時(shí)它先將動(dòng)態(tài)鏈接的 image 遞歸加載 (也就是上面測(cè)試棧中一串的遞歸調(diào)用的時(shí)刻)嚎尤。 再從可執(zhí)行文件 image 遞歸加載所有符號(hào)荔仁。
當(dāng)然所有這些都發(fā)生在我們真正的main函數(shù)執(zhí)行前。
動(dòng)態(tài)鏈接庫加載的具體流程
動(dòng)態(tài)鏈接庫的加載步驟具體分為5步：
load dylibs image 讀取庫鏡像文件?
Rebase image?
Bind image?
Objc setup?
initializers
load dylibs image
在每個(gè)動(dòng)態(tài)庫的加載過程中芽死， dyld需要：
分析所依賴的動(dòng)態(tài)庫?
找到動(dòng)態(tài)庫的mach-o文件?
打開文件?
驗(yàn)證文件?
在系統(tǒng)核心注冊(cè)文件簽名?
對(duì)動(dòng)態(tài)庫的每一個(gè)segment調(diào)用mmap()
通常的乏梁，一個(gè)App需要加載100到400個(gè)dylibs， 但是其中的系統(tǒng)庫被優(yōu)化关贵，可以很快的加載遇骑。 針對(duì)這一步驟的優(yōu)化有：
減少非系統(tǒng)庫的依賴?
合并非系統(tǒng)庫?
使用靜態(tài)資源，比如把代碼加入主程序
rebase/bind
由于ASLR(address space layout randomization)的存在揖曾，可執(zhí)行文件和動(dòng)態(tài)鏈接庫在虛擬內(nèi)存中的加載地址每次啟動(dòng)都不固定落萎，所以需要這2步來修復(fù)鏡像中的資源指針，來指向正確的地址炭剪。 rebase修復(fù)的是指向當(dāng)前鏡像內(nèi)部的資源指針练链； 而bind指向的是鏡像外部的資源指針。?
rebase步驟先進(jìn)行奴拦，需要把鏡像讀入內(nèi)存媒鼓，并以page為單位進(jìn)行加密驗(yàn)證，保證不會(huì)被篡改，所以這一步的瓶頸在IO绿鸣。bind在其后進(jìn)行疚沐，由于要查詢符號(hào)表，來指向跨鏡像的資源潮模，加上在rebase階段亮蛔，鏡像已被讀入和加密驗(yàn)證，所以這一步的瓶頸在于CPU計(jì)算擎厢。?
通過命令行可以查看相關(guān)的資源指針:
xcrun dyldinfo -rebase -bind -lazy_bind myApp.App/myApp
優(yōu)化該階段的關(guān)鍵在于減少__DATA segment中的指針數(shù)量尔邓。我們可以優(yōu)化的點(diǎn)有：
減少Objc類數(shù)量， 減少selector數(shù)量?
減少C++虛函數(shù)數(shù)量?
轉(zhuǎn)而使用swift stuct（其實(shí)本質(zhì)上就是為了減少符號(hào)的數(shù)量）
Objc setup
這一步主要工作是:
注冊(cè)O(shè)bjc類 (class registration)?
把category的定義插入方法列表 (category registration)?
保證每一個(gè)selector唯一 (selctor uniquing)
由于之前2步驟的優(yōu)化锉矢，這一步實(shí)際上沒有什么可做的梯嗽。
initializers
以上三步屬于靜態(tài)調(diào)整(fix-up)，都是在修改__DATA segment中的內(nèi)容沽损，而這里則開始動(dòng)態(tài)調(diào)整灯节，開始在堆和堆棧中寫入內(nèi)容。 在這里的工作有：
Objc的+load()函數(shù)?
C++的構(gòu)造函數(shù)屬性函數(shù) 形如attribute((constructor)) void DoSomeInitializationWork()?
非基本類型的C++靜態(tài)全局變量的創(chuàng)建(通常是類或結(jié)構(gòu)體)(non-trivial initializer) 比如一個(gè)全局靜態(tài)結(jié)構(gòu)體的構(gòu)建绵估，如果在構(gòu)造函數(shù)中有繁重的工作炎疆，那么會(huì)拖慢啟動(dòng)速度
Objc的load函數(shù)和C++的靜態(tài)構(gòu)造函數(shù)采用由底向上的方式執(zhí)行，來保證每個(gè)執(zhí)行的方法国裳，都可以找到所依賴的動(dòng)態(tài)庫形入。
上圖是在自定義的類XXViewController的+load方法斷點(diǎn)的調(diào)用堆棧，清楚的看到整個(gè)調(diào)用棧和順序：
dyld 開始將程序二進(jìn)制文件初始化?
交由 ImageLoader 讀取 image缝左，其中包含了我們的類亿遂、方法等各種符號(hào)?
由于 runtime 向 dyld 綁定了回調(diào)，當(dāng) image 加載到內(nèi)存后渺杉，dyld 會(huì)通知 runtime 進(jìn)行處理?
runtime 接手后調(diào)用 mapimages 做解析和處理蛇数，接下來 loadimages 中調(diào)用 callloadmethods 方法，遍歷所有加載進(jìn)來的 Class是越，按繼承層級(jí)依次調(diào)用 Class 的 +load 方法和其 Category 的 +load 方法
至此耳舅，可執(zhí)行文件中和動(dòng)態(tài)庫所有的符號(hào)(Class，Protocol倚评，Selector浦徊，IMP，…)都已經(jīng)按格式成功加載到內(nèi)存中天梧，被 runtime 所管理盔性，再這之后，runtime 的那些方法(動(dòng)態(tài)添加 Class腿倚、swizzle 等等才能生效)纯出。
整個(gè)事件由 dyld 主導(dǎo)蚯妇，完成運(yùn)行環(huán)境的初始化后，配合 ImageLoader 將二進(jìn)制文件按格式加載到內(nèi)存暂筝， 動(dòng)態(tài)鏈接依賴庫箩言，并由 runtime 負(fù)責(zé)加載成 objc 定義的結(jié)構(gòu)，所有初始化工作結(jié)束后焕襟，dyld 調(diào)用真正的 main 函數(shù)陨收。
如果程序剛剛被運(yùn)行過，那么程序的代碼會(huì)被dyld緩存鸵赖，因此即使殺掉進(jìn)程再次重啟加載時(shí)間也會(huì)相對(duì)快一點(diǎn)务漩，如果長(zhǎng)時(shí)間沒有啟動(dòng)或者當(dāng)前dyld的緩存已經(jīng)被其他應(yīng)用占據(jù)，那么這次啟動(dòng)所花費(fèi)的時(shí)間就要長(zhǎng)一點(diǎn)它褪，這就分別是熱啟動(dòng)和冷啟動(dòng)的概念饵骨，如下圖所示:
main()之前的加載時(shí)間如何衡量
那么問題就來了，那怎么衡量main()之前也就是time1的耗時(shí)呢茫打，蘋果官方提供了一種方法居触，那就是在真機(jī)調(diào)試的時(shí)候勾選dyldPRINTSTATISTICS選項(xiàng)。
會(huì)得到如下形式的輸出：
由此可見對(duì)于系統(tǒng)級(jí)別的動(dòng)態(tài)鏈接庫老赤，因?yàn)樘O果做了優(yōu)化轮洋，所以耗時(shí)并不多，在這個(gè)awesome的例子中抬旺，自身App中的代碼占用了整體時(shí)間的94.2% 我們應(yīng)用中一次典型的Log如下：
由此可見弊予，最多的用時(shí)還是在image加載和OC類的初始化，共占用總時(shí)長(zhǎng)的79.3%开财，精簡(jiǎn)framework的引入和OC類有優(yōu)化的空間汉柒。
總結(jié)一下：對(duì)于main()調(diào)用之前的耗時(shí)我們可以優(yōu)化的點(diǎn)有：
減少不必要的framework，因?yàn)閯?dòng)態(tài)鏈接比較耗時(shí)?
check framework應(yīng)當(dāng)設(shè)為optional和required床未，如果該framework在當(dāng)前App支持的所有iOS系統(tǒng)版本都存在竭翠，那么就設(shè)為required振坚，否則就設(shè)為optional薇搁，因?yàn)閛ptional會(huì)有些額外的檢查?
合并或者刪減一些OC類，關(guān)于清理項(xiàng)目中沒用到的類渡八，使用工具AppCode代碼檢查功能啃洋，查到當(dāng)前項(xiàng)目中沒有用到的類如下：
刪減一些無用的靜態(tài)變量?
刪減沒有被調(diào)用到或者已經(jīng)廢棄的方法
方法見：
?? http://stackoverflow.com/questions/35233564/how-to-find-unused-code-in-xcode-7
https://developer.Apple.com/library/ios/documentation/ToolsLanguages/Conceptual/Xcode_Overview/CheckingCodeCoverage.html
將不必須在+load方法中做的事情延遲到+initialize中?
盡量不要用C++虛函數(shù)(創(chuàng)建虛函數(shù)表有開銷)
main()調(diào)用之后的加載時(shí)間
在main()被調(diào)用之后，App的主要工作就是初始化必要的服務(wù)屎鳍，顯示首頁內(nèi)容等宏娄。而我們的優(yōu)化也是圍繞如何能夠快速展現(xiàn)首頁來開展。 App通常在AppDelegate類中的- (BOOL)Application:(UIApplication *)Application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions方法中創(chuàng)建首頁需要展示的view逮壁，然后在當(dāng)前runloop的末尾孵坚，主動(dòng)調(diào)用CA::Transaction::commit完成視圖的渲染。?
而視圖的渲染主要涉及三個(gè)階段：
準(zhǔn)備階段 這里主要是圖片的解碼?
布局階段 首頁所有UIView的- (void)layoutSubViews()運(yùn)行?
繪制階段 首頁所有UIView的- (void)drawRect:(CGRect)rect運(yùn)行?
再加上啟動(dòng)之后必要服務(wù)的啟動(dòng)、必要數(shù)據(jù)的創(chuàng)建和讀取卖宠，這些就是我們可以嘗試優(yōu)化的地方
因此巍杈，對(duì)于main()函數(shù)調(diào)用之前我們可以優(yōu)化的點(diǎn)有：
不使用xib，直接視用代碼加載首頁視圖?
NSUserDefaults實(shí)際上是在Library文件夾下會(huì)生產(chǎn)一個(gè)plist文件扛伍，如果文件太大的話一次能讀取到內(nèi)存中可能很耗時(shí)筷畦，這個(gè)影響需要評(píng)估，如果耗時(shí)很大的話需要拆分(需考慮老版本覆蓋安裝兼容問題)?
每次用NSLog方式打印會(huì)隱式的創(chuàng)建一個(gè)Calendar刺洒，因此需要?jiǎng)h減啟動(dòng)時(shí)各業(yè)務(wù)方打的log鳖宾，或者僅僅針對(duì)內(nèi)測(cè)版輸出log?
梳理應(yīng)用啟動(dòng)時(shí)發(fā)送的所有網(wǎng)絡(luò)請(qǐng)求，是否可以統(tǒng)一在異步線程請(qǐng)求
實(shí)測(cè)數(shù)據(jù)
建立了一個(gè)空的HelloWorld工程逆航，只加入了pods中的代碼鼎文，不包含主端的業(yè)務(wù)邏輯代碼，一次典型的冷啟動(dòng)基本接近2s iPhone6 iOS9.3.5系統(tǒng)測(cè)試主要時(shí)間在加載動(dòng)態(tài)庫因俐，類/方法的初始化還有符號(hào)地址綁定階段漂问。
一次典型的熱啟動(dòng)數(shù)據(jù)如下：可以看到因?yàn)橄到y(tǒng)做了緩存方面的優(yōu)化，比冷啟動(dòng)快了500ms加上頭條主端業(yè)務(wù)邏輯代碼之后一次典型的熱啟動(dòng)耗時(shí)2.1s女揭。
以上用時(shí)均為main()之前的加載耗時(shí)蚤假。
main()函數(shù)之后加載時(shí)間優(yōu)化記錄
NSUserDefaults是否是瓶頸
蘋果官方文檔提到NSUserDefaults加載的時(shí)候是整個(gè)plist配置文件全部load到內(nèi)存中，目前頭條主端當(dāng)中NSUserDefaults存儲(chǔ)了200多項(xiàng)緩存數(shù)據(jù)吧兔，因此懷疑可能拖慢啟動(dòng)速度磷仰，但是測(cè)試結(jié)果顯示并不會(huì)。 通過符號(hào)斷點(diǎn)+[NSUserDefaults standardUserDefaults]確定最早一次的+load()從執(zhí)行到結(jié)束耗時(shí)1.8ms境蔼，可見NSUserDefaults的初始化僅耗時(shí)1.8ms灶平，并不是啟動(dòng)耗時(shí)的瓶頸。
如何找到拖慢啟動(dòng)應(yīng)用時(shí)長(zhǎng)的瓶頸
為了找到瓶頸箍土，我們?cè)趩?dòng)之后的didFinishLauhcning方法開始執(zhí)行到首頁列表頁的NewsListViewController的viewDidAppear方法逢享，幾乎每個(gè)可能比較耗時(shí)的流程進(jìn)行拆分和統(tǒng)計(jì)，得到統(tǒng)計(jì)數(shù)據(jù)之后發(fā)現(xiàn)： 主要耗時(shí)在首頁UI構(gòu)造和渲染(storyboard加載吴藻，tabBar/topBar渲染瞒爬，開屏廣告加載/cell注冊(cè)/日志模塊初始化這幾個(gè)步驟)。
具體優(yōu)化點(diǎn)
因此沟堡，針對(duì)于今日頭條這個(gè)App我們可以優(yōu)化的點(diǎn)如下：
純代碼方式而不是storyboard加載首頁UI侧但。?
對(duì)didFinishLaunching里的函數(shù)考慮能否挖掘可以延遲加載或者懶加載，需要與各個(gè)業(yè)務(wù)方pm和rd共同check 對(duì)于一些已經(jīng)下線的業(yè)務(wù)航罗，刪減冗余代碼禀横。?
對(duì)于一些與UI展示無關(guān)的業(yè)務(wù)，如微博認(rèn)證過期檢查粥血、圖片最大緩存空間設(shè)置等做延遲加載
對(duì)實(shí)現(xiàn)了+load()方法的類進(jìn)行分析柏锄，盡量將load里的代碼延后調(diào)用酿箭。?
上面統(tǒng)計(jì)數(shù)據(jù)顯示展示feed的導(dǎo)航控制器頁面(NewsListViewController)比較耗時(shí)，對(duì)于viewDidLoad以及viewWillAppear方法中盡量去嘗試少做趾娃，晚做七问，不做。
優(yōu)化結(jié)果
之前曾經(jīng)有一位同事已經(jīng)做了一定的優(yōu)化茫舶，比如啟動(dòng)之后展示閃屏廣告圖的同時(shí)初始化首頁的列表頁械巡，當(dāng)廣告展示完成之后列表頁也就渲染完成了。經(jīng)過這一次優(yōu)化之后的main()之后的啟動(dòng)總時(shí)長(zhǎng)通過上線之后收集數(shù)據(jù)的驗(yàn)證達(dá)到了預(yù)期的效果饶氏。
本文轉(zhuǎn)載：https://techblog.toutiao.com/2017/01/17/iosspeed/
