支付寶客戶端架構分析：自動化日誌收集及分析

前言

《支付寶客戶端架構解析》系列將從支付寶客戶端的架構設計方案入手，細分拆解客戶端在「容器化框架設計」、「網絡優化」、「性能啓動優化」、「自動化日誌收集」、「RPC 組件設計」、「移動應用監控、診斷、定位」等具體實現，帶領你們進一步瞭解支付寶在客戶端架構上的迭代與優化歷程。

本節將結合禾兮在 OSChina 珠海站現場的分享《移動端分析方案在螞蟻金服 mPaaS 中的實踐》，介紹支付寶客戶端自動化日誌收集與分析的具體思路。內容將分紅三個部分展開：

• 支付寶客戶端分析方案的探索；
• MAS 移動分析框架淺析；
• mPaaS 技術架構與助力。

支付寶客戶端分析方案的探索

正如咱們在《開篇 | 模塊化與解耦式開發在螞蟻金服 mPaaS 深度實踐探討》已經對支付寶的架構演變與開發團隊規模發展作過介紹：

截止目前，在研發上面，支付寶僅 Android、iOS 客戶端開發人員近千人，客戶端代碼行數超過了數百萬行，按業務劃分的工程數也已近千個，每一個工程都有獨立的開發 owner 負責某一個具體的模塊。雖然工程師團隊及工程量愈加龐大，支付寶依舊可以作到日發佈的頻率以確保業務快速迭代，同時在業務功能日益複雜的環境，保證 App 閃退率僅 0.01%。

那麼，在如此大致量的用戶規模和研發團隊下，支付寶又是如何確保用戶使用過程當中的用戶體驗呢？咱們主要從如下兩個維度衡量客戶端用戶體驗：

• 靜態：指應用開發過程當中，關注 App 自己的安裝包大小、存儲、涉及到的用戶隱私權限、安全策略等，決定用戶是否願意安裝並使用你的應用

• 動態：指應用發佈上線後，用戶在使用過程當中，App 的啓動速度，閃退、卡死卡頓等穩定性數據，網絡請求，內存以及電量流量等用戶實際的使用感覺

  

  啓動應用是用戶使用任何一款應用最必不可少的操做，從點擊 App 圖標到首頁展現，整個啓動過程的性能，嚴重影響着用戶的體驗，支付寶客戶端做爲一個超級 App，啓動速度固然是咱們關注的重要指標之一。支付寶對於應用啓動過程當中的優化，主要分爲如下三個方面：

• 框架治理：

  • 梳理啓動流程並重構，遵照啓動過程當中按需加載原則
  • 引用 Pipeline 機制，根據業務優先級規定業務初始化時機
  • 制定統一的開發規範，儘可能下降業務方流程對啓動性能的影響

• 業務治理：

  • 按需加載，延時執行
  • 線程治理：統一管理已有線程，並調整線程優先級
  • I/O 治理：關注主線程 I/O，優化合並頻繁讀寫的 I/O 操做，儘可能使用統一存儲

• 技術突破：

  • 防止啓動過程當中的 UI 重刷操做
  • 虛擬機優化，包括 JIT 關閉，下降 GC 次數
  • 基礎模塊調優，分析主線程耗時操做並優化

另外，用戶使用過程當中 App 的內存、存儲、電量及流量等消耗，也是重要的衡量指標。具體的優化點以下：

• 內存：
  • 內存分析：memtrace hprof 線下內存分析，遍歷對象，根據生命週期標記內存泄露，同時根據 object 建立引用肯定業務歸屬
  • Native 內存：圖像庫切換到 native 層，4.x bitmap 像素數據放到 ashme 共享內存，下降 GC
  • 內存優化：對象池複用，減少 bitmap 對內存佔用，使用更小的圖，尤爲注意三方 H5 頁面
• 存儲：
  • 存儲分析：查看應用存儲大小
  • 存儲優化：使用共享庫，業務定向優化，壓縮存儲等
• 流量：
  • 耗流量緣由：分析各類網絡請求
  • 流量異常捕獲：hook 全部網絡請求，根據host聚合流量，超過閾值肯定異常
  • 流量優化：PC 底層協議優化，資源增量按需下載，同時經過切面信息調用方
