浅析 Cocoapods-Binary 实现

背景

公司级别的项目在发展过程，不可避免会遇到项目过大，致使的编译和开发效率的下降。在如何提升编译速度，加快生产效率，各大厂都有各类尝试，惋惜在业内没有一个成本低、效果好的开源方案。而做者所在的公司，因为业务线聚合，原有两条彻底不一样的交易线业务以组件的形式合并到主App，加重了编译的问题。项目的完整编译时间从原有的5分钟，直接 double 到25分钟左右，同时 CI 的打包也不断的往30分钟的趋势奔去。

思路

CocoaPods-Binar 是针对二进制化的一个总体的实践，而非像 CocoaPods-Packager 仅仅针对单个私有库的。所谓的二进制化，简单说来能够经过 podSpec 将 source 指向事先打包好的 binary 来提升编译效率，这个是目前的主流作法。固然也能够经过更改编译缓存如 CCache 或者换个编译器 Buck (FB) / Bazel (Google) 来实现分布式编译。微信团队的这篇 微信编译速度优化 有进行了比较完整的阐述。而本文的主角 CocoaPods-Binary 是经过将 dependencies 预编译成 binary 后缓存至本地，而后将原有的 Source Code link 到 binary 以几乎零成本的方式实现编译效率的提升。惟一缺点就是没法实现服务端缓存（这是咱们须要改造的地方，不过这个能够经过定制化实现)，所谓的分布式的二进制编译。

CocoaPod-Binary

最先发现这个 plugin 是在浏览官方 blog 时发现的，并且做者仍是国内 developer 。该插件发布也有两年多，目前支持到 Pods 版本 1.6.x。咱们先来看看类图构成：

CocoaPods 自己提供了比较不错的插件模版，如须要的话能够看这篇文章。CocoaPods-Binary 的核心代码都在 lib/cocoapods-binary 文件夹下。咱们来看看整个插件的主要部件，及其对应的做用。

Main

做为整个插件的执行的入口，经过 CocoaPods 提供的 pre_install hook 在 pod install 的 prepare 阶段拦截到当前的 pod install context，进而 fork 出一份独立的 installer 以完成将预编译源码 clone 至 Pod/_Prebuild 目录下。

Helper

主要对 Sandbox、Installer、Pod、Podfile Options 相关的类添加各类 attribute 状态来知足逻辑须要。例如，子类化 Sandbox > PrebuildSandbox 来指定 generate frameworks 的地址、prebuild Pods 的地址，以及是否存在编译好的 framework 等；对 Podfile DSL 添加 binary、all_bianry 关键字来控制 binary 和源码的切换。

Room Build Framework

核心类，经过 xcodebuild 将全部 :binary => true 的 dependencies 编译成 binary 和 dSYM，并输出到指定目录。这里针对 iOS 平台输出的 framework 多作了一步处理，当检测到是 platform 是 iOS 会分别对模拟器和真机设备单独编译，最后再利用 libo 将各自的 binary 和 dSYM 合并成一份输出。

Prebuild Installer

利用 ruby 语言的动态性，重载 Installer 的 run_plugins_post_install_hooks 以实现 pre_install 结束后触发 build framework 将 dependencies 打包成二进制包。对于 dependencies 是否须要进行预编译是经过检查生成的 framework 中是否存在 xxx_name 文件做为标识该 lib 是否已经完成编译过（xxx 为对应 lib 名称。

Integration

在插件源码同步完预编译结束后，会将 install context 交还，进入 install 最后阶段。在这里将完成对 binary frameworks 的 symbol link 以替换原有 Pods 源码和 Embed 操做则会修改各个 pod.xcproject 配置，最后生成 project。

结果

基本的模块介绍完，咱们来看看，引入 CocoaPods-Binary 插件后 Pods 的文件构成：

_Prebuild 目录下则完整保存了一份 Pods 源代码，同时多出来的 GeneratedFrameworks 则缓存了预编译后的 binary 文件以及 dSYM 符号表。在最后的 integration 阶段 symbol link 替换完后源码则会被删除同时指向binary。

至此，整个 pod install 就算完成了，那 CocoaPods有哪些限制呢？

• 因为 CocoaPods 在 1.7.x 以上版本，修改了 framework 生成逻辑，不会把 bundle copy 至 framework，所以咱们须要将 Pod 环境固定到 1.6.2；
• pod 要支持 binary，header ref 须要变动为 #import <>或者 @import 以符合 moduler 标准；
• 统一 CI 和开发的 compiler 环境，若是项目支持 Swift，不一样 compiler 编译产物有 Swift 版本兼容问题；
• 最终的 binary size 会比使用源码的时候大一点，不建议最终上传 Store；
• 建议 Git ignore Pods 文件夹，不然在 source code 与 binary 切换过程会有大量的 file change，增长 git 负担；

流程图

无图无真相，简单的流程图但愿能帮助各位理解 CocoaPods-Binary 做者的基本思路；