如何将 iOS 项目的编译速度提高 5 倍

目前的项目架构

我们的项目使用 CocoaPods 来管理第三方库和私有库的依赖，对大部分项目来说应该是标配了。目前还是纯 Objective-C 的项目，没有引入 Swift。

调研过的方案

下面列出我研究过的一些主流方案以及我最后没有采用的原因，这些方案有各自的局限性，但是也给了我不少启发，思考过程跟最终方案一样有价值。

cocoapods-packager

cocoapods-packager 可以将任意的 pod 打包成 Static Library，省去重复编译的时间，一定程度上可以加快编译时间，但是也有自身的缺点：

1. 优化不彻底，只能优化第三方和私有 Pod 的编译速度，对于其他改动频繁的业务代码无能为力
2. 私有库和第三方库的后续更新很麻烦，当有源码修改后，需要重新打包上传到内部的 Git 仓库
3. 过多的二进制文件会拖慢 Git 的操作速度（目前还没部署 Git 的 LFS）
4. 难以调试源码

Carthage

这个方案跟 cocoapods-packager 比较类似，优缺点都差不多，但 Carthage 可以比较方便地调试源码。因为我们目前已经大规模使用 CocoaPods，转用 Carthage 来做包管理需要做大量的转换工作，所以不考虑这个方案了。

Buck

Buck 是一套通用的构建系统，由 Facebook 开源。最大的特色是智能的增量编译可以极大地提高构建速度。最早听说 Buck 的时候，它还只能用在安卓上，现在已经适配了 iOS。

它能增快构建速度的主要原因是缓存了编译结果，通过持续监视项目目录的文件变化，每次编译时只编译有改动的文件。另外一个让我很受启发的功能是 HTTP Cache Server，通过一台缓存文件服务器来保存大家的编译结果，这样只要团队里其中一人编译过的文件，其他人就不用再编译了，直接下载就行。

Buck 是个相当完备的解决方案，很多国外的大公司例如 Uber 都已经用上。我也花了很多时间来研究，最终还是认为对我们的项目和团队来说，目前并不是很适合，主要原因是：

1. Buck 抛弃了 Xcode 的项目文件，需要手工编写配置文件来指定编译规则，这要对现有项目作出大幅度的调整。我们目前还在快速迭代新功能，没有余暇和人手来实施。
2. 开发和调试的流程都得做出很大的改变。因为 Buck 接管了项目编译的过程，想调试项目不能简单地在 Xcode 里面 ?+R 了，得先反过来让 Buck 生成 Xcode 的项目文件。Uber 的工程师甚至推荐使用 Nuclide 来代替 Xcode 作为开发环境。虽然原理上是可行的，但是团队需要花不少时间来适应，短期内效率降低无可避免。
3. 用 Xcode 调试代码享受不到加快编译速度的好处。虽然可以用 buck 命令启动 App，然后在命令行里启动 lldb 来调试，但那就无法使用 Xcode 的调试工具 例如 View Debugging 和 Memory Graph Debugger。

Bazel

Bazel 跟 Buck 很