• 電量：
  • 耗電緣由：監控 CPU 使用率，各類 sensor、gps、weaklock、網絡鏈接等耗電操做
  • 耗電異常捕獲：遍歷線程，獲取全部線程運行時間，與主線程比較肯定異常
  • 耗電優化：高性能 dump 線程棧優化，經過線程映射調用方，評估調用邏輯進行優化

針對以上每一個優化點，支付寶都投入了大量精力進行研究和實踐，啓動速度優化的詳細內容能夠查閱文檔《支付寶客戶端架構解析：iOS 客戶端啓動性能優化初探》和《支付寶客戶端架構解析：Android 客戶端啓動速度優化之「垃圾回收」》，其餘優化點請持續關注「客戶端架構解析」系列文章。

基於這些對用戶體驗優化的內容，支付寶構建了一套完整的超級 App 線上運維體系，實時監控線上 App 發生的異常問題，針對這些問題，以最快的時間定位問題緣由並找到對應的解決方案，最後經過動態熱修復的技術及時修復線上問題，最終造成一個線上質量保障的閉環，保障應用運行的穩定性。

MAS 移動分析框架淺析

接下來，詳細介紹超級 App 運維體系中的移動監控框架具體是如何實現的。 移動分析 MAS（Mobile Analysis Service）經過對移動客戶端、H五、小程序、PC等多端埋點數據的採集與分析，實現產品核心指標監控，提供頁面、設備、留存、性能等基礎分析，並支持自定義事件分析、漏斗分析等高階分析，幫助企業更好地完成業務監控、用戶洞察與行爲分析，指導產品迭代，精細化產品運營，輔助營銷決策，加速業務商業化。主要分爲如下四個階段：

整個移動分析的完整鏈路從左往右看，就是客戶端經過調用埋點 SDK的接口進行數據埋點，埋點 SDK 對日誌進行格式化後，先寫入客戶端本地文件，知足日誌上報觸發條件後，將本地日誌上報到日誌服務器並清理本地日誌文件以減小存儲大小；日誌服務器接收到客戶端上報的日誌後同步到計算平臺，通過離線計算和實時計算後，將結果進行展現，用來監控、分析、搜索、推薦等。

結合上圖，接下來從移動分析框架的四個階段，詳細介紹數據分析的整個鏈路邏輯。

1. 數據採集

根據採集數據時機、應用場景，最終用途的不一樣，咱們把客戶端採集的數據分爲了如下幾類。其中結合 mPaaS 模塊化開發框架，報活埋點、押後臺埋點、頁面自動化埋點、性能埋點及 H5 埋點，由客戶端 SDK 自動採集，無需開發者手動調用接口實現，開發者只須要關注本身的業務邏輯，在須要監控的邏輯除埋點統計。

爲了下降頻繁上報日誌對應用性能的影響，客戶端採集到數據後，會預先保存在應用本地，經過如下三種方式同步到日誌服務器

• 自動上報：知足必定條件後自動上報
  • 程序每次冷啓動都會觸發檢查日誌上報的邏輯。
  • 程序進入後臺會當即觸發上報。
  • 寫日誌時，某種類型的日誌默認到達 40 條就觸發上報。
• 實時監控：對於比較重要的客戶端日誌，如異常、應用閃退日誌等，可實時上報，產生一條上報一條，便於後臺實時監控。
• 動態控制：在自動上報的基礎上，經過服務端下發的開關值，修改客戶端日誌寫入和日誌上報觸發的條件。如在大流量併發的狀況下，爲減小日誌服務器的壓力，控制客戶端只寫入並上報異常或閃退日誌，忽略行爲日誌的統計。

2. 數據計算

上報到日誌服務器的日誌，會同步到計算平臺進行計算，後臺主要包含如下幾個系統：

• mdap：日誌採集網關，負責收集客戶端埋點日誌，收到日誌後，直接傳輸至 JStorm 集羣進行計算。
• JStorm：實時計算引擎，根據處理規則對日誌進行實時解析並將須要的數據存儲入庫。
• SSDB： kv 數據存儲層，底層使用 leveldb，支持單表十億級記錄。
• ZooKeeper：集羣管理、組件間服務發現。

3. 數據應用

