大型IM穩(wěn)定性監(jiān)測實踐：手Q客戶端性能防劣化系統(tǒng)的建設(shè)之路

Posted on 2024-08-02 10:38 Jack Jiang 閱讀(111) 評論(0) 編輯收藏

本文來自騰訊手Q基礎(chǔ)架構(gòu)團隊楊蕭玉、邱少雄、張自蹊、王褚重天、姚偉斌的分享，原題“QQ 客戶端性能穩(wěn)定性防劣化系統(tǒng) Hodor 技術(shù)方案”，下文進行了排版和內(nèi)容優(yōu)化。

1、引言

防劣化是比較經(jīng)典的技術(shù)話題，手 Q 的防劣化系統(tǒng)從 2021 年 10 月開始投入研發(fā)，從 0 到 1 迭代了將近三年的時間，已經(jīng)達到了業(yè)界先進水平。為了守護好手 Q 性能穩(wěn)定性的門禁，我們將其命名為 Hodor 系統(tǒng)，即 Hold the door！

從驗證可行性跑通最小閉環(huán)，到搭建群控機架一次次為集群擴容，實屬不易。其中涉及到大量的方案討論甚至推翻，很多思路和實現(xiàn)細節(jié)是業(yè)界找不到公開方案的，只能自己摸索。

本文以iOS端為例，詳細分享了手 Q 客戶端性能防劣化系統(tǒng)從0到1的構(gòu)建之路，相信對業(yè)界和IM開發(fā)者們都有較高的借鑒意義。

技術(shù)交流：

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

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

（本文已同步發(fā)布于：http://www.52im.net/thread-4680-1-1.html）

2、為什么要做防劣化

主要有以下原因：

1）代碼體量較大：業(yè)務(wù)涵蓋 IM/空間/短視頻/超級 QQ 秀等；
2）迭代需求緊：雙周迭代，研發(fā)人員多；每版本幾十條需求分支，主干每周構(gòu)建出包數(shù)百次；
3）問題較多：需求合流新增性能問題多，基礎(chǔ)側(cè)人力寡不敵眾，問題越堆越多，事后回溯效率低。

當業(yè)務(wù)的體量足夠大，問題足夠復(fù)雜的時候，解決問題的思路也需要轉(zhuǎn)變。

3、如何破局

盤點了下手 Q 研發(fā)流程的困局，現(xiàn)有的手段更著重于線上監(jiān)控問題并在下個版本修復(fù)（甚至是下下個版本），如果能在開發(fā)階段發(fā)布前甚至合入 master 之前就把問題扼殺在搖籃之中，就可以達到防劣化的目標。

下圖根據(jù)手 Q 真實慘痛案例改編，當年為了查一個嚴重的啟動耗時劣化問題，二分法拉代碼手動跑 Instruments 的痛，懂的都懂。

（此聊天記錄為虛構(gòu)，如有雷同純屬巧合）

大家開發(fā)需求都愛趕 deadline，所以合流高峰期光靠堆人力代碼 CR 和手動測試性能是不現(xiàn)實的，性能問題漏出事后優(yōu)化也是不夠的。因為業(yè)務(wù)的復(fù)雜性，總是優(yōu)化趕不上劣化快。

手 Q 在優(yōu)化性能穩(wěn)定性的同時，也提前布局防劣化系統(tǒng)，將其作為質(zhì)量三位一體中的重要一環(huán)（如下圖所示）。

4、防劣化系統(tǒng)的目標

提前發(fā)現(xiàn)部分主路徑問題，通過門禁防止性能劣化：

1）主干合流門禁：對于較穩(wěn)定的性能指標，合流前自動檢查；
2）日常自動提單：針對偶現(xiàn)的性能問題，開發(fā)階段提前發(fā)現(xiàn)；
3）性能數(shù)據(jù)看板：常態(tài)化詳細數(shù)據(jù)看板，上帝視角觀測性能；
4）告警機器人：自定義各性能維度告警規(guī)則，第一時間發(fā)現(xiàn)問題。

5、防劣化系統(tǒng)的實現(xiàn)

因為整套系統(tǒng)的實現(xiàn)比較復(fù)雜，考慮到整體篇幅限制，數(shù)據(jù)采集部分僅概述 iOS 平臺的方案，各平臺數(shù)據(jù)的上報協(xié)議及服務(wù)端的處理邏輯是共享的。

