1. 啟動流程

1.1 準備知識

Mach-O

Apple的操作系統的可執行文件格式幾乎都是mach-o，mach-o可以大致的分為三部分：

絕大多數mach-o包括以下三個段（支持用戶自定義Segment，但是很少使用）

dyld

dyld的全稱是dynamic loader，它的作用是加載一個進程所需要的image，它是開源的。

• Virtual Memory

  虛擬內存是在物理內存上建立的一個邏輯地址空間，它向上（應用）提供了一個連續的邏輯地址空間，向下隱藏了物理內存的細節。
  虛擬內存使得邏輯地址可以沒有實際的物理地址，也可以讓多個邏輯地址對應到一個物理地址。

  虛擬內存被劃分為一個個大小相同的Page（64位系統上是16KB），提高管理和讀寫的效率。 Page又分為只讀和讀寫的Page。

  虛擬內存是建立在物理內存和進程之間的中間層。在iOS上，當內存不足的時候，會嘗試釋放那些只讀的Page，因為只讀的Page在下次被訪問的時候，可以再從磁盤讀取。如果沒有可用內存，會通知在后臺的App（也就是在這個時候收到了memory warning），如果在這之后仍然沒有可用內存，則會殺死在后臺的App。

• Page fault
  在應用執行的時候，它被分配的邏輯地址空間都是可以訪問的，當應用訪問一個邏輯Page，而在對應的物理內存中并不存在的時候，這時候就發生了一次Page fault。當Page fault發生的時候，會中斷當前的程序，在物理內存中尋找一個可用的Page，然后從磁盤中讀取數據到物理內存，接著繼續執行當前程序。

• Dirty Page & Clean Page
  如果一個Page可以從磁盤上重新生成，那么這個Page稱為Clean Page
  如果一個Page包含了進程相關信息，那么這個Page稱為Dirty Page
  像代碼段這種只讀的Page就是Clean Page。而像數據段(_DATA)這種讀寫的Page，當寫數據發生的時候，會觸發COW(Copy on write)，也就是寫時復制，Page會被標記成Dirty，同時會被復制。

1.2 dyld2啟動流程

加載動態庫

dyld會首先讀取mach-o文件的Header和load commands。
接著就知道了這個可執行文件依賴的動態庫。例如加載動態庫A到內存，接著檢查A所依賴的動態庫，就這樣的遞歸加載，直到所有的動態庫加載完畢。通常一個App所依賴的動態庫在100-400個左右，其中大多數都是系統的動態庫，它們會被緩存到dyld shared cache，這樣讀取的效率會很高。

查看mach-o文件所依賴的動態庫，可以通過MachOView的圖形化界面(展開Load Command就能看到)，也可以通過命令行otool。

Rebase && Bind

有兩種主要的技術來保證應用的安全：ASLR和Code Sign。

ASLR的全稱是Address space layout randomization，翻譯過來就是“地址空間布局隨機化”。App被啟動的時候，程序會被影射到邏輯的地址空間，這個邏輯的地址空間有一個起始地址，而ASLR技術使得這個起始地址是隨機的。如果是固定的，那么黑客很容易就可以由起始地址+偏移量找到函數的地址。

Code Sign相信大多數開發者都知曉，這里要提一點的是，在進行Code sign的時候，加密哈希不是針對于整個文件，而是針對于每一個Page的。這就保證了在dyld進行加載的時候，可以對每一個page進行獨立的驗證。

mach-o中有很多符號，有指向當前mach-o的，也有指向其他dylib的，比如printf。那么，在運行時，代碼如何準確的找到printf的地址呢？

mach-o中采用了PIC技術，全稱是Position Independ code。當你的程序要調用printf的時候，會先在__DATA段中建立一個指針指向printf，在通過這個指針實現間接調用。dyld這時候需要做一些fix-up工作，即幫助應用程序找到這些符號的實際地址。主要包括兩部分

Rebase 修正內部(指向當前mach-o文件)的指針指向
Bind 修正外部指針指向

之所以需要Rebase，是因為剛剛提到的ASLR使得地址隨機化，導致起始地址不固定，另外由于Code Sign，導致不能直接修改Image。Rebase的時候只需要增加對應的偏移量即可。待Rebase的數據都存放在__LINKEDIT中。

Rebase解決了內部的符號引用問題，而外部的符號引用則是由Bind解決。在解決Bind的時候，是根據字符串匹配的方式查找符號表，所以這個過程相對于Rebase來說是略慢的。

