iOS-底层原理13：dyld加载流程

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

1、知识补充

1.1 编译过程

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

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

流程图:

1.2 静态库&动态库

库类型	描述	优点	缺点
静态库	在链接阶段，会将可汇编生成的目标程序与引用的库一起链接打包到可执行文件当中。此时的静态库就不会在改变了，因为它是编译时被直接拷贝一份，复制到目标程序里的	编译完成后，库文件实际上就没有作用了，目标程序没有外部依赖，直接就可以运行	由于静态库会有两份，所以会导致目标程序的体积增大，对内存、性能、速度消耗很大
动态库	程序编译时并不会链接到目标程序中，目标程序只会存储指向动态库的引用，在程序运行时才被载入	1、减少app的大小：因为不需要拷贝至目标程序中，所以不会影响目标程序的体积，与静态库相比，减少了app的体积大小; 2、共享内存，节约资源：同一份库可以被多个程序使用; 3、通过更新动态库，达到更新程序的目的：由于运行时才载入的特性，可以随时对库进行替换，而不需要重新编译代码	动态载入会带来一部分性能损失，使用动态库也会使得程序依赖于外部环境，如果环境缺少了动态库，或者库的版本不正确，就会导致程序无法运行

图示如下

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文件有如下几个部分组成：

名称	作用
Header	保存了一些基本信息，包括了该文件运行的平台、文件类型、LoadCommands的个数等等。
LoadCommands	加载命令，在加载Mach-O文件时会使用这里的数据来确定内存的分布以及相关的加载命令。比如我们的main函数的加载地址，程序所需的dyld的文件路径，以及相关依赖库的文件路径。
Data	每个segment的具体数据保存在这里，包含具体的代码、数据等等。

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函数

//  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流程图