前言

xcode中的build settings中有很多涉及到编译设置的选项，了解这些设置，对我们代码的编译速度和安装包大小会有不小的影响，所以我最近对build settings进行了一番探究。

正文

要了解build settings中的各个参数，最好的渠道还是官方文档，于是我们从官方文档中来进行发掘（这里只探讨与编译相关的），我尝试了几乎所有与编译和包大小影响有关的setting，做出了以下总结。

• Architectures (ARCHS)

Architectures就是指定你的项目所支持的指令集。在build settings中搜索Architectures，相关的有三个，默认情况如下：

image.png

Build Active Architecture Only该编译项用于设置是否只编译当前使用的设备对应的arm指令集。当该选项设置成YES时，你连上一个armv7指令集的设备，就只会生成一个armv7指令集的二进制包。无疑这既可以减小包大小又可以缩减编译时间，所以在debug模式下我们通常设置为YES，而release模式下设置为NO。Valid Architectures表示你项目所支持的指令集合，支持的越多二进制包也就越大，一般为了兼容老设备我们项目使用armv7和arm64。Architectures这里我们设置默认值就好。

• Optimization

1. Link-Time Optimization

Link-Time Optimization 是 LLVM 编译器的一个特性，用于在 link 中间代码时，对全局代码进行优化。这个优化是自动完成的，因此不需要修改现有的代码；这个优化也是高效的，因为可以在全局视角下优化代码。更详细的讲解可以阅读这篇文章。总结来说就是，开启LTO后，一方面可以减少汇编代码的体积，另一方面也提高了代码的运行效率。
我在测试中也发现包大小减小了5.7M，首次编译时间会有所提高，但是二次编译反而会有所下降。我这里建议开启Incremental，苹果官方也是建议开启的。

这里在开启Incremental后有可能会出现duplicate symbols for architecture x86_64的错误，这可能是由于你的代码不规范导致的，全局变量在定义时，.h文件中只能声明变量，而不应该定义变量。在.m中定义全局变量的时候也应该增加命名空间或者使用static关键字避免命名冲突。

2. Optimization Level
   Optimization Level是指编译器的优化层度，优化后的代码效率比较高，但是可读性比较差，且编译时间更长。 它一共有以下几个选项:

• None: 编译器不会尝试优化代码，当你专注解决逻辑错误、编译速度快时使用此项。
• Fast: 编译器执行简单的优化来提高代码的性能，同时最大限度的减少编译时间，该选项在编译过程中会使用更多的内存。
• Faster: 编译器执行所有优化，增加编译时间，提高代码的性能。
• Fastest: 编译器执行所有优化，改善代码的速度，但会增加代码长度，编译速度慢。
• Fastest, Smallest: 编译器执行所有优化，不会增加代码的长度，它是执行文件占用更少内存的首选方案

所以说我们平时开发的时候可以选择使用None来不给代码执行优化，这样既可以减少编译时间，又可以看出你代码哪里有性能问题。
而你的release版应该选择Fastest, Smalllest，这样既能执行所有的优化而不增加代码长度，又能使执行文件占用更少的内存。

3. Optimization (ASSETCATALOG_COMPILER_OPTIMIZATION)

With no value, the compiler uses the default optimization. You can also specify time to optimize for speed of access or space to optimize for a smaller compiled asset catalogs.

官方的介绍说的是当Optimization设为time的时候会使存取的速度最优，而设为space的时候会使编译的包大小最小的优化。然而我这里经过测试发现设置space和time都没有差别，包大小并没有改变。

• Debug Information Format

这一项设置的是是否将调试信息加入到可执行文件中，改为DWARF后，如果程序崩溃，将无法输出崩溃位置对应的函数堆栈，但由于Debug模式下可以在XCode中查看调试信息，所以改为DWARF影响并不大。所以建议在debug的时候设置为DWARF，而在release的时候设置为DWARF with dSYM file。

• Deployment Postprocessing和Strip Linked Product

Xcode中Strip Linked Product 的默认设置为YES，但是Deployment Postprocessing的默认设置为NO。Deployment Postprocessing 是Deployment的总开关，所以在打开这个选项之前 Strip Linked Product是不起作用的。打开Deployment Postprocessing后我发现编译速度和包大小都有不少提升。
注意：当Strip Linked Product设为YES的时候，运行app，断点不会中断，在程序中打印[NSThread
callStackSymbols]也无法看到类名和方法名。而在程序崩溃时，函数调用栈中也无法看到类名和方法名。所以一般在release的时候打开就可以了。

更多与symbols有关的settings可以看我mentor的这篇文章Xcode中和symbols有关的几个设置
，讲得非常详细。

其它一些有关的settings：