6、方案設(shè)計

6.1概述

要做好門禁，就需要把性能數(shù)據(jù)精確到每一次 commit，并做好科學的對比。

現(xiàn)實情況是很復(fù)雜的，可能有各種各樣的突發(fā)情況：

基于以上訴求，我們開發(fā)了 feature 分支對比 master 的算法策略。建立全維度性能指標和科學歸因方案。Hodor 實現(xiàn)了性能報告、數(shù)據(jù)分析、智能調(diào)度、提單告警、設(shè)備管理、用例管理等一系列能力。

大概的運行機制如下：

此方案的優(yōu)點：

1）性能測試和性能報告創(chuàng)建審批左移到開發(fā)階段；
2）覆蓋場景可拓展：測試用例云端獨立管理派發(fā)；
3）性能維度可拓展：支持 Instruments 所有模板；
4）靜態(tài)檢查可拓展：構(gòu)建數(shù)據(jù)服務(wù)端存儲與比對。

6.2防劣化 ≠ 自動化測試

現(xiàn)有測試平臺和工具的不足：

1）測試平臺站在發(fā)現(xiàn)問題角度，缺乏解決問題思維；
2）APM SDK 運行時采集能力受限。

詳細來說，就是：

1）傳統(tǒng)的自動化性能測試平臺和工具的報告只有 metric 統(tǒng)計數(shù)據(jù)和 App 截圖/日志，信息太少不足以定位問題；
2）APM 平臺的線上監(jiān)控很強大，但無法動態(tài)追蹤采集 time profiler 等詳細數(shù)據(jù)。

所以解決問題依然需要開發(fā)同學獲取更詳細信息或能夠 debug 復(fù)現(xiàn)問題，而性能問題往往是偶現(xiàn)的。

自動防劣化解決方案：打通發(fā)現(xiàn)和解決問題全鏈路。

主要是：

1）通過 Instruments 動態(tài)追蹤技術(shù)采集 diagnostic 診斷數(shù)據(jù)，無侵入性；
2）xctrace 自動解析 trace 文件，翻譯堆棧精準歸因，還原『案發(fā)現(xiàn)場』；
3）每次提交構(gòu)建均執(zhí)行防劣化檢測，精準定位問題的提交引入者；
4）數(shù)據(jù)可視化看板+自動提單派發(fā)+大模型 AI 分析問題 = 測開降本增效。

總之，手 Q 的解決方案從一開始就打破了傳統(tǒng)思維，最終的方案也是真香！

6.3復(fù)雜業(yè)務(wù)下如何降低性能波動

俗話說細節(jié)決定成敗，很多事情想跑通 demo 很容易，但是想達到高可用性，需要打磨很多很多細節(jié)才能應(yīng)用到生產(chǎn)環(huán)境。比如為了控制變量降低場外因素波動，大到集群調(diào)度策略，小到機器零件型號，都錙銖必較。

7、數(shù)據(jù)采集實現(xiàn)

在運行時性能數(shù)據(jù)采集方面，我們擁有一套自研方案；在靜態(tài)掃描方面，也從編譯鏈接過程采集了相關(guān)數(shù)據(jù)。

7.1 動態(tài)性能數(shù)據(jù)采集

性能采集方案選型之初，我們對于性能采集主要有以下幾個訴求：

1）需要有詳細的堆棧信息；
2）性能維度足夠多；
3）最好非侵入式的；
4）容易與 CI 流程相結(jié)合。

為了滿足上述訴求，最終我們選則了當時蘋果剛推出的 xctrace 方案。

7.1.1）應(yīng)用外數(shù)據(jù)采集：

[1] xctrace：

Instruments 是 iOS & macOS 平臺進行性能分析必不可少的工具，它能采集到絕大多數(shù)的性能數(shù)據(jù)，同時擁有精美的 GUI 方便排查和分析。但是 Instruments一直都只有 GUI（古早年代曾經(jīng)有過導出性能數(shù)據(jù)的功能，后面也去掉了），沒有 CLI，這也使自動化使用 Instruments 進行性能采集和分析成為奢望。直到 Xcode 12，蘋果終于推出了 Instruments 的 CLI 版本：xctrace。