Objective-C

Objective C是動態語言，所以在執行main函數之前，需要把類的信息注冊到一個全局的Table中。同時，Objective C支持Category，在初始化的時候，也會把Category中的方法注冊到對應的類中，同時會唯一Selector，這也是為什么當你的Cagegory實現了類中同名的方法后，類中的方法會被覆蓋。

另外，由于iOS開發是基于Cocoa Touch的，所以絕大多數的類起始都是系統類，所以大多數的Runtime初始化起始在Rebase和Bind中已經完成。

Initializers

接下來就是必要的初始化部分了，主要包括幾部分：

• load(Swift已棄用，只能使用initialize)
• C/C++靜態初始化對象和標記為__attribute__(constructor)的方法

1.3 dyld3啟動流程

上文的講解是dyld2的加載方式。而最新的是dyld3加載方式略有不同：

out-of-process會做如下事情：

• 分析Mach-o Headers
• 分析依賴的動態庫
• 查找需要Rebase & Bind之類的符號
• 把上述結果寫入緩存

這樣，在應用啟動的時候，就可以直接從緩存中讀取數據，加快加載速度。

1.4 main之后

相對于開發者來說，main才是程序入口。下面是加載流程：

• 1. main函數

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

UIApplicationMain函數有四個參數,最后一個參數是AppDelegate的類名，通常使用模板創建的AppDelegate是AppDelegate，如果我們想要改變它的名字，我們同樣需要在這里傳入對應的類名。

 UIApplicationMain(int argc, char *argv[], NSString *principalClassName, NSString *delegateClassName);

• 2. 程序完成加載
     我們一般會在這里進行一些初始化配置，例如創建window。

- [AppDelegate application:didFinishLaunchingWithOptions:]

• 3. 創建window窗口
     我們所有的畫面最終都會顯示在該窗口上，makeKeyAndVisible是window顯示的關鍵。

_window = UIWindow.new;
_window.backgroundColor = [UIColor whiteColor];
[_window makeKeyAndVisible];

• 4. 程序被激活
     最后該方法會被調用，宣布程序處于激活狀態。

- [AppDelegate applicationDidBecomeActive:]

2. AppDelegate

AppDelegate類有以下常用的函數，這里是我們與系統進行交互的場所，一般在這里創建視圖以及監聽部分設備狀態。

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    NSLog(@"%s",__func__);
    return YES;
}

- (void)applicationWillResignActive:(UIApplication *)application {
     NSLog(@"%s",__func__);
}

- (void)applicationDidEnterBackground:(UIApplication *)application {
   NSLog(@"%s",__func__);
}

- (void)applicationWillEnterForeground:(UIApplication *)application {
   NSLog(@"%s",__func__);
}

- (void)applicationDidBecomeActive:(UIApplication *)application {
  NSLog(@"%s",__func__);
}

- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application {
     NSLog(@"%s",__func__);
}

- (void)applicationWillTerminate:(UIApplication *)application {
    NSLog(@"%s",__func__);
}

APP狀態更改后會收到一些通知。

// 啟動APP會調用
-[AppDelegate application:didFinishLaunchingWithOptions:]
-[AppDelegate applicationDidBecomeActive:]

// 點擊Home鍵會調用
-[AppDelegate applicationWillResignActive:]
-[AppDelegate applicationDidEnterBackground:]

// APP從后臺返回前臺
-[AppDelegate applicationWillEnterForeground:]
-[AppDelegate applicationDidBecomeActive:]

// 收到內存警告
-[AppDelegate applicationDidReceiveMemoryWarning:]

3. 啟動優化

如果你剛剛啟動過App，這時候App的啟動所需要的數據仍然在緩存中，再次啟動的時候稱為熱啟動。如果設備剛剛重啟，然后啟動App，這時候稱為冷啟動。

啟動時間在小于400ms是最佳的，因為從點擊圖標到顯示Launch Screen，到Launch Screen消失這段時間是400ms。啟動時間不可以大于20s，否則會被系統殺掉。

以main函數作為分水嶺，啟動時間其實包括了兩部分：main函數之前和main函數到第一個界面的viewDidAppear:。不過一般情況下都是耗時都產生在自己的代碼，優先考慮優化main之后的過程。

優化這些初始化的核心思想就是：能延遲初始化的盡量延遲初始化，不能延遲初始化的盡量放到后臺初始化。