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