xctrace 提供了一系列命令，可以錄制、導出性能數(shù)據(jù)，Instruments 支持哪些性能維度，xctrace 就支持哪些性能維度。我們根據(jù)不同的性能采集需求，生成不同的性能模板，使用 xctrace 錄制對應(yīng)的性能數(shù)據(jù)。錄制好的 trace 文件可以通過 xctrace 導出為 XML 格式的文件，從 XML 文件中讀取到性能數(shù)據(jù)。

值得一提的是，手 Q 作為早期第一批吃螃蟹使用 xctrace 的技術(shù)團隊，我們一邊摸著石頭過河探索 workaround，一邊與蘋果團隊合作以提升其可用性。Xcode 14 Release Notes 中解決的多個 issue 也是手 Q 團隊在防劣化開發(fā)過程中向 Apple 提出的：

所以手 Q 團隊已經(jīng)默默幫大家踩過很多坑了！

[2] Xcode Memory Graph：

在排查內(nèi)存泄露相關(guān)問題時，使用 Instruments 內(nèi)存相關(guān)模板只能看到對象的創(chuàng)建堆棧和引用計數(shù)的增減過程，無法展示對象間的引用關(guān)系。面對這類問題，Xcode Memory Graph 是更好的選擇，但 Xcode Memory Graph 也是一個嵌入到 Xcode 的 GUI 程序，目前為止還沒有 CLI 實現(xiàn)。為此，我們調(diào)研了 Xcode Memory Graph 的實現(xiàn)，獲取到相關(guān)協(xié)議，實現(xiàn)脫離 GUI 生成 Xcode 內(nèi)存圖，并使用 heap、vmmap、leaks 等工具分析內(nèi)存圖，實現(xiàn)自動采集內(nèi)存圖，進行大內(nèi)存占用和內(nèi)存泄露的分析和監(jiān)控。

[3] Crash：

Crash 的監(jiān)控比較簡單，我們是通過檢查測試過程中設(shè)備上有沒有新生成的 ips 文件方式來監(jiān)測 Crash 的。這種方式的優(yōu)點是監(jiān)控范圍廣，SIGKILL、pre-main 階段 Crash 等常規(guī)方式無法捕獲的 Crash 也能監(jiān)控到。實踐中遇到的一個小坑是單臺設(shè)備每天單個 App 生成 ips 文件是有上限的，之前測試閾值是 50，崩潰超過 50 次就不再生成 ips 文件。

[4] 高頻日志：

分析客戶端日志是必不可少的排查問題的手段，但大型項目業(yè)務(wù)繁多，會出現(xiàn)很多無效高頻日志，高頻日志會占用大量的 IO 和 CPU 資源造成卡頓和發(fā)熱，甚至有導致日志文件過大，無法打撈起來的情況。而且很多時候，高頻日志的背后就是一段死循環(huán)或者循環(huán)調(diào)用邏輯的存在，所以我們對高頻日志也進行了監(jiān)控和告警提單。

7.1.2）應(yīng)用內(nèi)數(shù)據(jù)采集：

[1] 流量監(jiān)控：

流量下載的數(shù)據(jù)采集，雖然 Instruments Network 模塊能夠監(jiān)控所有的下載請求，但 Network 上顯示的流量大小依賴了 Response Header的 Content-Length 或 Range 字段。由于部分后臺服務(wù)器并沒有填寫該字段，所以 Instruments 上無法獲取總的下載流量大小，故而放棄 Instruments 上采集數(shù)據(jù)，改用 App 運行時收集數(shù)據(jù)。

[2] 業(yè)務(wù)打點：

性能數(shù)據(jù)需要和業(yè)務(wù)場景進行關(guān)聯(lián)，我們采用了蘋果的 Signpost 方案進行打點。

選擇 Signpost 打點方案的原因主要是下面 3 點：

1）和 Instruments 高度契合，Instruments 有 os_signpost 模板，應(yīng)用內(nèi)使用 signpost 相關(guān)接口打的點，在 Instruments GUI 展示性能數(shù)據(jù)時，也能將業(yè)務(wù)打點一并展示，方便排查問題；
2）signpost 打點數(shù)據(jù)可以使用 xctrace 進行導出，可以實現(xiàn)業(yè)務(wù)場景和性能數(shù)據(jù)的相關(guān)聯(lián)；
3）相比 print 打點方式，signpost 性能損耗更低。

7.2 靜態(tài)掃描能力

7.2.1）符號掃描：

