前言

xcode中的build settings中有很多涉及到編譯設(shè)置的選項(xiàng)，了解這些設(shè)置，對(duì)我們代碼的編譯速度和安裝包大小會(huì)有不小的影響，所以我最近對(duì)build settings進(jìn)行了一番探究。

正文

要了解build settings中的各個(gè)參數(shù)，最好的渠道還是官方文檔，于是我們從官方文檔中來(lái)進(jìn)行發(fā)掘（這里只探討與編譯相關(guān)的），我嘗試了幾乎所有與編譯和包大小影響有關(guān)的setting，做出了以下總結(jié)。

• Architectures (ARCHS)

Architectures就是指定你的項(xiàng)目所支持的指令集。在build settings中搜索Architectures，相關(guān)的有三個(gè)，默認(rèn)情況如下：

image.png

Build Active Architecture Only該編譯項(xiàng)用于設(shè)置是否只編譯當(dāng)前使用的設(shè)備對(duì)應(yīng)的arm指令集。當(dāng)該選項(xiàng)設(shè)置成YES時(shí)，你連上一個(gè)armv7指令集的設(shè)備，就只會(huì)生成一個(gè)armv7指令集的二進(jìn)制包。無(wú)疑這既可以減小包大小又可以縮減編譯時(shí)間，所以在debug模式下我們通常設(shè)置為YES，而release模式下設(shè)置為NO。Valid Architectures表示你項(xiàng)目所支持的指令集合，支持的越多二進(jìn)制包也就越大，一般為了兼容老設(shè)備我們項(xiàng)目使用armv7和arm64。Architectures這里我們?cè)O(shè)置默認(rèn)值就好。

• Optimization

1. Link-Time Optimization

Link-Time Optimization 是 LLVM 編譯器的一個(gè)特性，用于在 link 中間代碼時(shí)，對(duì)全局代碼進(jìn)行優(yōu)化。這個(gè)優(yōu)化是自動(dòng)完成的，因此不需要修改現(xiàn)有的代碼；這個(gè)優(yōu)化也是高效的，因?yàn)榭梢栽谌忠暯窍聝?yōu)化代碼。更詳細(xì)的講解可以閱讀這篇文章?？偨Y(jié)來(lái)說(shuō)就是，開(kāi)啟LTO后，一方面可以減少匯編代碼的體積，另一方面也提高了代碼的運(yùn)行效率。
我在測(cè)試中也發(fā)現(xiàn)包大小減小了5.7M，首次編譯時(shí)間會(huì)有所提高，但是二次編譯反而會(huì)有所下降。我這里建議開(kāi)啟Incremental，蘋(píng)果官方也是建議開(kāi)啟的。

這里在開(kāi)啟Incremental后有可能會(huì)出現(xiàn)duplicate symbols for architecture x86_64的錯(cuò)誤，這可能是由于你的代碼不規(guī)范導(dǎo)致的，全局變量在定義時(shí)，.h文件中只能聲明變量，而不應(yīng)該定義變量。在.m中定義全局變量的時(shí)候也應(yīng)該增加命名空間或者使用static關(guān)鍵字避免命名沖突。

2. Optimization Level
   Optimization Level是指編譯器的優(yōu)化層度，優(yōu)化后的代碼效率比較高，但是可讀性比較差，且編譯時(shí)間更長(zhǎng)。 它一共有以下幾個(gè)選項(xiàng):

• None: 編譯器不會(huì)嘗試優(yōu)化代碼，當(dāng)你專注解決邏輯錯(cuò)誤、編譯速度快時(shí)使用此項(xiàng)。
• Fast: 編譯器執(zhí)行簡(jiǎn)單的優(yōu)化來(lái)提高代碼的性能，同時(shí)最大限度的減少編譯時(shí)間，該選項(xiàng)在編譯過(guò)程中會(huì)使用更多的內(nèi)存。
• Faster: 編譯器執(zhí)行所有優(yōu)化，增加編譯時(shí)間，提高代碼的性能。
• Fastest: 編譯器執(zhí)行所有優(yōu)化，改善代碼的速度，但會(huì)增加代碼長(zhǎng)度，編譯速度慢。
• Fastest, Smallest: 編譯器執(zhí)行所有優(yōu)化，不會(huì)增加代碼的長(zhǎng)度，它是執(zhí)行文件占用更少內(nèi)存的首選方案

所以說(shuō)我們平時(shí)開(kāi)發(fā)的時(shí)候可以選擇使用None來(lái)不給代碼執(zhí)行優(yōu)化，這樣既可以減少編譯時(shí)間，又可以看出你代碼哪里有性能問(wèn)題。
而你的release版應(yīng)該選擇Fastest, Smalllest，這樣既能執(zhí)行所有的優(yōu)化而不增加代碼長(zhǎng)度，又能使執(zhí)行文件占用更少的內(nèi)存。

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.

官方的介紹說(shuō)的是當(dāng)Optimization設(shè)為time的時(shí)候會(huì)使存取的速度最優(yōu)，而設(shè)為space的時(shí)候會(huì)使編譯的包大小最小的優(yōu)化。然而我這里經(jīng)過(guò)測(cè)試發(fā)現(xiàn)設(shè)置space和time都沒(méi)有差別，包大小并沒(méi)有改變。

• Debug Information Format

這一項(xiàng)設(shè)置的是是否將調(diào)試信息加入到可執(zhí)行文件中，改為DWARF后，如果程序崩潰，將無(wú)法輸出崩潰位置對(duì)應(yīng)的函數(shù)堆棧，但由于Debug模式下可以在XCode中查看調(diào)試信息，所以改為DWARF影響并不大。所以建議在debug的時(shí)候設(shè)置為DWARF，而在release的時(shí)候設(shè)置為DWARF with dSYM file。

• Deployment Postprocessing和Strip Linked Product

Xcode中Strip Linked Product 的默認(rèn)設(shè)置為YES，但是Deployment Postprocessing的默認(rèn)設(shè)置為NO。Deployment Postprocessing 是Deployment的總開(kāi)關(guān)，所以在打開(kāi)這個(gè)選項(xiàng)之前 Strip Linked Product是不起作用的。打開(kāi)Deployment Postprocessing后我發(fā)現(xiàn)編譯速度和包大小都有不少提升。
注意：當(dāng)Strip Linked Product設(shè)為YES的時(shí)候，運(yùn)行app，斷點(diǎn)不會(huì)中斷，在程序中打印[NSThread
callStackSymbols]也無(wú)法看到類名和方法名。而在程序崩潰時(shí)，函數(shù)調(diào)用棧中也無(wú)法看到類名和方法名。所以一般在release的時(shí)候打開(kāi)就可以了。

更多與symbols有關(guān)的settings可以看我mentor的這篇文章Xcode中和symbols有關(guān)的幾個(gè)設(shè)置
，講得非常詳細(xì)。

其它一些有關(guān)的settings：