OC底层探索16 -应用程序加载

1、库&静态库&动态库&dyld

1.1 库

• 库是已写好的、供使用的可复用代码集合，每个程序都要依赖很多基础的底层库，而且是已经编译好的二进制文件。

• 从本质上，库是一种可执行代码的二进制形式。可以被操作系统载入内存执行。库分为两种：静态库（.a .lib）和 动态库 （framework .so .dll）。

• 动&静的不同主要区分在链接方式：动态链接、静态链接

1.2 静态库

• 使用静态链接:链接时会被完整的复制到可执行文件中去，所以如果两个进程（程序）都使用了某个静态库，则这两个进程中都需要包含这份静态库的代码。而且链接时机在编译时期;
• 静态库:在编译时链接的库，需要链接到mach-O文件中去，如果需要更新则需要重新编译。

• 优点：加载快；缺点：会增加程序体积，更新需要重新编译

  
  静态库

1.3 动态库

• 动态链接:链接时不复制，程序运行时由系统动态的添加到内存中供程序使用，系统只会添加一次，多个程序公用。
• 动态库:在运行时链接的库，使用dyld动态链接器完成链接。并没有参与mach-O的编译。

• 优点：不增加程序体积；缺点：动态链接是一个耗时的操作

  
  动态库

1.4 dyld动态链接器

dyld（the dynamic link editor）:【动态链接器】是苹果操作系统一个重要部分，在 iOS / macOS 系统中，仅有很少的进程只需内核就可以完成加载，基本上所有的进程都是动态链接的，所以 Mach-O 镜像文件中会有很多对外部的库和符号的引用，但是这些引用并不能直接用，在启动时还必须要通过这些引用进行内容填充，这个填充的工作就是由 dyld 来完成的。

2、应用程序加载流程

库&静态库&动态库&dyld分别了解后，需要对整个流程有个认识。

应用程序编译过程.png

3、APP启动加载流程

在任意+(void)load方法中打下断点。

启动入口

• 根据堆栈信息得知：程序加载的第一步就是dyld的_dydl_start函数，通过下载dyld-源码来进一步探索。

3.1 _dyld_start函数

_dyld_start

• 会有不同的硬件架构对于的处理，最终指向这个dyldbootstrap::start函数

3.2 start函数

源文件-预编译-编译-汇编-链接-可执行文件 - dyld加载
链接： dyld链接器 - 动静态库（加载UIkit、FOunation库、libSystem） -读到 内存（表）-加载主程序中 -link（链接主程序-链接动态库）-库的初始化- main（）

start

3.3 dyld::main函数

这就是dyld最重要的方法。

uintptr_t
_main(const macho_header* mainExecutableMH, uintptr_t mainExecutableSlide, 
        int argc, const char* argv[], const char* envp[], const char* apple[], 
        uintptr_t* startGlue)
{
    ......

    // 第一步、设置运行环境，可执行文件准备工作
    ......

    // 第二步、 加载共享缓存(已经加载到内存中的动态库无需再次加载，如：UIKit、Founation等)
    //load shared cache   
    mapSharedCache();
    ......

reloadAllImages:

    ......
    // 第三步、 加载可主执行文件并生成一个ImageLoader实例对象
    // instantiate ImageLoader for main executable
    sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);

    ......

    // 第四步、   加载插入的动态库
    // load any inserted libraries 
    if  ( sEnv.DYLD_INSERT_LIBRARIES != NULL ) {
        for (const char* const* lib = sEnv.DYLD_INSERT_LIBRARIES; *lib != NULL; ++lib) 
            loadInsertedDylib(*lib);
    }
        
    // 第五步、  链接主程序
    // link main executable 
    link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);

    ......
    // 第六步、 链接所有插入的动态库
    // link any inserted libraries 
    if ( sInsertedDylibCount > 0 ) {
        for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
            ImageLoader* image = sAllImages[i+1];
            link(image, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL), -1);
            image->setNeverUnloadRecursive();
        }
        if ( gLinkContext.allowInterposing ) {
            for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
                ImageLoader* image = sAllImages[i+1];
                // 注册符号插入
                image->registerInterposing(gLinkContext);
            }
        }
    }

    ......
    // 第七步、 弱符号绑定
    sMainExecutable->weakBind(gLinkContext);
        
    sMainExecutable->recursiveMakeDataReadOnly(gLinkContext);

    ......
    // 第八步、   执行初始化方法
    // run all initializers 
    initializeMainExecutable(); 

    // 第九步、 main()调用
    // enter main()
    notifyMonitoringDyldMain();

    return result;
}