平臺有兩套符號掃描工具，都是面向鏈接期產(chǎn)物 (Mach-O Image) 進行靜態(tài)掃描，分別洞察產(chǎn)物中的 Objective-C (簡稱 OC) 符號問題和原生符號問題。

[1] OC 符號掃描：

OC 符號掃描工具，幫助掃描工程產(chǎn)物中存在的 OC Category 同名方法覆蓋和 +load 靜態(tài)初始化方法。

OC Category 同名方法覆蓋是指 Category 機制隱含的運行時實現(xiàn)覆蓋問題。

覆蓋問題有兩種情形：

1）若主類 (原類) 存在一個與 Category 擴展方法同名的方法，則運行時會選擇 Category 的實現(xiàn)使用；
2）若存在多個 Category 都對同一個類擴展了同名的方法，則運行時會選擇其中一個 Category 的實現(xiàn)使用。

這兩種情況都可能導致程序邏輯非預(yù)期地調(diào)用到其他庫的實現(xiàn)，出現(xiàn)功能異常或崩潰。該問題相對隱蔽不易被察覺，因為在鏈接期間不會產(chǎn)生警告。盡管代碼規(guī)范要求 Category 方法名必須加前綴來規(guī)避該問題，但該問題在大型多源項目的集成過程中，還是時有發(fā)生，只是往往因為恰好兼容沒出問題而沒感知。直到某天改動后出現(xiàn)莫名異常，溯源后才發(fā)現(xiàn)。

+load 方法在程序加載的靜態(tài)初始化階段執(zhí)行，會影響應(yīng)用的啟動耗時。

這兩類方法(符號)對穩(wěn)定性和性能有全局性的影響，因此平臺建設(shè)了工具來關(guān)注這些符號。

工具綜合基于 class-dump 和鏈接器生成的 LinkMap 信息 (如果有)，獲取產(chǎn)物中的全部 OC 符號和來源，統(tǒng)計篩選出重名 Category 方法和 +load 方法。并與 CI 構(gòu)建檢查相結(jié)合，監(jiān)控和管控這兩類問題方法，設(shè)立門禁要求業(yè)務(wù)新引入 +load 和重名方法須拉通基礎(chǔ)側(cè) Review。

[2] 原生符號掃描：

原生符號掃描工具，幫助掃描工程所有依賴庫中存在重復(fù)的庫函數(shù)(符號) (主要關(guān)注 C 符號重復(fù)問題)。

通常重復(fù)的庫函數(shù)是 C/C++ 編寫的基礎(chǔ)實用函數(shù)，這大部分歸咎于 C/C++ 缺少廣泛認可的依賴管理范式，部分大型業(yè)務(wù)靜態(tài)庫采取將其依賴的實用方法庫也一同編譯打包 (ar) 的范式而導致。這些實用方法庫通常是廣泛使用的基礎(chǔ)實用庫，如 FishHook、zip、libffi 等。若有多個業(yè)務(wù)靜態(tài)庫都集成了同源的基礎(chǔ)實用庫，在鏈接 (ld) 生成可執(zhí)行程序時，鏈接器會選擇其中一份鏈接 (取決于鏈接先后順序等因素，可以通過 LinkMap 確認選用的實現(xiàn))，它們雖然具有相同的符號 (API)，但版本/實現(xiàn)未必一致、ABI 未必兼容，所以如果鏈接時選取的實現(xiàn)不恰當，則可能出現(xiàn)功能異常或崩潰。

通過原生符號掃描工具，掃描出重復(fù)的庫函數(shù)，有助于標識出上述這樣“存在多份重復(fù)選其一不兼容”的潛在風險。

工具的工作流程是解析鏈接 (ld) 參數(shù)，遍歷每一個參與鏈接的靜態(tài)庫，使用 nm 工具等工具讀取它們包含的對外導出 (External & Defined) 符號。實踐中集成到 CI，在構(gòu)建完成后的現(xiàn)場回溯構(gòu)建日志取得鏈接 (ld) 參數(shù)并執(zhí)行，統(tǒng)計出重復(fù)的原生符號并根據(jù)規(guī)則登記歸檔。

最終的統(tǒng)計結(jié)果會展示在 Hodor 平臺，可以查看每個 commit 的重復(fù)符號變化情況（如下圖所示）。

7.2.2）碰撞掃描：

