Swift 項目編譯優化（一）

級別：★☆☆☆☆
標籤：「編譯過程」「Swift 項目優化編譯時間」
做者： WYW
審校： QiShare團隊php

前言
前段時間筆者組內同事十分快速地開發了一個應用（不妨設應用名爲QiShareDemo），筆者在使用8+128的Mac Air 運行項目的時候，發現項目編譯時間比較久，查看了相關資料，並作了部分實踐，落地了這篇文章。筆者在 clone 了 QiShareDemo 後，發現全量編譯編譯項目的編譯時間爲105.207s；後來通過筆者的部分優化編譯時間處理後，全量編譯項目的時間縮短爲44.573s；固然這裏還能夠繼續作優化，能夠根據項目中具體的代碼的編譯耗時排序，處理那些編譯耗時較長的代碼。html

1、名詞簡介

下邊筆者對本文中提到的名詞作一個簡單介紹。前端

1. 全量編譯

以Xcode編譯過程爲例，筆者理解的全量編譯的一種狀況爲：把Xcode 編譯項目時生成的Derived Data 刪除後，再次編譯項目的過程。git

2. 增量編譯

以Xcode編譯過程爲例，筆者理解的增量編譯的一種狀況爲：Xcode 已編譯過項目的狀況下，咱們又修改了部分文件，那麼編譯的時候，就會編譯咱們修改過的文件，及引用過相關文件的文件。github

3. Swift Compiler

若是項目不是 Objective-C 和 Swift 混編的項目而是純 Swift 項目，那麼編譯過程用的是 Swift Compiler，筆者在下文中第三部分的2.1.2部分有提到詳情。關於編譯的更多詳情能夠查看淺談編譯過程express

2、Swift 項目的編譯過程

使用 Xcode 查看項目具體編譯過程的方式以下：swift

1. 用 Xcode 查看項目具體編譯過程

用 Xcode 查看項目編譯過程方式：command + b 編譯項目，在 Xcode 中，按下圖方式查看具體編譯過程。微信

筆者根據 Xcode 編譯項目過程，作了以下 Swift 項目編譯過程示意圖。markdown

2. 查看項目編譯時間

咱們的目的是要優化項目的編譯時間，那麼首先咱們應該知道當前編譯時間。查看項目編譯時間的方式爲：在終端中輸入以下命令：defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES 以後在 Xcode 頂部的切換Scheme和運行設備的那一欄中便可看到具體編譯時間。查看具體編譯時間方式以下圖所示：架構

上圖是查看項目整體編譯時間的方式，那麼咱們想要對項目作編譯時間優化，就要找出來編譯耗時長的部分。上文中提到了經過 Xcode 查看項目具體編譯時間的方式，筆者也放了以下部分示意圖。

3、減小項目編譯時間的考慮

1. 調整 Xcode 的Build Settings 中的配置

關於調整 Xcode 的 Build Settings 中的配置，筆者查詢資料後發如今 Xcode10 及以前調整空間比較大，在 Xcode11 的時候，筆者初步嘗試後，發現調整 Xcode 的 Build Settings 中的配置對於優化項目編譯時間影響不大。

2. 把穩定三方打包成 Framework

筆者在分析了項目編譯時間後，發現 QiShareDemo 中引入的每一個三方都各自花費了20s+的時間，記不清是查看了網上的文章示例仍是如何，想到了若是在使用這些三方的過程當中，不會頻繁改動這些三方源代碼的狀況下，能夠把這些三方打包成 Framework，嘗試解決編譯耗時久的問題。通過嘗試把項目中的三方打成 Framework，供 QiShareDemo 使用後，就獲得了一個明顯的減小編譯耗時的成效。從開始的筆者在 clone 了 QiShareDemo 後，全量編譯編譯項目的編譯時間爲105.207s；後來通過筆者初步把三方打包成 Framework 後，全量編譯項目的時間縮短爲44.573s；

2.1 淺談編譯耗時縮短的緣由

2.1.1 把穩定三方打成 Framework 對編譯影響

能夠結合上一篇文章淺談編譯過程來談這個問題。關於項目直接使用 Framework ，會減小編譯時間的緣由，組內同窗沐靈洛和奇舞647 都說起過，筆者推測緣由是：從編譯過程來看，項目直接使用 Framework 相比使用 Cocoapods 的源代碼依賴，就省了預編譯、詞法分析、語法分析、生成中間代碼、生成目標文件的過程。因此就減小了編譯時間。(編譯過程更多信息可查看淺談編譯過程) 這部分還有一個劣勢，組內同窗大成小棧提到說，打成Framework 後在調試修改源代碼的時候就不方便了。這個是必然的，因此最好是把那些穩定的三方打包成 Framework ，或者是和組內同窗分工合做，分別負責某個三方。

