不改一行業務代碼，飛書 iOS 低端機啟動優化實踐
精選作者｜徐霜晴
引言
在啟動優化時，我們常常通過增加并發的方式來減輕主線程的耗時。而在 iOS 中，GCD 是并發編程最常用的框架。增加并發是否是啟動優化的良策？開發者適合選用哪個優先級的 GCD 隊列？本文將結合飛書啟動優化，給出選取 GCD 隊列的最佳實踐，也提供針對低端機的啟動優化思路。
應用此思路，我們在未修改飛書業務邏輯的情況下，在飛書低端機上，取得了不錯的用戶體驗收益：首屏展示時間優化 100ms，消息列表首刷時間優化 1500ms。
低端機的特性
通過 Instruments 的 App Launch 功能，我們能看到 App 啟動時的線程狀態、Time Profiler 等信息。其中，我們發現不同設備在啟動時的表現有很大差異。??
以 iPhone 7p（低端）和 iPhone 12（高端）舉例，它們的設備參數分別為：
設備 | CPU 參數 | 實際核數 ProcessInfo.processInfo.activeProcessorCount | 跑滿的 CPU 占比（Xcode 測試） |
iPhone 7p | A10 芯片[1]，2 高性能 + 2 低功耗，但是只有 2 核能同時工作 | 2 | 200% |
iPhone 12 | A14 芯片[2]，2 高性能 + 4 低功耗 | 6 | 600% |
啟動飛書時，我們通過 Instruments 觀察兩個設備的線程狀態，經過統計發現，iPhone 7p 上，主線程 Preempted 和 Runnable 狀態的占比高達 21%。Instruments 的圖中能看到主線程大片被搶占。
一個典型的局部，能看到主線程是 preempted 狀態，CPU0 在執行其他進程，CPU1 在執行 GCD 線程。
而 iPhone 12，主線程 Preempted 和 Runnable 狀態占比則只占 1%從這里我們能發現：對低端機來說，CPU 已經成為了啟動的瓶頸，“增大并發”已不是一個萬能的啟動優化措施，而想辦法減少其他線程對主線程的搶占，可能會是優化思路。
GCD queue 對主線程的搶占評測
為了評估“減少其他線程對主線程的搶占”是否是一個可行的優化思路，我們首先需要弄明白，主線程被搶占的程度會有多大？
我們可以使用 Demo 制造一些極端場景，了解極端場景下，主線程有多少比例會被其他線程搶占，因此有了如下 Demo 實驗：
實驗組1：
- 異步線程 QoS：DispatchQoS.userInteractive
代碼：
for _ in 1...100 {
let queue = DispatchQueue.init(label: "serialQueue", qos: .userInteractive)
queue.async {
while true {
}
}
}
while true {
}- qos_class_self 數值：33
- 主線程 Preempted + Runnable 占比：74%
實驗組2：
異步線程 QoS：不指定 QoS 或 DispatchQoS.userInitiated
代碼：
for _ in 1...100 {
let queue = DispatchQueue.init(label: "serialQueue")
queue.async {
while true {
}
}
}
while true {
}- qos_class_self 數值：25
- 主線程 Preempted + Runnable 占比：73%
實驗組3：
- 異步線程 QoS：DispatchQoS.utility?
- 代碼：
for _ in 1...100 {
let queue = DispatchQueue.init(label: "serialQueue", qos: .utility)
queue.async {
while true {
}
}
}
while true {
}- qos_class_self 數值：17
- 主線程 Preempted + Runnable 占比：1.3%
實驗組4：
- 異步線程 QoS：DispatchQoS.background?
- 代碼：
for _ in 1...100 {
let queue = DispatchQueue.init(label: "serialQueue", qos: .background)
queue.async {
while true {
}
}
}
while true {
}- qos_class_self 數值：9
- 主線程 Preempted + Runnable 占比：1.3%?
不指定 QoS 下，一個極端 Demo，啟動期間主線程長時間處于 preempted 狀態，一直無法得到 running 的機會
從中我們能看到幾個結論：
- 不指定 QoS 時，自行創建的 GCD queue 的 QoS 是 User-Initiated
- User-Initiated 及以上優先級，對主線程會有嚴重搶占現象；而 Utility 和 Background 則幾乎不會搶占主線程。
另外，我們也做測試驗證了，pthread_create 創建的線程，也有類似的搶占現象。
QoS 和 Priority
看到 iPhone 7p 上主線程被其他線程搶占，我們可能會有疑問：主線程不應該是優先級最高的么？怎么還會被其他線程搶占？
這里，我們需要理解一下 QoS 和線程 priority 兩個概念。
QoS（quality of service）意指服務質量，它影響線程優先級（priority），也影響 I/O 吞吐、 CPU 吞吐等指標[3]。開發者可以用 qos_class_self() 接口獲得當前線程 / 隊列的 QoS。
蘋果對于每個任務應該選用哪個 QoS，也有一些指導意見[4]：
QoS 和 priority 確實有對應關系，參考 xnu 源碼和實驗結果，對應關系為：?
QoS | Priority |
User-Interactive | 46，對于 UI 線程是 47 |
User-Initiated | 37 |
Utility | 20 |
Background | 4 |
同時，線程的 priority 會隨著執行動態調整。測試中我們會發現，主線程的 priority 在運行開始時是 QoS User-Interactive 對應的 47，但隨著運行會出現下降的情況。
官方文檔[5]中解釋了線程 priority 變化的原因，priority 由 Mach scheduler 控制，為了防止計算密集的線程壟斷資源，各個線程的 priority 會實時調整。
All of these mechanisms are operating continually in the Mach scheduler. This means that threads are frequently moving up or down in priority based upon their behavior and the behavior of other threads in the system.
進一步閱讀 xnu 內核的源碼[6]，我們發現，線程 priority 的變化，是由各個 Mach scheduler 實現的 compute_timeshare_priority 接口控制的。在 iOS 使用的 Mach scheduler 中，compute_timeshare_priority 為同一個實現 sched_compute_timeshare_priority。線程調度時的 priority，會在線程固有 priority 的基礎上，結合當前線程的 CPU 占用情況和當前設備的整體負載進行調整。
在這個實現中，我們能看到 Mach scheduler 對 priority 的調整會有一個極限：對于原先 priority = 47 的線程來說，向下調整的極限是 47 - ((BASEPRI_FOREGROUND - BASEPRI_DEFAULT) + 2) = 29。這和我們用多個設備測試到的結果吻合：主線程執行時，priority 的最低值是 29，依然高于 Utility 對應的 priority 20。
這也解釋了，為什么 Demo 中當異步線程的 QoS 是 Utility 時，就幾乎無法對主線程造成搶占。
優化落地
通過 Demo 實驗，一個啟動優化思路產生了：在飛書中，大量異步隊列的 QoS 是 User-Initiated，盡管這一 QoS 低于主線程的 User-Interactive，但依然可能對主線程造成搶占；那么，如果將異步隊列的 QoS 調低到 Utility，是不是就可以優先保障主線程執行，讓首屏更早展現出來？
經過一些粗暴的實驗，我們證實了飛書在這個思路上存在優化空間。但另一個問題隨之而來：如何兼顧首屏、消息列表首刷等多個指標？
考慮消息列表首刷的場景：獲取到最新的消息，不僅僅需要主線程構建 UI，還需要依賴數據庫讀取、網絡請求等異步操作。如果我們粗暴地將所有異步隊列的 QoS 調低，首屏確實能更快展現，但消息列表的首刷則隨著異步操作的變慢更劣化了。這對用戶體驗反而帶來了負向影響。
梳理出哪些異步操作是首刷依賴的，確保這些隊列的 QoS ，是優化中非常重要的一環。我們首先通過不斷用 Instruments 測試、閱讀代碼梳理出了首版白名單隊列，并在線下和線上驗證了首屏、首刷等關鍵指標的優化收益。在后來的迭代中，我們又開發了線下工具，通過在線下 hook dispatch_async 等函數，記錄下首刷等時機依賴的 GCD 隊列，達成了白名單隊列自動生成的能力。
效果分析
這一優化在線上產生了不錯的體驗優化效果：
啟動首屏展現時間優化 100ms
通過調整異步線程的 QoS，啟動期間主線程 CPU 搶占現象有明顯降低。更多計算資源集中到主線程，使得首屏展示速度明顯加快。
消息列表首刷時間優化 1500ms
通過對消息列表首刷依賴的任務的分析，我們調低了無關線程的 QoS，這也讓首刷依賴的數據庫讀取、網絡請求等任務得到了更多資源，加速了它們的執行。
總結
“增加并發”在一定范圍內可以作為啟動優化的方案，但在低端機上，CPU 已經成為瓶頸，并發時異步線程對主線程的搶占也需要引起重視。
GCD 提供了四種 QoS 給開發者使用，官方也為這四種 QoS 提供了最佳實踐建議。
經過評測和源碼推理，User-Interactive 和 User-Initiated 對主線程有明顯搶占，Utility 和 Background 對主線程的搶占極少。開發者創建的 GCD 隊列，默認的 QoS 實際為 User-Initiated。因此在啟動期間（或者任何耗時敏感期間），與啟動無直接關系的 queue，應該主動設置為 Utility 或 Background，減少對主線程的搶占。
通過飛書上落地優化，我們能得出結論：對線程或 GCD queue 調整 QoS，能在不改變啟動業務邏輯的情況下取得顯著收益。
當然，比事后優化更好的操作，是在編碼時就充分了解不同 QoS 的行為特性，選用最適合的 QoS。?
