作者：位元組跳動技術團隊

前言

啟動是 App 給使用者的第一印象，啟動越慢使用者流失的概率就越高，良好的啟動速度是使用者體驗不可缺少的一環。啟動優化涉及到的知識點非常多面也很廣，一篇文章難以包含全部，所以拆分成兩部分：原理和實踐。

本文從基礎知識出發，先回顧一些核心概念，為後續章節做鋪墊；接下來介紹 IPA 構建的基本流程，以及這個流程裡可用於啟動優化的點；最後大篇幅講解 dyld3 的啟動 pipeline，因為啟動優化的重點還在執行時。

小編推薦一個技術交流圈子會來淺談一下iOS開發中有哪些方向和職業規劃，同時小編也歡迎大家加入小編的可以加QQ群：1001906160！ 群裡會免費提供相關面試資料，書籍歡迎大家入駐！

基本概念

啟動的定義

啟動有兩種定義：

• 廣義：點選圖示到首頁資料載入完畢
• 狹義：點選圖示到 Launch Image 完全消失第一幀

不同產品的業務形態不一樣，對於抖音來說，首頁的資料載入完成就是視訊的第一幀播放；對其他首頁是靜態的 App 來說，Launch Image 消失就是首頁資料載入完成。由於標準很難對齊，所以我們一般使用狹義的啟動定義：即啟動終點為啟動圖完全消失的第一幀。

以抖音為例，使用者感受到的啟動時間：

Tips：啟動最佳時間是 400ms 以內，因為啟動動畫時長是 400ms。

這是從使用者感知維度定義啟動，那麼程式碼上如何定義啟動呢？Apple 在 MetricKit 中給出了官方計算方式：

• 起點：程序建立的時間
• 終點：第一個CA::Transaction::commit()

Tips：CATransaction 是 Core Animation 提供的一種事務機制，把一組 UI 上的修改打包，一起發給 Render Server 渲染。

啟動的種類

根據場景的不同，啟動可以分為三種：冷啟動，熱啟動和回前臺。

• 冷啟動：系統裡沒有任何程序的快取資訊，典型的是重啟手機後直接啟動 App
• 熱啟動：如果把 App 程序殺了，然後立刻重新啟動，這次啟動就是熱啟動，因為程序快取還在
• 回前臺：大多數時候不會被定義為啟動，因為此時 App 仍然活著，只不過處於 suspended 狀態

那麼，線上使用者的冷啟動多還是熱啟動多呢？

答案是和產品形態有關係，開啟頻次越高，熱啟動比例就越高。

Mach-O

Mach-O 是 iOS 可執行檔案的格式，典型的 Mach-O 是主二進位制和動態庫。Mach-O 可以分為三部分：

• Header
• Load Commands
• Data

Header 的最開始是 Magic Number，表示這是一個 Mach-O 檔案，除此之外還包含一些 Flags，這些 flags 會影響 Mach-O 的解析。

Load Commands 儲存 Mach-O 的佈局資訊，比如 Segment command 和 Data 中的 Segment/Section 是一一對應的。除了佈局資訊之外，還包含了依賴的動態庫等啟動 App 需要的資訊。

Data 部分包含了實際的程式碼和資料，Data 被分割成很多個 Segment，每個 Segment 又被劃分成很多個 Section，分別存放不同型別的資料。

標準的三個 Segment 是 TEXT，DATA，LINKEDIT，也支援自定義：

• TEXT，程式碼段，只讀可執行，儲存函式的二進位制程式碼(__text)，常量字串(__cstring)，Objective C 的類/方法名等資訊
• DATA，資料段，讀寫，儲存 Objective C 的字串(__cfstring)，以及執行時的元資料：class/protocol/method…
• LINKEDIT，啟動 App 需要的資訊，如 bind & rebase 的地址，程式碼簽名，符號表…

dyld

dyld 是啟動的輔助程式，是 in-process 的，即啟動的時候會把 dyld 載入到程序的地址空間裡，然後把後續的啟動過程交給 dyld。dyld 主要有兩個版本：dyld2 和 dyld3。

