dyld 全稱是 the dynamic link editor。他是蘋(píng)果的動(dòng)態(tài)鏈接器，是蘋(píng)果操作系統(tǒng)一個(gè)重要的組成部分，系統(tǒng)加載、鏈接mach-O文件，就是由dyld負(fù)責(zé)的。
前面聊到的應(yīng)用啟動(dòng)加載過(guò)程、類、分類加載，都不可避免的觸及dyld，所以了解 dyld源碼可以讓我們更好的理解iOS應(yīng)用的工作原理。

本文篇幅較長(zhǎng)，都是源碼和堆棧分析，比較枯燥，因此先上結(jié)論：

1. 加載從 _dyld_start開(kāi)始
2. 進(jìn)入dyld::main函數(shù)
   2.1 配置一些環(huán)境變量
   2.2 加載共享緩存庫(kù)（判斷是否禁用，iOS無(wú)法被禁用）
   2.3 初例化主程序
   2.4 加載插入的動(dòng)態(tài)庫(kù)
   2.5 鏈接主程序、鏈接綁定插入的動(dòng)態(tài)庫(kù)、弱綁定
   2.6 初始化方法
   2.6.1 經(jīng)過(guò)一系列的方法，會(huì)（回調(diào)_objc_init的load_images函數(shù)）
   2.6.2 doModInitFunctions函數(shù)，內(nèi)部會(huì)調(diào)用c++構(gòu)造函數(shù)
   2.7 返回入口（找到主程序的main方法）

一、_dyld_start

首先我們要找到dyld的入口，即dyld調(diào)用可執(zhí)行文件的地方。
新建一個(gè)項(xiàng)目，添加load方法，并打上斷點(diǎn)。

load.png

運(yùn)行，

_dyld_start.png

上圖就是我們app開(kāi)始的地方，下面我們打開(kāi)dyld的源碼，找到對(duì)應(yīng)的方法。

二、dyldbootstrap::start

從上面的堆棧我們可以看到 _dyld_start，調(diào)起的第一個(gè)方法就是dyldbootstrap::start（這個(gè)是c++語(yǔ)法，dyldbootstrap是命名空間，start是方法名）。
當(dāng)然我們也可以全局搜索_dyld_start，找到真正的方法實(shí)現(xiàn)。

start.png

通過(guò)dyldbootstrap，找到start方法實(shí)現(xiàn)(簡(jiǎn)化)：

//
//  This is code to bootstrap dyld.  This work in normally done for a program by dyld and crt.
//  In dyld we have to do this manually.
//
uintptr_t start(const struct macho_header* appsMachHeader, int argc, const char* argv[], 
                intptr_t slide, const struct macho_header* dyldsMachHeader,
                uintptr_t* startGlue)
{
    // if kernel had to slide dyld, we need to fix up load sensitive locations
    // we have to do this before using any global variables
    // ASLR=slide 滑塊 內(nèi)存地址布局隨機(jī)化，防止緩存溢出
    slide = slideOfMainExecutable(dyldsMachHeader);
    bool shouldRebase = slide != 0;
    if ( shouldRebase ) {
        rebaseDyld(dyldsMachHeader, slide);
    }

    // allow dyld to use mach messaging
    mach_init();
    
    // set up random value for stack canary
    //棧溢出保護(hù)
    __guard_setup(apple);

    // now that we are done bootstrapping dyld, call dyld's main
    uintptr_t appsSlide = slideOfMainExecutable(appsMachHeader);
    return dyld::_main(appsMachHeader, appsSlide, argc, argv, envp, apple, startGlue);
}

appsMachHeader：這個(gè)就是mach-O的header。
slide：這個(gè)其實(shí)就是ASLR，mac OS10.7、iOS4.3均開(kāi)始導(dǎo)入ASLR。

具體的流程：根據(jù)計(jì)算出來(lái)的slide(ASLR)來(lái)重定向mach-O；初始化允許dyld通過(guò)mach傳遞消息；棧溢出保護(hù)；初始化完成，調(diào)用dyld的main函數(shù)。

