南栀倾寒 •
2017-04-24 •
iOS
起因
去年，链家网iOS端，之前由于所有的业务端代码都是混乱管理，造成开发有很多痛点无法单测 团队成员提交代码冲突机率大 CI配合效果差 功能性代码多端无法复用 单仓库代码量大 编译时间长 等等痛点，领导和组内多次沟通开始着手组件化开发，希望能改进这些开发中的痛点，成立组件化团队。CocoaPodsuse_frameworks!，这个标记是说Pod管理的依赖全部编译为动态库，然后呢我们的很多组件又依赖了诸如百度地图，微信分享等静态库，于是我在执行 pod install 报了一个没有碰见过的错误
[!] The 'Pods-LJA_Example' target has transitive dependencies that include static binaries: (/Users/nero/Desktop/Static_Dynamic/Componment/Example/Pods/libWeChatSDK/libWeChatSDK.a)
这就尴尬了，于是一阵疯狂的搜索 google stackoverflow 等，然而并没有什么卵用，而且上面催得急，根本没时间处理这些小问题 业务重构是最主要的，以至于我们的业务组件没有做到独立仓库拆分。
理论功底
动态库和静态库
介绍
首先静态库和动态库都是以二进制提供代码复用的代码库
静态库 常见的是 .a
动态库常见的是 .dll(windows) .dylib(mac) so(linux)
framework(in Apple): Framework是Cocoa/Cocoa Touch程序中使用的一种资源打包方式，可以将代码文件、头文件、资源文件、说明文档等集中在一起，方便开发者使用。
静态库和动态库的区别
静态库: 链接时会被完整的复制到可执行文件中，所以如果两个程序都用了某个静态库，那么每个二进制可执行文件里面其实都含有这份静态库的代码
But我们的苹果爸爸在iOS平台上规定不允许存在动态库，并且所有的IPA都需要经过苹果爸爸的私钥加密后才能用，基本你用了动态库也会因为签名不对无法加载，(越狱和非APP store除外)。于是就把开发者自己开发动态库掐死在幻想中。APP Extension，swift编程语言也诞生了，由于iOS 主APP需要和Extension共享代码，Swift语言的机制也只能有动态库，于是苹果爸爸尴尬了，不过这难不倒我们的苹果爸爸，毕竟我是爸爸，规则是我来定，我想怎样就怎样，于是提出了一个概念Embedded Framework，这种动态库允许APP 和 APP Extension共享代码，但是这份动态库的生命被限定在一个APP进程内。简单点可以理解为 被阉割的动态库。
举个例子， iOS项目中使用Embeded Framework
如果你把某个自己开发的动态库(系统的不算，毕竟苹果是爸爸)放在了Linked Frameworks and Libraries里面，程序一启动就会报Reason: Image Not Found，你只能把它放在Embeded Binaries里面才能正常使用，
静态库和动态库如何构建和加载
简单点，说话的方式简单点~~
上面的介绍貌似有点抽象啊 套用在美团技术分享大会上的话就是:
这里我们来复习下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程序员的自我修养一书
静态库和动态库依赖关系
既然有2种库，那么依赖关系又是2*2喽
libA.a dependency libB.a
UIKit.dylib dependency Foundation.dylib
libA.a dependency Foundation.dylib
MyXX.dylib dependency libA.a
第一种 静态库互相依赖，这种情况非常常见，制作静态库的时候只需要有被依赖的静态库头文件在就能编译出来。但是这就意味者你要收到告诉使用者你的依赖关系CocoaPod就是这样做的隔离性，但是制作的静态库的时候需要被依赖动态库参与链接，但是具体的符号决议交给dyld来做。dyld加载，那么我直接把你静态库的.o偷过来，共同组成一个新的二进制。也被称做吸附性
那么我有多份动态库都依赖同样的静态库，这就尴尬了，每个动态库为了保证自己的正确性会把静态库吸附进来。然后两个库包含了同样的静态库，于是问题就出现了。 看到这里想必前面出现的错误你已经能猜出来了把~_~
后面再详细解释
先来个总结
遇到静态库，吸附进来
遇到动态库，打标记，彼此保持独⽴
Xcode 项目结构
target-对于一个产物(app,.a ,.framework)
iOS依赖管理事实上的标准
这么多年，Apple的博客和文档也就告诉了我们什么是静态库 什么是动态库，如何制作等。但是并没有给我们提供一系列的依赖管理工具。所以CocoaPods成了事实上的标准。
• CocoaPods
+ App.workspace
+ App.project
• Pods.project
• pod target => .a那么当我们按下CMD+B的时候，整个项目按照先编译被依赖Pod，然后依赖其他Pod的Pod也被构建出来，最终所有的组件被编译为一个lib-Pods-XXXAPP.a被添加进项目进去。资源通过CocoaPods提供的脚本也一并被复制进去。想了解CocoaPods做了什么的读者可以参看后面的链接
解决问题
这么多理论功底的建立，相信我们已经能分析出来之前pod install的原因了。就是用了use_framework那么我们的所有Pod都会以动态库(Embeded Framework)的形式去构建，于是那些非开源的库(如 百度地图，微信分享)如果被多个Pod依赖(组件化开发中太常见了)于是被吸附到动态库里面，所以CocoaPod直接就不让我们install成功。因为你现在的依赖管理就是错误的。隔离性，动态库依赖静态库具有吸附性，那么我们可以自定义一个动态库把百度地图这种静态库吸附进来。对外整体呈现的是动态库特性。其他的组件依赖我们自定义的动态库，由于隔离性的存在，不会出现问题。
制作动态库
1 创建动态库项目这里以wx举例
2 按照微信的官方文档。添加依赖库(我是因为pod install巨慢 所以我直接拽进来了)
3 将wx的PublicHeader暴露出来，注意由于我并没有使用到wx相关API所以链接器帮我们链接动态库 的时候可能并不会把wx静态库吸附进来。我们手动在build Setting的other link flags加上-all_load标记
4.在Schema里面跳转编译配置为Release ，并且选择所有的CPU架构
5 然后选择模拟器或者Generic iOS Device运行编译就会生成对应版本的Framework了。
6.但是为了保证开发者使用的时候是真机模拟器都能正常使用，我们需要合并不同架构Build Phases里添加以下脚本，真机和模拟器都Build一遍之后就会在工程目录下生成Products文件夹，
if [ "${ACTION}" = "build" ]
then
INSTALL_DIR=${SRCROOT}/Products/${PROJECT_NAME}.framework
DEVICE_DIR=${BUILD_ROOT}/${CONFIGURATION}-iphoneos/${PROJECT_NAME}.framework
SIMULATOR_DIR=${BUILD_ROOT}/${CONFIGURATION}-iphonesimulator/${PROJECT_NAME}.framework
if [ -d "${INSTALL_DIR}" ]
then
rm -rf "${INSTALL_DIR}"
fi
mkdir -p "${INSTALL_DIR}"
cp -R "${DEVICE_DIR}/" "${INSTALL_DIR}/"
#ditto "${DEVICE_DIR}/Headers" "${INSTALL_DIR}/Headers"
lipo -create "${DEVICE_DIR}/${PROJECT_NAME}" "${SIMULATOR_DIR}/${PROJECT_NAME}" -output "${INSTALL_DIR}/${PROJECT_NAME}"
open "${DEVICE_DIR}"
open "${SRCROOT}/Products"
fi
于是我们有了我们自己的私有动态库LJWXSDK，那么我们来验证我们之前的问题Github 上面
#
# Be sure to run `pod lib lint LJPod.podspec' to ensure this is a
# valid spec before submitting.
#
# Any lines starting with a # are optional, but their use is encouraged
# To learn more about a Podspec see http://guides.cocoapods.org/syntax/podspec.html
#
Pod::Spec.new do |s|
s.name = 'LJWXSDK'
s.version = '0.1.0'
s.summary = 'A short description of LJWXSDK.'
s.description = <<-DESC
TODO: Add long description of the pod here.
DESC
s.homepage = 'https://github.com/ValiantCat/LJWXSDK'
s.license = { :type => 'MIT', :file => 'LICENSE' }
s.author = { 'ValiantCat' => '519224747@qq.com' }
s.source = { :http => 'http://onk2m6gtu.bkt.clouddn.com/LJWXSDK.framework.zip' }
s.ios.deployment_target = '8.0'
s.default_subspec = 'zip'
s.subspec 'zip' do |zip|
puts '-------------------------------------------------------------------'
puts 'Notice:LJWXSDK is zip now'
puts '-------------------------------------------------------------------'
zip.ios.vendored_frameworks = '*.framework'
end
end注意上面我是把二进制压缩丢进了七牛的oss文件存储。毕竟免费还快。
然后通过pod lib create创建了一个pod用来验证之前我们的传递性依赖问题，
.
├── Example
│ ├── LJA
│ │ ├── Base.lproj
│ │ │ ├── LaunchScreen.storyboard
│ │ │ └── Main.storyboard
│ │ ├── Images.xcassets
│ │ │ └── AppIcon.appiconset
│ │ │ └── Contents.json
│ │ ├── LJA-Info.plist
│ │ ├── LJA-Prefix.pch
│ │ ├── LJAppDelegate.h
│ │ ├── LJAppDelegate.m
│ │ ├── LJViewController.h
│ │ ├── LJViewController.m
│ │ ├── en.lproj
│ │ │ └── InfoPlist.strings
│ │ └── main.m
│ ├── LJA.xcodeproj
│ ├── LJA.xcworkspace
│ ├── Podfile
│ ├── Podfile.lock
│ ├── Pods
│ │ ├── Headers
│ │ ├── LJWXSDK
│ │ │ └── LJWXSDK.framework
│ │ │ ├── Headers
│ │ │ │ ├── LJWXSDK.h
│ │ │ │ ├── WXApi.h
│ │ │ │ ├── WXApiObject.h
│ │ │ │ └── WechatAuthSDK.h
│ │ │ ├── Info.plist
│ │ │ ├── LJWXSDK
│ │ │ ├── Modules
│ │ │ │ └── module.modulemap
│ │ │ ├── _CodeSignature
│ │ │ │ └── CodeResources
│ │ │ └── read_me.txt
│ │ ├── Local\ Podspecs
│ │ │ ├── LJA.podspec.json
│ │ │ ├── LJB.podspec.json
│ │ │ └── LJWXSDK.podspec.json
│ │ ├── Manifest.lock
│ │ ├── Pods.xcodeproj
│ │ │ ├── project.pbxproj
│ │ │ ├── project.xcworkspace
│ │ ├── Target\ Support\ Files
│ │ │ ├── LJA
│ │ │ │ ├── Info.plist
│ │ │ │ ├── LJA-dummy.m
│ │ │ │ ├── LJA-prefix.pch
│ │ │ │ ├── LJA-umbrella.h
│ │ │ │ ├── LJA.modulemap
│ │ │ │ └── LJA.xcconfig
│ │ │ ├── LJB
│ │ │ │ ├── Info.plist
│ │ │ │ ├── LJB-dummy.m
│ │ │ │ ├── LJB-prefix.pch
│ │ │ │ ├── LJB-umbrella.h
│ │ │ │ ├── LJB.modulemap
│ │ │ │ └── LJB.xcconfig
│ │ │ ├── Pods-LJA_Example
│ │ │ │ ├── Info.plist
│ │ │ │ ├── Pods-LJA_Example-acknowledgements.markdown
│ │ │ │ ├── Pods-LJA_Example-acknowledgements.plist
│ │ │ │ ├── Pods-LJA_Example-dummy.m
│ │ │ │ ├── Pods-LJA_Example-frameworks.sh
│ │ │ │ ├── Pods-LJA_Example-resources.sh
│ │ │ │ ├── Pods-LJA_Example-umbrella.h
│ │ │ │ ├── Pods-LJA_Example.debug.xcconfig
│ │ │ │ ├── Pods-LJA_Example.modulemap
│ │ │ │ └── Pods-LJA_Example.release.xcconfig
│ │ │ └── Pods-LJA_Tests
│ │ │ ├── Info.plist
│ │ │ ├── Pods-LJA_Tests-acknowledgements.markdown
│ │ │ ├── Pods-LJA_Tests-acknowledgements.plist
│ │ │ ├── Pods-LJA_Tests-dummy.m
│ │ │ ├── Pods-LJA_Tests-frameworks.sh
│ │ │ ├── Pods-LJA_Tests-resources.sh
│ │ │ ├── Pods-LJA_Tests-umbrella.h
│ │ │ ├── Pods-LJA_Tests.debug.xcconfig
│ │ │ ├── Pods-LJA_Tests.modulemap
│ │ │ └── Pods-LJA_Tests.release.xcconfig
│ │ └── libWeChatSDK
│ │ ├── README.md
│ │ ├── WXApi.h
│ │ ├── WXApiObject.h
│ │ ├── WechatAuthSDK.h
│ │ └── libWeChatSDK.a
├── LICENSE
├── LJA
│ ├── Assets
│ └── Classes
│ └── LJA.m
├── LJA.podspec
├── LJB
│ ├── Assets
│ └── Classes
│ └── LJB.m
├── LJB.podspec
├── README.md
└── _Pods.xcodeproj -> Example/Pods/Pods.xcodeproj
测试工程我也丢在7牛上面。下载 测试即可
剖析下动态库Framework吧
上述解决了我们一开始遇到的问题。but既然动态库和静态库压根就不一回事，所以里面还是有很多细节值得我们去了解的。
回过头来看Embened Framework
首先我们之前记得如果一个动态库加在LinkedFrameworksand Libraies程序启动就会报ImageNotFound，如果放在EmbededBinaries里面就可以。这是为什么呢。我们拿MacoView来看下两种情况下可执行文件的细节
其中@rpth这个路径表示的位置可以查看Xcode 中的链接路径问题 EmbededBinaries里面的东西其实会被复制一份到xx.app里面，所以这个名字起得还是不错的直译就是嵌入的框架
Why Swift does not Support Staic Libraies
造成这个的主要原因是Swift的运行时库(不等同于OC的runtime概念)，由于Swift的ABI不稳定，静态库会导致最终的目标程序中包含重复的运行库，相关可以看下最后的参考文章SwiftInFlux#static-libraries 。等到我们的SwiftABI稳定之后，我们的静态库支持可能就又会出现了。当然也可能不出，Swift伴随诞生的SPM(Swift，Package Manager)，可能有更好的官方的包依赖管理工具。让我们期待吧。
CocoaPods 使用Use_framework!
既然加了Swift的第三方库之后就需要在Podfile里面加上use_framework! 那么CocoaPods就会帮我们生成动态库，但是奇怪的是，我们并没有在主工程的embeded binaries看到这个动态库，这又是什么鬼。其实是CocoaPods使用脚本帮我们加进去了。脚本位置在主工程的 build Phase下的 Emded Pods frameworks
"${SRCROOT}/Pods/Target Support Files/Pods-LJA_Example/Pods-LJA_Example-frameworks.sh"
动态库Framework的文件结构
.
├── Headers
│ ├── LJWXSDK.h
│ ├── WXApi.h
│ ├── WXApiObject.h
│ └── WechatAuthSDK.h
├── Info.plist
├── LJWXSDK
├── Modules
│ └── module.modulemap
└── _CodeSignature
└── CodeResources
Headers 一般是头文件。非private里面的头文件都会在里面
info.plist 配置信息，不深究
Modules 这个文件夹里有个module.modulemap文件，后面在讲解
二进制文件，这就是上面提到的不带 main的二进制文件了，.o的打包体
_codeSignature 签名文件 (苹果爸爸的约束)
more 资源文件。这里暂时没用到，所以没有 ，但是这个也是个大坑
更愉快的导入文件
@class，@protocol 不说了就是声明一个类，并不导入。#import <>, #import""是加强版的#include<>，#include"" 防止重复导入的。#import<> : 通过 build setting里面中的 header Search Path里面去找#import"" : 第一步先搜索user Header search Path 再搜索 header search Path 。所以对我们的framework来说，CocoaPod 帮我们加到了 Header search Path 目前2种导入方式都是可以支持的。
大家都知道iOS7之后多了@import，这又是什么鬼。module-umbrela.hl文件，然后就是导入的这个文件。
回过头来看我们的framework的结构 里面有个Modules文件夹，里面有个文件module.modulemap
framework module LJWXSDK {
umbrella header "LJWXSDK.h"
export *
module * { export * }
}
我们可以看到其实被暴露的header就是这个文件，之前我在按照#import "/"的时候有个警告
@import ，并且#import"/" 也不会报warningumbrella Header 参看文后参考
资源问题
首先我们来看常见的资源文件:主要分为图片和其他类资源那么加载图片和加载其他资源都是怎么做的？[UIimage imageNamed:][NSbundle bundleForclass[XXX class]]mainBundle去拿资源，方式2从XXX所在的框架里面去拿。Main Bundle里面[NSbundle bundleForclass[XXX class]]。需要注意的是很多人为了简单，下意识的使用self class 传递，但是有可能这个self实例不在资源所属的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里的导入头文件 iOS - Umbrella Header在framework中的应用 @import vs #import - iOS 7
阅读更多
目前的配置是non-recursive。如果把non去掉意思就是我可以递归的去查找某些framework下面的头文件了。 但是Xcode的效率肯定就会有影响。