dyld2 是從 iOS 3.1 引入，一直持續到 iOS 12。dyld2 有個比較大的優化是dyld shared cache，什麼是 shared cache 呢？

• shared cache 就是把系統庫(UIKit 等)合成一個大的檔案，提高載入效能的快取檔案。

iOS 13 開始 Apple 對三方 App 啟用了 dyld3，dyld3 的最重要的特性就是啟動閉包，閉包裡包含了啟動所需要的快取資訊，從而提高啟動速度。

虛擬記憶體

記憶體可以分為虛擬記憶體和實體記憶體，其中實體記憶體是實際佔用的記憶體，虛擬記憶體是在實體記憶體之上建立的一層邏輯地址，保證記憶體訪問安全的同時為應用提供了連續的地址空間。

實體記憶體和虛擬記憶體以頁為單位對映，但這個對映關係不是一一對應的：一頁實體記憶體可能對應多頁虛擬記憶體；一頁虛擬記憶體也可能不佔用實體記憶體。

iPhone 6s 開始，實體記憶體的 Page 大小是 16K，6 和之前的裝置都是 4K，這是 iPhone 6 相比 6s 啟動速度斷崖式下降的原因之一。

mmap

mmap 的全稱是 memory map，是一種記憶體對映技術，可以把檔案對映到虛擬記憶體的地址空間裡，這樣就可以像直接操作記憶體那樣來讀寫檔案。當讀取虛擬記憶體，其對應的檔案內容在實體記憶體中不存在的時候，會觸發一個事件：File Backed Page In，把對應的檔案內容讀入實體記憶體。

啟動的時候，Mach-O 就是通過 mmap 對映到虛擬記憶體裡的(如下圖)。下圖中部分頁被標記為 zero fill，是因為全域性變數的初始值往往都是 0，那麼這些 0 就沒必要儲存在二進位制裡，增加檔案大小。作業系統會識別出這些頁，在 Page In 之後對其置為 0，這個行為叫做 zero fill。

Page In

啟動的路徑上會觸發很多次 Page In，其實也比較容易理解，因為啟動的會讀寫二進位制中的很多內容。Page In 會佔去啟動耗時的很大一部分，我們來看看單個 Page In 的過程：

• MMU 找到空閒的實體記憶體頁面
• 觸發磁碟 IO，把資料讀入實體記憶體
• 如果是 TEXT 段的頁，要進行解密
• 對解密後的頁，進行簽名驗證

其中解密是大頭，IO 其次。

為什麼要解密呢？因為 iTunes Connect 會對上傳 Mach-O 的 TEXT 段進行加密，防止 IPA 下載下來就直接可以看到程式碼。這也就是為什麼逆向裡會有個概念叫做“砸殼”，砸的就是這一層 TEXT 段加密。iOS 13 對這個過程進行了優化，Page In 的時候不需要解密了。

二進位制重排

既然 Page In 耗時，有沒有什麼辦法優化呢？啟動具有區域性性特徵，即只有少部分函式在啟動的時候用到，這些函式在二進位制中的分佈是零散的，所以 Page In 讀入的資料利用率並不高。如果我們可以把啟動用到的函式排列到二進位制的連續區間，那麼就可以減少 Page In 的次數，從而優化啟動時間：

以下圖為例，方法 1 和方法 3 是啟動的時候用到的，為了執行對應的程式碼，就需要兩次 Page In。假如我們把方法 1 和 3 排列到一起，那麼只需要一次 Page In，從而提升啟動速度。

連結器 ld 有個引數-order_file 支援按照符號的方式排列二進位制。獲取啟動時候用到的符號的有很多種方式，感興趣的同學可以看看抖音之前的文章：基於二進位制檔案重排的解決方案 APP 啟動速度提升超 15%。

IPA 構建

pipeline

既然要構建，那麼必然會有一些地方去定義如何構建，對應 Xcode 中的兩個配置項：