三、dyld::_main

//
// Entry point for dyld.  The kernel loads dyld and jumps to __dyld_start which
// sets up some registers and call this function.
//
// Returns address of main() in target program which __dyld_start jumps to
//
uintptr_t
_main(const macho_header* mainExecutableMH, uintptr_t mainExecutableSlide, 
        int argc, const char* argv[], const char* envp[], const char* apple[], 
        uintptr_t* startGlue){
      //方法太長(zhǎng)，900+
}

3.1準(zhǔn)備工作，配置環(huán)境變量

    uintptr_t result = 0;
    sMainExecutableMachHeader = mainExecutableMH;  //主程序的MachO的頭
    sMainExecutableSlide = mainExecutableSlide;    //主程序的ASLR值

    //設(shè)置上下文信息
    setContext(mainExecutableMH, argc, argv, envp, apple);

    {
        //檢測(cè)環(huán)境變量 如果受限  禁止加載第三方庫(kù)
        checkEnvironmentVariables(envp);
        defaultUninitializedFallbackPaths(envp);
    }

    if ( sEnv.DYLD_PRINT_OPTS )
        printOptions(argv);
    if ( sEnv.DYLD_PRINT_ENV ) //打印machO地址
        printEnvironmentVariables(envp);
    //獲取主程序的信息：架構(gòu)、環(huán)境變量，準(zhǔn)備工作完成
    getHostInfo(mainExecutableMH, mainExecutableSlide);

checkEnvironmentVariables(envp)：熟悉越獄插件的同學(xué)應(yīng)該都很清楚，某些環(huán)境變量會(huì)直接影響該庫(kù)是否會(huì)被加載，有些防護(hù)操作就是基于這個(gè)原理來(lái)做的。
DYLD_PRINT_OPTS、DYLD_PRINT_ENV：環(huán)境變量，通過(guò)scheme配置，分別可以打印mach-O即可執(zhí)行文件地址、啟動(dòng)時(shí)環(huán)境變量及其值。

3.2 加載共享緩存

1：檢測(cè)共享緩存的禁用狀態(tài)checkSharedRegionDisable，ios不可以被禁用。
由于 iOS 系統(tǒng)中 UIKit、Foundation 等系統(tǒng)動(dòng)態(tài)庫(kù)每個(gè)應(yīng)用都會(huì)通過(guò) dyld 加載到內(nèi)存中，因此，為了節(jié)約空間，蘋(píng)果將這些系統(tǒng)庫(kù)放在了一個(gè)地方：動(dòng)態(tài)庫(kù)共享緩存區(qū) dyld shared cache， Mac OS 一樣有 。
例如，NSLog 的函數(shù)實(shí)現(xiàn)地址，并不在我們自己的工程的 Mach-O 中。那么我們的工程想要調(diào)用 NSLog 方法，如何能找到其真實(shí)的實(shí)現(xiàn)地址呢？？？

在工程編譯時(shí)，所產(chǎn)生的 Mach-O 可執(zhí)行文件中會(huì)預(yù)留出一段空間，這個(gè)空間其實(shí)就是符號(hào)表，存放在 _DATA 數(shù)據(jù)段中(因?yàn)?_DATA 段在運(yùn)行時(shí)是可讀可寫(xiě)的)
編譯時(shí)：工程中所有引用了共享緩存區(qū)中的系統(tǒng)庫(kù)方法 , 其指向的地址設(shè)置成符號(hào)地址，(例如工程中有一個(gè) NSLog，那么編譯時(shí)就會(huì)在 Mach-O 中創(chuàng)建一個(gè) NSLog 的符號(hào)，工程中的 NSLog 就指向這個(gè)符號(hào))
運(yùn)行時(shí)：當(dāng) dyld 將應(yīng)用進(jìn)程加載到內(nèi)存中時(shí)，根據(jù) load commands 加載需要的庫(kù)文件，然后去做相應(yīng)的綁定操作。(如 NSLog ，dyld 就會(huì)去找到 Foundation 中 NSLog 的真實(shí)地址，映射到 _DATA 段符號(hào)表的 NSLog 上)。