在 Hodor 防劣化系統(tǒng)上線了一段時候后，我們抓到了一個冷啟動劣化的 case：主干上一個新提交導致冷啟動 T0 階段（pre-main）劣化了 150+ ms，但該提交只修改了一個方法名。在排除掉外部因素、測試環(huán)境穩(wěn)定性因素之后，發(fā)現(xiàn)真的因為一個方法名導致冷啟動劣化那么多。

問題看起來很棘手：幸好，我們有詳細的 trace 文件，在詳細分析對比了劣化前后的堆棧之后，發(fā)現(xiàn)劣化的根源是冷啟動創(chuàng)建啟動閉包時調(diào)用了一個 perfect hash 的算法，新修改的方法名導致這個算法的碰撞次數(shù)增加了，發(fā)生碰撞的情況下，需要 rehash，于是耗時增加。

以下是生成啟動閉包的簡要流程：

找到了劣化的原因，那如何找到發(fā)生碰撞的方法名呢？

答案只能去 dyld 源碼里找，還好，dyld 是開源的，我們在 dyld 源碼里找到了生成啟動閉包相關(guān)的部分，在發(fā)生碰撞的地方輸出對應(yīng)的 sel 名字，將其編譯起來后，把 QQ 的 Mach-O 掃一遍，這樣我們就找到了所有的碰撞點，之后我們修復(fù)了所有的碰撞點，冷啟動得以降低了 700 ms（iPhone 11）。

我們將該掃描工具部署回了 Hodor 系統(tǒng)，監(jiān)測每一個提交的碰撞情況，同時我們也將這個問題反饋給了蘋果負責 linker 的團隊。

8、任務(wù)調(diào)度實現(xiàn)

職責在于監(jiān)聽 Git 事件與自定義事件并生成多類型的性能測試任務(wù)，在合適的時間點將任務(wù)與合適的測試機進行匹配然后生成配置文件，最后將配置文件派發(fā)到數(shù)據(jù)采集端驅(qū)動性能測試任務(wù)在對應(yīng)測試機上執(zhí)行。

8.1任務(wù)類型

防劣化性能測試任務(wù)主要分為以下幾大類

8.1.1）主流程測試：

由基礎(chǔ)側(cè)提供的核心測試用例組，測試流程包括手Q的幾個核心場景進行測試（啟動、登錄、AIO、頻道、短視頻等），所有分支默認運行當前測試用例組。

后續(xù)性能報告也是基于當前用例組所上報的性能數(shù)據(jù)來進行對比。保證統(tǒng)一的測試用例流程與環(huán)境，性能數(shù)據(jù)的對比才是可信任的。

8.1.2）專項測試：

針對某些性能維度（內(nèi)存、IO、預(yù)下載流量檢測等）單獨進行測試。最終生成相應(yīng)性能看板。

8.1.3）自定義用例測試：

手 Q 功能場景十分的龐大復(fù)雜，基礎(chǔ)用例也無法覆蓋到所有的場景，由此誕生自定義測試用例功能。

如果業(yè)務(wù)同學想觀察自己所處業(yè)務(wù)部分詳細的性能數(shù)據(jù)，防劣化系統(tǒng)支持由各業(yè)務(wù)來編寫自定義的測試用例，測試完畢后根據(jù)上報數(shù)據(jù)與定義的場景將自動生成相應(yīng)性能看板。

8.1.4）Crash、Monkey 測試：

在日常開發(fā)中，發(fā)生 Crash 問題將會嚴重影響整個項目開發(fā)進度。我們希望能第一時間將問題檢測暴露出來并推動修改。

啟動以及主流程 Crash 則是最為嚴重的，直接導致項目不可使用，影響大家日常開發(fā)。Master 主干的每一個 Commit 合入都會進行 Crash 測試。如果發(fā)生 Crash，會立即拉群通知排查。而對于非啟動以及主流程 Crash 問題則會進行自動提單。

而 Monkey 測試則是模擬用戶操作，無序進行操作。能夠盡可能的將 Crash 問題暴露出來。

8.1.5）閑時利用：

為了更充分的利用防劣化系統(tǒng)，在空閑時間（深夜、周末）會對過去已經(jīng)測試過的主干 Commit 再次進行測試。用盡可能多的測試來暴露出更多的問題。

8.2 任務(wù)調(diào)度管理

