main 函數(shù)是 iOS 程序的入口，我們寫的代碼都是在 main 函數(shù)之后執(zhí)行的，但是在夜深人靜的時(shí)候，我的腦海中經(jīng)常會(huì)冒出這樣的問(wèn)題：main 函數(shù)之前到底發(fā)生了什么？用戶點(diǎn)擊程序圖標(biāo)之后，我們的 App 是怎樣被啟動(dòng)的？這期間系統(tǒng)做了哪些事情、經(jīng)歷了哪些步驟才一步步地調(diào)用到程序 main 函數(shù)的？于是我又獻(xiàn)祭了自己的空閑時(shí)間對(duì) iOS 應(yīng)用的啟動(dòng)流程進(jìn)行了一番探究。

調(diào)研結(jié)論

咳咳，這里先把結(jié)論貼出來(lái)，然后再一步步分析，對(duì)總體流程有了一個(gè)大體的認(rèn)識(shí)才不會(huì)在技術(shù)細(xì)節(jié)中迷路：

(1) 系統(tǒng)為程序啟動(dòng)做好準(zhǔn)備

(2) 系統(tǒng)將控制權(quán)交給 Dyld，Dyld 會(huì)負(fù)責(zé)后續(xù)的工作

(3) Dyld 加載程序?所需的動(dòng)態(tài)庫(kù)

(3) Dyld 對(duì)程序進(jìn)行 rebase 以及 bind 操作

(4) Objc SetUp

(5) 運(yùn)行初始化函數(shù)

(6) 執(zhí)行程序的 main 函數(shù)

步驟比較多，不過(guò)不用擔(dān)心，我會(huì)結(jié)合代碼對(duì)其進(jìn)行進(jìn)一步的講解。

Dyld

在用戶點(diǎn)擊應(yīng)用后，系統(tǒng)內(nèi)核會(huì)去創(chuàng)建一個(gè)新的進(jìn)程并為應(yīng)用的執(zhí)行做好準(zhǔn)備，詳情可參考趣探 Mach-O：加載過(guò)程，之后會(huì)去調(diào)用 Dyld 來(lái)接管后續(xù)的工作。Dyld 是 iOS 系統(tǒng)的動(dòng)態(tài)鏈接器，它的代碼在這里，整體來(lái)說(shuō)它的機(jī)制還是比較復(fù)雜的，所里這里只是簡(jiǎn)單概括一下，感興趣的同志可以下載源碼閱讀。

Dyld 的啟動(dòng)代碼源于 dyldStartup.s 文件，在一大串的匯編代碼中有個(gè)名為 __dyld_start 的方法，它會(huì)去調(diào)用 dyldbootstrap::start() 方法，然后進(jìn)一步調(diào)用 dyld::_main() 方法，里面包含 App 的整個(gè)啟動(dòng)流程，該函數(shù)最終返回應(yīng)用程序 main 函數(shù)的地址，最后 Dyld 會(huì)去調(diào)用它。dyld::_main() 函數(shù)的源碼很長(zhǎng)，所以這里只保留關(guān)鍵信息，并用偽代碼進(jìn)行簡(jiǎn)化從而得到整體流程：

uintptr_t _main(···/省略參數(shù)/···) {
    // 1. 設(shè)置運(yùn)行環(huán)境
    ......
    
    // 2. instantiate ImageLoader for main executable
    sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);   
    
    ......
    
    //3. link main executable
    link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
    
    ......
   
    //4. run all initializers
    initializeMainExecutable(); 
    
    ......
    
    //5. find entry point for main executable
    result = (uintptr_t)sMainExecutable->getThreadPC();
   
    ......
    
    return result;
}

接下來(lái)我會(huì)對(duì)以上關(guān)鍵代碼進(jìn)行解讀，希望大家對(duì)啟動(dòng)流程有著更為清晰的認(rèn)識(shí)。?

加載可執(zhí)行文件

二進(jìn)制文件常被稱為 image，包括可執(zhí)行文件、動(dòng)態(tài)庫(kù)等，ImageLoader 的作用就是將二進(jìn)制文件加載進(jìn)內(nèi)存。dyld::_main() 方法在設(shè)置好運(yùn)行環(huán)境后，會(huì)調(diào)用 instantiateFromLoadedImage 函數(shù)將可執(zhí)行文件加載進(jìn)內(nèi)存中，加載過(guò)程分為三步：

