總是被低估，從未被超越，揭秘QQ極致絲滑背后的硬核IM技術優化

Posted on 2024-05-23 14:20 Jack Jiang 閱讀(105) 評論(0) 編輯收藏

本文由騰訊云開發者張曌、畢磊分享，原題“QQ 9“傻快傻快”的？！帶你看看背后的技術秘密”，本文進行了排版和內容優化等。

1、引言

最新發布的 QQ 9 自上線以來，流暢度方面收獲了眾多用戶好評，不少用戶戲稱 QQ 9 “傻快傻快”的，快到“有點不習慣了都”。

作為龐大量級的IM應用，QQ 9 從哪些方面做了哪些優化，使得用戶能夠明顯感覺到流暢度的提升？本文將詳細介紹 QQ 9 流暢背后的技術實現，以及在全流程做的性能優化探索，為你揭秘QQ極致絲滑背后的硬核IM技術優化，希望在提升IM應用流暢度這個技術方向上提供一些可借鑒的經驗。

技術交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-4656-1-1.html）

2、5億人堅持用QQ

今年是中國開啟互聯網時代的第 30 年，也是 QQ 作為“初代互聯網產品”的第25年，手機 QQ 的第 14 年。

“仍有5億人堅持用 QQ”：正是有這群用戶的堅持，督促著 QQ 技術團隊不斷的自我革新，為了能給用戶更好的體驗，對性能孜孜不倦的追求。

QQ 9 開始，我們從底層架構自底向上全部重構優化，解決了手機客戶端原來啟動緩慢、容易卡、轉菊花等待時間長、UI 跳變等一系列問題。上線后，收獲了用戶眾多好評，其中有個高頻關鍵詞是「絲滑」，在絲滑的背后，其實是技術人吹毛求疵般的打磨。

本文將為大家揭開 QQ 9 背后的技術探索，分享 QQ 匠人們硬核的IM優化手段。

3、啟動速度優化（極致秒開）

QQ 的絲滑體驗從「啟動優化」開始。

以 iOS 端為例，啟動流程主要分為 3 個階段：

1）T0：點擊圖標到 main 函數開始；
2）T1：從 main 函數開始到 didFinishLaunchingWithOptions 結束；
3）T2：didFinishLaunchingWithOptions 結束到首幀渲染完成。

一般將啟動過程按階段分為 pre-main (T0) 和 post-main (T1 + T2) 兩個執行階段。

這兩個兩個執行階段分別是：

1）pre-main 階段：系統 dyld 加載 App 鏡像和初始化行為，與程序結構和規模關系較大；
2）post-main 階段：App 在渲染上屏前做的業務初始化行為，與具體業務邏輯關系較大。

一般工程上的優化方向：

1）pre-main 階段降低加載和鏈接的耗時：如動態鏈接轉為靜態鏈接，代碼拆分組成動態庫并進行懶加載；
2）post-main 階段減少主線程所執行的代碼總量：如代碼下架，代碼執行時機延后或異步子線程化，代碼邏輯執行效率優化等。

以下就這兩個方向，介紹一下 QQ 本次做的有亮點的地方。

4、啟動速度優化實踐1：按需裝載代碼（pre-main階段）

動態庫懶加載方案原理圖：

代碼拆分組成動態庫并進行懶加載這項技術多應用于業界大型 App（抖音、Facebook、快手）中，但 QQ 的業務復雜度頗高，直接使用業界方案無法滿足我們的需求。

經過一番探索我們找到了一些創新技術點：

1）使用 __attribute__((objc_runtime_visible)) 實現低成本代碼動態化改造；
2）使用 objc_setHook_getClass 實現動態化代碼入口收斂，保證了方案穩定性。

最終在 QQ 9 中大規模的應用實現了對 pre-main 階段的啟動耗時優化（這個技術方案約貢獻了33%左右的啟動總耗時優化數據收益），如下圖所示。

5、啟動速度優化實踐2：線程治理（post-main階段）

5.1概述

