在讲dyld流程之前，我先提一个问题，就是在我们程序运行的时候，在main函数之前，会先走ViewController的load方法， 再走C++的方法，这是为什么？
带着这个问题，我们开始今天的探索之旅。
首先我们都知道在程序跑起来之前，依赖于很多库，比如说动态库和静态库，我们称为镜像文件images，这些库和文件在加载的时候都需要用到dyld程序进行链接，dyld是苹果的动态链接器，在程序加载前一个非常重要部分。链接完了之后就会生成一个可执行文件exec。 流程如下：
那么明白这一点之后，接下来我们分析整个的流程必然就从dyld入手，dyld是开源的，先从苹果开发者官网下载一份dyld，我这里下载的是750.6版本。
把dyld打开，打开之后发现里面东西很多，不知道从哪入手，不过看过我之前文章的人，我相信应该知道堆栈这个东西，就是bt，我们在load里面打个断点bt一下
bt之后我们可以看到最后一行的dyld_dyld_start，所以dyld入口就在_dyld_start`里面，接下来我们全局搜索找到相关源码
找到相应的入口之后，可以看到是通过一些汇编写的，看不懂没关系，旁边有注释，看注释看到了这一句# call dyldbootstrap::start(app_mh, argc, argv, dyld_mh, &startGlue) ，这就好办了，这是一个C++的开始函数，我们跟过去
跟过来之后，我们看到这里有一个main，我们可以从堆栈里面看出这是第二个流程。我们点到main里面去。
发现里面有大几百行代码，从头看到尾肯定不行， 那么看一下最后它最后的返回值是result，然后找到赋值的地方，发现主要是sMainExecutable这个主程序赋的值，那么接下来我们又开始找sMainExecutable这个玩意，最终发现它在6577行sMainExecutable = instantiateFromLoadedImage(mainExecutableMH, mainExecutableSlide, sExecPath);在这个地方进行了初始化，那么这个主程序是怎么进行初始化的呢，我们继续点到instantiateFromLoadedImage里面去看一看
进入instantiateFromLoadedImage源码后，发现创建了一个ImageLoader实例对象，通过instantiateMainExecutable方法创建
再进到instantiateMainExecutable里面，其作用是为主可执行文件创建映像，返回一个ImageLoader类型的image对象，即主程序。其中sniffLoadCommands函数时获取Mach-O类型文件的Load Command的相关信息，并对其进行各种校验
说到这里，我们的dyld究竟做了些什么事情， 主要分为以下几步：
1、环境变量的配置（根据环境变量设置相应的值以及获取当前运行架构）
2、检查共享缓存 (检查是否开启，以及共享缓存是否映射到共享区域，例如UIKit、CoreFoundation等)
3、主程序的初始化 （调用instantiateFromLoadedImage函数实例化了一个ImageLoader对象）
4、 加入动态库（遍历DYLD_INSERT_LIBRARIES环境变量，调用loadInsertedDylib）
5、link 链接主程序
6、link 链接动态库
7、main()(把链接起来的所有东西运行起来，并发送通知)
那么我们是怎么进行initializers初始化的呢，我们点进去看一下
来到initializeMainExecutable里面之后,我们看到主要是循环遍历，执行runInitializers方法。 我们再全局搜索runInitializers(cons,找到源码，其核心代码是processInitializers函数的调用
继续全局搜索processInitializers，来到processInitializers函数源码实现
这里重点在594行，对我们的镜像列表调用recursiveInitialization进行递归实例化，我们继续全局搜索recursiveInitialization一探到底
这个地方有两个重点，第一个重点是1595行和1603号都调用了notifySingle，并传入了dyld_image。 第二个重点是1598行this->doInitialization(context);，我们先来看看notifySingle做了什么操作
这里的重点是(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());这一句，然后再全局搜索sNotifyObjCInit，发现没有找到实现，只有赋值的操作
接着我们搜索registerObjCNotifiers在哪个地方调用了，结果发现在_dyld_objc_notify_register调用了
_dyld_objc_notify_register这个函数不知道大家熟不熟悉，反正它离我们很近，结果在我们libobjc源码中一搜索，就在我们的_objc_init里面
看到这里，sNotifyObjCInit的赋值的就是来自objc中的load_images，那么_objc_init是什么时候调用的呢，接下来我们回到上面说的二个重点的第二个重点this->doInitialization(context);
我们进入到doInitialization源码实现
这里有两句重点，我们先来看第一句doImageInit
进入到doImageInit之后，其核心主要是for循环加载方法的调用，这里需要注意的一点是，libSystem库的要求很高，需要先初始化运行，这里也标了注释libSystem initializer must run first
再来看看doModInitFunctions源码，这个方法中加载了所有Cxx文件
说了这么多，现在在load方法打个断点来看看堆栈和整个初始化过程
虽然把整个堆栈过程打印出来了，但是没有看到_objc_init的调用，我们再加个符号断点看一下
来到_objc_init之后，前面的流程都一样，来看一下libSystem_initializer。在libsystem工程中查找libSystem_initializer，查看源码实现
来到这个源码之后，我们看到走了libdispatch_init函数，在我们初始化过程里面
这个函数在libSystem_initializer前面，源码是在libdispatch.dylib开源库中的，接下来我们找到libdispatch搜索libdispatch_init，找到实现的源码如图：
在libdispatch_init源码里我们看到了_os_object_init，也在我们初始化过程里面，我们继续跟过去
跟过来之后，发现第一句就调用了_objc_init，_objc_init里面又调用了_dyld_objc_notify_register进行注册，传了第二个参数load_images。 注册了之后回到dyld里面的notifySingle， 然后会跳到sNotifyObjCInit = 参数2 调用sNotifyObjcInit()，形成了一个闭环
看到这里，总的流程总算是看完了，我这篇文章截图代码没有注释，所以不一定要搞懂代码的意思，只需了解dyld大致流程即可，毕竟这些代码没几个人能玩的通转。 整个流程如图：
明白了dyld的整体流程之后，我们再来看文章开始前提到的一个问题就很好分析了
首先在程序加载的时候来到objc_init调用_dyld_objc_notify_register
然后执行load_images，load_images里面有call_load_methods-> call_class_loads -> (*load_method)(cls, @selector(load)) 调用所有类的load
调用完load之后会来到doInitialization里面的doModInitFunctions，在doModInitFunctions会调用所有Cxx函数
可以打断点bt验证一下
走完Cxx函数之后我们接着往下走
走完之后会回到_dyld_start，此时register read读一下寄存器， rax 已经是main at main.m:15，然后循环完之后会jmpq跳到main函数里面。
这就是为什么调用顺序是load -> Cxx -> main
最后注意一点，main是写定的函数，写入内存，读取到dyld，所以main函数的名称是不能改的，改了就会报错
