本文的目的主要是分析dyld的加载流程。

1、知识补充

1.1 编译过程

其中编译过程如下图所示，主要分为以下几步：

step1: 载入源文件，包括.h、.m、.cpp等文件；
step2: 进行预处理，替换宏，删除注释，展开头文件，产生.i文件；
step3: 进行编译，将.i文件转换为汇编语言，产生.s文件；
step4: 进行汇编，将汇编文件转换为机器码文件，产生.o文件；
step5: 库链接，对.o文件中引用其他库的地方进行引用，生成最后的可执行文件。

流程图:

1.2 静态库&动态库

图示如下

1.3 Mach-O

Mach-O格式全称为Mach Object文件格式的缩写，是mac上可执行文件的格式，像我们编译过程产生的.O文件，以及程序的可执行文件，动态库等都是Mach-O文件

1.3.1 支持的文件类型

【Mach-O】 的三种文件类型：Executable、Dylib、Bundle

• Executable

Executable 是 app 的二进制主文件，我们可以在 Xcode 项目中的 products 文件中找到它：

• Dylib

Dylib 是动态库，动态库分为 动态链接库 和 动态加载库。

动态链接库：在没有被加载到内存的前提下，当可执行文件被加载，动态库也随着被加载到内存中。【随着程序启动而启动】

动态加载库：当需要的时候再使用 dlopen 等通过代码或者命令的方式加载。【程序启动之后】

• Bundle

Bundle 是一种特殊类型的Dylib，你无法对其进行链接。所能做的是在Runtime运行时通过dlopen来加载它，它可以在macOS 上用于插件。

• Image 和 Framework

Image （镜像文件）包含了上述的三种类型;
Framework 可以理解为动态库。

1.3.2 Mach-O结构

mach-o文件有如下几个部分组成：

1.3.3 镜像文件（Image File）

Mach-O镜像文件

【Mach-O】镜像文件 是由 segments 段组成的。

• 段的名称为大写格式

所有的段都是 page size 的倍数。

• 在arm64上为 16kB
• 其它架构为 4KB

1.4 虚拟内存

1.4.1 什么是虚拟内存

• 虚拟内存是一层间接寻址 。
• 虚拟内存是在物理内存上建立的一个逻辑地址空间。建立在进程和物理内存之间的中间层，它向上（应用）提供了一个连续的逻辑地址空间，向下隐藏了物理内存的细节。
• 虚拟内存被划分为一个个大小相同的Page（64位系统上是16KB），提高管理和读写的效率。 Page又分为只读和读写的Page。

1.4.2 虚拟内存的应用

• 虚拟内存解决的是管理所有进程使用物理RAM的问题。通过添加间接层来让每个进程使用 逻辑地址空间，它可以映射到RAM 上的某个物理页上。这种映射 不是一对一 的，逻辑地址可能映射不到 RAM 上，也有可能有多个逻辑地址映射到同一个物理RAM 上。
• 虚拟内存使得逻辑地址可以没有实际的物理地址，也可以让多个逻辑地址对应到一个物理地址。
  • 逻辑地址可能映射不到 RAM：在应用执行的时候，它被分配的逻辑地址空间都是可以访问的，当应用访问一个逻辑Page，而在对应的物理内存中并不存在的时候，这时候就发生了一次Page fault。当Page fault发生的时候，会中断当前的程序，在物理内存中寻找一个可用的Page，然后从磁盘中读取数据到物理内存，接着继续执行当前程序。
  • 多个逻辑地址映射到同一个物理RAM 上就是多进程共享内存。
• 对于文件可以不用一次性读入整个文件，可以使用分页映射 mmap（）的方式获取。也就是把文件 某个片段 映射到进程逻辑内存的 某个页 上。当某个想要读取的页没有在内存中，就会触发 page fault，内核只会读入那一页，实现文件的 懒加载。也就是说 Mach-O 文件中的 __TEXT 段可以映射到多个进程，并可以懒加载，且进程之间 共享内存。
• __DATA 段是可读写的。这里使用到了Copy-On-Write 技术，简称COW。 也就是多个进程共享一页内存空间时，一旦有进程要做写操作，它会先将这页内存内容复制一份出来，然后重新映射逻辑地址到新的RAM 页上。也就是这个进程自己拥有了那页内存的拷贝。这就涉及到了 clean/dirty page 的概念。dirty page 含有进程自己的信息，而clean page 可以被内核重新生成（重新读磁盘）。多以 dirty page 的代价大于 clean page。

1.5 内存页

