iOS App啓動優化（一）：檢測啓動時間

冷啓動和熱啓動

冷啓動：指APP被後臺kill後從新啓動APP，這種啓動方式叫作冷啓動。
熱啓動：APP的狀態由running切換爲suspend，APP 沒有被kill仍然在後臺運行。再次把APP切換到前臺，這種啓動方式叫熱啓動。

啓動時間的組成

啓動時間的劃分能夠把main()函數做爲關鍵點分割成兩塊
t1階段，main()以前的處理所需時間，稱爲pre-main
t2階段，main()及main()以後處理所需時間

t1階段：`pre-main`

t2階段

t2階段耗時的主要是業務代碼oop

推薦 BLStopwatch，這個工具能夠打點統計業務耗時post

本部分優化根據各自業務需求自行處理性能

Xcode 測量 `pre-main` 時間

經過添加環境變量能夠獲取到pre-main階段的時間測試

`DYLD_PRINT_STATISTICS`

Xcode 中提供了測量 pre-main 的時間 Edit scheme -> Run -> Auguments 添加環境變量 DYLD_PRINT_STATISTICS，value設爲YES。

啓動之後能夠看到啓動時長

加載`dylib`

分析每一個dylib（大部分是系統的），找到其Mach-O文件，打開並讀取驗證有效性；找到代碼簽名註冊到內核，最後對dylib的每一個segment調用mmap()。

在dylib的加載過程當中系統爲了安全考慮引入了ASLR（Address Space Layout Randomization）技術和代碼簽名。

ASLR技術：鏡像Image、可執行文件、dylib、bundle在加載的時候會在其指向的地址（preferred_address）前面添加一個隨機數誤差（slide），防止應用內部地址被定位。

rebase/bind

dylib加載完成以後，它們處於相互獨立的狀態，須要綁定起來。

Rebase將鏡像讀入內存，修正鏡像內部的指針，性能消耗主要在IO。

Bind是查詢符號表，設置指向鏡像外部的指針，性能消耗主要在CPU計算。

Objc setup

runtime會維護一張類名與類的方法列表的全局表。

讀取全部類，將類對象其註冊到這個全局表中（class registration）
讀取全部分類，把分類加載到類對象中（category registration）
檢查selector的惟一性（selector uniquing）

initalizer time

這部分其實就是load方法的耗時

`DYLD_PRINT_STATISTICS_DETAILS`

還能夠獲取更詳細的時間，添加環境變量DYLD_PRINT_STATISTICS_DETAILS，value設爲YES。

優化思路

移除不須要用到的動態庫，儘可能使用系統庫，且蘋果建議數量控制在 6 個如下
移除不須要用到的類；合併功能相似的類和擴展；經測試 20000 個類會增長約 800毫秒
儘可能進行懶加載，儘可能避免在load()方法裏執行操做，把操做推遲到initialize()方法

繼續瞭解優化請移步 iOS App啓動優化（二）：物理內存和虛擬內存