目录

前言

main before

dyld简介

dyld加载流程

总结

前言

对于一个程序的加载，我们看到的入口函数都是main.m里面的main函数，这让我们很容易的认为程序是从这里开始执行的。其实不然，在这之前，故事已经悄悄展开了...

main before

在main函数之前，究竟做了什么？我们新建一个工程，在main.m文件里给我们的main函数打上断点，探探究竟。

在main函数打断点

此时我们可以看到，在main之前执行了一个start函数，敲上bt指令查看，可以看到libdyld.dylib start，再敲上up指令。

跟踪start函数

这时我们看到dylib的start并不是我们想要的，有点失望......重新整整思路，我们会发现，load函数在main函数之前执行，马上为load函数打下断点探一探。

load函数断点

在这断点下，我们可以看到函数调用栈的调用顺序，发现首先调用_dyld_start,马上跟进

_dyld_start的汇编

查看_dyld_start，我们看到调用的是dyldbootstrap这个类的start函数，此时想要继续探究就必须查看苹果的dyld源码（开源），这里的版本是635.2。

dyld简介

dyld全名为dynamic loader。在程序启动运行时会依赖很多系统动态库，系统动态库会通过dyld(动态加载器)（默认是/usr/lib/dyld）加载到内存中，系统内核读取程序可执行文件信息做一些准备工作，接着会将工作交给dyld。由于很多程序需要使用系统动态库，不可能在每个程序加载时都去加载所有的系统动态库，为了优化程序启动速度和利用动态库缓存，iOS系统采用了共享缓存技术，将所有系统库（私有与公有）编译成一个大的缓存文件，这就是dyld_shared_cache,该缓存文件存在iOS系统下的 /System/Library/Caches/com.apple.dyld/目录下。

dyld加载流程

从_dyld_start函数开始设置相关信息，并在最后调用了_mian()函数。

_dyld_start()

进入_main()函数，我们可以看到dyld加载的主要流程。

1.设置上下文信息，配置进程是否受限

首先，调用setContext，设置上下文信息，包括后面需要调用的函数及传入参数。然后，调用configureProcessRestrictions，设置进程是否受限。

2.配置环境变量，获取当前运行架构

调用checkEnvironmentVariables，如果allowEnvVarsPath与allowEnvVarsPrint为空，直接跳过，否则调用processDyldEnvironmentVariable处理并设置环境变量。

3.检查共享缓存是否映射到了共享区域

首先，调用 checkSharedRegionDisable 检查是否开启共享缓存，在iOS中是必须开启的，接着调用 mapSharedCache函数，将共享缓存映射到共享区域。

4.加载可执行文件，生成一个ImageLoader 实例对象

调用 instantiateFromLoadedImage 函数实例化一个 ImageLoader 对象。该函数先调用 isCompatibleMachO 来判断文件的架构是否和当前的架构兼容，然后调用 ImageLoderMachO::instantiateMainExecutable 来加载文件生成实例，并将 image 添加到全局 sAllImages 中。

5.加载所有插入的库

遍历 DYLD_INSERT_LIBRARIES 环境变量，调用 loadInsertedDylib 加载。

6.链接主程序

调用 link 链接主程序。内核调用的是ImageLoader::link 函数。

7.链接所有插入的库，执行符号替换

对 sAllimages （除了主程序的Image外）中的库调用link进行链接，然后调用 registerInterposing 注册符号插入。

8.执行初始化方法

initializeMainExecutable 执行初始化方法，其中 +load 和 constructor 方法就是在这里执行。 initializeMainExecutable 内部先调用了动态库的初始化方法，后调用主程序的初始化方法。

该函数依次调用了 runInitializers、processInitializers、recursiveInitialization、notifySingle。也就是我们在函数调用栈里看到的顺序

在notifySingle函数里我们找不到 load_images 的调用，但分析发现一个可疑的函数指针

此处调用了sNotifyObjCInit ，发现 sNotifyObjCInit  是在下面的位置赋值的。继续寻找，可以找到调用该函数的位置。

当我们继续寻找谁调用了_dyld_objc_notify_register()函数时，发现在dyld源码里找不到。从函数的定义来看，该接口是供 objc runtime 调用的，我们可以在新工程里为 _dyld_objc_notify_register 下符号断点查看。

这时，打开objc 源码 查看_objc_init()函数。

看到_dyld_objc_notify_register()函数的第二个参数时，我们找到了 load_images ，查看load_images()函数发现一个回调 call_load_methods()，继续查看call_load_methods()函数，发现里面循环调用 call_class_loads()，这也就说明为什么load函数比main函数先调用。到这里，我们找到函数调用栈的所有函数，接下来返回dyld。

9.寻找主程序入口

调用 getEntryFromLC_MAIN，从 Load Command 读取LC_MAIN入口，如果没有LC_MAIN入口，就读取LC_UNIXTHREAD，然后跳到入口处执行，这样就来到了我们熟悉的main函数处。

总结

上面对dyld加载大概走了一个流程，很多细节还没探究。最后附上一张图！