iOS Swift工程優化編譯速度

Other Swift Flags

在build setting的Other Swift Flags中添加以下flag，就可在building log中看到詳細的編譯時長:
-Xfrontend -debug-time-compilation：輸出文件的編譯時長
-Xfrontend -debug-time-function-bodies:輸出function編譯時長
-Xfrontend -debug-time-expression-type-checking：輸出function內每一行代碼的編譯時長
-Xfrontend -warn-long-function-bodies=100：編譯時間超過100ms的function報警告
-Xfrontend -warn-long-expression-type-checking=100：編譯時間超過100ms的代碼報警告

日誌通常都有數十萬行，可閱讀性極差。GitHub上有個工具能夠方便的統計展現這些日誌信息，連接以下： github.com/fastred/Opt…

使用flag和對應的工具能夠定位到具體編譯時間特長的代碼的位置，相應的進行修改就能解決代碼層面的編碼時間長的問題。

build setting

1. Optimization Level：優化等級，Debug設爲None
2. Debug Information Format：在Debug模式下移除dsym文件
3. Build Active Architecture：Debug模式下設爲YES，只編譯當前的Architecture，能夠加快編譯速度 這三個是常見的優化編譯速度的設置。

代碼規範

1. Dictionary和數組之類的容器對象須要變量聲明類型。不聲明類型的容器對象會致使編譯時長增長一秒左右
2. String和array等對象不要用」+「拼接串聯，String用「+」拼接會大幅增長編譯速度
3. 在if等邏輯判斷語句中不要進行「+-/」計算操做
   
   以上三點規範對編譯時長影響比較大，建議嚴格遵照。
   能縮短編譯時長的代碼規範的有不少，可是大多都不具有可操做性。好比：複雜的「+-/」和頻繁嵌套類型轉換也會致使編譯時間長，經過將長的計算式拆分爲多個短計算式等方式能夠縮減編譯時間，可是沒有什麼實際的意義，因此能夠不用在乎。

參考文檔

參考文檔比我寫的詳細，我只是將這些文檔實踐，而後總結一下有用的東西。
koke.me/2017/03/24/…
hackernoon.com/speed-up-sw…
github.com/fastred/Opt…
工具連接： github.com/RobertGumme…