概念

dyld（the dynamic link editor）是苹果的动态链接器，是苹果操作系统一个重要组成部分，在系统内核 XNU 完成 Mach-O 文件的加载，做好程序准备工作之后，交由 dyld 负责余下的工作。在 macOS 系统中，dyld 位于 D/usr/lib/dyld。

dyld 1.0(1996 - 2004)

在 NeXTStep 3.3 中引入了 dyld 1.0，在此之前，NeXT 使用 static binaries
对POSIX dlopen() 进行了标准化
预绑定 Prebinding

dyld 2(2004 - 2017)

dyld 2 对 dyld 1.0 进行了全面的重写;
- 它具有对 C++ 初始化程序语义的正确支持，扩展了 Mach-O 格式，并更新了 dyld ，以便有效支持的 C++ 库。
dyld 2 具有完整的 dlopen 和 dlsym 实现，此时弃用了旧版 API。
支持更多的架构及平台
- 自从Power PC上发布 dyld 2.0 以来，添加了 x86，x86 64 arm，arm64 等架构，支持了 iOS, tvOS, 和 watchOS 平台
通过多种方式提高了安全性
- Codesigning ：代码签名
- ASLR ：Address space layout randomization 地址空间配置随机加载
- bounds checking：对 Mach-O Header 中的许多内容添加了重要的边界检查功能，从而可以避免恶意二进制数据的注入
提升性能
- 使用 shared cache 技术完全替代了预绑定 prebinding；

执行流程

请添加图片描述

dyld 的初始化，主要代码在 dyldbootstrap::start，接着执行 dyld::_main ，dyld::_main 代码较多，是 dyld 加载的核心部分；
检查并准备环境，比如获取二进制路径，检查环境变量，解析主二进制的 image header 等信息；
实例化主二进制的 image loader ，校验主二进制和 dyld 的版本是否匹配；
检查 shared cache 是否已经 map ，没有的话则先执行 map shared cache 操作；
检查 DYLD_INSERT_LIBRARIES，有的话则加载插入的动态库（实例化 image loader）;
执行 link 操作。这个过程比较复杂，会先递归加载依赖的所有动态库（会对依赖库进行排序，被依赖的总是在前面），同时在这阶段将执行符号绑定，以及rebase，binding 操作；
执行初始化方法。Objective-C 的 +load 以及 C 的 constructor方法都会在这个阶段执行；
读取 Mach-O 的 LC_MAIN段获取程序的入口地址，调用 main 方法。

加载共享缓存

因为 Foundation 还会依赖一些其他动态库，这些依赖的其他库还会再依赖更多的库，所以相互依赖的符号会很多，需要处理的时间也会比较长。这里系统上的动态链接器会使用共享缓存，共享缓存在 /var/db/dyld/。当加载 Mach-O 文件时，动态链接器会先检查是否有共享缓存。每个进程都会在自己的地址空间映射这些共享缓存，这样做可以起到优化 App 启动速度的作用。

动态库加载

链接的共用库分为静态库和动态库：

静态库是编译时链接的库，需要链接进 Mach-O 文件里，如果需要更新就要重新编译一次，无法动态加载和更新；
而动态库是运行时链接的库，使用 dyld 就可以实现动态加载。
Mach-O 文件是编译后的产物，而动态库在运行时才会被链接，并没参与 Mach-O 文件的编译和链接，所以 Mach-O 文件中并没有包含动态库里的符号定义。也就是说，这些符号会显示为“未定义”，但它们的名字和对应的库的路径会被记录下来。运行时通过 dlopen 和 dlsym 导入动态库时，先根据记录的库路径找到对应的库，再通过记录的名字符号找到绑定的地址。
dlopen 会把共享库载入运行进程的地址空间，载入的共享库也会有未定义的符号，这样会触发更多的共享库被载入。dlopen 也可以选择是立刻解析所有引用还是滞后去做。dlopen 打开动态库后返回的是引用的指针，dlsym 的作用就是通过 dlopen 返回的动态库指针和函数符号，得到函数的地址然后使用。

dyld 2 存在的问题

Parse mach-o headers 可以使用撰改过的 Mach-O 文件头进行攻击，
Find dependencies 可以使用 @rpaths 即搜索路径。通过撰改这些路径或者将库插到适当的位置，可以破坏程序；
Perform symbol lookups 符号查找部分，因为在给定的库中，除非进行软件更新或者在磁盘上更改库，符号将始终位于库中的相同偏移位置

Tips ： -Wl,-sectcreate,__RESTRICT,__restrict,/dev/null 虽然在 iOS 10 以前才可以避免动态库的注入，但是可以通过修改 Mach-O 绕过

Tips ：一般情况下，动态库的路径都是 @rpath ，比如： @excutable/Frameworks

dyld 3 (2017)

dyld 3是全新的动态链接器，它完全改变了动态链接概念。WWDC-App Startup Time: Past, Present, and Future 提到在iOS 13系统中，iOS 全面采用新的 dyld 3 以替代之前版本的 dyld 2。dyld 3带来了可观的性能提升，减少了APP的启动时间。因为 dyld 3 完全兼容 dyld 2，API 接口是一样的，所以在大部分情况下，开发者不需要做额外的适配就能平滑过渡。

执行流程

请添加图片描述
dyld 3 包含这三个部分:

进程外 Mach-O 分析器和编译器（out-of-process mach-o parser）
- 由于 dyld 2 存在的问题，dyld 3 中将采用提前写入把结果数据缓存成文件的方式构成一个 lauch closure（可以理解为缓存文件）
进程内引擎执行 launch closure 处理 (in-process engine)
- 验证”lauch closures“是否正确，映射dylib，执行main函数。此时，它不再需要分析mach-o header和执行符号查找，节省了不少时间。
launch closure 缓存服务 (launch closure cache )
- 系统程序的 lauch closure 直接内置在 shared cache 中，而对于第三方APP，将在APP安装或更新时生成，这样就能保证 launch closure 总是在 APP 打开之前准备好。

大多数程序启动会使用缓存，而不需要调用进程外 mach-o分析器或编译器；并且 launch closure 比 Mach-O 更简单，它们是内存映射文件，不需要用复杂的方法进行分析，我们可以简单地验证它们，其作用是为了提高速度

dyld 3的符号缺失问题

dyld 2 默认采取的是lazy symbol的符号加载方式，但在 dyld 3中，在 App 启动之前，符号解析的结果已经在 lauch closure 内了，所以 lazy symbol 就不再需要。这时，如果有符号缺失的情况，APP 的行为会有不同：在 dyld 2 中，首次调用缺失符号时 APP 会 crash；而 dyld 3 中，缺失符号会导致 APP 一启动就会 crash