• Build Phase：以 Target 為維度定義了構建的流程。可以在 Build Phase 中插入指令碼，來做一些定製化的構建，比如 CocoaPod 的拷貝資源就是通過指令碼的方式完成的。
• Build Settings：配置編譯和連結相關的引數。特別要提到的是 other link flags 和 other c flags，因為編譯和連結的引數非常多，有些需要手動在這裡配置。很多專案用的 CocoaPod 做的元件化，這時候編譯選項在對應的.xcconfig 檔案裡。

以單 Target 為例，我們來看下構建流程：

• 原始檔(.m/.c/.swift 等)是單獨編譯的，輸出對應的目標檔案(.o)
• 目標檔案和靜態庫/動態庫一起，連結出最後的 Mach-O
• Mach-O 會被裁剪，去掉一些不必要的資訊
• 資原始檔如 storyboard，asset 也會編譯，編譯後加載速度會變快
• Mach-O 和資原始檔一起，打包出最後的.app
• 對.app 簽名，防篡改

編譯

編譯器可以分為兩大部分：前端和後端，二者以 IR（中間程式碼）作為媒介。這樣前後端分離，使得前後端可以獨立的變化，互不影響。C 語言家族的前端是 clang，swift 的前端是 swiftc，二者的後端都是 llvm。

• 前端負責預處理，詞法語法分析，生成 IR
• 後端基於 IR 做優化，生成機器碼

那麼如何利用編譯優化啟動速度呢？

程式碼數量會影響啟動速度，為了提升啟動速度，我們可以把一些無用程式碼下掉。那怎麼統計哪些程式碼沒有用到呢？可以利用 LLVM 插樁來實現。

LLVM 的程式碼優化流程是一個一個 Pass，由於 LLVM 是開源的，我們可以新增一個自定義的 Pass，在函式的頭部插入一些程式碼，這些程式碼會記錄這個函式被呼叫了，然後把統計到的資料上傳分析，就可以知道哪些程式碼是用不到的了 。

Facebook 給 LLVM 提的order_file的 feature 就是實現了類似的插樁。

連結

經過編譯後，我們有很多個目標檔案，接著這些目標檔案會和靜態庫，動態庫一起，連結出一個 Mach-O。連結的過程並不產生新的程式碼，只會做一些移動和補丁。

• tbd 的全稱是 text-based stub library，是因為連結的過程中只需要符號就可以了，所以 Xcode 6 開始，像 UIKit 等系統庫就不提供完整的 Mach-O，而是提供一個只包含符號等資訊的 tbd 檔案。

舉一個基於連結優化啟動速度的例子：

最開始講解 Page In 的時候，我們提到 TEXT 段的頁解密很耗時，有沒有辦法優化呢？

可以通過 ld 的-rename_section，把 TEXT 段中的內容，比如字串移動到其他的段(啟動路徑上難免會讀很多字串)，從而規避這個解密的耗時。

抖音的重新命名方案：

"-Wl,-rename_section,__TEXT,__cstring,__RODATA,__cstring",
"-Wl,-rename_section,__TEXT,__const,__RODATA,__const", 
"-Wl,-rename_section,__TEXT,__gcc_except_tab,__RODATA,__gcc_except_tab", 
"-Wl,-rename_section,__TEXT,__objc_methname,__RODATA,__objc_methname", 
"-Wl,-rename_section,__TEXT,__objc_classname,__RODATA,__objc_classname",
"-Wl,-rename_section,__TEXT,__objc_methtype,__RODATA,__objc_methtype"

複製程式碼

裁剪

編譯完 Mach-O 之後會進行裁剪(strip)，是因為裡面有些資訊，如除錯符號，是不需要帶到線上去的。裁剪有多種級別，一般的配置如下：

• All Symbols，主二進位制
• Non-Global Symbols，動態庫
• Debugging Symbols，二方靜態庫

為什麼二方庫在出靜態庫的時候要選擇 Debugging Symbols 呢？是因為像 order_file 等連結期間的優化是基於符號的，如果把符號裁剪掉，那麼這些優化也就不會生效了。

簽名 & 上傳

