本文來自騰訊手Q基礎架構團隊楊蕭玉、邱少雄、張自蹊、王褚重天、姚偉斌的分享，原題“QQ 客戶端性能穩定性防劣化系統 Hodor 技術方案”，下文進行了排版和內容優化。

1、引言

接上篇《首次公開，最新手機QQ客戶端架構的技術演進實踐》。

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

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

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

2、為什么要做防劣化

主要有以下原因：

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

當業務的體量足夠大，問題足夠復雜的時候，解決問題的思路也需要轉變。

3、如何破局

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

 

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

（此聊天記錄為虛構，如有雷同純屬巧合）

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

手 Q 在優化性能穩定性的同時，也提前布局防劣化系統，將其作為質量三位一體中的重要一環（如下圖所示）。

4、防劣化系統的目標

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

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

5、防劣化系統的實現

因為整套系統的實現比較復雜，考慮到整體篇幅限制，數據采集部分僅概述 iOS 平臺的方案，各平臺數據的上報協議及服務端的處理邏輯是共享的。

6、方案設計

6.1概述

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

現實情況是很復雜的，可能有各種各樣的突發情況：

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

大概的運行機制如下：

此方案的優點：

• 1）性能測試和性能報告創建審批左移到開發階段；
• 2）覆蓋場景可拓展：測試用例云端獨立管理派發；
• 3）性能維度可拓展：支持 Instruments 所有模板；
• 4）靜態檢查可拓展：構建數據服務端存儲與比對。

6.2防劣化 ≠ 自動化測試

現有測試平臺和工具的不足：

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

詳細來說，就是：

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

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

自動防劣化解決方案：打通發現和解決問題全鏈路。

主要是：

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

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

6.3復雜業務下如何降低性能波動

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

7、數據采集實現

在運行時性能數據采集方面，我們擁有一套自研方案；在靜態掃描方面，也從編譯鏈接過程采集了相關數據。

7.1 動態性能數據采集

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

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

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

7.1.1）應用外數據采集：

[1] xctrace：

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

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

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

所以手 Q 團隊已經默默幫大家踩過很多坑了！

[2] Xcode Memory Graph：

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

[3] Crash：

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

[4] 高頻日志：

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

7.1.2）應用內數據采集：

[1] 流量監控：

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

[2] 業務打點：

性能數據需要和業務場景進行關聯，我們采用了蘋果的 Signpost 方案進行打點。

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

• 1）和 Instruments 高度契合，Instruments 有 os_signpost 模板，應用內使用 signpost 相關接口打的點，在 Instruments GUI 展示性能數據時，也能將業務打點一并展示，方便排查問題；
• 2）signpost 打點數據可以使用 xctrace 進行導出，可以實現業務場景和性能數據的相關聯；
• 3）相比 print 打點方式，signpost 性能損耗更低。

7.2 靜態掃描能力

7.2.1）符號掃描：

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

[1] OC 符號掃描：

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

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

覆蓋問題有兩種情形：

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

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

+load 方法在程序加載的靜態初始化階段執行，會影響應用的啟動耗時。

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

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

[2] 原生符號掃描：

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

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

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

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

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

7.2.2）碰撞掃描：

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

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

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

 

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

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

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

8、任務調度實現

職責在于監聽 Git 事件與自定義事件并生成多類型的性能測試任務，在合適的時間點將任務與合適的測試機進行匹配然后生成配置文件，最后將配置文件派發到數據采集端驅動性能測試任務在對應測試機上執行。

8.1任務類型

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

8.1.1）主流程測試：

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

后續性能報告也是基于當前用例組所上報的性能數據來進行對比。保證統一的測試用例流程與環境，性能數據的對比才是可信任的。

8.1.2）專項測試：

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

8.1.3）自定義用例測試：

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

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

8.1.4）Crash、Monkey 測試：

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

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

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

8.1.5）閑時利用：

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

8.2 任務調度管理

所有生成的測試任務會根據任務類型，優先級等條件進行一輪排序，最終優先保證最緊急的任務最優先執行。

簡單示意圖如下：

當任務狀態異常時，也會有告警：

8.3 設備管理

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

• 1）對于 Crash 任務，為了保證能第一時間發現問題，會分配專門的機器池進行測試；
• 2）對于性能任務，根據版本流程與任務優先級進行動態分配。基礎性能>業務自定義>=專項測試>閑時利用。

設備環境發生問題，也將及時進行告警：

9、 數據處理實現

9.1概述

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

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

9.2 不同類型性能數據的處理

9.2.1） 基礎性能數據：

對于基礎性能數據而言（CPU、內存、IO、線程數），上報的數據是原始每一次采樣所得數據（大致在一秒采樣一次）。

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

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

整體示意圖如下：

9.2.2）重點性能數據：

