做过iOS的Library开发的都知道，开发者可以创建静态库工程(Static Library)，编译出来的产物是.a文件；也可以创建动态库工程(Dynamic Library)，编译出来的产物是.framework文件。然而，你也有可能遇到过，外面是.framework文件，里面包含的却是.a的文件，还有的二进制文件根本没有格式后缀。但是系统的动态库文件却是.dylib(xcode 8.0以前)和.tbd(xcode 8.0及以后)格式的。刚开始接触时肯定对这些充满了疑惑，本文将对这些问题进行一些探讨。
在进行探讨之前，首先要介绍一下Mach-O。
Mach-O
Mach-O格式全称为Mach Object文件格式的缩写，是mac上可执行文件的格式，类似于windows上的PE格式 (Portable Executable ), linux上的elf格式 (Executable and Linking Format)。
mach-o文件类型分为：
- Executable：应用的主要二进制
- Dylib Library：动态链接库（又称DSO或DLL）
- Static Library：静态链接库
- Bundle：不能被链接的Dylib，只能在运行时使用dlopen( )加载，可当做macOS的插件
- Relocatable Object File：可重定向文件类型
看着貌似很陌生，我们可以类比着相对熟悉一点的Linux看。Linux中常见的库文件有.o文件、.a文件、.so文件。
以一个简单的add函数源文件为例，介绍一下编译过程。
int add(int a,int b)
{
return a+b;
}
先预处理为.i文件gcc -E add.c -o add.i
再编译为汇编文件
gcc -S add.i -o add.s
再汇编为二进制的.o文件
gcc -c add.s -o add.o
现在.o文件出来了。它就是C/C++编译的产物，因为C/C++编译的单元编译。每一个.c/.cpp文件就是一个编译单元，把所有单元都编译好之后，再连接成一个完整的程序。所以可以看出：
- .o文件
.o文件是源码编译出的二进制文件。 - .a文件
.a文件实质上就是.o文件打了个包。一般把它叫做静态库文件。它在使用的时候，效果和使用.o文件是一样的。 - .so文件
.so文件就不一样了,它不是简单的.o文件打了一个包，它是一个ELF格式的文件，也就是linux的可执行文件。.so文件可以用于多个进程的共享使用（位置无关的才行），所以又叫共享库文件。程序在使用它的时候，会在运行时把它映射到自己进程空间的某一处，其不在使用它的程序中。
OSX或者iOS是类Unix系统，和Linux很相似。文件格式也很类似，其中Relocatable Object File和.o文件类型对应；Static Library和.a文件类型对应；Dylib Library和.so文件类型对应。
iOS Library
在任意一个iOS工程中，可以进入到Build Settings，搜索"Mach-O"，可以搜出"Mach-O Type"配置项，在下拉菜单里可以看到有5个选项，如图所示：
可以看到，正好和前面的几种Mach-O文件类型对应。其中Executable用于编译应用，Bundle用于编译资源包，Relocatable Object File用于编译单元二进制文件。Static Library和Dynamic Library分别用于编译静态和动态库。Executable、Bundle以及Relocatable Object File比较好区分，这里主要探讨Static Library和Dynamic Library。
前面提到过，静态库一般是.a文件，动态库一般是.framework文件。为什么说一般，因为静态库也可能没有后缀；.framework文件其实只是个文件夹，真正的二进制文件在.framework里面。.framework里面的二进制文件也可能是静态库，也有可能是动态库。有后缀也可能没有后缀。因此有时候不通过工具很难区分。所以这里推荐一款Mach-O格式文件浏览器：MachOView。
MachOView下载地址：http://sourceforge.net/projects/machoview/
MachOView源码地址：https://github.com/gdbinit/MachOView
用MachOView打开Mach-O格式文件，可以清楚地看到文件类型，是动态库还是静态库。如果是动态库，可以看到Shared Library标志；如果是静态库，可以看到Static Library标志。
动态库（这里只讲自己编译的动态库，因为系统的动态库还有些不一样，后面会讲到）和静态库的主要区别有以下几点：
- 在使用静态库时，把库拖进工程，设置好library search path即可使用；在使用动态库时，多一个步骤，要在Build Settings——>General——>Embeeded Binaries中add一下，否则应用启动时会崩溃。
- 静态库里不能有资源文件；动态库有.framework文件夹包裹着，可以带资源文件。
- 静态库会被编译进应用的二进制文件里；动态库只是被完整地拷贝到应用的沙盒里，不会被编译进应用的二进制文件里。
- 静态库实质上就是源码编译出的多个.o二进制文件打了个包；动态库可以用于多个进程的共享使用（位置无关的才行），所以又叫共享库文件。程序在使用它的时候，会在运行时把它映射到自己进程空间的某一处，其不在使用它的程序中。
- 在应用启动时，系统会把应用所链接的所有静态库（包括系统的和自己编译的）全部放进分配好的内存空间里，如果一次性加载的内容过多，会造成App启动慢；动态库分两种情况，如果是自己编译的，则会被通过load的方式全部加载进内存；如果是系统的动态库则相对智能些，只有当应用用到这个库时，系统才把这个库加载进内存。
现在对静态库应该没有什么疑问了，很容易区分。但是自己编译的动态库和系统的动态库还不是很清晰。有人把自己编译的动态库归类静态库，可能有两点理由：1、自己编译的动态库用法和静态库很类似，而且不能动态加载；2、自己编译的动态库是.framework文件，而系统的动态库是.tbd文件，格式都不一样。
目前，自己编译的动态库用法和静态库用法确实很类似，而且不能动态加载。但是不能动态加载的原因是系统的限制。查看苹果的API文档，会发现有一个方法提供了加载可执行文件的功能，那就是NSBundle的load方法（底层实现为dlopen函数）， 如下所示：
然而，这个方法的使用是有前提的。那就是库和app的签名必需一致。iOS可能是出于安全考虑，在加载可执行代码前，需要校验签名。load方法的内部实现是调用了dlopen，而dlopen内部还会调用dlopen_preflight先校验签名。如果库不是事先打包进app，和app使用同一签名，就会报签名错误，从而加载不成功。如下图所示：
那么肯定有人会问，既然无法加载成功，苹果为什么要提供这个方法？答案是，虽然iOS无法使用，但是Mac OS可以使用，很明显这个方法目前是提供给Mac OS使用的。如果以后系统放开签名校验，那么iOS中也就可以动态加载了。
至于系统的动态库是.tbd文件，不妨先调查一下这个.tbd。详见：http://www.cocoachina.com/ios/20160506/16141.html
简而言之，其实tbd文件不是一个库，而是一个文本文件，其中包含架构信息，和在真实运行时候二进制所在的位置，以及动态库的符号表还有类的一些信息，这些信息在编译阶段足够了。在系统要使用时才通过tbd文件中的链接信息加载真正的二进制文件。
总结
- Mach-O格式的几种文件和iOS工程Build Settings里面的配置项是对应的。
- 可以通过MachOView工具查看Mach-O格式，不能只看文件后缀。
- iOS工程Build Settings里面的配置项选择Static Library和Dynamic Library分别编译出的二进制文件还是有本质区别的。
- 系统动态库和自己编译的动态库本质上是一样的，只是使用方式不一样。自己编译的动态库由于签名校验限制，只能当作静态库一样使用；系统的动态库不受签名校验限制，可以动态加载。
参考链接：
http://blog.csdn.net/zhangjie1989/article/details/54614246
https://www.jianshu.com/p/54d842db3f69
http://www.cocoachina.com/ios/20160506/16141.html