我們防劣化系統監控到主線程搶占的問題越來越嚴重，通過 Instruments 查看，我們發現一些嚴重的情況下，溫啟動過程中主線程有 14%的時間片處于被其他線程搶占的狀態。

Instruments 分析 QQ 啟動耗時圖：

什么是主線程搶占（Preempted）問題？

簡單來說就是主線程的 CPU 時間片被其他線程搶占，導致主線程得不到 CPU 資源。隨著搶占問題越來越嚴重，也引出一些相關的問題，例如啟動總耗時也隨著劣化、啟動后卡頓、啟動耗時波動大、防劣化性能報告誤判概率增大等。

為什么會出現主線程被搶占？

簡單來說有以下幾個原因：

1）系統調度行為、系統級線程（比如 PageIn 線程）搶占；
2）APP 頻繁開辟子線程卻不注意管理子線程的數量，可能會出現「線程爆炸」的情況，而且子線程不恰當地設置 QoS，會容易導致主線程被搶占；
3）主線程任務過重，占用時間片過長，會被系統懲罰降級，然后被其他子線程搶占。

了解了原因以后，我們從以下三個方面進行治理。

5.2減少子線程的數量

手 Q 大部分業務廣泛使用 GCD，經過查找資料和研究，我們發現頻繁使用 GCD 的全局隊列，可能會導致線程爆炸，原因是當子線程在 sleep/wait/lock 狀態時，會被 GCD 認為是非活躍的狀態，當有新的任務到來時可能便會創建新的線程。

Apple 工程師、前 GCD 開發工程師發表言論：

蘋果官方建議不要創建大量隊列，使用 target_queue 設置隊列的層級結構，多個子系統就形成了一個隊列的樹狀結構，最后隊列底層使用串行隊列作為 target_queue 。（詳情請見《Modernizing Grand Central Dispatch Usage - WWDC17》）。

5.3降低子線程 QoS

如果全局隊列 QoS 設置為 DISPATCH_QUEUE_PRIORITY_DEFAULT，則該任務的 QoS 將繼承原來所在隊列的 QoS （如果原來隊列是主隊列，將從 QOS_CLASS_USER_INTERACTIVE 降低為 QOS_CLASS_USER_INITIATED）。開發同學經常在主線程將任務派發到全局隊列，并指定 QoS 為 DISPATCH_QUEUE_PRIORITY_DEFAULT ，這將導致存在大量子線程 QoS 為 QOS_CLASS_USER_INITIATED。

以下是 QoS 優先級排序：

__QOS_ENUM(qos_class, unsigned int,
  QOS_CLASS_USER_INTERACTIVE = 0x21, // 33
  QOS_CLASS_USER_INITIATED = 0x19, // 25
  QOS_CLASS_DEFAULT = 0x15, // 21
  QOS_CLASS_UTILITY = 0x11, // 17
  QOS_CLASS_BACKGROUND = 0x09, // 9
  QOS_CLASS_UNSPECIFIED = 0x00, // 0
);

而實際開發中，很多網絡請求、寫磁盤 I/O，都使用了該 QoS，實際上是可以通過降低 QoS 來降低子線程的優先級。

5.4提高主線程的優先級 QoS

QoS 并不完全等價于最終的線程優先級，主線程優先級范圍為 29~47 。

為什么運行過程中主線程優先級會變化？

蘋果官方文檔《Mach Scheduling and Thread Interfaces》中的 “Why Did My Thread Priority Change? ” 章節解釋了這個原因：

如果線程的運行超出了其分配的時間而沒有被阻塞，則會受到懲罰甚至被降低優先級，這么做的目的就是為了避免高優先級的線程一直搶占系統資源，導致低優先級的線程一直處于饑餓的狀態。

如何避免主線程運行超出 CPU 分配時間，而免除降級懲罰？可以從 RunLoop 層面做減負。

App 啟動過程開始的第一個 RunLoop，會執行持續到首屏渲染結束。而首屏的任務一般很重，導致 RunLoop 耗時很長，容易被系統降級。