這個(gè)過(guò)程被稱為 PIC 技術(shù)(Position Independent Code：位置代碼獨(dú)立)。這里提一下fishhook，他的函數(shù)名稱是 rebind_symbols，他的工作原理：將編譯后系統(tǒng)庫(kù)函數(shù)所指向的符號(hào)，在運(yùn)行時(shí)重綁定到用戶指定的函數(shù)地址，然后將原系統(tǒng)函數(shù)的真實(shí)地址賦值到用戶指定的指針上。

2：加載共享緩存 mapSharedCache() -> loadDyldCache()

bool loadDyldCache(const SharedCacheOptions& options, SharedCacheLoadInfo* results)
{
    results->loadAddress        = 0;
    results->slide              = 0;
    results->errorMessage       = nullptr;

#if TARGET_IPHONE_SIMULATOR
    // simulator only supports mmap()ing cache privately into process
    return mapCachePrivate(options, results);//模擬器 模擬器僅支持加載到當(dāng)前進(jìn)程
#else
    if ( options.forcePrivate ) {
        // mmap cache into this process only  僅加載到當(dāng)前進(jìn)程
        return mapCachePrivate(options, results);
    }
    else {
        // fast path: when cache is already mapped into shared region
        bool hasError = false;
        // 共享緩存庫(kù)已經(jīng)被加載過(guò)
        if ( reuseExistingCache(options, results) ) {
            hasError = (results->errorMessage != nullptr);
        } else {
            // slow path: this is first process to load cache
            // 共享緩存第一次加載
            hasError = mapCacheSystemWide(options, results);
        }
        return hasError;
    }
#endif
}

3.3 實(shí)例化主程序

// instantiate ImageLoader for main executable
sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);

3.3.1：檢測(cè)可執(zhí)行程序格式，isCompatibleMachO會(huì)通過(guò)mach-O的header里的magic、cputype、cpusubtype 去檢測(cè)是否兼容。

// The kernel maps in main executable before dyld gets control.  We need to 
// make an ImageLoader* for the already mapped in main executable.
static ImageLoaderMachO* instantiateFromLoadedImage(const macho_header* mh, uintptr_t slide, const char* path)
{
    // try mach-o loader 檢查machO格式是否合法
    if ( isCompatibleMachO((const uint8_t*)mh, path) ) {
        //實(shí)例化主程序
        ImageLoader* image = ImageLoaderMachO::instantiateMainExecutable(mh, slide, path, gLinkContext);
        addImage(image);//添加到allimage
        return (ImageLoaderMachO*)image;
    }
    
    throw "main executable not a known format";
}

然后真正實(shí)例化主程序：instantiateFromLoadedImage -> instantiateMainExecutable -> sniffLoadCommands。

sniffLoadCommands，有幾個(gè)參數(shù)(請(qǐng)結(jié)合mach-O文件看)：
compressed，根據(jù) LC_DYLD_INFO_ONYL 來(lái)決定
segCount，segment段命令數(shù)量 , 最大不能超過(guò) 255 個(gè)
libCount，依賴庫(kù)數(shù)量 , LC_LOAD_DYLIB (Foundation、UIKit等) , 最大不能超過(guò) 4095 個(gè)
codeSigCmd , 應(yīng)用簽名
encryptCmd , 應(yīng)用加密信息

3.3.2：實(shí)例化之后，addImage(image)會(huì)將這個(gè)image添加到static std::vector<ImageLoader*> sAllImages;，這是一個(gè)全局的鏡像列表，設(shè)置好上下文，至此主程序的實(shí)例化已經(jīng)完成。

主程序會(huì)第一個(gè)被加載到鏡像文件列表，所以image list的第一個(gè)永遠(yuǎn)是我們的主程序的可執(zhí)行文件。