虚拟内存 会被分为相同大小的块，这些块被称为内存页（page）。计算机处理器和它的内存管理单元（MMU - memory management unit）维护着一张将程序的 虚拟内存 映射到 物理地址 上的分页表 page table

1.6 ASLR

有两种主要的技术来保证应用的安全：ASLR 和 Code Sign。

ASLR的全称是Address space layout randomization，翻译过来就是“地址空间布局随机化”。App被启动的时候，程序会被映射到逻辑的地址空间，这个逻辑的地址空间有一个起始地址，而ASLR技术使得这个起始地址是随机的。如果是固定的，那么黑客很容易就可以由起始地址+偏移量找到函数的地址。

1.7 Code Signing

Code Sign 在运行时 验证 Mach-O 文件的签名，在进行Code Sign的时候，加密哈希不是针对于整个文件，而是针对于每一个Page的。并存储在 __LINKEDIT 中。这就保证了在dyld进行加载的时候，可以对每一个page进行独立的验证

1.8 exec()

• exec() 是一个系统调用。
• 系统内核把应用程序映射到新的地址空间，且每次起始位置都是随机的（因为ASLR）。并将起始位置到0x000000 这段范围的进程权限都标记为不可读写不可执行。
• 如果是32 位进程，这个范围至少是4kb ；如果是64位进程则至少是4GB。
• NULL指针引用和指针截断误差都是会被它捕获，这个范围也叫做 PAGEZERO

2. dyld

dyld(The dynamic link editor)是苹果的动态链接器，负责程序的链接及加载工作，是苹果操作系统的重要组成部分，存在于MacOS系统的(/usr/lib/dyld)目录下.在应用被编译打包成可执行文件格式的Mach-O文件之后 ，交由dyld负责链接，加载程序.

2.1 dyld缓存

dyld加载时，为了优化程序启动，启用了共享缓存（shared cache）技术。共享缓存会在进程启动时被dyld映射到内存中，之后，当任何Mach-O映像加载时，dyld首先会检查该Mach-O映像与所需的动态库是否在共享缓存中，如果存在，则直接将它在共享内存中的内存地址映射到进程的内存地址空间。在程序依赖的系统动态库很多的情况下，这种做法对程序启动性能是有明显提升的。

2.2 dyld流程

• Load dylibs

从主执行文件header获取到需要加载的所依赖的动态库列表，而header早就被内核映射过。然后它需要找到每个dylib，然后打开文件，读取文件起始位置，确保它是Mach-O文件。接着会找到代码签名并将其注册到内核。然后在dylib文件的每个segment 上调用 mmap（）。

应用所依赖的dylib文件可能会再依赖其他dylib，所有dyld所需要加载的是动态库列表一个递归依赖的集合。一般应用会加载100到400 个dylib文件，但大部分都是系统的dylib，它们会被预先计算和缓存起来，加载速度很快。

• Fix-ups

在加载所有的动态链接库之后，它们只是处在相互独立的状态，需要将它们绑定起来，这就是Fix-ups。代码签名使得我们不能修改指令，那样就不能让一个dylib 调用另一个 dylib，这是就需要很多间接层。

Mach-O中有很多符号，有指向当前 Mach-O 的，也有指向其他 dylib 的，比如printf。那么，在运行时，代码如何准确的找到printf的地址呢？

Mach-O中采用了PIC技术，全称是Position Independ code。意味着代码可以被加载到间接的地址上。当你的程序要调用printf的时候，会先在 __DATA 段中建立一个指针指向printf，在通过这个指针实现间接调用。dyld这时候需要做一些fix-up工作，即帮助应用程序找到这些符号的实际地址。主要包括两部分：rebasing和binding。

• Rebasing 和 Binding

Rebasing：在镜像内部调整指针的指向。
Binding： 将指针指向镜像外部的内容。

之所以需要Rebase，是因为刚刚提到的 ASLR 使得地址随机化，导致起始地址不固定，另外由于 Code Sign，导致不能直接修改 Image。Rebase的时候只需要增加对应的偏移量即可。(待Rebase的数据都存放在__LINKEDIT中，可以通过MachOView查看：Dynamic Loader Info -> Rebase Info)

Binding就是将这个二进制调用的外部符号进行绑定的过程。 比如我们objc代码中需要使用到NSObject, 即符号_OBJC_CLASS_$_NSObject，但是这个符号又不在我们的二进制中，在系统库 Foundation.framework中，因此就需要Binding这个操作将对应关系绑定到一起。

3. App 加载流程

在ViewController中重写了load方法，在main.m文件中新增一个名为lbhFunc的C++方法

