優化 Swift 編譯速度

這兩天 Uber 的開發團隊在一個大會上分享了用 Swift 3 重寫客戶端的過程, 視頻裏介紹了一個很黑科技的技巧, 能夠極大地加快編譯速度, 我本身試了一下以後發現確實有效, 但也有小坑, 在這裏跟你們分享一下.

Uber 的開發團隊偶然發現若是把全部 Model 文件所有合併到一個文件去編譯, 那編譯時間會從 1min 35s 減小到 17s, 那麼咱們若是把全部代碼文件都合併到一塊兒, 那就能夠極大地優化編譯速度了.

WHO(Whole-Module-Optimization) 也會把文件合併起來再進行編譯, 實際使用時咱們發現編譯雖然快了, 但對於編譯時間的減小仍是遠沒有直接把文件合併到一塊兒那麼有效. 主要緣由是由於 WHO 除了合併文件以外, 還會在預編譯階段作這些事情:

1. 檢測沒有被調用的方法和類型, 在預編譯期去掉它們
2. 給沒有被繼承的類, 沒有被繼承的方法加上 final 標籤, 給編譯器提供更多信息, 以便這些方法被優化爲靜態調用或者是內聯進去

這些優化會對於程序的效率有很大的提高, 但編譯時須要加載更多的 context, 每合併一個文件, 就會遍歷全部文件進行一次上面的檢查, 編譯時間會隨着文件的增多呈指數級增加.

Uber 的團隊發現經過增長一個編譯宏就能夠作到只合並文件, 而不作優化. 進入工程文件設置 -> Build Setting -> Add User-Defined Settings, key 爲 SWIFT_WHOLE_MODULE_OPTIMIZATION, value 設爲 YES, 而後把優化級別設爲 None 就能夠了.

那麼問題來了, 爲何 Swift 的編譯器沒有進行這樣的優化呢?

答案很簡單, 由於這種優化會讓增量編譯的顆粒度從 File 級別增大到 Module 級別.

編譯的過程通常是每個文件單獨進行編譯, 而後再連接到一塊兒. 編譯後緩存的是連接前的產物, 而把全部文件都合併到一塊兒再編譯, 緩存的就是合併後的文件編譯後的產物.

只要修改咱們項目裏的一個文件, 想要編譯 debug 一下, 就又得從新合併文件從頭開始編譯一次, 而不能讀取緩存跳過沒有被修改的文件.

但 pod 裏的庫, storyboard 和 xib 文件就不會受這個影響, 只是咱們修改了文件以後, 就得整個 module 從頭編譯一遍 (咱們的項目也是一個 module, 只是 main 函數位於這個 module 而已, 除此以外跟別的 module 沒有任何本質區別)

因此這個優化手段其實沒想象中那麼有用, 反正打包通常都是 CI 去作, 不在本機, 而平常 debug 都會直接增量編譯. 只有到了 Uber 這種規模的團隊, 每個 feature branch 都須要到 CI 上打包測試, 使用這種優化手段才比較有現實意義.

非要說對於普通開發者的意義的話, 多是 flow.ci 那種按照時長計費的方式能夠省點錢, 畢竟內部測試的時候對性能要求沒那麼高. (仔細想一想, 好像還能夠省蠻多錢的, 小型項目幾萬行代碼使用這種優化的話, 以前編譯一次的費用如今能夠用三四次, 並且收益也會隨着項目增大呈指數級增加)

---

喜歡我寫的文章的話能夠關注個人博客