3.3.3：繼續(xù)往 dyld :: main 下面找，會(huì)發(fā)現(xiàn)一個(gè)方法

// Bind and notify for the main executable now that interposing has been registered
gLinkContext.notifyBatch(dyld_image_state_bound, false);

跟進(jìn)去，notifyBatch -> notifyBatchPartial -> (*sNotifyObjCMapped)(objcImageCount, paths, mhs);，這個(gè)回調(diào)函數(shù)最終會(huì)調(diào)起_objc_init里面的回調(diào)函數(shù)map_images。

3.4、加載插入動(dòng)態(tài)庫(kù)

// load any inserted libraries（越獄的環(huán)境都是用這個(gè)?。?插入的動(dòng)態(tài)庫(kù)
if  ( sEnv.DYLD_INSERT_LIBRARIES != NULL ) {
    for (const char* const* lib = sEnv.DYLD_INSERT_LIBRARIES; *lib != NULL; ++lib) 
        loadInsertedDylib(*lib);
}

越獄開(kāi)發(fā)中，根據(jù) DYLD_INSERT_LIBRARIES 環(huán)境變量，可以決定是否加載插入的動(dòng)態(tài)庫(kù)。
越獄的插件就是基于這個(gè)原理來(lái)實(shí)現(xiàn)的，只需要下載插件，就可以影響到應(yīng)用，有部分防護(hù)手段就用到了這個(gè)環(huán)境變量。

// record count of inserted libraries so that a flat search will look at 
// inserted libraries, then main, then others.
sInsertedDylibCount = sAllImages.size()-1; //記錄 插入的動(dòng)態(tài)庫(kù)的數(shù)量

3.5、鏈接主程序

這里會(huì)多次調(diào)用link函數(shù)，循環(huán)加載動(dòng)態(tài)庫(kù)，對(duì)主程序的依賴庫(kù)進(jìn)行rebase、符號(hào)綁定、弱綁定操作。
3.5.1 鏈接主程序

// link main executable  鏈接主程序
gLinkContext.linkingMainExecutable = true;

link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);

3.5.2 鏈接主程序完成后，判斷sInsertedDylibCount插入的動(dòng)態(tài)庫(kù)數(shù)量是否大于0，然后循環(huán)調(diào)用link鏈接插入的動(dòng)態(tài)庫(kù)。

// link any inserted libraries
// do this after linking main executable so that any dylibs pulled in by inserted 
// dylibs (e.g. libSystem) will not be in front of dylibs the program uses
if ( sInsertedDylibCount > 0 ) {
    for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
        ImageLoader* image = sAllImages[i+1];
        //鏈接動(dòng)態(tài)庫(kù)
        link(image, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
        image->setNeverUnloadRecursive();
    }
    // only INSERTED libraries can interpose 只有插入動(dòng)態(tài)庫(kù)可以被插入
    // register interposing info after all inserted libraries are bound so chaining works  
    //注冊(cè)插入的動(dòng)態(tài)庫(kù)，已保證鏈接有效
    for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
        ImageLoader* image = sAllImages[i+1];
        image->registerInterposing(gLinkContext);
    }
}

3.5.3 bind 符號(hào)綁定和弱綁定

// Bind and notify for the main executable now that interposing has been registered
uint64_t bindMainExecutableStartTime = mach_absolute_time();
sMainExecutable->recursiveBindWithAccounting(gLinkContext, sEnv.DYLD_BIND_AT_LAUNCH, true);
uint64_t bindMainExecutableEndTime = mach_absolute_time();
ImageLoaderMachO::fgTotalBindTime += bindMainExecutableEndTime - bindMainExecutableStartTime;
gLinkContext.notifyBatch(dyld_image_state_bound, false);

// Bind and notify for the inserted images now interposing has been registered
if ( sInsertedDylibCount > 0 ) {
    for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
        ImageLoader* image = sAllImages[i+1];
        image->recursiveBind(gLinkContext, sEnv.DYLD_BIND_AT_LAUNCH, true);
    }
}

