寫在前面
新到一個公司，拉下代碼后，發(fā)現(xiàn)編譯時間在10分鐘以上，不知道為啥這么長時間，之前開發(fā)過程中沒有遇到過這樣的情況。于是準(zhǔn)備研究一下為啥這么長時間，這樣也太影響開發(fā)效率了。
在網(wǎng)上找了一些相關(guān)資料，大致介紹如下：
1. 增加XCode執(zhí)行的線程數(shù)
可以根據(jù)自己Mac的性能，更改線程數(shù)：
defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 5
另外想看看編譯你的工程需要花費多久，可以開啟一個設(shè)置：
defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES
XCode默認使用與CPU核數(shù)相同的線程來進行編譯，但由于編譯過程中的IO操作往往比CPU運算要多，因此適當(dāng)?shù)奶嵘€程數(shù)可以在一定程度上加快編譯速度。
實驗證明：此方法不是很明顯。
2. 將Debug Information Format改為DWARF
在工程對應(yīng)Target的Build Settings中，找到Debug Information Format這一項，將Debug時的DWARF with dSYM file改為DWARF。
這一項設(shè)置的是是否將調(diào)試信息加入到可執(zhí)行文件中，改為DWARF后，如果程序崩潰，將無法輸出崩潰位置對應(yīng)的函數(shù)堆棧，但由于Debug模式下可以在XCode中查看調(diào)試信息，所以改為DWARF影響并不大。
順便提一下，如果通過Cocoapod引入第三方則Debug Information Format默認就是設(shè)置為DWARF的。
實驗證明：此方法很明顯。
3. 將Build Active Architecture Only改為Yes
在工程對應(yīng)Target的Build Settings中，找到Build Active Architecture Only這一項，將Debug時的NO改為Yes。
這一項設(shè)置的是是否僅編譯當(dāng)前架構(gòu)的版本，如果為NO，會編譯所有架構(gòu)的版本。需要注意的是，此選項在Release模式下必須為NO，否則發(fā)布的ipa在部分設(shè)備上將不能運行。
實驗證明：此方法很明顯。
4. 設(shè)計編譯優(yōu)化等級
不要再項目中或者靜態(tài)庫中使用-O4，因為這會讓Clang鏈接Link Time Optimizations (LTO)使得編譯更慢，通常使用-O3。
注意：在設(shè)置編譯優(yōu)化之后，XCode斷點和調(diào)試信息會不正常，所以一般靜態(tài)庫或者其他Target這樣設(shè)置。
總結(jié)：
以上是網(wǎng)絡(luò)的一般做法，其實有些地方還是可以做更細的優(yōu)化的，比如：
- 將常用的代碼及文件打包成靜態(tài)庫；
- 添加預(yù)編譯文件，把常用的頭文件放到預(yù)編譯文件里面；
- 能用@class就用@class，盡量減少文件引用關(guān)系；
- 減少資源的引用，以及xib文件的使用；
- 考慮使用不同的Configurations控制編譯：
- 考慮使用不同的Targets控制編譯：
- 構(gòu)建自己的Pods文件；
以上僅是個人的一點心得，如果有更好的優(yōu)化空間，還希望給我留言。
參考：Programering