裁剪完二進位制後，會和編譯好的資原始檔一起打包成.app 檔案，接著對這個檔案進行簽名。簽名的作用是保證檔案內容不多不少，沒有被篡改過。接著會把包上傳到 iTunes Connect，上傳後會對__TEXT段加密，加密會減弱 IPA 的壓縮效果，增加包大小，也會降低啟動速度 （iOS 13 優化了加密過程，不會對包大小和啟動耗時有影響）。

dyld3 啟動流程

Apple 在 iOS 13 上對第三方 App 啟用了 dyld3，官方資料顯示，過去四年新發布的裝置中有 93%的裝置是 iOS 13，所以我們重點看下 dyld3 的啟動流程。

Before dyld

使用者點選圖示之後，會發送一個系統呼叫 execve 到核心，核心建立程序。接著會把主二進位制 mmap 進來，讀取 load command 中的 LC_LOAD_DYLINKER，找到 dyld 的的路徑。然後 mmap dyld 到虛擬記憶體，找到 dyld 的入口函式_dyld_start，把 PC 暫存器設定成_dyld_start，接下來啟動流程交給了 dyld。

注意這個過程都是在核心態完成的，這裡提到了 PC 暫存器，PC 暫存器儲存了下一條指令的地址，程式的執行就是不斷修改和讀取 PC 暫存器來完成的。

dyld

建立啟動閉包

dyld 會首先建立啟動閉包，閉包是一個快取，用來提升啟動速度的。既然是快取，那麼必然不是每次啟動都建立的，只有在重啟手機或者更新/下載 App 的第一次啟動才會建立。閉包儲存在沙盒的 tmp/com.apple.dyld 目錄，清理快取的時候切記不要清理這個目錄。

閉包是怎麼提升啟動速度的呢？我們先來看一下閉包裡都有什麼內容：

• dependends，依賴動態庫列表
• fixup：bind & rebase 的地址
• initializer-order：初始化呼叫順序
• optimizeObjc: Objective C 的元資料
• 其他：main entry, uuid…

動態庫的依賴是樹狀的結構，初始化的呼叫順序是先呼叫樹的葉子結點，然後一層層向上，最先呼叫的是 libSystem，因為他是所有依賴的源頭。

為什麼閉包能提高啟動速度呢？

因為這些資訊是每次啟動都需要的，把資訊儲存到一個快取檔案就能避免每次都解析，尤其是 Objective C 的執行時資料（Class/Method...）解析非常慢。

fixup

有了閉包之後，就可以用閉包啟動 App 了。這時候很多動態庫還沒有載入進來，會首先對這些動態庫 mmap 載入到虛擬記憶體裡。接著會對每個 Mach-O 做 fixup，包括 Rebase 和 Bind。

• Rebase：修復內部指標。這是因為 Mach-O 在 mmap 到虛擬記憶體的時候，起始地址會有一個隨機的偏移量 slide，需要把內部的指標指向加上這個 slide。
• Bind：修復外部指標。這個比較好理解，因為像 printf 等外部函式，只有執行時才知道它的地址是什麼，bind 就是把指標指向這個地址。

舉個例子：一個 Objective C 字串@"1234"，編譯到最後的二進位制的時候是會儲存在兩個 section 裡的

• __TEXT，__cstring，儲存實際的字串"1234"
• __DATA，__cfstring，儲存 Objective C 字串的元資料，每個元資料佔用 32Byte，裡面有兩個指標：內部指標，指向__TEXT，__cstring中字串的位置；外部指標 isa，指向類物件的，這就是為什麼可以對 Objective C 的字串字面量發訊息的原因。

如下圖，編譯的時候，字串 1234 在__cstring的 0x10 處，所以 DATA 段的指標指向 0x10。但是 mmap 之後有一個偏移量 slide=0x1000，這時候字串在執行時的地址就是 0x1010，那麼 DATA 段的指標指向就不對了。Rebase 的過程就是把指標從 0x10，加上 slide 變成 0x1010。執行時類物件的地址已經知道了，bind 就是把 isa 指向實際的記憶體地址。

LibSystem Initializer

