前言

接到一份10年OC老代码，具有以下几个特点：

1 平均每过2年都有一个“架构师”注入自己引以为傲的核心代码。所以项目中林立着多套优秀的网络框架、方法名重复的各种工具类和类别、IT行业几十年浓缩的各种架构、通信模式。从这些框架中可以看到每一个架构师不同的架构思路，学到了许多。。。

2 重构了又没有完全重构，充满思想的代码目录里隐藏了许多妥协。

3 目前几套架构开始打架了。

4 由于pch预编译头文件的滥用，依赖链路完成多条路径的闭环。想到了一个名词：熵增。

5 还有swift混编。。。用了一些OC的桥接类，也有半套swift核心库。

成果

优化前：全量编译时间： 2600s + xcode卡死

              增量运行时间：>40s+xcode卡死

优化后：全量编译时间：1800s

             增量运行时间：<2s

本文不讨论全量编译的提升，网上有许多：包括buildSetting的设置、swift编码规范等

1 导致XCode卡顿的缘由：

直接说答案：编译日志太大

由于PCH文件、swift桥接文件通过各种隐藏路径，基本包含了项目60%的头文件，导致最终的每个类文件的编译都天然的携带了这60%的头文件，当然也包括：警告（warning）。

这最终导致输出的日志文件达到了500M

我们姑且不去研究这500M是在内存还是在文件里。当编译结束后这500M文件的读写是造成XCode卡顿的罪魁祸首。对了，增量编译和运行也是这份日志欧～～一样卡。

解决方案：

1 模块化、静态包。（不推荐）

    不提议做，搞到一半极有可能像前任一样再给项目注入“半套架构”。

2 解耦PCH，所有没必要的引入下沉。（延后做）

    延后做。由于PCH的梳理和下沉，也是一个解耦的过程。工作量超级大，这个需要用到“职场向上管理”等技术。

3 给编译日志瘦身

通过pch或buildsetting 屏蔽不必要的警告

屏蔽警告后（留下必要的警告），全量编译的导出日志为40M。虽然由于PCH滥用，日志依旧很大。但是40M日志在缓存里已经无法造成xcode卡顿了。

增量编译/运行速度的提升

绕过Pod资源文件的copy

Target-Build phases-Copy Pods Resources

前后对比：

编译速度主要消耗在了Pod脚本copy资源文件上，当全量编译后撤销这个脚本，之后的运行速度提升20倍以上！。