前言

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

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

基本概念

啟動的定義

啟動有兩種定義：

• 廣義：點擊圖標到首頁數據加載完畢
• 狹義：點擊圖標到 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。

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

加入我們

我們是負責抖音客戶端基礎能力研發和新技術探索的團隊。我們在工程/業務架構，研發工具，編譯系統等方向深耕，支撐業務快速迭代的同時，保證超大規模團隊的研發效能和工程質量。在性能/穩定性等方面不斷探索，努力為全球數億用戶提供最極致的基礎體驗。

如果你對技術充滿熱情，歡迎加入抖音基礎技術團隊，讓我們共建億級全球化 App。目前我們在上海、北京、杭州、深圳均有招聘需求，內推可以聯系郵箱：tech@bytedance.com ；郵件標題：姓名 - 工作年限 - 抖音 - 基礎技術 - iOS/Android。