一、序言
作为iOSer，我们天天在xcode上写代码，然后打包发布或者测试，可曾想过代码是如何到内存种的？app是如何从点击图标到整个程序运行的呢？现在我们来探究一下。
二、库
什么是库？库就是能够被系统加载到内存中的可执行的二进制文件，库有这种形式： 静态库(.a .o等)和动态库(.framework .so .dylib等)
1、动态库和静态库的区别
我们梳理一下库的加载过程，首先我们的代码(.h .m .cpp .swift等)经过预编译、编译成汇编，然后链接装载生成可执行文件，大致流程图如下：
1.1、静态库
链接时，静态库会被挨个挨个完整地装载到可执行文件中，被多次使用就有多份冗余拷贝，如图：
图中会很明显的有重复的库，这样就会浪费很多性能。
1.2、动态库
动态库在加载时才进行链接，比如加载到某个节点发现需要某一个库时并不是直接加载，而是共享这个动态库。相比于静态库，动态库会被共用，这样会节省更多的空间和时间。加载的大致流程如下所示：
三、链接器
库是如何加载到内存种的呢？这就需要一个非常重要的东西了dyld。
1、App的启动入口
App是如何启动的呢？我们都知道所有程序的入口都是main函数，那么我们来验证一下。首先创建一个空的iOS项目，并在main函数上打个断点，执行程序,如图：
很容易发现在
main之前有个start_sim，我们下个下个符号断点start，再次运行程序，如图：
很遗憾还是在这里，好像失去了方向。但是经验告诉我们有个方法会在
main之前执行，对，就是load方法，我们随便添加个load并断点，如图：
运行起来，如图：
山穷水复疑无路，柳暗花明又一村。赶紧查看一下堆栈信息，如图：
好像这里才是我们程序的起点。
2、APP的启动流程
刚刚我们找到了APP的启动入口，那么从启动到main函数这个中间经历了什么呢？干了什么事情呢？我们需要到dyld的源码中寻找，打开dyld的源码，搜索_dyld_start（由于源码编译依赖太多就没有流程可以跟踪。还有因系统版本Xcode打开dyld源码闪退的问题，可以将dyld的源码拖入到新建的工程中，不要copy，可以避免闪退），如下所示：
全在深奥的汇编中，这不要紧，因为这里都写的注释。我们很容易发现所有的架构类型中都有call dyldbootstrap::start(app_mh, argc, argv, dyld_mh, &startGlue)这个注释，直接搜索dyldbootstrap:: 没有任何结果，这是c++语法，要先找到命名空间dyldbootstrap，如图：
然后再搜索
start(，如图所示：
这里返回的是个
dyld::_main(我们再次去找实现，同样先找命名空间，在找函数，如图：
13180条结果，太多了，过滤一下，搜索namespace dyld {，如图：
锐减到
14条结果，挨个搜索_main(,找到了实现如下所示：
好长，收起来一看近
1000行代码，如图：
为了找准核心代码，我们可以直接渠道最后查看返回值，然后根据返回值找关键的东西，如图：
返回值是
result，那么找出result赋值相关的代码，如图：
fake_main返回值是0，如图：
所以可以忽略不看，那么result的值很大可能与sMainExecutable相关。接下来找sMainExecutable相关的东西，如图：
这里的绑定可以说明
sMainExecutable就是我们需要找的代码。所以我们要看sMainExecutable的初始化，如图：
然后进入到
instantiateFromLoadedImage方法中，如图：
大概意思是为已经映射到可执行文件中的对象创建一个
ImageLoader*,然后往下，如图：
加载动态库，然后如图：
link主程序，再然后：
link库。在所有镜像文件都链接完毕之后进行弱引用绑定符号表：
然后初始化执行主程序：
具体代码如图：
即拿到各个镜像文件，然后
runInitializers，如图：
其中
processInitializers代码如下：
第一个
for大概意思就是对镜像文件列表中的镜像文件递归初始化，第二个for是继续初始化向上以来的文件。具体的初始在recursiveInitialization中，继续进去查看，如图：
里面是个
try catch，那么我们从try中查找即可，如图：
再继续看
notifySingle，如图：
notifySingle定义的是一个函数，接下来来就需要找到他赋值的地方，如图：
在然后实现的地方，如图：
接下来看
1112行的sNotifyObjCInit，搜索到定义和赋值如下：
sNotifyObjCInit的赋值源于registerObjCNotifiers函数的第二个参数，所以继续搜索registerObjCNotifiers的调用，如图：
继续搜索，如图：
貌似没有找到调用，线索断了？放松一下。
3、从_objc_init开始的逆向推导
打开objc源码搜索registerObjCNotifiers，如图：
发现在
_objc_init有调用registerObjCNotifiers，且objc源码是可编译的，断点伺候，如图： 点击
_os_object_init，如图： 在
libdispatch.dylib库中的_os_object_init有调用_objc_init，所以我们去libdispatch.dylib查找_os_object_init，如图：
果真在
_os_object_init有调用_objc_init，继续往下找，如图： 在同一个库中的
libdispatch_init中找到了_os_object_init的调用。那么libdispatch_init的调用是在哪里呢？当前库也搜索不到，所以我们回到objc源码中，在控制台输入bt查看堆栈信息，如图：
在
libSystem.B.dylib中有调用，那么我们去libSystem.B.dylib查找libdispatch_init，如图：
在
libSystem库的libSystem_initializer调用了libdispatch_init，继续搜索libSystem_initializer并没有找到的调用，再看堆栈信息，在dyld中的doModInitFunctions(ImageLoader::LinkContext const&)调用，所以回到dyld中搜索ImageLoaderMachO::doModInitFunctions，如图：
根据注释判断出该方法是加载
libSystem的。其中func为libSystem_initializer，根据参数判断。然后查找doModInitFunctions的调用，如图：
再查找
doInitialization的调用处，如图：
再次回到了
recursiveInitialization中，大概理清楚了通知注册的方法，由于目前xcode直接打开dyld库会闪退，影响部分分析，请各位大神多多指导。