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

guojin08發表於2018-03-19
客戶端優化
http://www.52im.net/thread-921-1-1.html
微信客戶端團隊負責人技術訪談：如何著手客戶端效能監控和優化
閱讀（6298） | 評論（1）收藏2 淘帖1 贊
JackJiang Lv.9 百尺杆頭 精華之王 終身成就 8 個月前 | |只看大圖

前言


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

如微信 Slogan 說的那樣：微信，是一個生活方式。所以，微信 App 本身就包含非常多且複雜度高的業務模組（如搜尋、視訊等），也接入了很多第三方的外掛，這勢必會拖慢應用的啟動時間和響應速度，尤其是目前出現了“微信重度使用者”這一現象，迫使微信追求更多的分析和優化措施。

在由聽雲聯合極客邦科技 /InfoQ 共同主辦的 APMCon 2017 會議上，我們邀請微信“小黑屋 11 人”之一的微信客戶端開發團隊負責人陳嶽偉（Lylechen）來 APMCon 現場分享“微信重度⽤戶體驗的優化之道”。InfoQ 對陳嶽偉進行了會前採訪，簡單瞭解了微信在客戶端效能監控和優化做了哪些工作。

訪談嘉賓


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

訪談內容


1請介紹一下，微信 iOS 客戶端第一個版本開發花了多長時間，在效能上有哪些關注點？


陳嶽偉：第一個 iOS 和 Android 微信版本均花了 2 個月左右的開發時間。初期階段主要集中在功能開發上，對效能沒有特別花太多時間關注，主要對於啟動速度、訊息收發等主場景做了壓力測試。對於一個初創的產品，微信研發團隊更看重版本的快速迭代，“先迭代再優化”是第一原則。（相關文章《開發往事：記錄微信3.0版背後的故事（距微信1.0釋出9個月時）》、《開發往事：深度講述2010到2015，微信一路風雨的背後》）

2目前微信客戶端有哪些維度的效能監控，侵入性如何，對效能有何影響？


陳嶽偉：目前微信客戶端的效能監控緯度，主要包含 Crash、卡頓、耗時、記憶體、SQLite、安裝包大小、網路效能等。

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

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

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

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

相關文章請見《移動端IM實踐：iOS版微信介面卡頓監測方案》、《移動端IM實踐：Android版微信如何大幅提升互動效能（一）》、《移動端IM實踐：Android版微信如何大幅提升互動效能（二）》。

3微信客戶端在效能上有哪些優化點？


陳嶽偉：針對微信客戶端的效能優化，主要分為網路、UI、記憶體、儲存等四大模組。

  • 網路方面：在 IPList 選擇策略、複合連線、連線耗時和穩定性、收發包耗時和穩定性、協議包壓縮精簡等諸多方面均作了長期的優化措施；針對安卓的後臺長連線這一項，研發團隊就在心跳策略、Push 及時性等方面做了很多工作。（參照  Mars 開源專案瞭解更多）。
  • UI 方面：除了經典 TableView 和 ListView 優化外，團隊在圖片 / 視訊編解碼、Bitmap 磁碟對映、視訊渲染 Open GL 等領域也花了不少功夫。
  • 記憶體方面：微信團隊構建了實用的記憶體洩漏工具以及前臺 OOM 檢測工具，在開發過程中即可快速發現記憶體訪問不當的程式碼實現；針對聯絡人、頭像和圖片等模組做了統一的資源池，制定了符合微信特點的快取和淘汰策略。
  • 儲存方面：團隊研發了高易用介面的 WCDB 元件，統一了微信內的 DB 執行緒模型和事務機制；根據微信客戶端的訊息、聯絡人、朋友圈和收藏等模組做了針對性的 DB 分離和資料表拆分；通過修改 SQLite 原始碼，大幅度降低了 SQLITE_BUSY 的發生次數；通過配置 DB 檔案和 WAL 檔案的 mmap 模式，對 DB 的 IO 效能也有不少的提升。關於這方面的內容，歡迎大家參考 WCDB 開源專案。

4微信客戶端目前開發了哪些跨端元件，是否均使用 C/C++ 開發？


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

微信的移動端資料庫元件WCDB和移動端IM網路層跨平臺元件庫Mars都已開源，開原始碼和資料託管等詳見《[資訊] 微信正式開源移動端資料庫元件WCDB！》、《如約而至：微信自用的移動端IM網路層跨平臺元件庫Mars已正式開源》 。

5微信 iOS 端在 WebView 上做了哪些優化，有哪些效能監控點？


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

目前微信絕大部分 WebView，均已替換為 WKWebView，在記憶體佔用和穩定性上有很大的提升。效能監控點，主要包含各階段耗時分佈、相關錯誤碼分類和記憶體 OOM 監控。

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


陳嶽偉：從 2015 年底開始，當時出發點是 DB 損壞率極速上升，以及使用者儲存空間快速增長；目前主要對 DB 損壞、記憶體 OOM 和儲存架構等做部分優化工作，前兩者會在 APMCon 給大家做詳細分享；後續希望對重度使用者大盤進行更精確的監控和分析，提升問題發現和定位能力。（《微信團隊原創分享：微信客戶端SQLite資料庫損壞修復實踐》一文詳細介紹了相關技術實踐）

相關文章