前言
接到一份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倍以上！。
