关于Xcode编译性能优化的研究工作总结

关于Xcode编译性能优化的研究工作总结

本文为原创文章，转载注明出处，谢谢！本文链接：关于Xcode编译性能优化的研究工作总结

近来（8月1–8月12）结合Xcode的官方文档和网上资料经验对Xcode的一些配置选项进行了编译优化的尝试研究，所谓优化主要从编译耗时及编译出的安装包大小进行优化。在研究分析过程中将手上的几个Demo项目进行了编译测试，有Swift项目也有Object-C项目。此外，对于不同配置的相应原理也做了较深入的挖掘分析。

总的来说，对Xcode的Build Setting 进行配置选项的修改是最直接的编译设置。本工作总结除了从Xcode本身的配置进行优化以外，还从外部环境、Xcode插件以及外部硬件配置的编译优化进行了研究分析。

---

目录

---

一、编译时长优化 Swift编译优化 Find Implicit Dependencies
二、编译时长优化 Architectures
三、编译时长优化 Precompile Prefix Header 预编译头文件
四、编译时长优化 Swift Compile - Code Generation Optimization Level
五、加载RAM磁盘编译Xcode项目
六、编译线程数和Debug Information Format
6.1、 提高XCode编译时使用的线程数
6.2、 将Debug Information Format改为DWARF
七、Link-Time Optimizations 链接时优化
八、加装SSD固态硬盘
九、安装包大小优化 Asset Catalog Compiler - Options Optimization
十、安装包大小优化 Flatten Compiles XIB Files
十一、安装包大小优化 清理未被使用的图片资源LSUnusedResources
十二、安装包大小优化 Deployment Postprocessing和Strip Linked Product
十三、安装包大小优化 Linking->Dead Code Stripping
十四、Injection for Xcode 高效Xcode编译调试插件
14.1 Injection
14.2 Limitations of Injection(局限性)

---

一、编译时长优化 Swift编译优化 Find Implicit Dependencies

对所编译项目的Scheme进行配置
Product > Scheme > Edit Scheme > Build
Build Opitions选项中，去掉Find Implicit Dependencies.

原理：
选中Find Implicit Dependencies时，编译以下内容：
* 项目所有的文件
* 被修改的frameworks文件
未选中Find Implicit Dependencies时，编译以下内容：
* 项目中必要的文件
* 不会重新编译frameworks文件，即时你对其中的文件做了修改

Test:
对不同设置下（是否选中Find Implicit Dependencies）的项目编译时间进行比较。
注：每次编译前 进行clean操作（shift + command + k），达到消除Xcode自身增量编译带来的干扰。

Result：
对手头的两个demo进行了编译耗时的比较：

对于两个不同的项目，该配置所带来的编译优化效果并不一定都能体现。

对两个工程的framework文件进行对比之后发现，LoveFreshBeen的framework文件要比DXDoctor的少得多。所以应用该配置时，DXDoctor编译时所反映出来的效果会更明显。

缺点分析：
在这个选项（Find Implicit Dependencies）被选中的情况下，即使你只是对项目进行了很细微的改变，项目中的所有资源文件都会被重新编译一遍。也会对所有被改变的frameworks进行编译。没有选中这个选项时，只会对文件中的一些Swift文件进行编译，编译耗时会显著的下降。只是，在这种模式下，你对frameworks中的文件所进行的修改将不会进行重新编译。

结论：
视修改的项目文件的不同，对两种Scheme进行选择，择一使用以提高编译性能。

参考：Swift Slow Compile Times Fix

---

二、编译时长优化 Architectures

在Build Settings中，有个Architectures配置选项。

Architectures
是指定工程支持的指令集的集合，如果设置多个architecture，则生成的二进制包会包含多个指令集代码，提及会随之变大。

Valid Architectures
有效的指令集集合，Architectures与Valid Architectures的交集来确定最终的数据包含的指令集代码。

Build Active Architecture Only
指定是否只对当前连接设备所支持的指令集编译，默认Debug的时候设置为YES，Release的时候设为NO。Debug设置为YES时只编译当前的architecture版本，生成的包只包含当前连接设备的指令集代码；设置为NO时，则生成的包包含所有的指令集代码（上述的V艾力达Architecture与Architecture的交集）。所以为了更快的编译速度，Debug应设为YES，而Release应设为NO。

注：Debug设置为YES时，如果连接的设备是arm64的（iPhone 5s，iPhone 6（plus）等），则Valid Architecture中必须包含arm64，否则编译会出错。这种模式下编译出来的版本是向下兼容的，即：编译出的armv6版本可在armv7版本上运行。

参考：苹果官方“Xcode Build Setting Reference”
关于Xcode “Build Setting”中的Architectures详解

---

三、编译时长优化 Precompile Prefix Header 预编译头文件

Build Setting > Apple LLVM 7.1 - Language

Xcode 6及之后版本默认不使用pch文件参与项目编译，原因有二：
* 去掉自动导入的系统框架类库的头文件们可以提高源文件的复用性，便于迁移；
* 一个庞大的Prefix Header会增加Build耗时。

但对于原有项目应用了pch文件的情况，就需要对Xcode的Build Setting进行配置以使用pch。

当Precompile Prefix Header设为NO时，头文件pch不会被预编译，而是在每个用到它导入的框架类库中编译一次。每个引用了pch内容的.m文件都要编译一次pch，这会降低项目的编译速度。

将Precom