OC底层原理09:dyld加载过程

326 阅读8分钟

引用iOS-底层原理 15:dyld加载流程

本文主要分析dyld的加载流程,了解在main函数之前,底层做了什么

引用

//ViewController.m
@implementation ViewController

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

- (void)viewDidLoad {
    [super viewDidLoad];
}
@end

//mian.m
int main(int argc, char * argv[]) {
    NSString * appDelegateClassName;
    NSLog(@"main");
    @autoreleasepool {
        // Setup code that might create autoreleased objects goes here.
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
    }
    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}

// load -> Cxx -> main
__attribute__((constructor)) void kcFunc(){
    printf("来了 : %s \n",__func__);
}

打印是:+[ViewController load], 来了 : kcFunc ,main. 也就是 load --> C++方法 --> main。 我们看下main之前,系统做了什么

编译过程及库

在分析app启动之前,我们需要先了解iOSapp代码的编译过程以及动态库静态库

编译过程

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

image.png

  • 源文件:载入.h、.m、.cpp等文件

  • 预编译:替换宏,删除注释,展开头文件,产生.i文件

  • 编译:将.i文件转换为汇编语言,产生.s文件

  • 汇编:将汇编文件转换为机器码文件,产生.o文件

  • 链接:对.o文件中引用其他库的地方进行引用,生成最后的可执行文件

静态库和动态库

程序运行起来之前,需要依赖底层很多库 静态库(.a.lib) 和 动态库(.so.framwork)

  • 静态库:在链接阶段,会将可汇编生成的目标程序与引用的库一起链接打包到可执行文件当中。此时的静态库就不会在改变了,因为它是编译时被直接拷贝一份,复制到目标程序里的

    • 好处:编译完成后,库文件实际上就没有作用了,目标程序没有外部依赖,直接就可以运行
    • 缺点:由于静态库会有两份,所以会导致目标程序的体积增大,对内存、性能、速度消耗很大
  • 动态库:程序编译时并不会链接到目标程序中,目标程序只会存储指向动态库的引用,在程序运行时才被载入

    • 优势

      • 减少打包之后app的大小:因为不需要拷贝至目标程序中,所以不会影响目标程序的体积,与静态库相比,减少了app的体积大小
      • 共享内存,节约资源:同一份库可以被多个程序使用
      • 通过更新动态库,达到更新程序的目的:由于运行时才载入的特性,可以随时对库进行替换,而不需要重新编译代码
    • 缺点:动态载入会带来一部分性能损失,使用动态库也会使得程序依赖于外部环境,如果环境缺少了动态库,或者库的版本不正确,就会导致程序无法运行

dyld加载流程分析

根据dyld源码,以及libobjclibSystemlibdispatch源码协同分析。 dyld(the dynamic link editor)是苹果的动态链接器,是苹果操作系统的重要组成部分,在app被编译打包成可执行文件格式的Mach-O文件后,交由dyld负责连接,加载程序。 App的启动流程图如下:

image.png

app启动的起始点

在前文的demo中,在load方法处加一个断点,通过bt堆栈信息查看app启动是从哪里开始的

image.png 通过程序运行发现,是从dyld中的_dyld_start开始的,所以需要去OpenSource下载一份dyld的源码来进行分析。

也可以通过xcode左侧的堆栈信息来找到入口。

image.png 可以留意一下调用栈方法,后续会分析到相关流程。

dyld::_main函数源码分析

dyld-750.6源码为例 dyld-750.6分析工程.zip: pan.baidu.com/s/1BT1Jnxr-…  密码: 40i1

_dyld_start

dyld-750.6源码中查找_dyld_start,查找arm64架构发现,是由汇编实现,通过汇编注释发现会调用dyldbootstrap::start(app_mh, argc, argv, dyld_mh, &startGlue)方法,是一个C++方法(以arm64架构为例) image.png

源码中搜索dyldbootstrap这个命名作用空间,再在这个文件中查找start方法,其核心是返回值的调用了dyldmain函数 image.png 其中macho_headerMach-O的头部,而dyld加载的文件就是Mach-O类型的,即Mach-O类型是可执行文件类型,由四部分组成:Mach-O头部、Load Command、section、Other Data,可以通过MachOView查看可执行文件信息

image.png

dyld::_main

进入dyld::_main的源码实现,特别长,大约600多行,如果对dyld加载流程不太了解的童鞋,可以根据_main函数的返回值进行反推,这里就多作说明。在_main函数中主要做了一下几件事情:

【第一步:环境变量配置】:根据环境变量设置相应的值以及获取当前运行架构

image.png

【第二步:共享缓存】:检查是否开启了共享缓存,以及共享缓存是否映射到共享区域,例如UIKitCoreFoundation

image.png

【第三步:主程序的初始化】:调用instantiateFromLoadedImage函数实例化了一个ImageLoader对象

image.png

【第四步:插入动态库】:遍历DYLD_INSERT_LIBRARIES环境变量,调用loadInsertedDylib加载

image.png

【第五步:link 主程序

image.png

【第六步:link 动态库

image.png

【第七步:弱符号绑定

image.png

【第八步:执行初始化方法

image.png

【第九步:寻找主程序入口main函数】

Load Command读取LC_MAIN入口,如果没有,就读取LC_UNIXTHREAD,这样就来到了日常开发中熟悉的main函数了

image.png

下面主要分析下【第三步】、【第八步】和【第九步】.

第三步:主程序初始化

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

    image.png

  • 进入instantiateFromLoadedImage源码,其中创建一个ImageLoader实例对象,通过instantiateMainExecutable方法创建

    image.png

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

    image.png

第八步:执行初始化方法

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

    image.png

  • 全局搜索runInitializers(cons,找到如下源码,其核心代码是processInitializers函数的调用

    image.png

  • 进入processInitializers函数的源码实现,其中对镜像列表调用recursiveInitialization函数进行递归实例化

    image.png

  • 全局搜索recursiveInitialization(cons函数,其源码实现如下

    image.png

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

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

image.png

  • 全局搜索sNotifyObjCInit,发现没有找到实现,有赋值操作

image.png

  • 搜索registerObjCNotifiers在哪里调用了,发现在_dyld_objc_notify_register进行了调用

image.png 注意:_dyld_objc_notify_register的函数需要在libobjc源码中搜索.

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

image.png

load函数加载

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

  • 通过objc源码中_objc_init源码实现,进入load_images的源码实现

    image.png

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

    image.png

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

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

image.png 【总结】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是什么时候调用的呢?请接着往下看

doInitialization 函数
  • 走到objc_objc_init函数,发现走不通了,我们回退到recursiveInitialization递归函数的源码实现,发现我们忽略了一个函数doInitialization

    image.png

  • 进入doInitialization函数的源码实现

    image.png 这里也需要分成两部分,一部分是doImageInit函数,一部分是doModInitFunctions函数.

doImageInit函数

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

image.png

doModInitFunctions源码

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

image.png

可以通过测试程序的堆栈信息来验证,在C++方法处加一个断点.

image.png

走到这里,还是没有找到_objc_init的调用?我们还可以通过_objc_init加一个符号断点来查看调用_objc_init前的堆栈信息.

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

    image.png 会走到libsystem.B.dyliblibSystem_initializer.

  • libsystem源码中查找libSystem_initializer,查看其中的实现

    image.png

  • 根据前面的堆栈信息,我们发现走的是libSystem_initializer中会调用libdispatch_init函数,而这个函数的源码是在libdispatch开源库中的,在libdispatch中搜索libdispatch_init image.png

  • 进入_os_object_init源码实现,其源码实现调用了_objc_init函数

    image.png 结合上面的分析,从初始化_objc_init注册的_dyld_objc_notify_register的参数2,即load_images,到sNotifySingle --> sNotifyObjCInie=参数2sNotifyObjcInit()调用,形成了一个闭环

所以可以简单的理解为sNotifySingle这里是添加通知即addObserver_objc_init中调用_dyld_objc_notify_register相当于发送通知,即push,而sNotifyObjcInit相当于通知的处理函数,即selector

【总结】:_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)

第九步:寻找主入口函数

  • 汇编调试,可以看到显示来到+[ViewController load]方法

    image.png

  • 继续执行,来到kcFunc的C++函数

    image.png

  • 点击step over,继续往下,跑完了整个流程,会回到_dyld_start,然后调用main()函数,通过汇编完成main的参数赋值等操作

    image.png dyld汇编源码实现

image.png

注意:main是固定写死的函数名字,写入内存,读取到dyld,如果修改了main函数的名称,会报错
所以,综上所述,最终dyld加载流程,如下图所示,图中也诠释了前文中的问题:为什么是load-->Cxx-->main的调用顺序

image.png

关于装载链接详细参照《程序员自我修养》

文章列表

博客文章列表