1. 合法性檢查。主要是檢查可執(zhí)行文件是否合法，是否能在當(dāng)前的 CPU 架構(gòu)下運(yùn)行。

2. 選擇 ImageLoader 加載可執(zhí)行文件。系統(tǒng)會(huì)去判斷可執(zhí)行文件的類型，選擇相應(yīng)的 ImageLoader 將其加載進(jìn)內(nèi)存空間中。

3. 注冊(cè) image 信息?？蓤?zhí)行文件加載完成后，系統(tǒng)會(huì)調(diào)用 addImage 函數(shù)將其管理起來(lái)，并更新內(nèi)存分布信息。

以上三步完成后，Dyld 會(huì)調(diào)用 link 函數(shù)開始之后的處理流程。另外補(bǔ)充下，如果有同學(xué)對(duì) ImageLoader 感興趣的話，dyld 加載 Mach-O這篇文章是不錯(cuò)的，推薦大家看。

Load Dylibs

link(sMainExecutable, ......) 函數(shù)究竟做了些什么，我們可以從源碼中一探究竟：

void ImageLoader::link(···/省略參數(shù)/···) {
    //dyld::log("ImageLoader::link(%s) refCount=%d, neverUnload=%d\n", imagePath, fDlopenReferenceCount, fNeverUnload);
    
    // clear error strings
    (*context.setErrorStrings)(0, NULL, NULL, NULL);

    uint64_t t0 = mach_absolute_time();
    this->recursiveLoadLibraries(context, preflightOnly, loaderRPaths, imagePath);
    context.notifyBatch(dyld_image_state_dependents_mapped, preflightOnly);

    // we only do the loading step for preflights
    if ( preflightOnly )
        return;
        
    uint64_t t1 = mach_absolute_time();
    context.clearAllDepths();
    this->recursiveUpdateDepth(context.imageCount());

    uint64_t t2 = mach_absolute_time();
    this->recursiveRebase(context);
    context.notifyBatch(dyld_image_state_rebased, false);
    
    uint64_t t3 = mach_absolute_time();
    this->recursiveBind(context, forceLazysBound, neverUnload);

    uint64_t t4 = mach_absolute_time();
    if ( !context.linkingMainExecutable )
        this->weakBind(context);
    uint64_t t5 = mach_absolute_time(); 

    context.notifyBatch(dyld_image_state_bound, false);
    uint64_t t6 = mach_absolute_time(); 

    std::vector<DOFInfo> dofs;
    this->recursiveGetDOFSections(context, dofs);
    context.registerDOFs(dofs);
    uint64_t t7 = mach_absolute_time(); 

    // interpose any dynamically loaded images
    if ( !context.linkingMainExecutable && (fgInterposingTuples.size() != 0) ) {
        this->recursiveApplyInterposing(context);
    }
    
    // clear error strings
    (*context.setErrorStrings)(0, NULL, NULL, NULL);

    fgTotalLoadLibrariesTime += t1 - t0;
    fgTotalRebaseTime += t3 - t2;
    fgTotalBindTime += t4 - t3;
    fgTotalWeakBindTime += t5 - t4;
    fgTotalDOF += t7 - t6;
    
    // done with initial dylib loads
    fgNextPIEDylibAddress = 0;
}

link 函數(shù)不是很長(zhǎng)，這里就全部貼出來(lái)了，它首先調(diào)用 recursiveLoadLibraries，遞歸加載程序所需的動(dòng)態(tài)鏈接庫(kù)。使用 otool -L 二進(jìn)制文件路徑 可以列出程序的動(dòng)態(tài)鏈接庫(kù)：

$ otool -L gaoda

/System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 1349.55.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)
/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation (compatibility version 150.0.0, current version 1349.56.0)
/System/Library/Frameworks/UIKit.framework/UIKit (compatibility version 1.0.0, current version 3600.7.47)

UIKit 和 Foundation 框架相信大家已經(jīng)很熟悉了，那么 libobjc.A.dylib 以及 libSystem.B.dylib 是什么呢？libobjc.A.dylib 包含 runtime，而 libSystem.B.dylib 則包含像 libdispatch、libsystem_c 等系統(tǒng)級(jí)別的庫(kù)，二者都是被默認(rèn)添加到程序中的。動(dòng)態(tài)鏈接庫(kù)的加載也是借助 ImageLoader 完成的，但是由于動(dòng)態(tài)鏈接庫(kù)本身還可能依賴其他動(dòng)態(tài)鏈接庫(kù)，所以整個(gè)加載過(guò)程是遞歸進(jìn)行的。當(dāng)程序的動(dòng)態(tài)鏈接庫(kù)加載完畢后，link 函數(shù)進(jìn)入下一流程。

