原文地址 ,此简书只做备份，强烈推荐原文，毕竟格式比简书好看，还清晰
起因
去年，链家网iOS端，之前由于所有的业务端代码都是混乱管理，造成开发有很多痛点<code>无法单测</code> <code>团队成员提交代码冲突机率大</code> <code>CI配合效果差</code> <code>功能性代码多端无法复用</code> <code>单仓库代码量大</code> <code>编译时间长</code> 等等痛点，领导和组内多次沟通开始着手组件化开发，希望能改进这些开发中的痛点，成立组件化团队。 组件化的方案大同小异，基础性代码封装私有库，业务组件交互交由中间件负责，项目依赖工具用 iOS项目事实上的标准 <code>CocoaPods</code> 前期的基础性组件拆分都较为顺利，从依赖树的叶子节点开发是最合适的方案。 随着组件抽离的越来越多，私有库的依赖体系也越来越复杂，慢慢过渡到了业务组件。业务组件用了Swift的第三方组件，用了Swift库的同学都知道必须加上<code>use_frameworks!</code>，这个标记是说Pod管理的依赖全部编译为<code>动态库</code>，然后呢我们的很多组件又依赖了诸如百度地图，微信分享等<code>静态库</code>，于是我在执行 <code>pod install</code> 报了一个没有碰见过的错误
installError
这就尴尬了，于是一阵疯狂的搜索 google stackoverflow 等，然而并没有什么卵用，而且上面催得急，根本没时间处理这些<code>小问题</code> 业务重构是最主要的，以至于我们的业务组件没有做到独立仓库拆分。 直到最近终于找到了解决办法:( 主要是自己的功力不够深厚
理论功底
首先静态库和动态库都是以二进制提供代码复用的代码库
静态库 常见的是 <code>.a</code>
动态库常见的是 <code>.dll(windows)</code> <code>.dylib(mac)</code> <code>so(linux)</code>
framework(in Apple): Framework是Cocoa/Cocoa Touch程序中使用的一种资源打包方式，可以将代码文件、头文件、资源文件、说明文档等集中在一起，方便开发者使用。
也就是说我们的framework其实是资源打包的方式，和静态库动态库的本质是没有关系的
静态库: 链接时会被完整的复制到可执行文件中，所以如果两个程序都用了某个静态库，那么每个二进制可执行文件里面其实都含有这份静态库的代码
动态库: 链接时不复制，在程序启动后用dyld加载，然后再决议符号，所以理论上动态库只用存在一份，好多个程序都可以动态链接到这个动态库上面，达到了节省内存(不是磁盘是内存中只有一份动态库)，还有另外一个好处，由于动态库并不绑定到可执行程序上，所以我们想升级这个动态库就很容易，windows 和linux上面一般插件和模块机制都是这样实现的。
But我们的苹果爸爸在iOS平台上规定不允许存在动态库，并且所有的IPA都需要经过苹果爸爸的私钥加密后才能用，基本你用了动态库也会因为签名不对无法加载，(越狱和非APP store除外)。于是就把开发者自己开发动态库掐死在幻想中。
直到有一天，苹果爸爸的iOS升级到了8，iOS出现了<code>APP Extension</code>，<code>swift</code>编程语言也诞生了，由于iOS 主APP需要和Extension共享代码，Swift语言的机制也只能有动态库，于是苹果爸爸尴尬了，不过这难不倒我们的苹果爸爸，毕竟我是爸爸，规则是我来定，我想怎样就怎样，于是提出了一个概念<code>Embedded Framework</code>，这种动态库允许<code>APP</code> 和 <code>APP Extension</code>共享代码，但是这份动态库的生命被限定在一个APP进程内。简单点可以理解为 被阉割的动态库。
如果你把某个自己开发的动态库(系统的不算，毕竟苹果是爸爸)放在了<code>Linked Frameworks and Libraries</code>里面，程序一启动就会报<code>Reason: Image Not Found</code>，你只能把它放在<code>Embeded Binaries</code>里面才能正常使用，
看图:
简单点，说话的方式简单点~~
上面的介绍貌似有点抽象啊 套用在美团技术分享大会上的话就是:
静态库: 一堆目标文件(.o/.obj)的打包体(并非二进制文件)
动态库: 一个没有main函数的可执行文件
这里我们来复习下C语言的基本功，编译和链接
编译:将我们的源代码文件编译为目标文件
链接:将我们的各种目标文件加上一些第三方库，和系统库链接为可执行文件。
由于某个目标文件的符号(可以理解为变量，函数等)可能来自其他目标文件，其实链接这一步最主要的操作就是 决议符号的地址。
若符号来⾃静态库(本质就是.o的集合包)或 .o，将其纳⼊链接产物，并确定符号地址
若符号来⾃动态库，打个标记，等启动的时候再说---交给dyld去加载和链接符号
于是链接加装载就有了不同的情况
Load 装载：将库⽂件载⼊内存
Static Loading：启动时
Dynamic Loading：启动后（使⽤时）
Link 链接：决议符号地址
Static Linking：构建（链接）时
Dynamic Linking：运⾏时（启动时或使⽤时）
然后组合起来就是2*2 = 4了
Static Loading + Static Linking
Static Loading + Dynamic Linking
Dynamic Loading + Dynamic Linking
Dynamic Loading + Static Linking
第一种是纯静态库相关了
第二种就是静态加载(启动时)，动态链接 ，链接时，动态库参与链接，但是这时候只是给符号打了标记告诉我这个符号来自与动态库，程序启动时，iOS或者Mac OS操作系统的dyld自动 load+link。
既然全部都是自动的。那么符号的调用方完全不知道你到底是源码还是静态库，动态库 。
第三种收到调用dlopen + performSelector 通常iOS的APP不适用这里不讨论
第四种，没见过，个人也不是特别懂
有需求请参看文后的<code>程序员的自我修养</code>一书
既然有2种库，那么依赖关系又是2*2喽
libA.a dependency libB.a
UIKit.dylib dependency Foundation.dylib
libA.a dependency Foundation.dylib
MyXX.dylib dependency libA.a
第一种 静态库互相依赖，这种情况非常常见，制作静态库的时候只需要有被依赖的静态库头文件在就能编译出来。但是这就意味者你要收到告诉使用者你的依赖关系
幸运的是 <code>CocoaPod</code>就是这样做的
第二种动态库依赖动态库，两个动态库是相互隔离的具有<code>隔离性</code>，但是制作的静态库的时候需要被依赖动态库参与链接，但是具体的符号决议交给<code>dyld</code>来做。
第三种，静态库依赖动态库，也很常见，静态库制作的时候也需要动态库参与链接，但是符号的决议交给dyld来做。
第四种，动态库依赖静态库，这种情况就有点特殊了。首先我们设想动态库编译的时候需要静态库参与编译，但是静态库交由dyld来做符号决议，but 这和我们前面说的就矛盾了啊。静态库本质是一堆.o的打包体，首先并不是二进制可执行文件，再者你无法保证主程序把静态库参与链接共同生成二进制可执行文件。这就尴尬了。
怎么办？
目前的编译器的解决办法是，首先我无法保证主程序是否包含静态库，再者静态库也无法被<code>dyld</code>加载，那么我直接把你静态库的.o偷过来，共同组成一个新的二进制。也被称做<code>吸附性</code>
那么我有多份动态库都依赖同样的静态库，这就尴尬了，每个动态库为了保证自己的正确性会把静态库吸附进来。然后两个库包含了同样的静态库，于是问题就出现了。 看到这里想必前面出现的错误你已经能猜出来了把_
后面再详细解释
先来个总结
可执⾏⽂件（主程序或者动态库）在构建的链接阶段
遇到静态库，吸附进来
遇到动态库，打标记，彼此保持独⽴
target-对于一个产物(app,.a ,.framework)
project-一个项目包含多个target
workspace:一个包含多个target
schema: 指定了一个产物是按照何种的依赖关系，编译-链接到最终的一个产物
这么多年，Apple的博客和文档也就告诉了我们什么是静态库 什么是动态库，如何制作等。但是并没有给我们提供一系列的依赖管理工具。所以CocoaPods成了事实上的标准。
通常CocoaPods管理的工程结构如下:
那么当我们按下CMD+B的时候，整个项目按照先编译被依赖Pod，然后依赖其他Pod的Pod也被构建出来，最终所有的组件被编译为一个<code>lib-Pods-XXXAPP.a</code>被添加进项目进去。资源通过CocoaPods提供的脚本也一并被复制进去。想了解CocoaPods做了什么的读者可以参看后面的链接
这么多理论功底的建立，相信我们已经能分析出来之前<code>pod install</code>的原因了。就是用了<code>use_framework</code>那么我们的所有Pod都会以动态库(Embeded Framework)的形式去构建，于是那些非开源的库(如 百度地图，微信分享)如果被多个Pod依赖(组件化开发中太常见了)于是被吸附到动态库里面，所以CocoaPod直接就不让我们install成功。因为你现在的依赖管理就是错误的。
在听取美团叶樉老师分享的时候 他们的出发点是因为要绕过苹果爸爸在iOS9以下对__text段60M的限制使用了动态库方案，我们是因为某些swift库必须要用到(历史遗留原因)动态库。美团的做法是摘除依赖关系，自定义CocoaPods(开源的本来就是用着不爽我就改)。但是我是个小菜鸡啊。我也不会ruby(以后会学的)，但是叶樉老师给我提了别的idea。 前面我们知道 动态库和动态库是<code>隔离性</code>，动态库依赖静态库具有<code>吸附性</code>，那么我们可以自定义一个动态库把百度地图这种静态库吸附进来。对外整体呈现的是动态库特性。其他的组件依赖我们自定义的动态库，由于<code>隔离性</code>的存在，不会出现问题。
1 创建动态库项目这里以wx举例
2 按照微信的官方文档。添加依赖库(我是因为pod install巨慢 所以我直接拽进来了)
3 将wx的PublicHeader暴露出来，注意由于我并没有使用到wx相关API所以链接器帮我们链接动态库 的时候可能并不会把wx静态库吸附进来。我们手动在build Setting的other link flags加上<code>-all_load</code>标记
4.在Schema里面跳转编译配置为Release ，并且选择所有的CPU架构
5 然后选择模拟器或者Generic iOS Device运行编译就会生成对应版本的Framework了。
6.但是为了保证开发者使用的时候是真机模拟器都能正常使用，我们需要合并不同架构
这里在<code>Build Phases</code>里添加以下脚本，真机和模拟器都Build一遍之后就会在工程目录下生成Products文件夹，
于是我们有了我们自己的私有动态库LJWXSDK，那么我们来验证我们之前的问题
首先指定一个LJWXSDK.podspec这里我直接传到了我的Github上面
注意上面我是把二进制压缩丢进了七牛的oss文件存储。毕竟免费还快。
然后通过pod lib create创建了一个pod用来验证之前我们的传递性依赖问题，
文件夹结构如下
测试工程我也丢在7牛上面。下载测试即可
编译运行。完美。我们又可以愉快的和swift第三方库配合使用。
很多人可能会问 诸如百度地图 微信这种sdk为什么官方不支持动态库版(所说的都是embeded Framework)，猜测是为了兼容更低iOS7版本吧
很多人会觉得麻烦的要死。首先每个公司多多少少都有历史包袱，麻烦也要做，再者这是一次对基本功的补充，即便你们没有用到，但是为了学习，这篇教程所做的也值得你尝试一次。
上述解决了我们一开始遇到的问题。but既然动态库和静态库压根就不一回事，所以里面还是有很多细节值得我们去了解的。
首先我们之前记得如果一个动态库加在<code>LinkedFrameworksand Libraies</code>程序启动就会报ImageNotFound，如果放在<code>EmbededBinaries</code>里面就可以。这是为什么呢。我们拿MacoView来看下两种情况下可执行文件的细节
其中@rpth这个路径表示的位置可以查看Xcode 中的链接路径问题
这样我们就知道了其实加在<code>EmbededBinaries</code>里面的东西其实会被复制一份到xx.app里面，所以这个名字起得还是不错的直译就是<code>嵌入的框架</code>
造成这个的主要原因是Swift的运行时库(不等同于OC的runtime概念)，由于Swift的ABI不稳定，静态库会导致最终的目标程序中包含重复的运行库，相关可以看下最后的参考文章SwiftInFlux#static-libraries。等到我们的SwiftABI稳定之后，我们的静态库支持可能就又会出现了。当然也可能不出，Swift伴随诞生的SPM(Swift，Package Manager)，可能有更好的<code>官方的</code>包依赖管理工具。让我们期待吧。
既然加了Swift的第三方库之后就需要在<code>Podfile</code>里面加上<code>use_framework!</code> 那么CocoaPods就会帮我们生成动态库，但是奇怪的是，我们并没有在主工程的<code>embeded binaries</code>看到这个动态库，这又是什么鬼。其实是CocoaPods使用脚本帮我们加进去了。脚本位置在主工程的 <code>build Phase</code>下的 <code>Emded Pods frameworks</code>
Headers 一般是头文件。非private里面的头文件都会在里面
info.plist 配置信息，不深究
Modules 这个文件夹里有个module.modulemap文件，后面在讲解
二进制文件，这就是上面提到的<code>不带 main的二进制文件了</code>，.o的打包体
_codeSignature 签名文件 (苹果爸爸的约束)
more 资源文件。这里暂时没用到，所以没有 ，但是这个也是个大坑
更愉快的导入文件
<code>@class，@protocol</code> 不说了就是声明一个类，并不导入。
<code>#import <>, #import""</code>是加强版的<code>#include<>，#include""</code> 防止重复导入的。
<code>#import<></code> : 通过 build setting里面中的 header Search Path里面去找
<code>#import"" :</code> 第一步先搜索user Header search Path 再搜索 header search Path 。所以对我们的framework来说，<code>CocoaPod</code> 帮我们加到了 Header search Path 目前2种导入方式都是可以支持的。
上面的导入方式都带了 某个framework的路径 <XX/xx.h> "xx/xx.h" ，我们在开发自己主工程的时候会发现我们导入主工程其他类是不需要导入前缀的。 这又是怎么回事。
看下面的配置
目前的配置是non-recursive。如果把non去掉意思就是我可以递归的去查找某些framework下面的头文件了。 但是Xcode的效率肯定就会有影响。
还是不建议修改的好。
大家都知道iOS7之后多了@import，这又是什么鬼。
简单理解这个方式叫做Module导入，好处就是使用了@import之后不需要在project setting手动添加 framework，系统会自动加载，而且效率更高。
最主要的是swift也只能这样用。
导入的时候系统会查找如果有模块同名的文件就会导入这个文件。如果没有CocoaPods帮我们生成一个<code>module-umbrela.hl</code>文件，然后就是导入的这个文件。
回过头来看我们的framework的结构 里面有个<code>Modules</code>文件夹，里面有个文件<code>module.modulemap</code>
我们可以看到其实被暴露的header就是这个文件，之前我在按照<code>#import "/"</code>的时候有个警告
而且按照@import导入的东西发现没有导入可用的头文件就是因为并没有在 umbrella header的头文件中加入其他头文件。
加入之后我们就可以完美的使用<code>@import</code> ，并且<code>#import"/"</code> 也不会报warning
更多关于<code>umbrella Header</code> 参看文后参考
首先我们来看常见的资源文件:主要分为图片和其他类资源那么加载图片和加载其他资源都是怎么做的？
1: <code>[UIimage imageNamed:]</code>
2: <code>[NSbundle bundleForclass[XXX class]]</code>
其实方式1去本质就是去<code>mainBundle</code>去拿资源，方式2从<code>XXX</code>所在的框架里面去拿。
前面也说道framework只是资源的打包方式，本质上是有两种的。
我们这个framework如果本质是静态库，那么无需改变使用方式，资源最终都会打包到<code>Main Bundle</code>里面
如果我们这个framework本质是动态库，那么我们的资源就发生了变化，资源就会被存放在 framework里面。所以我们需要使<code>[NSbundle bundleForclass[XXX class]]</code>。需要注意的是很多人为了简单，下意识的使用<code>self class</code> 传递，但是有可能这个<code>self实例</code>不在资源所属的framework。所以会出现资源加载 失败。一定要谨慎使用。
参考
程序员的自我修养，链接，装载 和库
iOS里的动态库和静态库
Systems Programming: What is the exact difference between Dynamic loading and dynamic linking?
CocoaPods 都做了什么？
Dynamic Linking of Imported Functions in Mach-O
OS里的导入头文件
iOS - Umbrella Header在framework中的应用
SwiftInFlux#static-libraries
iOS里的导入头文件
@import vs #import - iOS 7
作者：南栀倾寒
链接：https://www.jianshu.com/p/7f6a7e1b3235
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。