本文由快学吧个人写作，以任何形式转载请表明原文出处

一、资料准备

1. objc4-818.2

对应mac的版本是11.1。可根据自己的系统版本挑选可以进行调试的源码。

2. dyld3-852。

因为mac的版本我没有更新过，一直停留在11.1，所以我选择的dyld源码也是老版本的dyld3，最新版本的dyld4会在系统更新之后再单独写一篇关于dyld4的个人见解。

3. 关于dyld和库，以及framework的一些简单的内容放在了上一章。另外，源码中有注释的地方一定是比较重要的地方，否则不会进行注释。所以自己探索的时候，有注释的地方可当作重点来看。

二、项目准备

新建一个正常的iOS的项目。

三、思路

1. 一个常规的iOS项目的启动会从main.m中的main函数开始。而在开发中，曾发现+load方法会比main.m更先调用。
2. 既然main函数不是最早的程序启动入口，那么+load是不是？或者说load之前是否还做过一些其他的操作？
3. 库是怎么进入到了项目中的？dyld到底做了什么？

四、程序的main函数之前还做了什么

1. 在准备的项目中的ViewController里面实现+load方法。在main.m处打上断点。运行程序，运行结果如下图。

2. 可以看到load是在main函数之前就调用了。那么load是怎么调用的？在load处打上断点。运行程序，查看堆栈信息(lldb命令是bt，xcode自带查看堆栈信息的地方)。

3. 调用信息是从下向上看，所以在load之前，最开始调用的是_dyld_start。

五、如何查找dyld的执行流程

1. 打开dyld852源码，全局搜索_dyld_start。只看arm64架构下的。汇编看不懂无所谓，后面有注释。

2. 直接搜::start或者dyldbootstrap::start(是搜不到的，所以start不是一个c++的函数，那么作为一个oc的底层，最可能的就是c函数，c函数的书写规范是:void + 空格 + 函数名 + (，例如:void test()。所以搜空格 + start(。

3. dyld::main可以直接跳转到源码，直接进入dyld的main源码，这里就是dyld的主程序，也就是dyld做了什么。

六、dyld的执行流程

1. 怎么去看dyld的main函数

明确目的 : 为了找dyld怎么加载的库，怎么就调用到了ViewController的+load方法。+load方法可是objc库中的方法，也就是在libobjc动态库中，而不是dyld中的方法。

1. 看参数。dyld的main函数都有哪些参数，既然有这些参数，那么基本都是要用的。
2. 有备注的一般比较重要，可以从中挑选重要的内容。
3. 只看arm64架构下的。

2. dyld的简要流程

1. 环境变量的处理

2. 加载共享缓存

检查共享缓存是否可用，iOS中是必须开启共享缓存的。映射共享缓存到共享区。像我们常用的UIKit、CoreFoundation框架，都是要映射加载到共享缓存区的。

3. 把dyld自己加到uuid列表中

4. 为主可执行程序实例化一个镜像加载器

说人话就是实例化一个主程序。

5. 加载所有的动态库

把所有的lib库都变成了image(镜像)，在需要的时候，就可以直接map(映射)到上面。

6. 链接主可执行程序

7. 链接动态库

8. 执行弱绑定

9. 运行所有的初始化程序

10. 查找main()函数入口

11. 小结

从上面的流程可以看到，dyld是在第5步的时候，通过遍历环境变量中的DYLD_INSERT_LIBRARIES标识，把所有插入的动态库都加载到内存中。

那么dyld是怎么调用起的objc库中的+load方法？

回看在+load处断点拿到的堆栈信息 :

3. initializeMainExecutable

1. 通过堆栈信息可以看到，ViewController在调用load方法之前，是进入了dyld的main函数，然后一直到initializeMainExecutable这里，这就是上面的dyld简要流程中的 : 9.运行所有的初始化程序。

2. 跟着堆栈信息进源码 : initializeMainExecutable ---> runInitializers(需要全局搜索) ---> processInitializers(需要全局搜索) ---> recursiveInitialization(需要全局搜索) ---> notifySingle(需要全局搜索)

3. sNotifyObjCInit需要存储的是一个函数的地址。在这里进行回调，完成初始化程序。那么就需要找sNotifyObjCInit在哪里被赋值，被给予函数地址。全局搜索sNotifyObjCInit。

4. 那么哪里调用了registerObjCNotifiers，对sNotifyObjCInit进行赋值？搜索registerObjCNotifiers。

5. 找到了_dyld_objc_notify_register。再看dyld里面谁给_dyld_objc_notify_register进行了赋值，在dyld里面再就找不到相关的代码，但是在上面打印的堆栈信息中可以看到，notifySingle之后的一步，执行的代码的库已经变成了libobjc。

6. 既然是libobjc，那么上面准备好的项目就是可以利用的。在上面准备好的项目中打一个_dyld_objc_notify_register的符号断点，再运行程序看看哪里调用的_dyld_objc_notify_register。

7. 找到objc4-818.2的源码，查找_dyld_objc_notify_register。

8. 发现进入了objc库的初始化函数。而dyld中的sNotifyObjCInit存储的是load_images函数的地址，也就是调用sNotifyObjCInit就等于调用load_images。

9. 在查看_dyld_objc_notify_register断点的堆栈信息的时候，也可以根据堆栈信息得到一个结论 : 运行所有库的初始化也是有顺序的，堆栈信息从下向上看，就是调用顺序，先是libSystem初始化、然后是libdispatch初始化，然后是libobjc初始化。

七、总结

1. dyld的入口是 : _dyld_start，_dyld_start会调用dyldbootstrap::start函数。这不是一个c++函数，而是一个C函数。
2. start函数会返回dyld::main，也就是dyld的主函数。也就是_dyld_start会调起dyld的main函数。
3. dyld的main函数的主要流程 :

(1). 环境变量的检查和处理。

(2). 检查共享缓存是否可用(iOS环境下强制可用)，加载共享缓存，并将共享缓存映射到共享区。

(3). dyld将自己加入到UUID列表中。

(4). 为主可执行程序初始化一个镜像加载器。就是实例化这个主程序。

(5). 加载所有的动态库。就是将所有的动态库都变成镜像，在需要的地方，直接可以映射。

(6). 链接主可执行程序。

(7). 链接所有的动态库。链接动态库一定要在链接主可执行程序之后执行，这是为了保证主可执行程序的动态库的优先性，其他插入的动态库必须在主可执行程序的动态库的后面。

(8). 对主可执行程序执行弱绑定。

(9). 执行所有初始化函数。

(10). 找main()函数的入口

4. 在执行所有的初始化函数的时候，libSystem、libDispatch，libobjc，就会进行初始化，并且是按照libSystem ---> libDispatch ---> libobjc这个顺序初始化的。

5. dyld和libobjc的联系是通过通知来完成的，实质上是通过c的函数回调方式。