由于方法实在过长就简练最重要步骤，有兴趣的同学可以去dyld源码中一探究竟。

3.4 第八步initializeMainExecutable

重点函数，需要单独进行分析：

3.4.1 ImageLoader::runInitializers

3.4.2 ImageLoader::processInitializers

• 虽然该方法中循环只执行一次，但是processInitializers会有递归调用存在。

3.4.3 ImageLoader::recursiveInitialization

• 需要重点关注2个函数：
  1. notifySingle
  2. doInitialization

3.5 notifySingle函数

• 在dyld中出现了Objc...,就一定不简单
• (*sNotifyObjCInit)(image->getRealPath(), image->machHeader()); 传入镜像文件的真实地址进行sNotifyObjCInit调用（所有类的load方法的调用）。

3.5.1 sNotifyObjCInit赋值

• sNotifyObjCInit在该方法中进行了赋值

3.5.2 registerObjCNotifiers调用

• _dyld_objc_notify_register这个方法一定不陌生。

3.5.3 _objc_init

_objc_init

• 第二个参数：就是所有类的load方法调用

3.5.4 load_image

void
load_images(const char *path __unused, const struct mach_header *mh)
{
    // Call +load methods (without runtimeLock - re-entrant)
    call_load_methods();
}

void call_load_methods(void)
{
    do {
        // 1. Repeatedly call class +loads until there aren't any more
        while (loadable_classes_used > 0) {
            call_class_loads();
        }
        // 2. Call category +loads ONCE
        more_categories = call_category_loads();
        // 3. Run more +loads if there are classes OR more untried categories
    } while (loadable_classes_used > 0  ||  more_categories);
}

static void call_class_loads(void)
{
    int i;
    // Call all +loads for the detached list.
    for (i = 0; i < used; i++) {
        Class cls = classes[i].cls;
        load_method_t load_method = (load_method_t)classes[i].method;
        (*load_method)(cls, @selector(load));
    }
}

• 通过一系列的调用后，通过循环完成所有类load方法的函数调用。

3.5 小结

在runtime的初始化方法_objc_init中，将所有类load方法的注册到了dyld中等待dyld的调用。也就是说：所有类load方法调用是等：libobjc库加载完成后进行的。

3.6 doInitialization函数

3.5中提到了libobjc初始化时注册了所有类load方法,这一步就是libobjc初始化_objc_init调用的地方

• 在第一步中完成了所有动态库的init调用
• 在第二步中完成了所有c++函数的调用

3.7 main()

执行完dyld_start的所有函数之后，就会来到程序的入口main()函数

验证一下：

4、_objc_init调用时机

在3.5中提到了_objc_init中做了部分处理，只知道是在3.6 -doInitialization函数调用的,具体的调用时机需要在可执行的objc源码打下一个符号断定_objc_init。

4.1 libSystem库

libSystem库源码

libSystem-init

• 不但完成自己的初始化，还调起了dyld、pthread、libdisPatch等库
• libSystem库是第一个初始化的库

4.2 libdispatch库

libdispatch

• 最终调起_objc_init函数;

5、 总结

• 本文从动&静态库到dyld，着重分析了dyld通过9个步骤完成了APP的启动；期间对第八步initializeMainExecutable做了详细的分析；也分析了类的load方法是在dyld的完成调用的；同时也对libSystem、libDispatch、libObjc的依次调用做了分析；最后还通过源码分析了load方法、C++方法、main()的调用时机。
• 其实这只是dyld的冰山一角，希望以后有机会可以更加深入。

最后求个赞，不过分吧~~~