對于重點關注的數據（啟動時間，啟動線程狀態），采集端會使用專門的模板來進行測試，上報數據后。Server 端對多次測試結果數據進行綜合計算，得出結果最后展示在相應看板上。

9.2.3）自定義性能數據：

對于自定義上報數據（重復符號變動，啟動階段函數監控），則是開放專門上報數據接口，由對應業務方自主計算上傳（防劣化會向業務方提供基本數據）。防劣化系統負責記錄數據并展示相應看板。

9.3 消費性能劣化數據

9.3.1） 自動提單：

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

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

9.3.2）性能告警：

對于主干的性能數據進行實時監控，不同用例不同性能維度可以配置不同的告警規則。當發生劣化時及時將對應的信息拋到對應業務群中進行告警。

10、 管理端展示

10.1 防劣化看板

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

 

10.2 分支性能報告

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

 

測試報告有多種狀態，比如“等待數據上報”、“自動審批通過”、“自動審批不通過” 等：

 

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

 

10.3 測試用例管理

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

 

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

11、 整體架構

12、 收益與總結

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

 

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

Hodor 系統還在不斷迭代中，2024 年還拓展了 QQ 桌面客戶端，并在運行效率方面持續優化。目前防劣化系統已經落地了 QQ 各平臺。

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

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

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

13、 相關資料

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

[2] 大型IM工程重構實踐：企業微信Android端的重構之路

[3] 企業微信針對百萬級組織架構的客戶端性能優化實踐

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

[5] 騰訊技術分享：Android版手機QQ的緩存監控與優化實踐

[6] 騰訊技術分享：Android手Q的線程死鎖監控系統技術實踐

[7] 全面解密新QQ桌面版的Electron內存優化實踐

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

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

[10] 微信Windows端IM消息數據庫的優化實踐：查詢慢、體積大、文件損壞等

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

[12] 微信客戶端團隊負責人技術訪談：如何著手客戶端性能監控和優化

[13] 抖音技術分享：飛鴿IM桌面端基于Rust語言進行重構的技術選型和實踐總結

[14] 阿里技術分享：閑魚IM基于Flutter的移動端跨端改造實踐

[15] QQ設計團隊分享：新版 QQ 8.0 語音消息改版背后的功能設計思路

[16] 首次公開，最新手機QQ客戶端架構的技術演進實踐

14、更多鵝廠技術文章匯總

微信朋友圈千億訪問量背后的技術挑戰和實踐總結

騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)

IM全文檢索技術專題(二)：微信移動端的全文檢索多音字問題解決方案

微信團隊分享：iOS版微信的高性能通用key-value組件技術實踐

微信團隊分享：iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的？

微信團隊分享：微信Android版小視頻編碼填過的那些坑

IM全文檢索技術專題(一)：微信移動端的全文檢索優化之路

企業微信客戶端中組織架構數據的同步更新方案優化實戰

微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解

微信“紅包照片”背后的技術難題

移動端IM實踐：iOS版微信的多設備字體適配方案探討

騰訊信鴿技術分享：百億級實時消息推送的實戰經驗

IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）

騰訊技術分享：GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐

微信團隊分享：Kotlin漸被認可，Android版微信的技術嘗鮮之旅

社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等

社交軟件紅包技術解密(四)：微信紅包系統是如何應對高并發的

社交軟件紅包技術解密(十)：手Q客戶端針對2020年春節紅包的技術實踐

微信團隊分享：極致優化，iOS版微信編譯速度3倍提升的實踐總結

IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術實現

微信團隊分享：微信支付代碼重構帶來的移動端軟件架構上的思考

IM開發寶典：史上最全，微信各種功能參數和邏輯規則資料匯總

微信團隊分享：微信直播聊天室單房間1500萬在線的消息架構演進之路

企業微信的IM架構設計揭秘：消息模型、萬人群、已讀回執、消息撤回等

IM全文檢索技術專題(四)：微信iOS端的最新全文檢索技術優化實踐

微信團隊分享：微信后臺在海量并發請求下是如何做到不崩潰的

微信Windows端IM消息數據庫的優化實踐：查詢慢、體積大、文件損壞等

微信技術分享：揭秘微信后臺安全特征數據倉庫的架構設計

IM跨平臺技術學習(九)：全面解密新QQ桌面版的Electron內存優化實踐

企業微信針對百萬級組織架構的客戶端性能優化實踐

揭秘企業微信是如何支持超大規模IM組織架構的——技術解讀四維關系鏈

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

微信團隊分享：微信后端海量數據查詢從1000ms降到100ms的技術實踐

大型IM工程重構實踐：企業微信Android端的重構之路

IM技術干貨：假如你來設計微信的群聊，你該怎么設計？

微信團隊分享：來看看微信十年前的IM消息收發架構，你做到了嗎

長連接網關技術專題(十一)：揭秘騰訊公網TGW網關系統的技術架構演進

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