2.1.2 Objective-C 和 Swift 混編耗時影響

組內同窗沐靈洛還結合着筆者發出的編譯過程圖，說起過Swift 和 OC 項目混編相對於純 Swift 項目可能耗時更多的問題。這部分筆者的推測是看 Swift 項目的編譯過程。若是隻是單純的 Swift 項目，編譯的前端過程用 Swift 編譯器就夠用了。若是是Swift 和 OC 混編的項目，編譯的前端過程還會用到 Clang ，Clang 會把 C、Objective-C 的 API 向Swift API 作一個對應。我想這個過程多少會比 Swift 編譯器單純編譯Swift 代碼多一些編譯耗時的增長。下邊筆者放了一個Swift Compiler 架構圖，筆者是以流程圖的方式繪製製做的Swift Compiler 架構圖。

注：在以前的文章淺談編譯過程中筆者介紹了 GCC、LLVM編譯器，Swift 語言的編譯器是用的自有的Swift Compiler。

3. 使用工具查看項目中代碼編譯耗時

可使用工具 BuildTimeAnalyzer-for-Xcode 查看項目中本身寫的代碼的編譯時間。筆者使用 BuildTimeAnalyzer-for-Xcode 查看了項目編譯時間，找出了2處編譯時間耗時的地方。下圖是筆者使用 BuildTimeAnalyzer-for-Xcode 查看出的項目編譯時間耗時狀況。筆者在Target -> Build Settings -> Swift Compiler 的 Other Swift Flags 中添加了以下配置：

-Xfrontend -warn-long-function-bodies=100
-Xfrontend -warn-long-expression-type-checking=100
-Xfrontend -debug-time-function-bodies
複製代碼

上述配置內容用於添加使用 BuildTimeAnalyzer-for-Xcode 的配置，用於查看出方法或表達式編譯耗時超過100ms的位置以警告的形式表現出來。

下邊筆者舉2個遇到的編譯耗時的代碼示例。

3.1 ??（nil-coalescing 空合併運算符）及」+「拼接在一塊兒的耗時

這種「??」和「+」拼接字符串用在一塊兒時，在編譯過程當中會比較耗時。最好改爲短短的小代碼語句。

通過筆者把上述耗時代碼使用 if let 的方式處理後，編譯耗時的問題已獲得瞭解決。

3.2 使用 snapkit 時候可能遇到的編譯耗時

筆者打開了測出的使用 Snapkit 的過程當中，可能遇到的編譯耗時的代碼。檢測編譯耗時的示意圖以下：

若是把上述的紅色箭頭指向的代碼改爲使用藍色箭頭指向的代碼能夠解決編譯耗時的問題。筆者收穫是：使用Snapkit 佈局的時候，參考值儘量是一個明確值，儘量不要設置參考的時候，再讓編譯器去幫咱們計算值，咱們能夠儘量多的告訴編譯器咱們知道的事情。

4、其餘考慮方向

1. SwiftUI

使用SwiftUI能夠實時查看代碼顯示效果，並能夠在不一樣設備上預覽效果。使用 SwiftUI 能夠提升開發效率。 SwiftUI 官方教程：Learn to Make Apps with SwiftUI

2. Swift的HotReload嘗試

考慮到市面上 Flutter 支持 HotReload 能夠極大提高開發效率，其實Swift 也支持 Hot Reload ，目前筆者只試過 injectionIII Demo 的HotReload，目前不作過多介紹。 Swift 的 HotReload 嘗試可使用工具 Injection III 。以下網址中有 InjectionIII 的使用介紹及使用Demo。injectionIII Injection III App Store下載地址：apps.apple.com/cn/app/inje…

5、參考學習網址

瞭解更多iOS及相關新技術，請關注咱們的公衆號：

可添加以下小編微信，並備註加入QiShare技術交流羣，小編會邀請你加入《QiShare技術交流羣》。

關注咱們的途徑有：
QiShare(簡書)
QiShare(掘金)
QiShare(知乎)
QiShare(GitHub)
QiShare(CocoaChina)
QiShare(StackOverflow)
QiShare(微信公衆號)

推薦文章：
Swift 5.1 (14) - 初始化和反初始化
 Swift 5.1 (15) - 可選連接
 淺談編譯過程
 深刻理解HTTPS
淺談 GPU 及「App渲染流程」
iOS 查看及導出項目運行日誌
 Flutter Platform Channel 使用與源碼分析
 開發沒切圖怎麼辦？矢量圖標（iconFont）上手指南
 DarkMode、WKWebView、蘋果登陸是否必須適配？
奇舞團安卓團隊——aTaller
奇舞週刊