QQ 9“傻快傻快”的？帶你看看背後的技術秘密

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

作為龐大量級的應用，QQ 9 從哪些方面做了哪些優化，使得使用者能夠明顯感覺到流暢度的提升？本文将詳細介紹 QQ 9 流暢背後的技術實作，以及在全流程做的性能優化探索，為應用提升流暢度提供可複用的經驗。

仍有5億人堅持用 QQ

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

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

QQ 9 宣傳圖

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

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

吹毛求疵的打磨

2.1 極緻秒開 — 啟動速度優化

QQ 的絲滑體驗從「啟動優化」開始，以 iOS 端為例，啟動流程主要分為 3 個階段：

T0：點選圖示到 main 函數開始；
T1：從 main 函數開始到 didFinishLaunchingWithOptions 結束；
T2：didFinishLaunchingWithOptions 結束到首幀渲染完成。

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

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

一般工程上的優化方向：

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

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

2.1.1 pre-main 階段 - 按需裝載代碼

動态庫懶加載方案原理圖

代碼拆分組成動态庫并進行懶加載這項技術多應用于業界大型 App（抖音、Facebook、快手）中，但 QQ 的業務複雜度頗高，直接使用業界方案無法滿足我們的需求。經過一番探索我們找到了一些創新技術點：

使用 __attribute__((objc_runtime_visible)) 實作低成本代碼動态化改造。
使用 objc_setHook_getClass 實作動态化代碼入口收斂，保證了方案穩定性。

最終在 QQ 9 中大規模的應用實作了對 pre-main 階段的啟動耗時優化（這個技術方案約貢獻了33%左右的啟動總耗時優化資料收益）：

Xcode Organizer Launch 資料圖

2.1.2 post-main 階段 - 線程治理

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

Instruments 分析 QQ 啟動耗時圖

什麼是主線程搶占（Preempted）問題？簡單來說就是主線程的 CPU 時間片被其他線程搶占，導緻主線程得不到 CPU 資源。随着搶占問題越來越嚴重，也引出一些相關的問題，例如啟動總耗時也随着劣化、啟動後卡頓、啟動耗時波動大、防劣化性能報告誤判機率增大等。

為什麼會出現主線程被搶占？簡單來說有以下幾個原因：

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

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

減少子線程的數量

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

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

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

降低子線程 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 來降低子線程的優先級。

提高主線程的優先級

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 裡。這樣不僅有效地解決了啟動時主線程被搶占的情況，還能夠加速啟動更快看到首頁面。

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

2.2 "衆"享絲滑 — 性能流暢度提升

2.2.1 如何定義流暢？

流暢（絲滑），體感上的表現是螢幕内容跟随手指操作即時變化，每一次操作都即時地回報在螢幕上。如圖所示，未開啟高刷幀率時應保證 16.67ms 内将使用者操作更新至螢幕上。

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

讓 App 做到每 16.67 毫秒更新一次使用者操作很難嗎？難，難在這麼短的時間内 CPU 和 GPU 需要完成很多事情，更具體的：

螢幕上顯示的内容隻能在主線程更新（隻能單核，無法利用到手機的多核 CPU）。
影響 GPU 的耗時因素多，展示的界面越複雜耗時越多。

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

紫色區域：系統接受與處理使用者手勢操作的耗時

藍色區域：開發者轉換使用者操作為螢幕顯示内容的耗時

黃色區域：螢幕展示内容的耗時

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

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

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

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

NT 核心架構打好基礎

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

NT Kernel 多線程模型

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

NT Kernel 支援多平台架構圖

全量重新整理改增量重新整理

在全新 NT 核心的加持下，耗時業務邏輯都已經挪到子線程，主線程僅剩重新整理 UI 的相關工作。那重新整理 UI 這個事兒還有進一步優化的空間嗎？答案是肯定的，14 年陳的手機 QQ 在螢幕上更新一條新消息，會将目前展示的消息全部重新整理一遍，即"全量重新整理"機制。滾動時無法重新整理消息、資源跳變等壞體驗，都是該機制導緻的。

為什麼滾動時無法重新整理消息？并非無法重新整理，而是不能重新整理。多餘的重新整理操作很容易使得 UI 更新無法在 16.67ms 内完成，進而誘發夾頓。

