动态链接库(dynamic frameworks)
一般在动态链接库中的symbols并不会被包含到app的二进制文件中，一般是在app bundle的frameworks 文件下，会在app launch的时候加载这个动态链接库，这会花费app的启动时间
静态链接库(static libraries)
会在编译期间被链接到app的二进制文件中，但是这会增加build time
mergeable libraries
为了解决这个困境(静态库会增加开发者编译时间，动态库会增加使用者的启动时间)，就让这些库在开发期间(debug mode)为动态链接库，在发布期间为静态链接库
新的链接器相较于之前有什么区别
原先的链接器
静态链接器主要是将多个目标文件(.o)作为输入，每个目标文件包含了已编译的代码和数据以及元数据（符号表）
然后链接器会对symbol进行解析，识别每个目标文件中定义的symbol(函数和变量名)然后将这些构建成一个符号表，
重定义：链接去解析每个目标文件中的symbol引用，然后通过符号表指引正确定义和分配相关内存
最终结果就是将这些静态链接库的所有数据会被包含到app的二进制文件中，这些静态连接库就没用了。
新的链接器
构建动态库是添加元数据，将动态库与静态库类似对待，合并后的输出文件可以是可执行文件或者另一个动态库，合并类似于静态库的链接方式，最终生成一个包含库的
先使用-make_mergeable选项告诉链接器记录元数据，然后为了merged binary，链接器使用元数据和二进制文件一起生成最终输出(通过-merge_library or -merge_framework选项)，最终这个二进制文件将是一个包含segments的libraried，xcode还会对这个最终的二进制文件进行相关处理(When merging, the linker can de-duplicate content, such as strings, across all libraries. For instance, it removes redundant symbol references, Objective-C selectors, and objc_msgsend stubs.)
如何处理动态链接库为mergeable libraries：
当静态链接器创建二进制文件时，动态链接库也生成相应的元数据，这些元数据也是二进制的，允许静态链接器像对待静态连接库一样对待这些元数据的二进制数据(简单来说这些具有元数据的动态库会被静态链接器当作静态库处理)，这些元数据的二进制数据可以被静态链接为一个动态链接库或者合并他们(merged binary)，这个合并的方式和静态连接库链接的方式一致，
如何处理静态连接库
这个可能是以前的逻辑：？code不再从静态连接库copy进可执行程序，而是静态连接器记录静态库的安装路径在app二进制文件，关键的不同点在于当动态链接库被添加或更新时没静态链接器不再需要copy代码，这就回加快build的事件，但这也会倒置app在运行时变复杂，
操作
如何查看当前文件是动态还是静态
file xxx.a
如果出现current ar archive就是静态
如果输出包含 "shared object" 或 "dynamically linked"，则表示这是一个动态链接库
如何删除多余的
-wl.-no_exported_symbols
链接器
ld64应该是老的静态链接器，dyld是动态链接器
