常用命令
-
file - 用于判断是动态库还是静态库
动态库: 显示“Mach-O 64-bit dynamically linked shared library arm64”
静态库: 显示“current ar archive random library” 或“current ar archive ”。
-
lipo - 用于查看库包含的架构信息及合并拆分
lipo -info /framework路径/xxx.framework/xxx
lipo -create 库1 库2 -output 合并后的fat库
lipo 待拆分的fat库 -thin 需拆分框架 -output 新库
基础知识
- mach-o文件类型
- Executable：应用的主要二进制
- Dylib Library：动态链接库（又称DSO或DLL）
- Static Library：静态链接库
- Bundle：不能被链接的Dylib，只能在运行时使用dlopen( )加载，可当做macOS的插件
- Relocatable Object File：可重定向文件类型
- 文件类型
静态库一般是.a文件，也可能没有后缀。
动态库一般是.framework文件，.framework文件其实只是个文件夹，真正的二进制文件在.framework里面。.framework里面的二进制文件也可能是静态库，也有可能是动态库。有后缀也可能没有后缀。
c语言文件处理过程为：
// 预处理阶段。预处理为.i文件 ，所有的预处理器指令都是以井号 # 开头，只有空格字符可以出现在预处理指令之前。
// 例如#define,#import,#include,#ifdef #endif
// OC的#import相对#include来讲，优势就是解决了预处理阶段的循环包含的问题。
// A文件#include B文件，同事B文件include A文件，就会相互展开。#import只会展开一次。
gcc –E hello.c -o hello.i
// 编译阶段。编译为.s汇编语言文件
// 这个阶段编译器主要做词法分析、语法分析、语义分析等，在检查无错误后后，把代码翻译成汇编语言。 汇编语言程序，即低级机器语言指令
gcc -S hello.i -o hello.s
// 汇编阶段。汇编器as 将.s文件 翻译成机器语言，打包形成可重定位的目标文件hello.o 中（二进制文本形式）。
gcc -c hello.s -o hello.o
// 链接阶段。此阶段完成文件中调用的各种函数的静态链接和动态链接，并将它们一起打包合并形成目标文件，即可执行文件。
// 静态链接：是指把要调用的函数或者过程拷贝到可执行文件中，成为可执行文件的一部分。
// 动态链接：所调用的函数代码并没有被拷贝到应用程序的可执行文件中去，而是仅仅在其中加入了所调用函数的描述信息（往往是一些重定位信息）。
// mac、iOS中的可执行文件几乎都是mach-o文件类型
gcc hello.o -o hello
mach-o文件解析
// Header头部，包含可以执行的CPU架构，比如x86，arm64
// Load commands 加载命令，包含文件的组织架构和在虚拟内存中的布局方式
// Data，数据，包含load commands中需要的各个段(segment)的数据，每个Segment的大小都是Page的整数倍。
mach-o文件加载过程
// 1. 加载dyld到App进程
// 2. 加载动态库（包括所依赖的所有动态库）
// 3. Rebase
// 4. Bind
// 5. 初始化Objective C Runtime。
// 6. 其它的初始化代码
- 静态库和动态库的区别
静态库：链接时会被完整的复制到可执行文件中，所以如果两个程序都用了某个静态库，那么每个二进制可执行文件里面其实都含有这份静态库的代码。
动态库：链接时不复制，在程序启动后用动态加载，所以理论上动态库只用存在一份，好多个程序都可以动态链接到这个动态库上面，达到了节省内存(不是磁盘是内存中只有一份动态库)，还有另外一个好处，由于动态库并不绑定到可执行程序上，所以我们想升级这个动态库就很容易，windows和linux上面一般插件和模块机制都是这样实现的。
iOS动态库：
iOS平台上规定不允许存在动态库，并且所有的 IPA 都需要经过Apple的私钥加密后才能用。
基本你用了动态库也会因为签名不对无法加载，所以iOS下并不存在真正的动态库。
iOS8之前因为 iOS 应用都是运行在沙盒当中，不同的程序之间不能共享代码，并且iOS是单进程的，也就是某一时刻只有一个进程在运行，那么你写个共享库，给谁共享呢。
同时动态下载代码又是被苹果明令禁止的，没办法发挥出动态库的优势，综上所以上动态库也就没有存在的必要了。
但是后来iOS8之后，iOS有了App Extesion特性，而且Swift也诞生了。
由于iOS主App需要和Extension共享代码，Swift语言机制也需要动态库，于是苹果后来提出了Embedded Framework。
这种动态库允许APP和APP Extension共享代码，但是这份动态库的生命被限定在一个APP进程内。简单点可以理解为被阉割的动态库。
但是这种动态库（Embedded Framework） 和系统的 UIKit.Framework 还是有很大区别。
传统的动态库是给多个进程用的，而这里的动态库（Embedded Framework）是给单个进程里面多个可执行文件用的。
系统的 Framework 不需要拷贝到目标程序中，我们自己做出来的 动态库（Embedded Framework） 哪怕是动态的，最后也还是要拷贝到 App 中（App 和 Extension 的 Bundle 是共享的）。
所以苹果没有直接把这种Embedded Framework称作动态库而是叫Embedded Framework。
iOS中的Embedded Framework可以理解为独立的没有main函数的可执行文件。
- Cocoapods的做法
use_frameworks!选项：在使用CocoaPods的时候在Podfile里加入use_frameworks! ，那么你在编译的时候就会默认帮你生成动态库，我们能看到每个源码Pod都会在Pods工程下面生成一个对应的动态库Framework的target，我们能在这个target的Build Settings -> Mach-O Type看到默认设置是Dynamic Library。也就是会生成一个动态Framework，我们能在Products下面看到每一个Pod对应生成的动态库。
对于swift写的库，想通过cocoapods引入工程，必须加入use_frameworks! 选项。因为 Swift 是不支持静态库的。造成这个问题的原因主要是 Swift 的运行库没有被包含在 iOS 系统中，而是会打包进 App 中（这也是造成 Swift App 体积大的原因），静态库会导致最终的目标程序中包含重复的运行库。
打包进工程的动态库，可在 ipa 文件解压后的 Frameworks 文件夹下看到。
参考：
编译入门
深入理解iOS App的启动过程
iOS动态库、静态库及使用场景、方式
