微信客戶端性能監控和優化簡述

一款產品能否與用戶產生化學反應，客戶端在這一過程中的性能作用最關鍵。啟動時間太長、內存消耗太大、ANR等等，都會直接影響用戶對一款應用的判斷和使用體驗。

如微信Slogan說的那樣：微信，是一個生活方式。所以，微信App本身就包含非常多且複雜度高的業務模塊（如搜索、視頻等），也接入了很多第三方的插件，這勢必會拖慢應用的啟動時間和響應速度，尤其是目前出現了「微信重度用戶」這一現象，迫使微信不得不採取更多的分析和優化措施。

目前，已經有超過9億用戶在手機端使用微信，針對這樣龐大的用戶群，微信本著精益求精的態度和對用戶體驗的追求，在技術角度上最大程度的對性能進行優化。

微信研發團隊所做的監控系統可以分為兩類：一類是通用監控，一類是專項監控。

針對通用監控，團隊搭建了一套基於簡單數值上報的終端實時監控系統，可以覆蓋幾乎所有的監控緯度，最終呈現出來的是 PV、UV、耗時分布、錯誤統計等。比如准實時生成客戶端啟動次數、Crash 次數、網路調用次數等曲線，最少延遲可以做到10分鐘以內。

通用監控主要用於快速發現問題，而其定位問題的能力相對較弱，於是構建了多個專項監控系統。舉個例子，微信團隊構建的卡頓監控系統，不僅可以監控客戶端卡頓次數，還可以展示卡頓堆棧分類和排序，部分場景還可以做到精確標示函數調用的耗時分布。當然專項監控的上報延時更長，數據計算也比較複雜，目前能做到「小時～天」的級別，主要起分析定位的作用。

大部分監控以手動埋點、框架性自動埋點以及觸髮式上報為主，對性能影響很小。SQLite 和耗時監控，涉及較細力度的插樁，會有一定的性能損耗，前者主要用於開發和自動化測試階段，後者對現網用戶做了一定的採樣。

陳岳偉：針對微信客戶端的性能優化，主要分為網路、UI、內存、存儲等四大模塊。

網路方面，在 IPList 選擇策略、複合連接、連接耗時和穩定性、收發包耗時和穩定性、協議包壓縮精簡等諸多方面均作了長期的優化措施；針對安卓的後台長連接這一項，研發團隊就在心跳策略、Push 及時性等方面做了很多工作。（參照Mars 開源項目了解更多）

UI 方面，除了經典 TableView 和 ListView 優化外，團隊在圖片/視頻編解碼、Bitmap 磁碟映射、視頻渲染 Open GL 等領域也花了不少功夫。

內存方面，微信團隊構建了實用的內存泄漏工具以及前台 OOM 檢測工具，在開發過程中即可快速發現內存訪問不當的代碼實現；針對聯繫人、頭像和圖片等模塊做了統一的資源池，制定了符合微信特點的緩存和淘汰策略。

存儲方面，團隊研發了高易用介面的 WCDB 組件，統一了微信內的 DB 線程模型和事務機制；根據微信客戶端的消息、聯繫人、朋友圈和收藏等模塊做了針對性的 DB 分離和數據表拆分；通過修改 SQLite 源碼，大幅度降低了 SQLITE_BUSY 的發生次數；通過配置 DB 文件和 WAL 文件的 mmap 模式，對 DB 的 IO 性能也有不少的提升。關於這方面的內容，歡迎大家參考WCDB 開源項目。

陳岳偉：目前主要有兩大跨平台組件，包括 Mars 組件（COMM、XLOG、SDT、STN，詳見 Mars 介紹）和 WCDB 組件。其中 Mars 全部使用 C/C++開發，可適用於 iOS、Android、Windows 和 Mac 等平台；而 WCDB 主要根據 iOS（MacOS）和 Android 兩個平台提供了不同的語言適配，但底層的 SQLite源碼優化和 RepairKit，還是繼續採用 C/C++開發。

陳岳偉：iOS 端的 WebView 主要做了資源預載入與緩存、視頻代理與下載策略優化、圖片代理與編碼優化等，針對 WebView 安全和微信特有的 JS SDK 也有一系列的優化策略。

InfoQ：針對重度用戶的體驗優化是從什麼時候開始的？當時的觸發點是什麼？到目前主要做了哪些工作，有什麼規劃？

陳岳偉：從2015年底開始，當時觸發點是 DB 損壞率極速上升，以及用戶存儲空間快速增長；目前主要對 DB 損壞、內存 OOM 和存儲架構等做部分優化工作，前兩者會在 APMCon 給大家做詳細分享；後續希望對重度用戶大盤進行更精確的監控和分析，提升問題發現和定位能力。

嘉賓介紹：

陳岳偉（Lylechen），微信客戶端開發團隊負責人，統籌微信在iOS、Android、Mac和Windows等平台的開發管理工作。2010年加入微信團隊，從無到有構建出微信的第一個iOS版本，並持續不斷進行架構優化和性能穩定性打磨。近年來主要關注微信終端監控體系以及微信重度用戶的性能提升和體驗優化。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！