// <rdar://problem/12186933> do weak binding only after all inserted images linked
// 弱綁定 完成符號(hào)綁定
sMainExecutable->weakBind(gLinkContext);

weakBind弱綁定， 懶加載綁定，也就是說(shuō)弱綁定一定發(fā)生在其他庫(kù)鏈接綁定完成之后。

進(jìn)入link函數(shù)后，(注意 linkingMainExecutable 變量)

void ImageLoader::link(const LinkContext& context, bool forceLazysBound, bool preflightOnly, bool neverUnload, const RPathChain& loaderRPaths, const char* imagePath)
{
    //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);
    //在鏈接的時(shí)候,不僅僅是對(duì)主程序進(jìn)行鏈接,還有很多依賴庫(kù)也需要進(jìn)行鏈接,所以首先循環(huán)加載依賴庫(kù)
    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());//遞歸依賴層級(jí)

    __block uint64_t t2, t3, t4, t5;
    {
        dyld3::ScopedTimer(DBG_DYLD_TIMING_APPLY_FIXUPS, 0, 0, 0);
        t2 = mach_absolute_time();
        this->recursiveRebase(context); //必須對(duì)主程序和依賴庫(kù)做重定位rebase(由于ASLR的存在)
        context.notifyBatch(dyld_image_state_rebased, false);

        t3 = mach_absolute_time();
        if ( !context.linkingMainExecutable ) //符號(hào)綁定
            this->recursiveBindWithAccounting(context, forceLazysBound, neverUnload);

        t4 = mach_absolute_time();
        if ( !context.linkingMainExecutable )
            this->weakBind(context); //弱綁定
        t5 = mach_absolute_time();
    }

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

    std::vector<DOFInfo> dofs;
    this->recursiveGetDOFSections(context, dofs); //注冊(cè)DOF
    context.registerDOFs(dofs); //注冊(cè)DOF
    uint64_t t7 = mach_absolute_time(); 

    // interpose any dynamically loaded images
    if ( !context.linkingMainExecutable && (fgInterposingTuples.size() != 0) ) {
        dyld3::ScopedTimer timer(DBG_DYLD_TIMING_APPLY_INTERPOSING, 0, 0, 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;
}

到這里，主程序已經(jīng)實(shí)例化完畢，但是還沒(méi)有加載，FrameWork已經(jīng)加載完畢。
思考：不同的FrameWork，誰(shuí)會(huì)被先加載呢？？？其他他和category文件的加載順利邏輯一樣，都是根據(jù)二進(jìn)制編譯順序相關(guān)，在Xcode中可以自由調(diào)整，mach-O也可以看到。

3.6、初始化

繼續(xù)往 dyld :: main 下面找，我們會(huì)看到：

// run all initializers
initializeMainExecutable();

跟進(jìn)去：initializeMainExecutable -> runInitializers -> processInitializers -> recursiveInitialization 遞歸調(diào)用。
到這里就沒(méi)辦法跟了，cmd + shift + o搜索recursiveInitialization。

// let objc know we are about to initialize this image   load方法加載結(jié)束
uint64_t t1 = mach_absolute_time();
fState = dyld_image_state_dependents_initialized;
oldState = fState;
//
context.notifySingle(dyld_image_state_dependents_initialized, this, &timingInfo);

// initialize this image
bool hasInitializers = this->doInitialization(context);

// let anyone know we finished initializing this image
fState = dyld_image_state_initialized;
oldState = fState;
//
context.notifySingle(dyld_image_state_initialized, this, NULL);

if ( hasInitializers ) {
    uint64_t t2 = mach_absolute_time();
    timingInfo.addTime(this->getShortName(), t2-t1);
}

從notifySingle函數(shù)跟進(jìn)去，最后來(lái)到(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());，這個(gè)回調(diào)函數(shù)，最終會(huì)調(diào)起_objc_init里面的回調(diào)函數(shù)load_images，這塊內(nèi)容，在 本文第五節(jié) 具體分析。

3.6.2、doInitialization

在上一段代碼，也就是recursiveInitialization函數(shù)實(shí)現(xiàn)中，有一個(gè)函數(shù)doInitialization，搜索然后跟進(jìn)去，這里會(huì)調(diào)用 c++構(gòu)造方法。

bool ImageLoaderMachO::doInitialization(const LinkContext& context)
{
    CRSetCrashLogMessage2(this->getPath());

    // mach-o has -init and static initializers
    doImageInit(context);
    doModInitFunctions(context);//加載c++構(gòu)造函數(shù)
    
    CRSetCrashLogMessage2(NULL);
    
    return (fHasDashInit || fHasInitializers);
}

c++構(gòu)造方法，在mach-O的data段中對(duì)應(yīng)__mod_init_func。

3.7、找到主程序入口

// notify any montoring proccesses that this process is about to enter main()
if (dyld3::kdebug_trace_dyld_enabled(DBG_DYLD_TIMING_LAUNCH_EXECUTABLE)) {
    dyld3::kdebug_trace_dyld_duration_end(launchTraceID, DBG_DYLD_TIMING_LAUNCH_EXECUTABLE, 0, 0, 2);
}
notifyMonitoringDyldMain();

// find entry point for main executable 找到主程序的入口，調(diào)起main函數(shù)
result = (uintptr_t)sMainExecutable->getEntryFromLC_MAIN();
if ( result != 0 ) {
    // main executable uses LC_MAIN, we need to use helper in libdyld to call into main()
    if ( (gLibSystemHelpers != NULL) && (gLibSystemHelpers->version >= 9) )
        *startGlue = (uintptr_t)gLibSystemHelpers->startGlueToCallExit;
    else
        halt("libdyld.dylib support not present for LC_MAIN");
}

result = (uintptr_t)sMainExecutable->getEntryFromLC_MAIN(); 找到真的main入口，至此dyld加載結(jié)束。

四、代碼驗(yàn)證

4.1 新建一個(gè)Single View App項(xiàng)目，在ViewController.m 添加代碼。

@implementation ViewController

+ (void)load{
    NSLog(@"來(lái)了：%s", __func__);
}

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view.
}