load、lbhFunc和main 它们的执行顺序是什么？

创建一个新的工程project并按上面的要求重写load方法和新增lbhFunc方法，然后运行

//ViewController.m

@implementation ViewController

+ (void)load{
    NSLog(@"%s",__func__);
}

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

@end

// main.m
int main(int argc, char * argv[]) {
    
    NSLog(@"%s",__func__);
    
    return 0;
}

__attribute__((constructor)) void lbhFunc(){
    printf(" %s \n",__func__);
}

打印结果

+[ViewController load]
lbhFunc 
main

通过运行结果可以看出执行顺序为：load--> lbhFunc --> main，不是说main函数是入口函数吗，为什么它之前还调用这么多函数呢？

在main函数执行之前，到底还做了什么？

app启动起点

在前面demo中，在load方法处添加一个断点，等程序运行到此处，通过bt查找堆栈信息

也可以在xcode左侧的堆栈信息查看

从堆栈信息可以看出，在load函数执行前还执行了一系列方法，_dyld_start--> dyldbootstrap::start--> dyld::_main--> dyld::useSimulatorDyld--> start_sim--> dyld::_main--> dyld::initializeMainExecutable--> ImageLoader::runInitializers--> ImageLoader::processInitializers--> ImageLoader::recursiveInitialization--> dyld::notifySingle--> load_images

程序从dyld中的_dyld_start开始的，那我们从dyld开始研究。

4. 源码分析

准备一份dyld源码

4.1 dyld主流程分析

step1: 在源码dyld-750.6中全局搜索_dyld_start，会搜到dyldStartup.s文件，是由汇编实现的，以arm64架构为例进行探索。

通过汇编注释发现会调用dyldbootstrap::start(app_mh, argc, argv, dyld_mh, &startGlue)方法，是一个C++方法

step2: 源码中搜索dyldbootstrap找到命名作用空间，再在这个文件中查找start方法

其核心是返回值的调用了dyld的main函数

step3: 进入dyld::_main的源码实现

uintptr_t
_main(const macho_header* mainExecutableMH, uintptr_t mainExecutableSlide, 
        int argc, const char* argv[], const char* envp[], const char* apple[], 
        uintptr_t* startGlue)
{
    // 函数体分布在 6191 - 6828 行，太长了，可以去看源码。
}

在_main函数中主要做了一下几件事情：

part1: 环境变量配置，根据环境变量设置相应的值以及获取当前运行架构

part2: 共享缓存，检查是否开启了共享缓存，以及共享缓存是否映射到共享区域，例如UIKit、CoreFoundation等

part3: 主程序的初始化，调用instantiateFromLoadedImage函数实例化了一个ImageLoader对象

part4: 插入动态库

part5: link 主程序

part6: link 动态库

part7: 弱符号绑定

part8: 执行初始化方法

part9: 寻找主程序入口即main函数

4.2 局部流程分析

4.2.1 主程序初始化

step1: sMainExecutable表示主程序变量，查看其赋值，是通过instantiateFromLoadedImage方法初始化

//  主程序的初始化
//  加载可执行文件，生成一个ImageLoader实例对象
sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);
        gLinkContext.mainExecutable = sMainExecutable;
        gLinkContext.mainExecutableCodeSigned = hasCodeSignatureLoadCommand(mainExecutableMH);

step2: 进入instantiateFromLoadedImage源码，通过instantiateMainExecutable方法创建一个ImageLoader实例对象

// 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
    if ( isCompatibleMachO((const uint8_t*)mh, path) ) {
        ImageLoader* image = ImageLoaderMachO::instantiateMainExecutable(mh, slide, path, gLinkContext);
        addImage(image);
        return (ImageLoaderMachO*)image;
    }
    
    throw "main executable not a known format";
}

step3: 进入instantiateMainExecutable源码，其作用是为主可执行文件创建映像，返回一个ImageLoader类型的image对象，即主程序。其中sniffLoadCommands函数时获取Mach-O类型文件的Load Command的相关信息，并对其进行各种校验

