本文轉載：https://techblog.toutiao.com/2017/01/17/iosspeed/
應用啟動時間，直接影響使用者對一款應用的判斷和使用體驗。頭條主app本身就包含非常多并且複雜度高的業務子產品（如新聞、視訊等），也接入了很多第三方的插件，這勢必會拖慢應用的啟動時間，本着精益求精的态度和對使用者體驗的追求，我們希望在業務擴張的同時最大程度的優化啟動時間。
技術調研
先說結論，t(App總啟動時間) = t1(main()之前的加載時間) + t2(main()之後的加載時間)。 t1 = 系統dylib(動态連結庫)和自身App可執行檔案的加載；
t2 = main方法執行之後到AppDelegate類中的-
(BOOL)Application:(UIApplication *)Application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
方法執行結束前這段時間，主要是建構第一個界面，并完成渲染展示。
main()調用之前的加載過程
App開始啟動後， 系統首先加載可執行檔案（自身App的所有.o檔案的集合），然後加載動态連結庫dyld，dyld是一個專門用來加載動态連結庫的庫。 執行從dyld開始，dyld從可執行檔案的依賴開始, 遞歸加載所有的依賴動态連結庫。
動态連結庫包括：iOS 中用到的所有系統 framework，加載OC runtime方法的libobjc，系統級别的libSystem，例如libdispatch(GCD)和libsystem_blocks (Block)。
其實無論對于系統的動态連結庫還是對于App本身的可執行檔案而言，他們都算是image（鏡像），而每個App都是以image(鏡像)為機關進行加載的，那麼image究竟包括哪些呢？
什麼是image
1.executable可執行檔案 比如.o檔案。
2.dylib 動态連結庫 framework就是動态連結庫和相應資源包含在一起的一個檔案夾結構。
3.bundle 資源檔案 隻能用dlopen加載，不推薦使用這種方式加載。
除了我們App本身的可行性檔案，系統中所有的framework比如UIKit、Foundation等都是以動态連結庫的方式內建進App中的。
系統使用動态連結有幾點好處：
代碼共用：很多程式都動态連結了這些 lib，但它們在記憶體和磁盤中中隻有一份。 易于維護：由于被依賴的 lib 是程式執行時才連結的，是以這些 lib 很容易做更新，比如libSystem.dylib 是 libSystem.B.dylib 的替身，哪天想更新直接換成libSystem.C.dylib 然後再替換替身就行了。 減少可執行檔案體積：相比靜态連結，動态連結在編譯時不需要打進去，是以可執行檔案的體積要小很多。
如上圖所示，不同程序之間共用系統dylib的
_TEXT
區，但是各自維護對應的
_DATA
區。
所有動态連結庫和我們App中的靜态庫.a和所有類檔案編譯後的.o檔案最終都是由dyld(the dynamic link editor)，Apple的動态連結器來加載到記憶體中。每個image都是由一個叫做ImageLoader的類來負責加載（一一對應），那麼ImageLoader又是什麼呢？
什麼是ImageLoader
image 表示一個二進制檔案(可執行檔案或 so 檔案)，裡面是被編譯過的符号、代碼等，是以 ImageLoader 作用是将這些檔案加載進記憶體，且每一個檔案對應一個ImageLoader執行個體來負責加載。
兩步走： 在程式運作時它先将動态連結的 image 遞歸加載 (也就是上面測試棧中一串的遞歸調用的時刻)。 再從可執行檔案 image 遞歸加載所有符号。
當然所有這些都發生在我們真正的main函數執行前。
動态連結庫加載的具體流程
動态連結庫的加載步驟具體分為5步：
- load dylibs image 讀取庫鏡像檔案
- Rebase image
- Bind image
- Objc setup
- initializers
load dylibs image
在每個動态庫的加載過程中， dyld需要：
- 分析所依賴的動态庫
- 找到動态庫的mach-o檔案
- 打開檔案
- 驗證檔案
- 在系統核心注冊檔案簽名
- 對動态庫的每一個segment調用mmap()
通常的，一個App需要加載100到400個dylibs， 但是其中的系統庫被優化，可以很快的加載。 針對這一步驟的優化有：
- 減少非系統庫的依賴
- 合并非系統庫
- 使用靜态資源，比如把代碼加入主程式
rebase/bind
由于ASLR(address space layout randomization)的存在，可執行檔案和動态連結庫在虛拟記憶體中的加載位址每次啟動都不固定，是以需要這2步來修複鏡像中的資源指針，來指向正确的位址。 rebase修複的是指向目前鏡像内部的資源指針； 而bind指向的是鏡像外部的資源指針。
rebase步驟先進行，需要把鏡像讀入記憶體，并以page為機關進行加密驗證，保證不會被篡改，是以這一步的瓶頸在IO。bind在其後進行，由于要查詢符号表，來指向跨鏡像的資源，加上在rebase階段，鏡像已被讀入和加密驗證，是以這一步的瓶頸在于CPU計算。
通過指令行可以檢視相關的資源指針:
xcrun dyldinfo -rebase -bind -lazy_bind myApp.App/myApp
優化該階段的關鍵在于減少__DATA segment中的指針數量。我們可以優化的點有：
- 減少Objc類數量， 減少selector數量
- 減少C++虛函數數量
- 轉而使用swift stuct（其實本質上就是為了減少符号的數量）
Objc setup
這一步主要工作是:
- 注冊Objc類 (class registration)
- 把category的定義插入方法清單 (category registration)
- 保證每一個selector唯一 (selctor uniquing)
由于之前2步驟的優化，這一步實際上沒有什麼可做的。
initializers
以上三步屬于靜态調整(fix-up)，都是在修改__DATA segment中的内容，而這裡則開始動态調整，開始在堆和堆棧中寫入内容。 在這裡的工作有：
- Objc的+load()函數
- C++的構造函數屬性函數 形如attribute((constructor)) void DoSomeInitializationWork()
- 非基本類型的C++靜态全局變量的建立(通常是類或結構體)(non-trivial initializer) 比如一個全局靜态結構體的建構，如果在構造函數中有繁重的工作，那麼會拖慢啟動速度
Objc的load函數和C++的靜态構造函數采用由底向上的方式執行，來保證每個執行的方法，都可以找到所依賴的動态庫。
上圖是在自定義的類XXViewController的+load方法斷點的調用堆棧，清楚的看到整個調用棧和順序：
- dyld 開始将程式二進制檔案初始化
- 交由 ImageLoader 讀取 image，其中包含了我們的類、方法等各種符号
- 由于 runtime 向 dyld 綁定了回調，當 image 加載到記憶體後，dyld 會通知 runtime 進行處理
- runtime 接手後調用 mapimages 做解析和處理，接下來 loadimages 中調用 callloadmethods 方法，周遊所有加載進來的 Class，按繼承層級依次調用 Class 的 +load 方法和其 Category 的 +load 方法
至此，可執行檔案中和動态庫所有的符号(Class，Protocol，Selector，IMP，…)都已經按格式成功加載到記憶體中，被 runtime 所管理，再這之後，runtime 的那些方法(動态添加 Class、swizzle 等等才能生效)。
整個事件由 dyld 主導，完成運作環境的初始化後，配合 ImageLoader 将二進制檔案按格式加載到記憶體， 動态連結依賴庫，并由 runtime 負責加載成 objc 定義的結構，所有初始化工作結束後，dyld 調用真正的 main 函數。
如果程式剛剛被運作過，那麼程式的代碼會被dyld緩存，是以即使殺掉程序再次重新開機加載時間也會相對快一點，如果長時間沒有啟動或者目前dyld的緩存已經被其他應用占據，那麼這次啟動所花費的時間就要長一點，這就分别是熱啟動和冷啟動的概念，如下圖所示:
main()之前的加載時間如何衡量
那麼問題就來了，那怎麼衡量main()之前也就是time1的耗時呢，蘋果官方提供了一種方法，那就是在真機調試的時候勾選dyldPRINTSTATISTICS選項。
會得到如下形式的輸出：
由此可見對于系統級别的動态連結庫，因為蘋果做了優化，是以耗時并不多，在這個awesome的例子中，自身App中的代碼占用了整體時間的94.2% 我們應用中一次典型的Log如下：
由此可見，最多的用時還是在image加載和OC類的初始化，共占用總時長的79.3%，精簡framework的引入和OC類有優化的空間。
總結一下：對于main()調用之前的耗時我們可以優化的點有：
- 減少不必要的framework，因為動态連結比較耗時
- check framework應當設為optional和required，如果該framework在目前App支援的所有iOS系統版本都存在，那麼就設為required，否則就設為optional，因為optional會有些額外的檢查
- 合并或者删減一些OC類，關于清理項目中沒用到的類，使用工具AppCode代碼檢查功能，查到目前項目中沒有用到的類如下：
- 删減一些無用的靜态變量
- 删減沒有被調用到或者已經廢棄的方法
方法見： 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++虛函數(建立虛函數表有開銷)
main()調用之後的加載時間
在main()被調用之後，App的主要工作就是初始化必要的服務，顯示首頁内容等。而我們的優化也是圍繞如何能夠快速展現首頁來開展。 App通常在AppDelegate類中的- (BOOL)Application:(UIApplication *)Application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions方法中建立首頁需要展示的view，然後在目前runloop的末尾，主動調用CA::Transaction::commit完成視圖的渲染。
而視圖的渲染主要涉及三個階段：
- 準備階段 這裡主要是圖檔的解碼
- 布局階段 首頁所有UIView的- (void)layoutSubViews()運作
-
繪制階段 首頁所有UIView的- (void)drawRect:(CGRect)rect運作
再加上啟動之後必要服務的啟動、必要資料的建立和讀取，這些就是我們可以嘗試優化的地方
是以，對于main()函數調用之前我們可以優化的點有：
- 不使用xib，直接視用代碼加載首頁視圖
- NSUserDefaults實際上是在Library檔案夾下會生産一個plist檔案，如果檔案太大的話一次能讀取到記憶體中可能很耗時，這個影響需要評估，如果耗時很大的話需要拆分(需考慮老版本覆寫安裝相容問題)
- 每次用NSLog方式列印會隐式的建立一個Calendar，是以需要删減啟動時各業務方打的log，或者僅僅針對内測版輸出log
- 梳理應用啟動時發送的所有網絡請求，是否可以統一在異步線程請求
實測資料
建立了一個空的HelloWorld工程，隻加入了pods中的代碼，不包含主端的業務邏輯代碼，一次典型的冷啟動基本接近2s iPhone6 iOS9.3.5系統測試主要時間在加載動态庫，類/方法的初始化還有符号位址綁定階段。
一次典型的熱啟動資料如下：可以看到因為系統做了緩存方面的優化，比冷啟動快了500ms加上頭條主端業務邏輯代碼之後一次典型的熱啟動耗時2.1s。
以上用時均為main()之前的加載耗時。
main函數之後加載時間優化記錄
NSUserDefaults是否是瓶頸
蘋果官方文檔提到NSUserDefaults加載的時候是整個plist配置檔案全部load到記憶體中，目前頭條主端當中NSUserDefaults存儲了200多項緩存資料，是以懷疑可能拖慢啟動速度，但是測試結果顯示并不會。 通過符号斷點+[NSUserDefaults standardUserDefaults]确定最早一次的+load()從執行到結束耗時1.8ms，可見NSUserDefaults的初始化僅耗時1.8ms，并不是啟動耗時的瓶頸。
如何找到拖慢啟動應用時長的瓶頸
為了找到瓶頸，我們在啟動之後的didFinishLauhcning方法開始執行到首頁清單頁的NewsListViewController的viewDidAppear方法，幾乎每個可能比較耗時的流程進行拆分和統計，得到統計資料之後發現： 主要耗時在首頁UI構造和渲染(storyboard加載，tabBar/topBar渲染，開屏廣告加載/cell注冊/日志子產品初始化這幾個步驟)。
具體優化點
是以，針對于今日頭條這個App我們可以優化的點如下：
- 純代碼方式而不是storyboard加載首頁UI。
-
對didFinishLaunching裡的函數考慮能否挖掘可以延遲加載或者懶加載，需要與各個業務方pm和rd共同check 對于一些已經下線的業務，删減備援代碼。
對于一些與UI展示無關的業務，如微網誌認證過期檢查、圖檔最大緩存空間設定等做延遲加載
- 對實作了+load()方法的類進行分析，盡量将load裡的代碼延後調用。
- 上面統計資料顯示展示feed的導航控制器頁面(NewsListViewController)比較耗時，對于viewDidLoad以及viewWillAppear方法中盡量去嘗試少做，晚做，不做。
優化結果
之前曾經有一位同僚已經做了一定的優化，比如啟動之後展示閃屏廣告圖的同時初始化首頁的清單頁，當廣告展示完成之後清單頁也就渲染完成了。經過這一次優化之後的main()之後的啟動總時長通過上線之後收集資料的驗證達到了預期的效果