所有生成的測試任務(wù)會根據(jù)任務(wù)類型，優(yōu)先級等條件進行一輪排序，最終優(yōu)先保證最緊急的任務(wù)最優(yōu)先執(zhí)行。

簡單示意圖如下：

當任務(wù)狀態(tài)異常時，也會有告警：

8.3 設(shè)備管理

針對不同類型的任務(wù)采用不同的策略進行測試機分配：

1）對于 Crash 任務(wù)，為了保證能第一時間發(fā)現(xiàn)問題，會分配專門的機器池進行測試；
2）對于性能任務(wù)，根據(jù)版本流程與任務(wù)優(yōu)先級進行動態(tài)分配。基礎(chǔ)性能>業(yè)務(wù)自定義>=專項測試>閑時利用。

設(shè)備環(huán)境發(fā)生問題，也將及時進行告警：

9、數(shù)據(jù)處理實現(xiàn)

9.1概述

由于 Instruments 采集到的性能數(shù)據(jù)量巨大，動輒 GB 級別，無法全量上報，所以性能數(shù)據(jù)采集時會進行符號化和性能問題的分析，比如找出卡頓堆棧、內(nèi)存泄露的對象等。分析完畢后會將數(shù)據(jù)上報給服務(wù)端，由服務(wù)端進一步處理。

職責在于將上報的數(shù)據(jù)根據(jù)不同規(guī)則進行計算存儲。不同維度性能根據(jù)不同規(guī)則計算，得出相應(yīng)的性能結(jié)果并消費劣化性能數(shù)據(jù)（自動提單與告警）。

9.2 不同類型性能數(shù)據(jù)的處理

9.2.1）基礎(chǔ)性能數(shù)據(jù)：

對于基礎(chǔ)性能數(shù)據(jù)而言（CPU、內(nèi)存、IO、線程數(shù)），上報的數(shù)據(jù)是原始每一次采樣所得數(shù)據(jù)（大致在一秒采樣一次）。

這里誕生了兩種計算方式：

1）對于關(guān)注整體性能數(shù)據(jù)以及流程比較短的用例，則會整體計算出三個維度的數(shù)據(jù)：峰值數(shù)據(jù)、平均數(shù)據(jù)、結(jié)束時數(shù)據(jù)；
2）對于有定義「場景」的用例，會根據(jù)所傳遞的打點（Signpost）值來找到對應(yīng)時間范圍的數(shù)據(jù)進行計算。同樣是以上三個基礎(chǔ)維度，另外新增一個耗時計算。

整體示意圖如下：

9.2.2）重點性能數(shù)據(jù)：

對于重點關(guān)注的數(shù)據(jù)（啟動時間，啟動線程狀態(tài)），采集端會使用專門的模板來進行測試，上報數(shù)據(jù)后。Server 端對多次測試結(jié)果數(shù)據(jù)進行綜合計算，得出結(jié)果最后展示在相應(yīng)看板上。

9.2.3）自定義性能數(shù)據(jù)：

對于自定義上報數(shù)據(jù)（重復(fù)符號變動，啟動階段函數(shù)監(jiān)控），則是開放專門上報數(shù)據(jù)接口，由對應(yīng)業(yè)務(wù)方自主計算上傳（防劣化會向業(yè)務(wù)方提供基本數(shù)據(jù)）。防劣化系統(tǒng)負責記錄數(shù)據(jù)并展示相應(yīng)看板。

9.3 消費性能劣化數(shù)據(jù)

9.3.1）自動提單：

我們會定時掃描數(shù)據(jù)庫中上報的性能劣化信息。先根據(jù)白名單以及過濾規(guī)則進行篩選，然后將需要提單的數(shù)據(jù)進行信息聚合，最終以提單的形式將問題自動分配給對應(yīng)的業(yè)務(wù)負責人。

bug 單包含了缺陷的堆棧等詳細信息：

9.3.2）性能告警：

對于主干的性能數(shù)據(jù)進行實時監(jiān)控，不同用例不同性能維度可以配置不同的告警規(guī)則。當發(fā)生劣化時及時將對應(yīng)的信息拋到對應(yīng)業(yè)務(wù)群中進行告警。

10、管理端展示

10.1 防劣化看板

防劣化看板支持查看指定時間、分支、測試用例和場景下的每個 commit 的狀態(tài)以及各項性能數(shù)據(jù)，并可以快速標記 commit，支持與任意 commit 的性能數(shù)據(jù)做對比。

