我们先来看看这个现象吧。
新建一个工程，如下，分别添加c++函数，和load方法，运行程序。
添加c++函数
重写load方法
查看结果
运行结果
按我们一般的认知，main函数才是程序的入口，为什么会有方法在main之前就运行呢？？？这不是搞笑呢吗？其实这都是有原因的，隆重请出今天的主角——dyld。
什么是dyld？
dyld（the dynamic link editor）是苹果的动态链接器，是苹果操作系统的重要组成部分，在app被编译打包成可执行文件格式的Mach-O文件后，交由dyld负责连接，加载程序
所以 App的启动流程图如下
image.png
由此可以看出，其实在进入main函数之前，还是有不少前戏的。那么我们就从控制台最先打印的load方法入手吧。直接给load打个断点，查看一下堆栈信息：
image.png
我们会发现，是从dyld中的_dyld_start开始的，所以需要去OpenSource下载一份最新dyld的源码来进行分析。
直接在源码中搜索_dyld_start，可以看到不通架构，有不同的实现，这里就只分析arm64，也就是真机的源码哦。
汇编源码
如上图，汇编前面在做一些准备工作，最终会调用dyldbootstrap::start方法，源码中搜索dyldbootstrap,找到它的命名空间,我觉得这里的命名空间可以理解为一个类，然后找到start方法
dyldbootstrap
start方法
通过注释分析，前面是对dyld的准备，我们直接定位到dyld::_main,我们直接定位到dyld::_main函数，注意这里的dyld::_main并非我们工程里的main函数。
找到dyld::_main后会发现，这这这太tm长了吧，不想看了，呜呜呜。
image.png
额，我还是简单总结一下吧。
【第一步：环境变量配置】：根据环境变量设置相应的值以及获取当前运行架构
【第二步：共享缓存】：检查是否开启了共享缓存，以及共享缓存是否映射到共享区域，例如UIKit、CoreFoundation等
【第三步：主程序的初始化】：调用instantiateFromLoadedImage函数实例化了一个ImageLoader对象，其中sniffLoadCommands函数时获取Mach-O类型文件的Load Command的相关信息，并对其进行各种校验
【第四步：插入动态库】：遍历DYLD_INSERT_LIBRARIES环境变量，调用loadInsertedDylib加载
【第五步：link 主程序】
【第六步：link 动态库】
【第七步：弱符号绑定】
【第八步：执行初始化方法】递归遍历实例化
【第九步：寻找主程序入口即main函数】：从Load Command读取LC_MAIN入口，如果没有，就读取LC_UNIXTHREAD，这样就来到了日常开发中熟悉的main函数了
看到这好像和开头的问题没撒关系啊。搞什么飞机，偏题了？
问题出在我偷懒了，我们俩看看第八步的具体实现吧。
image.png
进入该方法
image.png
找到关键代码
runInitializers,找到其实现
image.png
继续往下
image.png
找到关键代码
image.png
这里主要有
doInitialization和 notifySingle 两个函数，通过阅读注释，感觉notifySingle 是类似于通知的东西，我们来验证一下是不是呢notifySingle 函数
全局搜索notifySingle(函数,其重点是(*sNotifyObjCInit)(image->getRealPath(), image->machHeader());这句
image.png
找到如上关键代码，搜索sNotifyObjCInit
image.png
发现只有赋值，没有实现，那追踪一下是哪里赋值过来的呢。搜索
registerObjCNotifiers
image.png
发现是这玩意赋值的
_dyld_objc_notify_register注意：
_dyld_objc_notify_register的函数需要在libobjc源码中搜索
然后继续探索_dyld_objc_notify_register又是怎么调用过来的呢？继续在dyld源码中搜索_dyld_objc_notify_register,发现找不到调用了，哦嚯，就这么断掉了？
作为要成为海贼王的男人，怎么能就这么断掉呢？？？我们使用倒推大法，康康之前的堆栈信息，发现是objc的load_images方法调用的load方法，
image.png
这个时候需要去objc源码中搜索load_images啦，同样可以在Opensource上下载。
诶嘿，找到这个逼了。
image.png
哈哈哈，这玩意-
_dyld_objc_notify_register也跟着出来了。我们来理一理，_objc_init调用_dyld_objc_notify_register，将load_images作为参数传到了dyld::registerObjCNotifiers并赋值给了sNotifyObjCInit,然后notifySingle方法调用了sNotifyObjCInit，清晰了清晰了。所以notifySingle是一个回调函数。load函数加载
下面我们进入load_images的源码看看其实现，以此来证明load_images中调用了所有的load函数
通过objc源码中_objc_init源码实现，进入load_images的源码实现
image.png
这里是通了，但好像又忽略了一个问题，_objc_init又是哪里调用过来的呢？这个时候回到刚才提到的另一个方法doInitialization。偷个懒，感兴趣的朋友可以按这个探索一下。
_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)
启动流程图
image.png
这也就解释了开头打印顺序的问题。
网友评论