Bind & Rebase 之後，首先會執行 LibSystem 的 Initializer，做一些最基本的初始化：

• 初始化 libdispatch
• 初始化 objc runtime，註冊 sel，載入 category

注意這裡沒有初始化 objc 的類方法等資訊，是因為啟動閉包的快取資料已經包含了 optimizeObjc。

Load & Static Initializer

接下來會進行 main 函式之前的一些初始化，主要包括+load 和 static initializer。這兩類初始化函式都有個特點：呼叫順序不確定，和對應檔案的連結順序有關係。那麼就會存在一個隱藏的坑：有些註冊邏輯在+load 裡，對應會有一些地方讀取這些註冊的資料，如果在+load 中讀取，很有可能讀取的時候還沒有註冊。

那麼，如何找到程式碼裡有哪些 load 和 static initializer 呢？

在 Build Settings 裡可以配置 write linkmap，這樣在生成的 linkmap 檔案裡就可以找到有哪些檔案裡包含 load 或者 static initializer：

• __mod_init_func，static initializer
• __objc_nlclslist，實現+load 的類
• __objc_nlcatlist，實現+load 的 Category

load 舉例

如果+load 方法裡的內容很簡單，會影響啟動時間麼？比如這樣的一個+load 方法？

+ (void)load 
{
    printf("1234");
}
複製程式碼

編譯完了之後，這個函式會在二進位制中的 TEXT 兩個段存在：__text存函式二進位制，cstring儲存字串 1234。為了執行函式，首先要訪問__text觸發一次 Page In 讀入實體記憶體，為了列印字串，要訪問__cstring，還會觸發一次 Page In。

• 為了執行這個簡單的函式，系統要額外付出兩次 Page In 的代價，所以 load 函式多了，page in 會成為啟動效能的瓶頸。

static initializer 產生的條件

靜態初始化是從哪來的呢？以下幾種程式碼會導致靜態初始化

• __attribute__((constructor))
• static class object
• static object in global namespace

注意，並不是所有的 static 變數都會產生靜態初始化，編譯器很智慧，對於在編譯期間就能確定的變數是會直接 inline。

//會產生靜態初始化
class Demo{ 
static const std::string var_1; 
};
const std::string var_2 = "1234"; 
static Logger logger;
//不會產生靜態初始化
static const int var_3 = 4; 
static const char * var_4 = "1234";
複製程式碼

std::string 會合成 static initializer 是因為初始化的時候必須執行建構函式，這時候編譯器就不知道怎麼做了，只能延遲到執行時～

UIKit Init

+load 和 static initializer 執行完畢之後，dyld 會把啟動流程交給 App，開始執行 main 函式。main 函式裡要做的最重要的事情就是初始化 UIKit。UIKit 主要會做兩個大的初始化：

• 初始化 UIApplication
• 啟動主執行緒的 Runloop

由於主執行緒的 dispatch_async 是基於 runloop 的，所以在+load 裡如果呼叫了 dispatch_async 會在這個階段執行。

Runloop

執行緒在執行完程式碼就會退出，很明顯主執行緒是不能退出的，那麼就需要一種機制：事件來的時候執行任務，否則讓執行緒休眠，Runloop 就是實現這個功能的。

Runloop 本質上是一個 While 迴圈，在圖中橙色部分的 mach_msg_trap 就是觸發一個系統呼叫，讓執行緒休眠，等待事件到來，喚醒 Runloop，繼續執行這個 while 迴圈。

Runloop 主要處理幾種任務：Source0，Source1，Timer，GCD MainQueue，Block。在迴圈的合適時機，會以 Observer 的方式通知外部執行到了哪裡。

那麼，Runloop 與啟動又有什麼關係呢？

• App 的 LifeCycle 方法是基於 Runloop 的 Source0 的
• 首幀渲染是基於 Runloop Block 的

Runloop 在啟動上主要有幾點應用：

• 精準統計啟動時間
• 找到一個時機，在啟動結束去執行一些預熱任務
• 利用 Runloop 打散耗時的啟動預熱任務