@end

//c++構(gòu)造方法
__attribute__((constructor)) void func1() {
    
    printf("\n func1來(lái)了 \n");
}

4.2 給當(dāng)前項(xiàng)目添加一個(gè)FrameWork，并添加Inject類，然后添加代碼。

#import "Inject.h"

@implementation Inject

+(void)load
{
    NSLog(@"來(lái)了：%s", __func__);
}

@end

4.3 運(yùn)行，查看控制臺(tái)。

dyld[15456:2366528] 來(lái)了：+[Inject load]
dyld[15456:2366528] 來(lái)了：+[ViewController load]


 func1來(lái)了 

打印結(jié)果剛好印證我們上述的的結(jié)論，當(dāng)然如果你想看下多個(gè)FrameWork結(jié)果，你可以自行添加測(cè)試驗(yàn)證。

五、 _objc_init

上文，我們兩次提到過(guò)notifySingle函數(shù)，下面我們來(lái)具體分析一下上文第二個(gè)notifySingle函數(shù)。

5.1 notifySingle

首先我么來(lái)回顧一下，我們第一節(jié)提到的一張圖，_dyld_start 到 load()的調(diào)用堆棧圖。

image.png

根據(jù)調(diào)用堆棧，下一步就是調(diào)用 load_images，但是cmd + shift + o搜索找到notifySingle函數(shù)實(shí)現(xiàn)，可是這里并沒(méi)有找到 load_images 的影子？？
但是，注意這里有一句代碼，如下：

//方法回調(diào)
(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());

這是個(gè)回調(diào)函數(shù)的調(diào)用，sNotifyObjCInit上面判斷了并不會(huì)為空，那就代表一定是有值的。那我們?cè)诋?dāng)前文件搜索一下 sNotifyObjCInit，看看什么時(shí)候被賦的值。

