动态库合并：
.m文件经过编译器，汇编器，生成一个mach-o中间文件，.o文件不能被执行，要经过连接器，生成一个可执行文件exec 和动态库dylib。
中间文件.o已经生成了汇编，代码成为__TEXT和__DATA方便连接。可以理解mach-o是一个配置文件+编译后的产物。
dyld作用：
1.加载可执行文件，2加载动态库。
.dyld动态库已经分配了虚拟内存地址，如何合并？
不能合并。
不同架构的动态库合并以后的本质就是两个动态库。合并lipo命令本质就是两个动态库放在一起，dylib连接的还是两个。
静态库（本质就是.o文件的合集）合并：
静态库合并OC不难，Swift静态库麻烦的地方：就是文件位
动态库格式，和上架的问题：
动态库格式:
1.dylib
2.framework = .h+资源文件+库文件（静态库/动态库有签名就可以上架（））
动态库加了签名就不能在进程中分享。
3.xc
app也可以调用app的代码
动态库也可以调用app的代码，连接的时候找不是编译的时候找，连接器传参Other Linker Flags；-Xlinker告诉它参数是传给连接器的。-Xlinker -u xxx
动态库反向依赖，所有符号加载完毕就可以加载到。
静态库中调用静态库：
需要借助app进行连接。
动态库中调用静态库
比较简单，连接过程中，把静态库代码合并过来，直接编译成功。
动态库中调用动态库：
编译不报错，运行失败。
因为动态库是运行时进行动态连接的，只有运行才会去查找动态库。
静态库中调用静态库：
Cocoapods签名，合并静态库是启动优化方法
拿到源码的库就进行合并。
静态库中调用动态库：
app使用静态库的时候，把静态库代码都加载在app了，使用framework search path。
那种库会让你的app变大？
理论上动态库大，静态库默认有ld的配置，dead code strip，进行不需要用的代码进行剥离，所以静态库会小一点。
实际上进行剥离的过程中，all- load -object等一些连接器参数配置，在otherlink里，传给ld，这些代码都会所有代码加载，就有可能造成静态库也很大。
apple 对于app大小的限制，__TEXT 限制500MB，静态库合并在了__TEXT字段里，动态库不在这里，所以可以抉择放在静态库和动态库里结合使用。
app - A动态库 - B动态库，app可访问B动态库吗？
app只能访问A动态库，B符号不对app可见。编译失败。B动态库只对A可见。方法：如果需要B对APP可用，使用re-Exported Framework 也重新吧B动态库暴露给app使用。
app - A动态库 - B静态库，B静态态库如何隐藏？
可以，配置-hidden-l。
一个动态库代表一个空间，重复符号的没关系会忽略。
动态库和静态库本质就是link的问题，在生成.o之前都一样，后面动态库比静态库多的一节就是动态连接。
静态库可以生成动态库，动态库不可以合并。