QQ 啟動時第一個 Runloop 耗時示意圖：

解決方案是對第一個 RunLoop 里的任務做拆分。

我們的做法是保留必要的全局初始化邏輯在第一個 RunLoop 中，把主 UI 的創建延遲到下一個 RunLoop 里。這樣不僅有效地解決了啟動時主線程被搶占的情況，還能夠加速啟動更快看到主頁面。

PS：其實這里還有一些優化空間，我們將第一個 RunLoop 的任務都挪到第二個 RunLoop 了，就又導致第二個 RunLoop 耗時較大，可以按照此思路繼續優化。

6、性能流暢度提升（"眾"享絲滑）

APP的流暢（絲滑），體感上的表現是屏幕內容跟隨手指操作即時變化，每一次操作都即時地反饋在屏幕上。

如下圖所示，未開啟高刷幀率時應保證 16.67ms 內將用戶操作更新至屏幕上。

用戶每個操作，都需經歷圖中的4個步驟，任一步驟時間過長，都會無法及時更新畫面造成卡頓（來源：《Advanced Graphics and Animation Performance》）。

讓 App 做到每 16.67 毫秒更新一次用戶操作很難嗎？

難，難在這么短的時間內 CPU 和 GPU 需要完成很多事情。

更具體的：

1）屏幕上顯示的內容只能在主線程更新（只能單核，無法利用到手機的多核 CPU）；
2）影響 GPU 的耗時因素多，展示的界面越復雜耗時越多。

主線程的 16.67 毫秒 - 系統需要的耗時 = 開發者可用的時間。如下圖所示，藍色區域為開發者占用的時間，當開發者使用的時間過長即會造成 hang，即卡頓。

如上圖所示：

1）紫色區域：系統接受與處理用戶手勢操作的耗時；
2）藍色區域：開發者轉換用戶操作為屏幕顯示內容的耗時；
3）黃色區域：屏幕展示內容的耗時。

（來源：《Explore UI animation hitches and the render loop》）

如此，想要絲滑就必須做到以下兩點：

1）善用多線程編程，盡可能少在主線程上做更新 UI 以外的事情；
2）盡可能讓 GPU 繪制簡單的界面，減少 GPU 耗時。

7、性能流暢度提升實踐1：善用多線程編程

善用多線程編程，盡可能少在主線程上做更新UI以外的事情。

7.1NT 內核架構打好基礎

QQ 9 所采用的 NT Kernel（NT全稱是New Technology，此處向 Windows NT 內核致敬），基于盡可能發揮多核 CPU 能效的理念而誕生，如下圖所示，最大程度將業務處理邏輯從負責 UI 展示的主線程中剝離，且使用異步調用代替線程鎖，提升效率的同時降低死鎖的可能。

NT Kernel 多線程模型：

此外，NT Kernel 采用 C++ 實現 IM 軟件的核心基礎能力，使其能跨平臺使用，保證各平臺的性能體驗一致，用戶交互界面則采用各平臺原生語言實現。讓用戶感受強勁性能的同時保證了各平臺特有的體驗。

NT Kernel 支持多平臺架構圖：

7.2全量刷新改增量刷新

在全新 NT 內核的加持下，耗時業務邏輯都已經挪到子線程，主線程僅剩刷新 UI 的相關工作。

那刷新 UI 這個事兒還有進一步優化的空間嗎？答案是肯定的，14 年陳的手機 QQ 在屏幕上更新一條新消息，會將當前展示的消息全部刷新一遍，即"全量刷新"機制。滾動時無法刷新消息、資源跳變等壞體驗，都是該機制導致的。

為什么滾動時無法刷新消息？

并非無法刷新，而是不能刷新。多余的刷新操作很容易使得 UI 更新無法在 16.67ms 內完成，進而誘發卡頓。

為什么會出現資源跳變？

全量刷新會觸使屏幕上的所有節點回收、重用，并且這種重用還是無序的。如下圖所示，全量刷新后節點位置會隨機發生改變，例如：尾號1b400（左圖第2個）的節點刷新前用于展示2，刷新則展示7（右圖第7個）。

