支付寶客戶端架構(gòu)分析：自動化日志收集及分析

正如我們在《 開篇 | 模塊化與解耦式開發(fā)在螞蟻金服 mPaaS 深度實踐探討 》已經(jīng)對支付寶的架構(gòu)演變與開發(fā)團隊規(guī)模發(fā)展做過介紹：

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

那么，在如此大體量的用戶規(guī)模和研發(fā)團隊下，支付寶又是如何確保用戶使用過程中的用戶體驗呢？我們主要從以下兩個維度衡量客戶端用戶體驗：

• 靜態(tài)： 指應用開發(fā)過程中，關(guān)注 App 本身的安裝包大小、存儲、涉及到的用戶隱私權(quán)限、安全策略等，決定用戶是否愿意安裝并使用你的應用。

• 動態(tài)： 指應用發(fā)布上線后，用戶在使用過程中，App 的啟動速度，閃退、卡死卡頓等穩(wěn)定性數(shù)據(jù)，網(wǎng)絡(luò)請求，內(nèi)存以及電量流量等用戶實際的使用感受。

啟動應用是用戶使用任何一款應用最必不可少的操作，從點擊 App 圖標到首頁展示，整個啟動過程的性能，嚴重影響著用戶的體驗。支付寶客戶端作為一個超級 App，啟動速度當然是我們關(guān)注的重要指標之一。支付寶對于應用啟動過程中的優(yōu)化，主要分為以下四個方面：

• 框架治理：

• 梳理啟動流程并重構(gòu)，遵守啟動過程中按需加載原則。

• 引用 Pipeline 機制，根據(jù)業(yè)務(wù)優(yōu)先級規(guī)定業(yè)務(wù)初始化時機。

• 制定統(tǒng)一的開發(fā)規(guī)范，盡量降低業(yè)務(wù)方流程對啟動性能的影響。

• 業(yè)務(wù)治理：

• 按需加載，延時執(zhí)行。

• 線程治理：統(tǒng)一管理已有線程，并調(diào)整線程優(yōu)先級。

• I/O 治理：關(guān)注主線程 I/O，優(yōu)化合并頻繁讀寫的 I/O 操作，盡量使用統(tǒng)一存儲。

• 技術(shù)突破：

• 防止啟動過程中的 UI 重刷操作。

• 虛擬機優(yōu)化，包括 JIT 關(guān)閉，降低 GC 次數(shù)。

• 基礎(chǔ)模塊調(diào)優(yōu)，分析主線程耗時操作并優(yōu)化。

另外，用戶使用過程中 App 的內(nèi)存、存儲、電量及流量等消耗，也是重要的衡量指標。具體的優(yōu)化點如下：

• 內(nèi)存：

• 內(nèi)存分析：memtrace hprof 線下內(nèi)存分析，遍歷對象，根據(jù)生命周期標記內(nèi)存泄露，同時根據(jù) object 創(chuàng)建引用確定業(yè)務(wù)歸屬。

• Native 內(nèi)存：圖像庫切換到 native 層，4.x bitmap 像素數(shù)據(jù)放到 ashme 共享內(nèi)存，降低 GC。

• 內(nèi)存優(yōu)化：對象池復用，減小 bitmap 對內(nèi)存占用，使用更小的圖，尤其注意三方 H5 頁面。

• 存儲：

• 存儲分析：查看應用存儲大小。

• 存儲優(yōu)化：使用共享庫，業(yè)務(wù)定向優(yōu)化，壓縮存儲等。

• 流量：

• 耗流量原因：分析各種網(wǎng)絡(luò)請求。

• 流量異常捕獲：hook 所有網(wǎng)絡(luò)請求，根據(jù)host聚合流量，超過閾值確定異常。

• 流量優(yōu)化：PC 底層協(xié)議優(yōu)化，資源增量按需下載，同時通過切面信息調(diào)用方。

• 電量：

• 耗電原因：監(jiān)控 CPU 使用率，各種 sensor、gps、weaklock、網(wǎng)絡(luò)連接等耗電操作。

• 耗電異常捕獲：遍歷線程，獲取所有線程運行時間，與主線程比較確定異常。

• 耗電優(yōu)化：高性能 dump 線程棧優(yōu)化，通過線程映射調(diào)用方，評估調(diào)用邏輯進行優(yōu)化。

針對以上每個優(yōu)化點，支付寶都投入了大量精力進行研究和實踐，有關(guān)啟動性能優(yōu)化的詳細內(nèi)容可以查閱文檔《支付寶客戶端架構(gòu)解析：iOS  客戶端啟動性能優(yōu)化初探》和《支付寶客戶端架構(gòu)解析：Android  客戶端啟動速度優(yōu)化之「垃圾回收」》，其他優(yōu)化點請持續(xù)關(guān)注“客戶端架構(gòu)解析”系列文章。