10.2 分支性能報告

防劣化系統(tǒng)會對所有需求分支的每一次 push 進行性能測試，然后與對應(yīng)的主干 Commit 性能數(shù)據(jù)進行對比生成性能報告。能直觀的看到需求分支的性能變化，當性能發(fā)生劣化的時候也能直觀的看到是從哪個 Commit 開始引入劣化問題，方便問題排查。

測試報告有多種狀態(tài)，比如“等待數(shù)據(jù)上報”、“自動審批通過”、“自動審批不通過” 等：

當測試報告“自動審批不通過” 時，也會標注出是哪些指標不通過，便于開發(fā)者迅速定位問題：

10.3 測試用例管理

基礎(chǔ)所提供的主流程測試用例必然是無法覆蓋手 Q 所有的場景，因此提供開放能力，支持各業(yè)務(wù)方的開發(fā)、測試自主提供測試用例。在防劣化平臺上進行配置測試，測試完畢后自動根據(jù)配置生成相應(yīng)的性能看板。

同時對正在運行的測試用例進行成功率監(jiān)控，低于一定的成功率將進行告警。如業(yè)務(wù)方在一段時間內(nèi)沒有處理告警，會將其臨時下架避免資源浪費。

11、整體架構(gòu)

12、收益與總結(jié)

Hodor 上線后收益顯著，研發(fā)效率大幅提升！

通過將問題發(fā)現(xiàn)和解決左移到開發(fā)階段，可以有效防止問題漏出到線上導致大盤數(shù)據(jù)劣化。如某次提交導致主干啟動耗時上漲，基于防劣化系統(tǒng)可精準快速定位到代碼提交者。

Hodor 系統(tǒng)還在不斷迭代中，2024 年還拓展了 QQ 桌面客戶端，并在運行效率方面持續(xù)優(yōu)化。目前防劣化系統(tǒng)已經(jīng)落地了 QQ 各平臺。

防劣化系統(tǒng)從 0 到 1 迭代了將近三年的時間。從驗證可行性跑通最小閉環(huán)，到搭建群控機架一次次為集群擴容，實屬不易。其中涉及到大量的方案討論甚至推翻，很多思路和實現(xiàn)細節(jié)是業(yè)界找不到公開方案的，只能自己摸索。

在建設(shè)過程中我們遇到了不少很底層的問題需要與廠商溝通，比如與 Apple 的技術(shù)專家們線上和線下交流過程中也學到了不少，在此也感謝 Apple。

客戶端的性能穩(wěn)定性防劣化是一個很復(fù)雜的話題，而且只有體量足夠大的業(yè)務(wù)才會面臨更多的挑戰(zhàn)。正因為我們面對的很多問題業(yè)界都無先例可循，所以也期待行業(yè)內(nèi)后續(xù)有更多的分享和交流。同時，我們也期望 Hodor 不僅在性能穩(wěn)定性方面發(fā)揮作用，未來也會把手 Q 研發(fā)效能的各項指標集成進來。

[2] 大型IM工程重構(gòu)實踐：企業(yè)微信Android端的重構(gòu)之路

[3] 企業(yè)微信針對百萬級組織架構(gòu)的客戶端性能優(yōu)化實踐

[4] 微信團隊分享：詳解iOS版微信視頻號直播中因幀率異常導致的功耗問題

[5] 騰訊技術(shù)分享：Android版手機QQ的緩存監(jiān)控與優(yōu)化實踐

[6] 騰訊技術(shù)分享：Android手Q的線程死鎖監(jiān)控系統(tǒng)技術(shù)實踐

[7] 全面解密新QQ桌面版的Electron內(nèi)存優(yōu)化實踐

[8] 移動端IM實踐：iOS版微信界面卡頓監(jiān)測方案

[9] 微信團隊原創(chuàng)分享：Android版微信的臃腫之困與模塊化實踐之路

[10] 微信Windows端IM消息數(shù)據(jù)庫的優(yōu)化實踐：查詢慢、體積大、文件損壞等

[11] 微信團隊分享：微信支付代碼重構(gòu)帶來的移動端軟件架構(gòu)上的思考

[12] 微信客戶端團隊負責人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化

[13] 抖音技術(shù)分享：飛鴿IM桌面端基于Rust語言進行重構(gòu)的技術(shù)選型和實踐總結(jié)