對比左右兩張圖的節點內存地址可見，全量刷新后會出現隨機變化，并無規律可言。

無論是靜態或是動態圖片，都存在磁盤 I/O、解碼等耗時操作，一般都會采用異步加載，避免主線程的卡頓。再疊加這種隨機重用的特性，也就造成了"資源跳變"的表現。

根據不同的重用情況會有以下三種表現：

1）恰好是上次所用的節點或者內容恰好相同：相同內容賦值，沒有任何變化；
2）沒有相關動/靜圖：內容從無到有，符合預期；
3）有相關動/靜圖，但與當前 Model 的內容不一致：出現閃爍。

如上圖下圖所示：

1）所有異步加載數據的元素搭配全量刷新，在未加載完畢前會展示其他節點的舊信息；
2）即使刷新時重置視圖也無法解決，只是從A->A->B改成A->空->B，依然存在明顯的跳變。

QQ 9 采用的"增量刷新"就能很好的解決上述兩個體驗問題。

此外，還有一個全量刷新無法實現的隱藏福利：節點動畫，如下視頻所示。

實現增量刷新需要有個可靠的 Diff 算法，告知系統有變化的節點是需要執行刷新、插入、刪除、移動中的哪種操作，一旦給到錯誤的信息將會直接導致 App Cras。敲定算法過程也是一波三折。

首先，閱讀源碼發現 Android 與 iOS 系統內置的 Diff 工具都是采用 Myers 算法實現的。

Myers：計算結果保存在changes的數組內，其中只有insert、remove兩種類型。（來源：Swift Diffing）

Myers算法求解過程，通過插入、刪除求源到目的的最短編輯距離（來源：《AnO(ND) difference algorithm and its variations》）。

該算法在計算移動時存在"缺陷"，其通過插入+刪除行為推測移動，特定場景下移動操作會降級為插入+刪除。

比如，先刪除再移動就會轉換為刪除+插入，反之則是移動+刪除：

1）刪 + 移 → 刪 + 增：數據集A:[1, 2, 3, 4, 5]->數據集B:[2, 3, 5, 4]。會刪除1、4，接著插入4；
2）移 + 刪 → 移 + 刪：數據集A:[1, 2, 3, 4, 5]->數據集B:[1, 2, 4, 3]。會交換3、4，隨后刪除5。

經過分析，理想的 Diff 算法應該具有以下兩種特質：

1）能夠記錄節點之間的移動關系，并不是通過插入、刪除的聯系推斷移動；
2）具備較低的時間復雜度與空間復雜度。

對比行業方案后，選中論文《A technique for isolating differences between files》中描述的 Heckel Diff 算法。該算法的最優、平均、最差復時間/空間復雜度均為 O(m+n)，優于 Myers 算法的 O((m+n)*d)。其符號表的實現方式保證所有移動操作均被記錄，不會再出現 Myers 中丟移動操作的情況，如下圖所示。

Heckel算法通過6個步驟借助符號表產生新老數據之間的Diff信息：

1）PASS1. 建立新數據所需新索引數組（NA）與 Symbol Table 之間的關系；
2）PASS2. 建立老數據所需舊索引數組（OA）與 Symbal Table 之間的關系；
3）PASS3. 查找位置沒有變化的節點，更新新舊索引數組（NA、OA）中的索引信息；
4）PASS4 - PASS5：適用于對兩個本文進行比較的 Case（存在 Key 值相同的情況），在 QQ 的應用場景中不允許出現相同 Key 值的情況，可跳過。感興趣的同學可以直接查閱論文；
5）PASS6. 根據現有結果計算差異，如圖下圖所示：

D表示被刪除，U表示沒有變化，4、5之間存在移動關系。

那么 Heckel 算法是完美的嗎？

不然，它并沒有考慮冗余的移動信息，冗余的移動操作會導致下圖中的動畫錯亂問題。