Tips: 會有一些邏輯要在啟動之後 delay 一小段時間再回到主執行緒上執行，對於效能較差的裝置，主執行緒 Runloop 可能一直處於忙的狀態，所以這個 delay 的任務並不一定能按時執行。

AppLifeCycle

UIKit 初始化之後，就進入了我們熟悉的 UIApplicationDelegate 回調了，在這些會調裡去做一些業務上的初始化：

• willFinishLaunch

• didFinishLaunch

• didFinishLaunchNotification

要特別提一下 didFinishLaunchNotification，是因為大家在埋點的時候通常會忽略還有這個通知的存在，導致把這部分時間算到 UI 渲染裡。

First Frame Render

一般會用 Root Controller 的 viewDidApper 作為渲染的終點，但其實這時候首幀已經渲染完成一小段時間了，Apple 在 MetricsKit 裡對啟動終點定義是第一個CA::Transaction::commit()。

什麼是 CATransaction 呢？我們先來看一下渲染的大致流程

iOS 的渲染是在一個單獨的程序 RenderServer 做的，App 會把 Render Tree 編碼打包給 RenderServer，RenderServer 再呼叫渲染框架(Metal/OpenGL ES)來生成 bitmap，放到幀緩衝區裡，硬體根據時鐘訊號讀取幀緩衝區內容，完成螢幕重新整理。CATransaction 就是把一組 UI 上的修改，合併成一個事務，通過 commit 提交。

渲染可以分為四個步驟

• Layout（佈局），源頭是 Root Layer 呼叫[CALayer layoutSubLayers]，這時候 UIViewController 的 viewDidLoad 和 LayoutSubViews 會呼叫，autolayout 也是在這一步生效
• Display（繪製），源頭是 Root Layer 呼叫[CALayer display]，如果 View 實現了 drawRect 方法，會在這個階段呼叫
• Prepare（準備），這個過程中會完成圖片的解碼
• Commit（提交），打包 Render Tree 通過 XPC 的方式發給 Render Server

啟動 Pipeline

詳細回顧下整個啟動過程，以及各個階段耗時的影響因素：

1. 點選圖示，建立程序
2. mmap 主二進位制，找到 dyld 的路徑
3. mmap dyld，把入口地址設為_dyld_start
4. 重啟手機/更新/下載 App 的第一次啟動，會建立啟動閉包
5. 把沒有載入的動態庫 mmap 進來，動態庫的數量會影響這個階段
6. 對每個二進位制做 bind 和 rebase，主要耗時在 Page In，影響 Page In 數量的是 objc 的元資料
7. 初始化 objc 的 runtime，由於閉包已經初始化了大部分，這裡只會註冊 sel 和裝載 category
8. +load 和靜態初始化被呼叫，除了方法本身耗時，這裡還會引起大量 Page In
9. 初始化 UIApplication，啟動 Main Runloop
10. 執行 will/didFinishLaunch，這裡主要是業務程式碼耗時
11. Layout，viewDidLoad 和 Layoutsubviews 會在這裡呼叫，Autolayout 太多會影響這部分時間
12. Display，drawRect 會呼叫
13. Prepare，圖片解碼發生在這一步
14. Commit，首幀渲染資料打包發給 RenderServer，啟動結束

dyld2

dyld2 和 dyld3 的主要區別就是沒有啟動閉包，就導致每次啟動都要：

• 解析動態庫的依賴關係
• 解析 LINKEDIT，找到 bind & rebase 的指標地址，找到 bind 符號的地址
• 註冊 objc 的 Class/Method 等元資料，對大型工程來說，這部分耗時會很長

總結

本文回顧了 Mach-O，虛擬記憶體，mmap，Page In，Runloop 等基礎概念，接下來介紹了 IPA 的構建流程，以及兩個典型的利用編譯器來優化啟動的方案，最後詳細的講解了 dyld3 的啟動 pipeline。

之所以花這麼大篇幅講原理，是因為任何優化都一樣，只有深入理解系統運作的原理，才能找到效能的瓶頸，下一篇我們會介紹下如何利用這些原理解決實際問題。