// create image for main executable
ImageLoader* ImageLoaderMachO::instantiateMainExecutable(const macho_header* mh, uintptr_t slide, const char* path, const LinkContext& context)
{
    //dyld::log("ImageLoader=%ld, ImageLoaderMachO=%ld, ImageLoaderMachOClassic=%ld, ImageLoaderMachOCompressed=%ld\n",
    //  sizeof(ImageLoader), sizeof(ImageLoaderMachO), sizeof(ImageLoaderMachOClassic), sizeof(ImageLoaderMachOCompressed));
    bool compressed;
    unsigned int segCount;
    unsigned int libCount;
    const linkedit_data_command* codeSigCmd;
    const encryption_info_command* encryptCmd;
    sniffLoadCommands(mh, path, false, &compressed, &segCount, &libCount, context, &codeSigCmd, &encryptCmd);
    // instantiate concrete class based on content of load commands
    if ( compressed ) 
        return ImageLoaderMachOCompressed::instantiateMainExecutable(mh, slide, path, segCount, libCount, context);
    else
#if SUPPORT_CLASSIC_MACHO
        return ImageLoaderMachOClassic::instantiateMainExecutable(mh, slide, path, segCount, libCount, context);
#else
        throw "missing LC_DYLD_INFO load command";
#endif
}

4.2.2 执行初始化方法

step1: 进入initializeMainExecutable源码,主要是循环遍历，都会执行runInitializers方法

void initializeMainExecutable()
{
    // record that we've reached this step
    gLinkContext.startedInitializingMainExecutable = true;

    // run initialzers for any inserted dylibs
    ImageLoader::InitializerTimingList initializerTimes[allImagesCount()];
    initializerTimes[0].count = 0;
    const size_t rootCount = sImageRoots.size();
    if ( rootCount > 1 ) {
        for(size_t i=1; i < rootCount; ++i) {
                   //  重点
            sImageRoots[i]->runInitializers(gLinkContext, initializerTimes[0]);
        }
    }
    
    // run initializers for main executable and everything it brings up 
    // 运行主要可执行的初始化程序及其所带来的一切
    sMainExecutable->runInitializers(gLinkContext, initializerTimes[0]);
    
    // register cxa_atexit() handler to run static terminators in all loaded images when this process exits
    if ( gLibSystemHelpers != NULL ) 
        (*gLibSystemHelpers->cxa_atexit)(&runAllStaticTerminators, NULL, NULL);

    // dump info if requested
    if ( sEnv.DYLD_PRINT_STATISTICS )
        ImageLoader::printStatistics((unsigned int)allImagesCount(), initializerTimes[0]);
    if ( sEnv.DYLD_PRINT_STATISTICS_DETAILS )
        ImageLoaderMachO::printStatisticsDetails((unsigned int)allImagesCount(), initializerTimes[0]);
}

其核心代码runInitializers

step2: 全局搜索runInitializers，找到如下源码

void ImageLoader::runInitializers(const LinkContext& context, InitializerTimingList& timingInfo)
{
    uint64_t t1 = mach_absolute_time();
    mach_port_t thisThread = mach_thread_self();
    ImageLoader::UninitedUpwards up;
    up.count = 1;
    up.imagesAndPaths[0] = { this, this->getPath() };
    processInitializers(context, thisThread, timingInfo, up);
    context.notifyBatch(dyld_image_state_initialized, false);
    mach_port_deallocate(mach_task_self(), thisThread);
    uint64_t t2 = mach_absolute_time();
    fgTotalInitTime += (t2 - t1);
}

其核心代码是processInitializers函数的调用

step3: 全局搜索processInitializers函数

// <rdar://problem/14412057> upward dylib initializers can be run too soon
// To handle dangling dylibs which are upward linked but not downward, all upward linked dylibs
// have their initialization postponed until after the recursion through downward dylibs
// has completed.
void ImageLoader::processInitializers(const LinkContext& context, mach_port_t thisThread,
                                     InitializerTimingList& timingInfo, ImageLoader::UninitedUpwards& images)
{
    uint32_t maxImageCount = context.imageCount()+2;
    ImageLoader::UninitedUpwards upsBuffer[maxImageCount];
    ImageLoader::UninitedUpwards& ups = upsBuffer[0];
    ups.count = 0;
    // Calling recursive init on all images in images list, building a new list of
    // uninitialized upward dependencies.
    // 在镜像列表中的所有镜像上递归调用实例化，以建立未初始化的向上依赖关系
    for (uintptr_t i=0; i < images.count; ++i) {
        images.imagesAndPaths[i].first->recursiveInitialization(context, thisThread, images.imagesAndPaths[i].second, timingInfo, ups);
    }
    // If any upward dependencies remain, init them.
    if ( ups.count > 0 )
        processInitializers(context, thisThread, timingInfo, ups);
}