基于這些對用戶體驗優(yōu)化的內(nèi)容，支付寶構(gòu)建了一套完整的超級  App 線上運維體系，實時監(jiān)控線上 App  發(fā)生的異常問題，針對這些問題，以最快的時間定位問題原因并找到對應的解決方案，最后通過動態(tài)熱修復的技術(shù)及時修復線上問題，最終形成一個線上質(zhì)量保障的閉環(huán)，保障應用運行的穩(wěn)定性。

接下來，詳細介紹超級 App 運維體系中的移動監(jiān)控框架具體是如何實現(xiàn)的。

移動分析  MAS（Mobile Analysis  Service）通過對移動客戶端、H5、小程序、PC等多端埋點數(shù)據(jù)的采集與分析，實現(xiàn)產(chǎn)品核心指標監(jiān)控，提供頁面、設(shè)備、留存、性能等基礎(chǔ)分析，并支持自定義事件分析、漏斗分析等高階分析，幫助企業(yè)更好地完成業(yè)務(wù)監(jiān)控、用戶洞察與行為分析，指導產(chǎn)品迭代，精細化產(chǎn)品運營，輔助營銷決策，加速業(yè)務(wù)商業(yè)化。主要分為以下四個階段：

整個移動分析的完整鏈路從左往右看，就是客戶端通過調(diào)用埋點  SDK 的接口進行數(shù)據(jù)埋點，埋點 SDK  對日志進行格式化后，先寫入客戶端本地文件，滿足日志上報觸發(fā)條件后，將本地日志上報到日志服務(wù)器并清理本地日志文件以減少存儲大??；日志服務(wù)器接收到客戶端上報的日志后同步到計算平臺，經(jīng)過離線計算和實時計算后，將結(jié)果進行展示，用來監(jiān)控、分析、搜索、推薦等。

接下來我們將從移動分析框架的四個階段，詳細介紹數(shù)據(jù)分析的整個鏈路邏輯。

數(shù)據(jù)采集

根據(jù)采集數(shù)據(jù)時機、應用場景，最終用途的不同，我們把客戶端采集的數(shù)據(jù)分為了以下幾類。其中結(jié)合  mPaaS 模塊化開發(fā)框架，報活埋點、押后臺埋點、頁面自動化埋點、性能埋點及 H5 埋點，由客戶端 SDK  自動采集，無需開發(fā)者手動調(diào)用接口實現(xiàn)，開發(fā)者只需要關(guān)注自己的業(yè)務(wù)邏輯，在需要監(jiān)控的邏輯除埋點統(tǒng)計。

為了降低頻繁上報日志對應用性能的影響，客戶端采集到數(shù)據(jù)后，會預先保存在應用本地，通過以下三種方式同步到日志服務(wù)器：

• 自動上報： 滿足一定條件后客戶端埋點 SDK 自動上報，包括

• 程序每次冷啟動都會觸發(fā)檢查日志上報的邏輯。

• 程序進入后臺會立即觸發(fā)上報。

• 寫日志時，某種類型的日志默認到達 40 條就觸發(fā)上報。

• 實時監(jiān)控： 對于比較重要的客戶端日志，如異常、應用閃退日志等，可實時上報，產(chǎn)生一條上報一條，便于后臺實時監(jiān)控。

• 動態(tài)控制： 在自動上報的基礎(chǔ)上，通過服務(wù)端下發(fā)的開關(guān)值，修改客戶端日志寫入和日志上報觸發(fā)的條件。如在大流量并發(fā)的情況下，為減少日志服務(wù)器的壓力，控制客戶端只寫入并上報異?；蜷W退日志，忽略行為日志的統(tǒng)計。

數(shù)據(jù)計算

上報到日志服務(wù)器的日志，會同步到計算平臺進行計算，后臺主要包含以下幾個系統(tǒng)：

• mdap： 日志采集網(wǎng)關(guān)，負責收集客戶端埋點日志，收到日志后，直接傳輸至 JStorm 集群進行計算。

• JStorm： 實時計算引擎，根據(jù)處理規(guī)則對日志進行實時解析并將需要的數(shù)據(jù)存儲入庫。

• SSDB： kv 數(shù)據(jù)存儲層，底層使用 leveldb，支持單表十億級記錄。

• ZooKeeper： 集群管理、組件間服務(wù)發(fā)現(xiàn)。

