文章目錄
       一、何為冷啟動
       1、冷啟動
       2、熱啟動
       二、冷啟動時間
       1、什麼是冷啟動時間
       2、冷啟動過程做了什麼 
       三、pre-main（）階段
       1、pre-main階段載入
       2、pr-main節點時間測量及其優化
       四、main()階段
       1、main()階段載入
       2、main()優化

一、何為冷啟動

1、冷啟動: app第一次啟動的過程(或者app被kill後，重新啟動的過程)。

2、熱啟動: app處於懸掛狀態，被重新切換回app的過程。

二、冷啟動時間

1、什麼是冷啟動時間: 簡而言之，就是使用者點選app的iocn那一刻開始到看到第一個介面的這段時間。

2、冷啟動過程做了什麼

將其劃分為兩部分,一個是pre-main，另一部分是main。

1.pre-main階段
    1.1 載入應用的可執行檔案
    1.2 載入動態連結庫載入器dyld(dynamic loader）
    1.3 dyld遞迴載入應用所有依賴的dylib（dynamic library 動態連結庫）
        包括iOS系統的以及APP依賴的第三方庫。
    
2.main階段    
   2.1 dyld呼叫main() 
   2.2 呼叫UIApplicationMain() 
   2.3 呼叫applicationWillFinishLaunching(這個一般用不到)
   2.4 呼叫didFinishLaunchingWithOptions
 

三、如何查詢冷啟動時間

1、pre-main階段載入
具體的載入步驟如下：
(1)載入dylib，分析每個dylib（大部分是iOS系統的），找到其Mach-O檔案，
開啟並讀取驗證有效性，找到程式碼簽名註冊到核心，
最後對dylib的每個segment呼叫mmap()。

(2)rebase/bind (指標重定向):
dylib載入完成之後，它們處於相互獨立的狀態，需要繫結起來。
在dylib的載入過程中，系統為了安全考慮，引入了ASLR
（Address Space Layout Randomization）技術和程式碼簽名。
由於ASLR的存在，映象（Image，包括可執行檔案、dylib和bundle）會在隨機的地址上載入，
和之前指標指向的地址（preferred_address）會有一個偏差，dyld需要修正這個偏差，來指向正確的地址。
rebase在前，Bind在後。rebase做的是將映象讀入記憶體，修正映象內部的指標

(3)ObjC setup
OC的runtime需要維護一張類名與類的方法列表的全域性表。
dyld做了如下操作：
對所有宣告過的OC類，將其註冊到這個全域性表中;
將category的方法插入到類的方法列表中
檢查每個selector的唯一性
(4)initializer(這是pre-main階段最耗時的部分)
dyld執行APP的初始化函式，呼叫每個OC類的+load方法，呼叫C++的構造器函式（attribute((constructor))修飾），建立非基本型別的C++靜態全域性變數，然後執行main函式。

2、pr-main節點時間測量及其優化
dyld 提供了內建的測量方法, Xcode 中 Edit scheme -> Run -> Auguments 將環境變數 DYLD_PRINT_STATISTICS 設為1或者YES。

# 優化前的
Total pre-main time: 1.4 seconds (100.0%)
         dylib loading time:  28.64 milliseconds (2.0%) 
        rebase/binding time:  41.42 milliseconds (2.9%)
            ObjC setup time:  37.08 milliseconds (2.6%)  
           initializer time: 1.3 seconds (92.4%)

分別做如下優化
(1) 移除不需要用到的動態庫
(2) 移除不需要用到的類, 減少selector、category的數量
(3) 儘量避免在+load方法裡執行的操作，可以推遲到+initialize方法中。

# 優化後的
Total pre-main time: 1.1 seconds (100.0%)
         dylib loading time:  22.88 milliseconds (1.9%)
        rebase/binding time:  35.48 milliseconds (2.9%)
            ObjC setup time:  29.95 milliseconds (2.5%)
           initializer time: 1.1 seconds (92.5%)

四、main()階段

1、main()階段載入: main方法執行只有到didFinishLaunchingWithOptions執行結束這段時間。

主要工作就是初始化必要的服務，顯示首頁內容等。而我們的優化也是圍繞如何能夠快速展現首頁來開展。簡要來說，只需要關注這個didFinishLaunchingWithOptions方法即可。
其實在這方法裡面，我們主要是初始化第三方sdk，專案配置，設定根檢視控制器等。
我們可以藉助打點計時器BLStopwatch來度量didFinishLaunchingWithOptions每行程式碼的初始時間。

例如：
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 
{
   NSLog(@"didFinishLaunchingWithOptions 開始執行");
   self.window = [[UIWindow alloc] initWithFrame:UIScreen.mainScreen.bounds];
   self.window.backgroundColor = [UIColor whiteColor];
   UITabBarController *tabVC = [[UITabBarController alloc] init];
   self.window.rootViewController =  tabVC;
   [self.window makeKeyAndVisible];
    
   BLStopwatch *timer = [BLStopwatch sharedStopwatch];
   [timer start];
   [self initShareSDK];
   [timer splitWithDescription:@"初始化分享SDK"];
   [timer stop];
   NSLog(@"%@",timer.prettyPrintedSplits);
   // #1 初始化SDK: 0.523  這是個假設時間
   return YES;
}

我們可以根據打點最後輸出的時間對我們的工程進行優化。我們的目的是儘快展現第一個頁面給使用者。首頁最好使用春程式碼建立，畢竟用sb還有一次解碼過程。

所以，為了優化啟動速度，我們需要對didFinishLaunchingWithOptions必須給任務進行分級分時。

* 日誌、統計等必須在 APP 一啟動就最先配置的事件
* 專案配置、環境配置、使用者資訊的初始化 、推送、IM等事件
* 其他 SDK 和配置事件

其實，總結來說，就是必須一進app就必須初始化和可以延遲初始化的。就上例而言，初始化一個SDK需要耗時0.5s，如果在該SDK 不是非必須初始化，可以放HomeVC的viewdidLoad或者viewDidAppear去做又或者需要用到才初始化。

2、main()優化
1、展示的首頁儘量用純程式碼建立，結合快取更加。
2、結合BLStopwatch對啟動服務進行分級分時。
3、對一些非必要的初始化操作，可以放到viewDidAppear，因為到viewDidAppear開始執行的時候，使用者已經看到了APP的首屏，即宣告啟動結束
4、一般僅針對測試版本進行log列印
5、建議超過0.1的都看下，是否有優化空間
6、對didFinishLaunching裡的函式考慮能否挖掘可以延遲載入或者懶載入，

總之：價效比最高的優化階段就是main函式之後的一些邏輯整理，儘量將不需要的耗時操作延遲到首屏展示之後執行。