iOS App的啟動與優化

App的啟動流程

App啟動分為冷啟動和熱啟動

冷啟動：從0開始啟動App
熱啟動：App已經在內存中，但是后臺還掛著，再次點擊圖標啟動App。

一般對App啟動的優化都是針對冷啟動。

App冷啟動可分為三個階段：

dyld：加載鏡像、動態庫
RunTime方法
main函數初始化

動態庫vs靜態庫

靜態庫：一堆.o文件的集合（通常是.a后綴），還沒有被鏈接過，缺點是產物體積比較大，優點是鏈接到App之后體積比較小。

動態庫：一個已經鏈接完全的鏡像，優點是產物體積比較小，缺點是鏈接到App之后體積比較大。

兩者最大的區別就是靜態庫沒有被鏈接過，而動態庫被鏈接過。

一.dyld

dyld是app的動態鏈接器。主要可以用來裝載Mach-O文件（可執行文件、動態庫等）

啟動APP時，dyld所做的事情有：

加載過程從exec()函數開始，這是一個系統調用。操作系統首先為進程分配一段內存空間。然后執行以下操作：

1.把App的可執行文件加載到內存
2.把dyld加載到內存
3.dyld進行動態鏈接

具體內容：

1、加載動態庫
- Dyld從主執行文件的header獲取到需要加載的所依賴動態庫列表，然后它需要找到每個 dylib，而應用所依賴的 dylib 文件可能會再依賴其他 dylib，所以所需要加載的是動態庫列表一個遞歸依賴的集合
2、Rebase和Binding
- 1、Rebase（偏移修正）
  ? ? ? ?任何一個app生成的二進制文件，在二進制文件內部所有的方法、函數調用，都有一個地址，這個地址是在當前二進制文件中的偏移地址。一旦在運行時刻（即運行到內存中），每次系統都會隨機分配一個ASLR（Address Space Layout Randomization，地址空間布局隨機化）地址值（是一個安全機制，會分配一個隨機的數值，插入在二進制文件的開頭），例如，二進制文件中有一個 test方法，偏移值是0x0001，而隨機分配的ASLR是0x1f00，如果想訪問test方法，其內存地址（即真實地址）變為 ASLR+偏移值 = 運行時確定的內存地址（即0x1f00+0x0001 = 0x1f01）
- 2、Binding（綁定）
  ? ? ? ?例如NSLog方法，在編譯時期生成的mach-o文件中，會創建一個符號！NSLog（目前指向一個隨機的地址），然后在運行時（從磁盤加載到內存中，是一個鏡像文件），會將真正的地址給符號（即在內存中將地址與符號進行綁定，是dyld做的，也稱為動態庫符號綁定），一句話概括：綁定就是給符號賦值的過程

二.RunTime階段

dyld階段結束之后就進入RunTime階段，這個階段主要進行如下內容：

1、Objc setup

1、注冊Objc類 (class registration)
2、把category的定義插入方法列表 (category registration)
3、保證每一個selector唯一 (selector uniquing)

2、Initializers

1、Objc的+load()函數
2、C++的構造函數屬性函數
3、非基本類型的C++靜態全局變量的創建(通常是類或結構體)

三.main()函數初始化

App的啟動由dyld主導，把可執行文件加載到內存，并且加載所有依賴的動態庫，并由RunTime負責加載成objc定義的結構，所有初始化工作結束后，dyld就會調用mainn函數接下來就是UIApplicationMain函數，AppDelegate的application:didFinishLaunchingWithOptions:方法

這個里面往往是最占用啟動時間的地方，同時也是我們最為可控的地方。

? 進入 main() 函數，啟動應用。

? 執行 UIApplicationMain() 函數，創建 UIApplication 對象并設置 AppDelegate。

? 加載應用的主 UI，包括 storyboard 或 xib 文件，以及 AppDelegate 的各種生命周期方法，如 application:didFinishLaunchingWithOptions:。

四.首屏渲染階段

初始化rootViewController，加載和渲染界面

渲染完成后，用戶將看到應用的首屏。

App冷啟動流程總結：

1. dyld 加載階段：

? 動態鏈接器 dyld 負責加載應用的可執行文件及其依賴的動態庫。此時，系統將會做如下工作：

? 查找應用的可執行文件和動態庫

? 將它們加載到內存中

? 進行符號解析和綁定

? 執行初始化函數（如 +load 方法和靜態構造函數）

2. runtime 初始化階段：

? ObjC 運行時對類和分類進行注冊。

? 執行各類 +load 方法，這個階段還會進行一些 Swift 類的初始化。

3. main() 函數執行階段：

? 進入 main() 函數，啟動應用。

? 執行 UIApplicationMain() 函數，創建 UIApplication 對象并設置 AppDelegate。

? 加載應用的主 UI，包括 storyboard 或 xib 文件，以及 AppDelegate 的各種生命周期方法，如 application:didFinishLaunchingWithOptions:。

4. 首屏渲染階段：

? 初始化 rootViewController，加載和渲染界面。

? 渲染完成后，用戶將看到應用的首屏。

+load與+initialize

1、+load

（1）+load方法是一定會在runtime中被調用的。只要類被添加到runtime中了，就會調用+load方法，因此+load方法總是在main函數之前調用。

（2）+load方法不會覆蓋。也就是說，如果子類實現了+load方法，那么會先調用父類的+load方法（無需手動調用super），然后又去執行子類的+load方法。

（3）+load方法只會調用一次。

（4）+load方法執行順序是：類 -> 子類 ->分類。而不同分類之間的執行順序不一定，依據在Compile Sources中出現的順序（先編譯，則先調用，列表中在下方的為“先”）。

（5）+load方法是函數指針調用，即遍歷類中的方法列表，直接根據函數地址調用。如果子類沒有實現+load方法，子類也不會自動調用父類的+load方法。

2、+initialize

（1）+initialize方法是在類或它的子類收到第一條消息之前被調用的，這里所指的消息包括實例方法和類方法的調用。因此+initialize方法總是在main函數之后調用。

（2）+initialize方法只會調用一次。

（3）+initialize方法實際上是一種惰性調用，如果一個類一直沒被用到，那它的+initialize方法也不會被調用，這一點有利于節約資源。

（4）+initialize方法會覆蓋。如果子類實現了+initialize方法，就不會執行父類的了，直接執行子類本身的。如果分類實現了+initialize方法，也不會再執行主類的。

（5）+initialize方法的執行覆蓋順序是：分類 -> 子類 ->類。且只會有一個+initialize方法被執行。

（6）+initialize方法是發送消息（objc_msgSend()），如果子類沒有實現+initialize方法，也會自動調用其父類的+initialize方法。

3、兩者的異同

（1）相同點

load和initialize會被自動調用，不能手動調用它們。
子類實現了load和initialize的話，會隱式調用父類的load和initialize方法。
load和initialize方法內部使用了鎖，因此它們是線程安全的。

（2）不同點

調用順序不同，以main函數為分界，+load方法在main函數之前執行，+initialize在main函數之后執行。（存疑）
子類中沒有實現+load方法的話，子類不會調用父類的+load方法；而子類如果沒有實現+initialize方法的話，也會自動調用父類的+initialize方法。
+load方法是在類被裝在進來的時候就會調用，+initialize在第一次給某個類發送消息時調用（比如實例化一個對象），并且只會調用一次，是懶加載模式，如果這個類一直沒有使用，就不回調用到+initialize方法。