數(shù)據(jù)應用

計算平臺計算出來的結(jié)果，可以為用戶提供用戶分析、事件分析、行為、性能等數(shù)據(jù)分析服務(wù)。

• 基礎(chǔ)分析： 關(guān)注于 App 的通用分析，包括每日登錄用戶、新增用戶、使用時長、用戶留存、頁面分析、訪問路徑等基礎(chǔ)分析。

• 高階分析： 用于 App 專注業(yè)務(wù)的特定分析需求，提供一種靈活的多維分析能力；提供熱修復報告，幫助您了解 RPC、修復、回滾相關(guān)信息等。

• 性能分析： 提供閃退、卡死、卡頓的統(tǒng)計功能。當客戶端發(fā)生性能問題后，移動分析服務(wù)提供實時查看性能分析的統(tǒng)計數(shù)據(jù)。

• 日志管理： 支持按關(guān)鍵字實時搜索查詢?nèi)罩?，或通過服務(wù)端開關(guān)實時控制客戶端日志上報邏輯。

數(shù)據(jù)決策

在上一步數(shù)據(jù)應用的基礎(chǔ)上，可以與大數(shù)據(jù)、營銷平臺及推送平臺結(jié)合，根據(jù)移動分析得到的埋點數(shù)據(jù)，通過大數(shù)據(jù)平臺進行打標、圈人、用戶畫像及建模后，可以在營銷平臺上發(fā)起一次營銷活動，指定活動的類型，活動算法，參與人群及活動獎品，通過消息推送、數(shù)據(jù)同步，動態(tài)發(fā)布等形式，觸達到客戶端，實現(xiàn)客戶端拉新促活、活動推廣及操作引導的目的。同時結(jié)合運營活動的場景需求，形成了一套完整的數(shù)字化運營體系，監(jiān)控一次運營活動的參與人數(shù)、活動發(fā)放率、核銷率等，觀察活動的有效性。

上面介紹的支付寶內(nèi)移動端分析方案的技術(shù)積累和架構(gòu)實踐，已經(jīng)通過  mPaaS 移動開發(fā)平臺作為螞蟻金服金融科技的一部分對外開放。mPaaS(Mobile Platform As A  Service)，源于支付寶 App  的移動開發(fā)平臺，為移動開發(fā)、測試、運營及運維提供云到端的一站式解決方案，能有效降低技術(shù)門檻、減少研發(fā)成本、提升開發(fā)效率，協(xié)助企業(yè)快速搭建穩(wěn)定高質(zhì)量的移動  App。

在  mPaaS  移動開放平臺上，我們將移動分析框架中的本地日志、埋點、自動化埋點、性能監(jiān)控、Crash報告、診斷日志等模塊，作為一個個獨立的組件來進行輸出。任何一個  App 都可以通過 mPaaS  插件，添加對應的組件，在當前應用中集成這些功能，只需要這樣簡單的操作，就可以讓你的應用具有和支付寶一樣強大的移動端分析監(jiān)控能力。

客戶端集成了這些移動分析相關(guān)的組件后，用戶在使用APP過程中會產(chǎn)生相應的日志，經(jīng)過數(shù)據(jù)采集、數(shù)據(jù)上報、數(shù)據(jù)計算等處理后，計算的結(jié)果會同步到  mPaaS 移動分析的大盤上展示，包括應用的基礎(chǔ)應用概況、性能穩(wěn)定數(shù)據(jù)、流量走向等等，方便開發(fā)者實時監(jiān)控 APP  的概況大盤和穩(wěn)定性等，實時發(fā)現(xiàn)線上問題并修復。

目前，mPaaS   移動開發(fā)平臺已經(jīng)服務(wù)了眾多企業(yè)，包括螞蟻金服內(nèi)部的香港支付寶、網(wǎng)商銀行、口碑商家等，同時還有大量的外部螞蟻生態(tài)合作伙伴，包括12306、上海地鐵、廣州地鐵、廣發(fā)銀行等。秉承著「給世界帶來小而美的變化」的理念，我們通過  mPaaS 幫助 12306 這樣的國民級 App 重構(gòu)了客戶端，使得大家可以用上一個好的體驗的 App 進行出行購票，用 mPaaS  這樣成熟的底層框架搭建一個 12306 僅需要 2-3 個月的時間。

除了 12306 還有 支付寶香港版 ， 廣發(fā)銀行手機銀行 和 發(fā)現(xiàn)精彩 多個客戶端，同樣在短短幾個月的時間內(nèi)便完成了業(yè)務(wù)重構(gòu)。