為什麼會出現資源跳變？全量重新整理會觸使螢幕上的所有節點回收、重用，并且這種重用還是無序的。如下圖所示，全量重新整理後節點位置會随機發生改變，例如：尾号1b400（左圖第2個）的節點重新整理前用于展示2，重新整理則展示7（右圖第7個）。

對比左右兩張圖的節點記憶體位址可見，全量重新整理後會出現随機變化，并無規律可言。

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

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

恰好是上次所用的節點或者内容恰好相同：相同内容指派，沒有任何變化。
沒有相關動/靜圖：内容從無到有，符合預期。
有相關動/靜圖，但與目前 Model 的内容不一緻：出現閃爍。如圖下圖所示。

所有異步加載資料的元素搭配全量重新整理，在未加載完畢前會展示其他節點的舊資訊；即使重新整理時重置視圖也無法解決，隻是從A->A->B改成A->空->B，依然存在明顯的跳變。

QQ 9 采用的"增量重新整理"就能很好的解決上述兩個體驗問題。此外，還有一個全量重新整理無法實作的隐藏福利：節點動畫，如下視訊所示。

，時長00:21

實作增量重新整理需要有個可靠的 Diff 算法，告知系統有變化的節點是需要執行重新整理、插入、删除、移動中的哪種操作，一旦給到錯誤的資訊将會直接導緻 App Cras。敲定算法過程也是一波三折。

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

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

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

該算法在計算移動時存在"缺陷"，其通過插入+删除行為推測移動，特定場景下移動操作會降級為插入+删除。比如，先删除再移動就會轉換為删除+插入，反之則是移動+删除：

删 + 移 → 删 + 增：
資料集A:[1, 2, 3, 4, 5]->資料集B:[2, 3, 5, 4]。會删除1、4，接着插入4。
移 + 删 → 移 + 删：
資料集A:[1, 2, 3, 4, 5]->資料集B:[1, 2, 4, 3]。會交換3、4，随後删除5。

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

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

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

Heckel算法通過6個步驟借助符号表産生新老資料之間的Diff資訊

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

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

那麼 Heckel 算法是完美的嗎？不然，它并沒有考慮備援的移動資訊，備援的移動操作會導緻下圖中的動畫錯亂問題。

我們在 Heckel 算法的基礎上進行改良優化，追蹤記錄移動操作，區分出直接移動與間接移動，并将間接移動部分進行過濾删除，最終得到滿足 QQ 9 各項名額要求的 Diff 算法。如下圖示例，ID5 直接移動到第一行，ID1-4 都是間接往下移動。

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

并行預布局

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

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

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

充分利用多核CPU的算力；使用并行計算，布局計算的總耗時減少了約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 ，超出的部分則被回收釋放。

資源預加載政策圖

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

除了布局可以異步計算，複雜的圖像也能使用"異步渲染"的方式降低 GPU 的耗時；特别是面對需要疊加裁剪的圖形時， GPU 的繪制任務無法在一個 Frame 内完成，就需要再額外開辟一個 Frame Buffer 進行繪制，并在全部完成後将兩個 Buffer 的内容進行合成，這被稱作“離屏渲染”。離屏渲染對于性能的損耗非常大，主要在于 GPU 的上下文切換所需的開銷很大，需要清空目前的管線和栅欄。原話在這：A Performance-minded take on iOS design | Lobsters。對于這種情況，蘋果的工程師給出的建議是用 CPU 繪制來給 GPU 分擔一部分工作。如下圖所示：

标黃區域為GPU離屏渲染，不可否認GPU的off-screen比CPU的off-screen代價高很多；在無法避免mask的場景下，使用多核CPU進行異步渲染性能更好。

我們在渲染消息時利用了多核 CPU 進行異步渲染，降低 GPU 部分的耗時。這裡面臨的難點在于：在可快速滑動更新的清單場景使用時會出現"閃白"的問題；如著名第三方開源架構 YYKit 也存在此類問題，我們通過 LRU 緩存+增量重新整理的方式很好的解決了此問題。

2.2.4 疊滿 buffer 的絲滑體驗