計算平臺計算出來的結果，能夠爲用戶提供用戶分析、事件分析、行爲、性能等數據分析服務。

• 基礎分析： 關注於 App 的通用分析，包括每日登陸用戶、新增用戶、使用時長、用戶留存、頁面分析、訪問路徑等基礎分析。
• 高階分析： 用於 App 專一業務的特定分析需求，提供一種靈活的多維分析能力；提供熱修復報告，幫助您瞭解 RPC、修復、回滾相關信息等。
• 性能分析： 提供閃退、卡死、卡頓的統計功能。當客戶端發生性能問題後，移動分析服務提供實時查看性能分析的統計數據。
• 日誌管理： 支持按關鍵字實時搜索查詢日誌，或經過服務端開關實時控制客戶端日誌上報邏輯。

4. 數據決策

在上一步數據應用的基礎上，能夠與大數據、營銷平臺及推送平臺結合，根據移動分析獲得的埋點數據，經過大數據平臺進行打標、圈人、用戶畫像及建模後，能夠在營銷平臺上發起一次營銷活動，指定活動的類型，活動算法，參與人羣及活動獎品，經過消息推送、數據同步，動態發佈等形式，觸達到客戶端，實現客戶端拉新促活、活動推廣及操做引導的目的。同時結合運營活動的場景需求，造成了一套完整的數字化運營體系，監控一次運營活動的參與人數、活動發放率、覈銷率等，觀察活動的有效性。

mPaaS 技術架構與助力

上面介紹的支付寶內移動端分析方案的技術積累和架構實踐，已經經過 mPaaS 移動開發平臺做爲螞蟻金服金融科技的一部分對外開放。

在 mPaaS 移動開放平臺上，咱們將移動分析框架中的本地日誌、埋點、自動化埋點、性能監控、Crash報告、診斷日誌等模塊，做爲一個個獨立的組件來進行輸出。任何一個 App 均可以經過 mPaaS 插件，添加對應的組件，在當前應用中集成這些功能，只須要這樣簡單的操做，就可讓你的應用具備和支付寶同樣強大的移動端分析監控能力。

客戶端集成了這些移動分析相關的組件後，用戶在使用 App 過程當中會產生相應的日誌，通過數據採集、數據上報、數據計算等處理後，計算的結果會同步到 mPaaS 移動分析的大盤上展現，包括應用的基礎應用概況、性能穩定數據、流量走向等等，方便開發者實時監控 App 的概況大盤和穩定性等，實時發現線上問題並修復。

目前，mPaaS 移動開發平臺已經服務了衆多企業，包括螞蟻金服內部的香港支付寶、網商銀行、口碑商家等，同時還有大量的外部螞蟻生態合做夥伴，包括1230六、上海地鐵、廣州地鐵、廣發銀行等。秉承着「給世界帶來小而美的變化」的理念，咱們經過 mPaaS 幫助 12306 這樣的國民級 App 重構了客戶端，使得你們能夠用上一個好的體驗的 App 進行出行購票，用 mPaaS 這樣成熟的底層框架搭建一個 12306 僅須要 2-3 個月的時間。 除了 12306 還有支付寶香港版，廣發銀行手機銀行和 發現精彩多個客戶端，一樣在短短几個月的時間內便完成了業務重構。

往期閱讀

《開篇 | 模塊化與解耦式開發在螞蟻金服 mPaaS 深度實踐探討》

《支付寶移動端動態化方案實踐》

《支付寶客戶端架構解析：iOS 容器化框架初探》

《支付寶客戶端架構解析：Android 容器化框架初探》

《支付寶客戶端架構解析：Android 客戶端啓動速度優化之「垃圾回收」》

《Demo Show | 螞蟻金服 mPaaS IDEA 插件實踐》

關注咱們公衆號，得到第一手 mPaaS 技術實踐乾貨

---

號外！問卷調研

填寫你對移動開發的具體需求和痛點吧，幫助咱們進一步優化 mPaaS 的能力！

即日起截止 11.30 晚 18:00，填寫提交 mPaaS 開發者調研問卷，即有機會獲取限量版螞蟻 U 型枕 1 個。 咱們將在掘金平臺完成問卷填寫的用戶中抽取 5 位，贈送螞蟻公仔限量版 U 型枕。