010-iOS底层原理-dyld加载流程

引言

本文主要探索dyld的加载流程，了解应用程序在main函数之前都做了什么准备工作，了解dyld是什么，我们所编写的代码、framework等是如何加载到内存里变活起来的。

dyld

dyld（The dynamic link editor ）是苹果的动态链接器，是苹果操作系统的重要组成部分，在我们的代码被编译打包成可执行文件的 Mach-O 文件之后 ，交由 dyld 负责链接 , 加载程序 。
dyld源码
本文用的是dyld-852版本的源码。

探索1

main -> start符号断点，调用栈

我们新建一个iOS工程，在main.m中打个断点，运行项目，查看调用堆栈，如图所示：

main调用堆栈

调用栈汇编

添加start符号断点

load方法和__attribute__

在ViewController.m中添加load方法

#import "ViewController.h"
@interface ViewController ()

@end
@implementation ViewController
+(void)load {
    NSLog(@"---%s---",__func__);
}
- (void)viewDidLoad {
    [super viewDidLoad];   
}
@end

在main.m中添加__attribute__

int main(int argc, char * argv[]) {
    NSString * appDelegateClassName;
    @autoreleasepool {
        NSLog(@"main 函数");
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
    }
    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}
//确保此函数在 在main函数被调用之前调用
__attribute__ ((constructor))void before_main(){
    printf("main 前 ：%s\n",__func__);
}

这三者打印顺序如何呢？如图所示：

打印顺序

load方法断点

在ViewController.m中的+load方法添加断点，运行后如图所示：

load断点

bt打印调用堆栈

dyld源码

下载好dyld-852后，打开dyld源码工程，由于工程底部所依赖的系统库太多（libdispatch，libsystem），运行不起来无法调试。

dyldbootstrap::start

全局搜索_dyld_start

_dyld_start

dyldbootstrap::start函数内部

dyld::_main

dyld::_main函数是我们此次研究的重头戏，点进去之后，发现它是一个800多行代码的一个函数。

dyld::_main

return result

result找到sMainExecutable

sMainExecutable的赋值

instantiateMainExecutable

MachOView

dyld::_main内部总结（借助注释来查看）

1.【第一步：条件准备】：环境配置、平台、版本、路径、主机信息等

第一步：条件准备

共享缓存配置

实例化主程序

插入动态库

link主程序和动态库

weakBind弱引用绑定主程序

运行所有初始化

寻找main函数

【第七步：初始化主程序】initializeMainExecutable的分析

1.进入initializeMainExecutable后，for循环将插入的动态库初始化。然后执行runInitializers初始化主程序。

initializeMainExecutable

sMainExecutable->runInitializers

processInitializers

doInitialization

进入到doInitialization函数，有两个函数调用

doInitialization函数

doImageInit

before_main调用栈

**陷入迷茫，无法继续下一步，返回到ImageLoader::recursiveInitialization函数，探索notifySingle

notifySingle

1.点击进入notifySingle，发现来到的是函数声明的地方，void (*notifySingle)(dyld_image_states, const ImageLoader* image, InitializerTimingList*);
2.全局搜索notifySingle(，找到它的实现：

notifySingle内部实现

sNotifyObjCInit赋值

image.png

6.打开objc4_818_2工程，全局搜索_dyld_objc_notify_register。在_objc_init函数中，找到其调用位置，其中load_images为dyld中registerObjCNotifiers为sNotifyObjCInit赋值的参数。而load_images，是一个函数，由此可知，dyld通知objc的方式，是通过load_images函数进行回调的。也就是说，dyld中的notifySingle是一个回调函数。

objc -> _dyld_objc_notify_register

load_images

进入load_images，首先查找发现所有+load方法，然后执行所有+load方法

load_images

call_load_methods

call_class_loads()

+load流程

调用流程如图所示：

+load调用栈

doInitialization未完成的流程

前面进入doInitialization内部后，发现无法继续深入，此时，我们回到objc调试工程，添加符号断点_objc_init。如图所示

_objc_init符号断点调用栈

_os_object_init

_os_object_init位于libdispatch.dylib库中，我们将下载libdispatch-1271.40.12源码
，解压后打开工程，全局搜索_os_object_init

_os_object_init

libdispatch_init

在之前的调用栈中，libdispatch_init是由libSystem_initializer调起的，此函数位于libSystem.B.dylib库中。我们将下载Libsystem-1292.60.1源码解压后打开工程，全局搜索libdispatch_init，确实位于libSystem_initializer中调用了。

libSystem_initializer

_objc_init流程

→_dyld_start(dyld)
→dyldbootstrap::start(dyld)
→dyld::_main(dyld)
→dyld::initializeMainExecutable(dyld)
→ImageLoader::runInitializers(dyld)
→ImageLoader::processInitializers(dyld)
→ImageLoader::recursiveInitialization(dyld)
→ImageLoaderMachO::doInitialization(dyld)
→ImageLoaderMachO::doModInitFunctions(dyld)
→libSystem_initializer(libSystem)
→libdispatch_init(libdispatch)
→_os_object_init(libdispatch)
→_objc_init(libobjc)

总结

本文Demo
dyld主线加载流程流程图如下：

dyld加载流程.png