库是已写好的、供使用的 可复用代码，每个程序都要依赖很多基础的底层库。
从本质上，库是一种可执行代码的二进制形式。可以被操作系统载入内存执行。库分为两种：静态库（.a .lib）和 动态库 （framework .so .dll）。
所谓的静态、动态指的是 链接的过程。
一、静态库和动态库的标准定义
1、静态库
1.1 简介
之所以称之为【静态库】，是因为在链接阶段，会将汇编生成的目标文件.o 与 引用的库一起链接到可执行文件中。对应的链接方式称为 静态链接。
如果多个进程需要引用到【静态库】，在内存中就会存在多份拷贝。
1.2【静态库】的特点：
①静态库对函数库的链接是在编译期完成的。执行期间代码装载速度快。
②使可执行文件变大，浪费空间和资源（占空间）。
③对程序的更新、部署与发布不方便，需要全量更新。如果 某一个静态库更新了，所有使用它的应用④程序都需要重新编译、发布给用户。
2、动态库
1.1 简介
在程序编译时并不会链接到目标代码中，而是在运行时才被载入。不同的应用程序如果调用相同的库，那么在内存中只需要有一份该共享库的实例，避免了空间浪费问题。同时也解决了静态库对程序的更新的依赖，用户只需更新动态库即可。
1.2 动态库分类（根据动态库的载入时间 load time ）
1.动态链接库: 在启动 app 时立刻将动态库进行加载 (随程序启动而启动)
2.动态加载库: 当需要的时候再使用 dlopen 等通过代码或者命令的方式来加载 (在程序启动之后)
以上行为是由动态链接器 (Dynamic linker, 简称 dyld) 来完成
1.3【动态库】的特点：
①动态库把对一些库函数的链接载入推迟到程序运行时期（占时间）。
②可以实现进程之间的资源共享。（因此动态库也称为共享库）
③将一些程序升级变得简单，不需要重新编译，属于增量更新。
二、iOS开发中的静态库和动态库
1、简介
在 iOS 系统中, Apple 为我们提出了另一种可以包含依赖库的模式 -- .framework
一个 .framework 其实就是一个有着特定结构的文件夹装着各种共享的资源. 这些资源通常是 图片, Xibs, 动态库, 静态库, 文档 等, .framework 毫不掩饰的表明它纯粹就是一个文件夹.
由于有 .framework 的存在, 我们在判断一个库到底是静态库还是动态库就有了麻烦, 因为一个 .framework 既可以是动态库也可以是静态库, 依赖于其内部的文件类型, 而.framework 中的二进制文件有可能有后缀, 也有可能没有后缀.
为了区分其类型我们可以借助MachOView, 或者是在 Xcode 的 Targets -> build setting 中查找 mach-o type 选项.
2、CocoaPods 中的动态库静态库使用
2.1 静态库使用
默认情况下,cocoapods 默认会使用静态库, 当我们在 Podfile 文件中写下:
platform :ios, '10.0'
source 'https://cdn.cocoapods.org/'
target 'HLTest' do
pod 'AsyncSwift'
end
我们可以在 Products 文件夹中看到编译出的 .a 文件
在项目的 .app 中, 我们可以看到静态库被编译进入可执行文件 (mach-o 文件), 导致文件大小为 14.9M
2.2 动态库使用
cocoapods 提供了 use_frameworks! 选项让我们可以以 .framework 的形式导入第三方库, cocoapods 默认我们开启了此选项后在 .framework 文件夹中放的是动态库, 因此我们可以在 Podfile 中加入 use_frameworks! 来达到引入动态库的效果, 如下:
platform :ios, '10.0'
source 'https://cdn.cocoapods.org/'
use_frameworks!
target 'HLTest' do
pod 'AsyncSwift'
end
然后经过 pod update 之后, 结果如下:
cocoapods 编译生成的结果文件已经变为了 .framework 文件夹
再来看项目结果文件 .app:
我们可以看到：
①由于动态库未被编译进入可执行文件 ( mach-o 文件), 导致文件大小减小到 14.8M
②多了一个 Frameworks 文件夹用于存放 .framework 文件
2.3 动静态库的混用
我们可以在一个项目中使用一部分动态库, 再使用一部分静态库, 如果涉及到第三方库与库之间的依赖关系时, 那么遵守如下原则:
静态库可以依赖静态库
动态库可以依赖动态库
动态库不能依赖静态库! 动态库不能依赖静态库是因为静态库不需要在运行时再次加载, 如果多个动态库依赖同一个静态库, 会出现多个静态库的拷贝, 而这些拷贝本身只是对于内存空间的消耗.
2.4 iOS中动态库的加载时机
我们知道，动态库分为：动态链接库 和 动态加载库，在iOS中，app 启动时系统会查找我们所依赖的所有动态库并加载, 这降低了我们 App 的启动速度, 那么iOS有没有动态加载库呢？
查看苹果的 API 文档, 会发现有一个方法提供了加载可执行文件的功能, 那就是 NSBundle 的 load 方法 (底层实现为 dlopen 函数), 如下所示:
然而, 这个方法的使用是有前提的. 那就是库和 app 的签名必须一致. iOS 可能是出于安全考虑, 在加载可执行代码前, 需要校验签名. load 方法的内部实现是调用了 dlopen, 而真机的 dlopen 内部还会调用 dlopen_preflight 先校验签名. 如果库不是事先打包进 app(打包进 app 的话会与 app 有相同签名), 就会报签名错误, 从而加载不成功. 如下图所示:
因此动态加载加载动态库在模拟器上可以实现, 但是真机上不能运行
那么肯定有人会问, 既然无法加载成功, 苹果为什么要提供这个方法? 答案是, 虽然 iOS 无法使用, 但是 Mac OS 可以使用, 很明显这个方法目前是提供给 Mac OS 使用的. 如果以后系统放开签名校验, 那么 iOS 中也就可以动态加载了。
2.5 总结
①在iOS 开发中, 系统的 Framework 不需要拷贝到目标程序中（系统动态库不受签名限制，可以动态加载）, 我们自己做的 Framework或者三方的库，哪怕是动态的，我们也只能通过配置 Embedding Frameworks 来使用, 这样的动态库并不是真正的动态库, 其会在编译时全部置入 app, 然后在 app 启动时全部加载, 这样的话会导致体积大, 加载速度慢。
②
.a 是典型的静态库, 在 Xode -> File -> New -> Project 中的 Static Library 即可新建 .a 静态库
.framework 可以做成静态库, 也可以做成动态库, 在工程中修改某个 target 的 Build Setting 的 Mach-O Type 即可. 在 Xode -> File -> New -> Project 中的 Static Library 的 Framework 即可新建 .framework 静态库
③.a 是纯二进制文件, .framework 中除了有二进制文件之外还可以有资源文件. .a 文件不能直接使用, 至少还要有 .h 文件配合, .framework 文件可以直接使用, 因为本身包含了 h 文件 和其他文件
.a ＋.h ＋source = .framework, 建议使用 .framework
④如果想通过 cocoapods 制作一个静态库被其他项目依赖, 那么可以在 pod 的 podspec 文件中使用 s.static_framework = true 命令, 这个命令会使 pod 变为由 .framework 包裹的静态库 (即使项目的 Podfile 中使用了 use_frameworks! 时使用 pod 也会以静态库使用), 这在解决 动态库不能依赖静态库 的问题上非常有用.
三、参考
《iOS 应用程序加载》
《iOS 中的静态库与动态库》
四、结束
如上述内容有错误之处，欢迎评论指正！