如何将 iOS 工程打包速度提升十倍以上！

过慢的编译速度有非常明显的副作用。一方面，程序员在等待打包的过程中可能会分心，比如刷刷朋友圈，看条新闻等等。这种认知上下文的切换会带来很多隐形的时间浪费。另一方面，大部分 app 都有自己的持续集成工具，如果打包速度太慢， 会影响整个团队的开发进度。

因此，本文会分别讨论日常开发和持续集成这两种场景，分析打包速度慢的瓶颈所在，以及对应的解决方案。利用这些方案，笔者成功的把公司 app 的持续集成时间从 45 min 成功的减少到 9 min，效率提升高达 80%，理论上打包速度可以提升 10 倍以上。如果用一句话总结就是：

在绝对的实力（硬件）面前，一切技巧（软件）都是浮云

日常开发

其实日常开发的优化空间并不大，因为默认情况下 Xcode 会使用上次编译时留下的缓存，也就是所谓的增量编译。因此，日常开发的主要耗时由三部分构成：

总耗时 = 增量编译 + 链接 + 生成调试信息（dSYM）

这里的增量编译耗时比较短，即使是在我 14 年高配的 MacBook Pro（4核心，8 线程，2.5GHz i7 4870HQ，下文简称 MBP) 上，也仅仅耗时十秒上下。我们的应用代码量大约一百多万行，业内超过这个量级的应用应该不多。链接和生成调试信息各花费不到 20s，因此一次增量的编译的时间开销在半分钟到一分钟左右，我们逐个分析：

1. 增量编译： 因为耗时较短（大概十几秒或者更少），几乎不存在优化的空间，但是非常容易恶化。因为只有头文件不变的编译单元才能被缓存，如果某个文件被 N 个文件引用，且这个文件的头文件发生了变化，那么这 N 个文件都会重编译。APP 的分层架构一般都会做，但一个典型的误区是在基础库的头文件中使用宏定义，比如定义一些全局都可以读取的常量，比如是否开启调试，服务器的地址等等。这些常量一旦改变（比如为了调试或者切换到某些分支）就会导致应用重编译。
2. 链接：链接没有缓存，而且只能用单核进行，因此它的耗时主要取决于单核性能和磁盘读写速度。考虑到我们的目标文件一般都比较小，因此 4K 随机读写的性能应该会更重要一些。
3. 调试信息：日常开发时，并不需要生成 dSYM 文件，这个文件主要用于崩溃时查找调用栈，方便线上应用进行调试，而开发过程中的崩溃可以直接在 Xcode 中看到，关闭这个功能 不会对开发产生任何负面影响。

日常开发的优化空间不大，即使是庞大的项目，落后的机器性能，关闭 dSYM 以后也就耗时 30s 左右。相比之下，打包速度可以优化和讨论的地方就比较多了。

持续集成

在利用 Jenkins 等工具进行持续集成时，缓存不推荐被使用。这是因为苹果的缓存不够稳定，在某些情况下还存在 bug。比如明明本地已经修复了 bug，可以编译通过，但上次的编译缓存没有被正确清理，导致在打包机器上依然无法编译通过。或者本地明明写出了 bug，但同样由于缓存问题，打包机器依然可以编译通过。

因此，无论是手动删除 Derived Data