step4: 全局搜索recursiveInitialization(cons函数

void ImageLoader::recursiveInitialization(const LinkContext& context, mach_port_t this_thread, const char* pathToInitialize,
                                          InitializerTimingList& timingInfo, UninitedUpwards& uninitUps)
{
    recursive_lock lock_info(this_thread);
    recursiveSpinLock(lock_info);//递归加锁

    if ( fState < dyld_image_state_dependents_initialized-1 ) {
        uint8_t oldState = fState;
        // break cycles  结束递归循环
        fState = dyld_image_state_dependents_initialized-1;
        try {
            // initialize lower level libraries first
            for(unsigned int i=0; i < libraryCount(); ++i) {
                ImageLoader* dependentImage = libImage(i);
                if ( dependentImage != NULL ) {
                    // don't try to initialize stuff "above" me yet
                    if ( libIsUpward(i) ) {
                        uninitUps.imagesAndPaths[uninitUps.count] = { dependentImage, libPath(i) };
                        uninitUps.count++;
                    }
                    else if ( dependentImage->fDepth >= fDepth ) {
                        dependentImage->recursiveInitialization(context, this_thread, libPath(i), timingInfo, uninitUps);
                    }
                }
            }
            
            // record termination order
            if ( this->needsTermination() )
                context.terminationRecorder(this);

            // let objc know we are about to initialize this image
            // 让objc 知道我们将要初始化此镜像
            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);
            }
        }
        catch (const char* msg) {
            // this image is not initialized
            fState = oldState;
            recursiveSpinUnLock();
            throw;
        }
    }
    
    recursiveSpinUnLock();
}

在这里，需要分成两部分探索，一部分是notifySingle函数，一部分是doInitialization函数，首先探索notifySingle函数

4.2.2.1 notifySingle函数

step1: 全局搜索notifySingle(函数,其重点是(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());这句

step2: 全局搜索sNotifyObjCInit，发现没有找到实现，有赋值操作

step3: 搜索registerObjCNotifiers在哪里调用了，发现在_dyld_objc_notify_register进行了调用

注意：_dyld_objc_notify_register的函数需要在libobjc源码中搜索

step4: 在objc4-781源码中搜索_dyld_objc_notify_register，发现在_objc_init源码中调用了该方法，并传入了参数，所以sNotifyObjCInit的赋值的就是objc中的load_images，而load_images会调用所有的+load方法。所以综上所述，notifySingle是一个回调函数

4.2.2.2 load函数加载

下面我们进入load_images的源码看看其实现，以此来证明load_images中调用了所有的load函数

step1: 通过objc源码中_objc_init源码实现，进入load_images的源码实现

step2: 进入call_load_methods源码实现，可以发现其核心是通过do-while循环调用+load方法

step3: 进入call_class_loads源码实现，了解到这里调用的load方法证实我们前文提及的类的load方法

所以，load_images调用了所有的load函数，以上的源码分析过程正好对应堆栈的打印信息

【总结】load的源码链为：_dyld_start --> dyldbootstrap::start --> dyld::_main --> dyld::initializeMainExecutable --> ImageLoader::runInitializers --> ImageLoader::processInitializers --> ImageLoader::recursiveInitialization --> dyld::notifySingle(是一个回调处理) --> sNotifyObjCInit --> load_images(libobjc.A.dylib)

那么问题又来了，_objc_init是什么时候调用的呢？请接着往下看

4.2.2.3 doInitialization 函数

doInitialization函数入口是在recursiveInitialization函数中

step1: 进入doInitialization函数的源码实现

这里也需要分成两部分，一部分是doImageInit函数，一部分是doModInitFunctions函数

• 进入doImageInit源码实现，其核心主要是for循环加载方法的调用，这里需要注意的一点是，libSystem的初始化必须先运行

• 进入doModInitFunctions源码实现，这个方法中加载了所有Cxx文件

还是没有找到_objc_init的调用？怎么办呢？我们还可以通过_objc_init加一个符号断点来查看调用_objc_init前的堆栈信息

step1: _objc_init加一个符号断点，运行程序，查看_objc_init断住后的堆栈信息

step2: 在libsystem中查找libSystem_initializer，查看其中的实现

libSystem_initializer中会调用libdispatch_init函数，而这个函数的源码是在libdispatch开源库中的

step3: 在libdispatch中搜索libdispatch_init

step4: 进入_os_object_init源码实现，其源码实现调用了_objc_init函数

【总结】：_objc_init的源码链：_dyld_start --> dyldbootstrap::start --> dyld::_main --> dyld::initializeMainExecutable --> ImageLoader::runInitializers --> ImageLoader::processInitializers --> ImageLoader::recursiveInitialization --> doInitialization --> libSystem_initializer（libSystem.B.dylib） --> _os_object_init（libdispatch.dylib） --> _objc_init(libobjc.A.dylib)

dyld流程图