基于上述 CPU 與 GPU 次元的各項優化，我們在消息 Tab 上實作了國内頭部同類應用目前也不具備的滾動中實時接收消息的能力，且不會出現卡頓；此外，也擴充了老版本 150 個會話的限制，與聊天界面一緻以分頁的形式加載使用者所有的會話節點，如下所示：

，時長00:13

滾動中接受消息，且不卡頓

進入群、好友聊天界面的速度也得到了質的提升，在加快進入動畫的同時，依然能夠保證即刻就能看到最新的聊天内容。如下圖所示 —— 同一個帳号進入同一個聊天頁面。左邊是優化前的效果，聊天頁面都快全部展示了，内容還在加載中；右邊是優化後效果，聊天頁面隻展示了一點點，就已經能看到發送方頭像和消息内容了。

進入聊天頁面加載速度對比圖（左為優化前，右為優化後）

除了進入速度的提升，聊天内容翻頁的速度也達到了業内頂尖水準：超越國内頭部同類應用，對标 Telegram。不論使用者有多少消息，都能夠通過不斷上拉看到，并且使用者感覺不到 loading 态。

聊天頁面優化前後對比圖（上為優化前，下為優化後）

2.3 青春常在 — 防劣化系統

打江山易，守江山難。防劣化是所有達到一定規模的技術團隊都會頭疼的問題，面對複雜的業務和技術債，手 Q 團隊投入了 3 年的時間疊代優化，現在手 Q 的防劣化系統已經達到了業界先進水準。作為手 Q 品質的守門員，我們将其命名為 Hodor（Hold the door）。

防劣化目标：提前發現部分主路徑問題，通過門禁防止性能劣化。

主幹合流門禁：對于較穩定的性能名額，合流前自動檢查。
日常自動提單：針對偶現的性能問題，開發階段提前發現。
性能資料看闆：常态化詳細資料看闆，上帝視角觀測性能。
告警機器人：自定義各性能次元告警規則，第一時間回報問題。

整體方案是基于 Instruments 動态追蹤技術采集 diagnostic 診斷資料；xctrace 自動解析 trace 檔案，翻譯堆棧精準歸因；每次送出建構均執行防劣化檢測，精準定位問題；還有資料可視化看闆 + 自動提單派發，将品質左移到開發階段。最終實作了性能報告、資料分析、智能排程、提單告警、裝置管理、用例管理等一系列能力。一圖以蔽之：

防劣化系統方案簡介

Xcode 12 開始提供了 xctrace，其 Release Notes 中解決的很多 issue 也來自于手 Q 團隊在防劣化開發過程中發現與回報。在性能優化方面 QQ 與 Apple 性能團隊交流緊密，大家也會加班克服中美時差。

整個手 Q 防劣化系統上線以來，有效地保證了開發主幹的穩定性，也檢測到了大量的性能和崩潰問題，同時攔住了很多新需求引入的性能問題。

防劣化成果圖

目前 Hodor 已經覆寫數十個場景，并落地 iOS/Android/Windows/macOS/Linux 五個平台。

輕盈煥新的 QQ 9

經過上述全方位優化，QQ 9 在各場景的性能都較曆史版本較大的提升，如下圖所示：

使用蘋果官方的工具：Xcode Organizer 可以看到 QQ 9在流暢度上較之前的版本 50 分位提升35%，卡頓率降低48%，啟動耗時降低40%。如下圖所示。

總結和展望

本文我們介紹了 QQ 9 絲滑背後的技術實作，從啟動速度，頁面重新整理，差異算法，預加載和回收，異步布局和渲染等方面介紹了我們在性能方面做的全流程優化，并介紹了幾個使用者體驗提升的場景表現。

其實技術領域深入複雜，每一項優化點都可以單獨拎出來好好地展開說明，因為篇幅問題，隻能留到以後慢慢和大家分享。

希望 QQ 技術團隊做的這些打磨，可以給使用者帶來切實的體驗提升；也希望 QQ 能越來越好，因為我們每一位也是堅持使用 QQ 的 5 億分之一。

作者:張曌丶畢磊

來源-微信公衆号:騰訊雲開發者

出處:https://mp.weixin.qq.com/s/nVXE0iSllZ3rFei4t7bR7g