我們在 Heckel 算法的基礎上進行改良優化，追蹤記錄移動操作，區分出直接移動與間接移動，并將間接移動部分進行過濾刪除，最終得到滿足 QQ 9 各項指標要求的 Diff 算法。

如下圖示例，ID5 直接移動到第一行，ID1-4 都是間接往下移動。

記錄直接移動的偏移量（move = insert X + delete Y的偏移量都需要記錄），修正間接/被動移動的結果（ID 1-4的移動）。

7.3并行預布局

異步布局作為業界的最佳實踐，自然不能在 QQ 9 上缺席。我們也進一步嘗試將異步布局并行化，深挖性能極限。

首先嘗試了 N 條消息 N 個線程的方案：用 GCD 派發 N 個并發任務，然后用 DispatchGroup 等待這些任務執行完成。通過并行預布局，將原本一個線程需要幾十毫秒的預布局減少到了十幾毫秒。

這個方案后來發現了 2 個問題：

1）并行布局 N 條消息的總耗時還是比串行布局一條消息的耗時要大得多，受限于 CPU 核心數，代碼中的鎖或其他資源競爭導致 N 條消息的參數準備和布局計算沒有能充分的并行；
2）這N條消息的布局任務分別和 N 個 GCD 任務一對一綁定了，GCD 調度這 N 個任務中有任何一個調度慢都會拉長整個預布局的耗時。

如上圖所示：

1）充分利用多核CPU的算力；
2）使用并行計算，布局計算的總耗時減少了約76%。

調整后的方案如上圖所示，使用了 M 個執行者來執行N條消息的布局任務（N>=M>0）。當前線程（異步布局主線程）來執行 1 個執行者，然后再由 GCD 額外調度（M-1）個線程來執行（M-1）個執行者。首先將待計算的消息放入一個隊列中，每個執行者都會循環從待計算的消息隊列中取出一條消息執行布局計算，直到待計算的消息隊列為空。因為消息的布局任務沒有和任何一個執行者綁定，即使有執行者較長時間沒有被調度也不會導致布局計算遲遲無法完成，大部分情況下這 M 個執行者會被 M 個線程并行執行。

并行布局的總耗時會隨著并發線程的增加而減少，當增加到5以后耗時就基本沒有怎么減少了。

看上去目前布局計算的工作已經從主線程挪走了，現實是很多時候計算出來的坐標與大小并沒有與屏幕的像素點大小吻合，此時系統會在主線程再做一次“像素對齊”。在“異步布局”時也不能忽略該細節，才能確確實實減少主線程的負擔，如下圖所示。

OLED屏幕的1個像素R:G:B比例為1:2:1，顯示時DDIC（Display Driver IC，顯示驅動芯片）會進行次像素渲染從其他像素借元素使顯示更飽滿。但代碼并不能直接控制該行為，系統需要保證提交的內容與屏幕像素完全對齊，即不能出現類似使用0.5個像素的情況。

標黃區域為坐標、大小結果與屏幕像素未對齊：

其他的優化還有：智能預加載、消息回收、圖片資源異步解碼等。

如下圖所示：根據屏幕比例得到一級緩存 display ，二級緩存 preload ，超出的部分則被回收釋放。

8、性能流暢度提升實踐2：減少GPU耗時

減少GPU耗時，盡可能讓GPU繪制簡單的界面。

除了布局可以異步計算，復雜的圖像也能使用"異步渲染"的方式降低 GPU 的耗時。特別是面對需要疊加裁剪的圖形時， GPU 的繪制任務無法在一個 Frame 內完成，就需要再額外開辟一個 Frame Buffer 進行繪制，并在全部完成后將兩個 Buffer 的內容進行合成，這被稱作“離屏渲染”。離屏渲染對于性能的損耗非常大，主要在于 GPU 的上下文切換所需的開銷很大，需要清空當前的管線和柵欄。原話在這：A Performance-minded take on iOS design | Lobsters。

對于這種情況，蘋果的工程師給出的建議是用 CPU 繪制來給 GPU 分擔一部分工作。如下圖所示。