Rebase && Bind

因?yàn)榈刂房臻g加載隨機(jī)化(ASLR，Address Space Layout Randomization)的緣故，二進(jìn)制文件最終的加載地址與預(yù)期地址之間會(huì)存在偏移，所以需要進(jìn)行 rebase 操作，對(duì)那些指向文件內(nèi)部符號(hào)的指針進(jìn)行修正，在 link 函數(shù)中該項(xiàng)操作由 recursiveRebase 函數(shù)執(zhí)行。rebase 完成之后，就會(huì)進(jìn)行 bind 操作，修正那些指向其他二進(jìn)制文件所包含的符號(hào)的指針，由 recursiveBind 函數(shù)執(zhí)行。

當(dāng) rebase 以及 bind 結(jié)束時(shí)，link 函數(shù)就完成了它的使命，iOS 應(yīng)用的啟動(dòng)流程也進(jìn)入到下一階段，即 Objc SetUp。

Objc SetUp

Objc Setup 算是 iOS 系統(tǒng)獨(dú)有的流程了，在 runtime 的初始化函數(shù) _objc_init 中，有這樣的代碼：

void _objc_init(void) {
    
    ......
    
    // Register for unmap first, in case some +load unmaps something
    _dyld_register_func_for_remove_image(&unmap_image);
    dyld_register_image_state_change_handler(dyld_image_state_bound,
                                             1/*batch*/, &map_2_images);
    dyld_register_image_state_change_handler(dyld_image_state_dependents_initialized, 0/*not batch*/, &load_images);
}

Dyld 在 bind 操作結(jié)束之后，會(huì)發(fā)出 dyld_image_state_bound 通知，然后與之綁定的回調(diào)函數(shù) map_2_images 就會(huì)被調(diào)用，它主要做以下幾件事來(lái)完成 Objc Setup：

1. 讀取二進(jìn)制文件的 DATA 段內(nèi)容，找到與 objc 相關(guān)的信息

2. 注冊(cè) Objc 類

3. 確保 selector 的唯一性

4. 讀取 protocol 以及 category 的信息

除了 map_2_images，我們注意到 _objc_init 還注冊(cè)了 load_images 函數(shù)，它的作用就是調(diào)用 Objc 的 + load 方法，它監(jiān)聽(tīng) dyld_image_state_dependents_initialized 通知。

雖然我說(shuō)的很簡(jiǎn)單，但是在讀源碼的時(shí)候，我發(fā)現(xiàn)這部分內(nèi)容其實(shí)是十分復(fù)雜而又十分有趣的，鑒于本文主旨是講啟動(dòng)流程，所以這一塊內(nèi)容先放下，以后有時(shí)間了再講。

Initializers

Objc SetUp 結(jié)束后，Dyld 便開始運(yùn)行程序的初始化函數(shù)，該任務(wù)由 initializeMainExecutable 函數(shù)執(zhí)行。整個(gè)初始化過(guò)程是一個(gè)遞歸的過(guò)程，順序是先將依賴的動(dòng)態(tài)庫(kù)初始化，然后在對(duì)自己初始化。初始化需要做的事情包括：

1. 調(diào)用 Objc 類的 + load 函數(shù)

2. 調(diào)用 C++ ?中帶有 constructor 標(biāo)記的函數(shù)

3. 非基本類型的 C++ 靜態(tài)全局變量的創(chuàng)建

main

當(dāng)初始化結(jié)束之后，可執(zhí)行文件才處于可用狀態(tài)，之后 Dyld 就會(huì)去調(diào)用可執(zhí)行文件的 main 函數(shù)，開始程序的運(yùn)行。

結(jié)語(yǔ)

同學(xué)們還可以開啟 DYLD_PRINT_STATISTICS 選項(xiàng)來(lái)打印各個(gè)階段的耗時(shí)，一般來(lái)說(shuō)400ms以內(nèi)是很棒的。

關(guān)于 iOS 應(yīng)用啟動(dòng)流程的介紹到此就告一段落了，自己挖的坑總算是填上了，日后如果有了新的發(fā)現(xiàn)我會(huì)補(bǔ)充上去的，然后嘛，就開始挖新的坑了??