void registerObjCNotifiers(_dyld_objc_notify_mapped mapped, _dyld_objc_notify_init init, _dyld_objc_notify_unmapped unmapped)
{
    // record functions to call
    sNotifyObjCMapped   = mapped;
    sNotifyObjCInit     = init;//賦值
    sNotifyObjCUnmapped = unmapped;

    // call 'mapped' function with all images mapped so far
    try {
        notifyBatchPartial(dyld_image_state_bound, true, NULL, false, true);
    }
    catch (const char* msg) {
        // ignore request to abort during registration
    }

    // <rdar://problem/32209809> call 'init' function on all images already init'ed (below libSystem)
    for (std::vector<ImageLoader*>::iterator it=sAllImages.begin(); it != sAllImages.end(); it++) {
        ImageLoader* image = *it;
        if ( (image->getState() == dyld_image_state_initialized) && image->notifyObjC() ) {
            dyld3::ScopedTimer timer(DBG_DYLD_TIMING_OBJC_INIT, (uint64_t)image->machHeader(), 0, 0);
            (*sNotifyObjCInit)(image->getRealPath(), image->machHeader());
        }
    }
}

然后我們發(fā)現(xiàn)(反推)：registerObjCNotifiers <- _dyld_objc_notify_register，在往前就找不到了。
這個(gè)時(shí)候，我們可以給我們的項(xiàng)目下一個(gè)符號(hào)斷點(diǎn)_dyld_objc_notify_register，看看函數(shù)調(diào)用棧。

image.png

至此，我們就看到了runtime整個(gè)被加載的流程。這里涉及iOS多個(gè)庫(kù)，我們不一一看。可以參考objc 750源碼找到_objc_init。

5.2 _objc_init

void _objc_init(void)
{
    static bool initialized = false;
    if (initialized) return;
    initialized = true;
    
    // fixme defer initialization until an objc-using image is found?
    environ_init();
    tls_init();
    static_init();
    lock_init();
    exception_init();

    _dyld_objc_notify_register(&map_images, load_images, unmap_image);
}

在這里我們就看到_dyld_objc_notify_register被調(diào)用，傳遞了三個(gè)參數(shù)，我在ios應(yīng)用啟動(dòng)加載過(guò)程、類、分類加載 做過(guò)詳細(xì)介紹。

map_images：dyld 將 image 加載進(jìn)內(nèi)存時(shí)，會(huì)觸發(fā)該函數(shù)。
load_images：dyld初始化 image會(huì)觸發(fā)該方法。（我們所熟知的 load 方法也是在此處調(diào)用）。
unmap_image：dyld 將 image 移除時(shí)，會(huì)觸發(fā)該函數(shù)。

我們可以通過(guò)LLDB驗(yàn)證一下：

lldb.png

5.3 dyld鏈接主程序 到 調(diào)起_objc_init的具體流程

1. 當(dāng) dyld 加載到開(kāi)始鏈接主程序的時(shí)候，遞歸調(diào)用 recursiveInitialization 函數(shù)
2. 這個(gè)函數(shù)第一次執(zhí)行，進(jìn)行 libsystem 的初始化，會(huì)走到 doInitialization -> doModInitFunctions -> libSystemInitialized
3. LibSystem 初始化，會(huì)調(diào)用起 libdispatch_init，然后會(huì)調(diào)用 _os_object_init，這個(gè)函數(shù)里面調(diào)用了 _objc_init
4. _objc_init 中注冊(cè)并保存了 map_images、load_images、unmap_image 函數(shù)地址
5. 注冊(cè)完畢，繼續(xù)回到 recursiveInitialization 遞歸下一次調(diào)用。例如 libobjc，當(dāng) dyld 來(lái)到 recursiveInitialization 調(diào)用時(shí)，會(huì)觸發(fā) libsystem 調(diào)用到 _objc_init 里注冊(cè)好的回調(diào)函數(shù)進(jìn)行調(diào)用，就來(lái)到了 libobjc，然后調(diào)用 load_images

推薦參考：dyld詳解