?????♀??編者按：本文作者是螞蟻集團客戶端工程師禹晨，介紹了支付寶是如何監(jiān)測、治理耗時類體驗問題的，歡迎查閱～

??一、前言

客戶端的體驗是一個大的概念，包括橫跨業(yè)務(wù)和產(chǎn)品功能的體驗，以及端的基礎(chǔ)性能體驗。要給用戶提供一個體驗好的應(yīng)用 App，做好這兩點是缺一不可的。我們把端上的基礎(chǔ)性能體驗分兩類，耗時類體驗和資源類體驗。

耗時類的體驗場景有，冷啟動、首登、首跳、首頁渲染、掃碼、喚端、小程序等；

資源類的性能體驗維度有，功耗、ANR、卡頓、內(nèi)存、存儲、網(wǎng)絡(luò)、包大小等。之后的文章會大家分批介紹這兩類性能體驗的監(jiān)測和治理方案。本文就先從耗時類性能體驗開始，給大家介紹一下支付寶是如何監(jiān)測、治理耗時類體驗問題的，以及在這塊的沉淀和積累。

在支付寶做性能體驗優(yōu)化之前，80% 的用戶是通過冷啟動打開支付寶。來自用戶和行業(yè)的壓力也越來越大，尤其在排隊支付場景，在超市、公交地鐵，用戶希望快速打開支付寶完成支付。

應(yīng)用的啟動定義

冷啟動：應(yīng)用進程已經(jīng)被系統(tǒng)殺掉，再啟動應(yīng)用的時候，系統(tǒng)會重新創(chuàng)建一個新的進程分配給應(yīng)用，系統(tǒng)應(yīng)用層初始化以及應(yīng)用內(nèi)部的初始化工作，最終把頁面繪制到屏幕上。

熱啟動：應(yīng)用完成啟動后，用戶 back 或 home 鍵，使應(yīng)用停留在后臺，應(yīng)用進程保留、存活，這時用戶再點擊應(yīng)用圖標(biāo)，喚起應(yīng)用，首頁頁面回到 resume 狀態(tài)，直接展示在屏幕上，這種啟動方式叫熱啟動，要比冷啟動方式要快很多。

應(yīng)用的啟動速度，對應(yīng)用體驗來說，是最重要的體驗指標(biāo)。因為只有打開了應(yīng)用，才能操作應(yīng)用里面的功能。冷啟動場景的性能優(yōu)化也是重中之重，優(yōu)化力度和投入最大，經(jīng)過問題攻堅和性能優(yōu)化，支付寶即便在冷啟動場景，也能達到秒開。接下來，就以冷啟動這個場景的性能優(yōu)化，來給大家講講，支付寶是如何做場景的度量、診斷，以及端整體的性能體驗保障的。

??二、場景性能度量

2.1 場景度量手段

首先簡單介紹幾個常用的場景體驗度量方案。

視頻分幀

視頻分幀是比較常用的場景度量手段，通過錄制視頻的方式，把視頻保存，然后通過視頻分幀技術(shù)，將視頻分割成若干幀，然后計算起始幀到頁面完全展示的幀，之間的耗時，作為整個場景的耗時。

優(yōu)點：比較貼合用戶體感，行業(yè)對比常用手段?

缺點：資源占用多，計算較繁瑣，精度較差，80-200 ms 左右?

相關(guān)技術(shù)：openCV, ffmpeg, 推薦自動化實現(xiàn)。

ActivityTaskManager

在 Andriod kitKat 發(fā)布之后，任何一個 activity 啟動的時候，ActivityTaskMananger 都會帶一個頁面顯示的耗時時間, 示例：

ActivityTaskManager:Displayed com.android.samples.mytest/.MainActivity: ?+1s100ms?

這個持續(xù)時間 (本例中為 1,100 ms ) 表示了從啟動應(yīng)用到系統(tǒng)認為其 "已啟動" 所花費的時間，其中包括繪制第一幀 (所以是 "已顯示" 的狀態(tài))，只適合統(tǒng)計 Activity 的耗時， 冷啟動的場景不適合用這個方法。

埋點方案

埋點應(yīng)該是最常用的場景耗時度量方案，線上監(jiān)測、線下檢測通用。業(yè)務(wù)鏈路以及代碼模塊耗時，都可以通過埋點監(jiān)測。支付寶端內(nèi)還有全鏈路埋點，來度量每個節(jié)點的耗時。但是有一點需要注意，埋的點一定要貼合用戶場景，尤其有頁面渲染的場景，比如 feed 流，埋的點位要保證頁面恰好渲染完成。

優(yōu)點：線上、線下統(tǒng)一，線下可以評估下線上性能水位，精度高；

缺點：需要有技術(shù)手段，讓埋點的點位和頁面渲染完成時機同步。支付寶采用的是埋點的技術(shù)方案，支付寶是如何獲取到頁面恰好渲染完成的時機呢？支付寶主要做了以下兩點（雙端）：

1、通過監(jiān)測 android.view.ViewTreeObserver.OnGlobalLayoutListener ，當(dāng) view 的有效 requestLayout 的時候，會導(dǎo)致觸發(fā) onGlobalLayout 回調(diào)方法；

2、首頁貼圖技術(shù)方案，在提升冷啟動性能和線下度量精度提升方面，起到了很重要的作用。關(guān)于貼圖技術(shù)，后面章節(jié)里面會詳細介紹，簡單來說就是，支付寶在非首次冷啟動的場景，優(yōu)先把一個完整的首頁展示給用戶，并且用戶還可以點擊頁面，再等一個合適的時機重新渲染首頁。

點擊支付寶 logo 開始，到歡迎頁，直接展示首頁（首頁貼圖技術(shù)）

2.2 場景度量精度提升

在場景度量精度方面是個很大的挑戰(zhàn)，如果沒有高精度度量，就很難發(fā)現(xiàn) 10 ms 左右的性能問題，以及研發(fā)側(cè)嘗試優(yōu)化的點，也無法度量。關(guān)于如何提升度量精度，我們也是做了很多次實驗和探索，包括冷啟動時機、樣本數(shù)據(jù)采集和計算、設(shè)備溫度控制、CPU 鎖頻等方面等，做了大量的實驗和探索，才形成了自己獨特的場景度量采集方案。支付寶冷啟動場景度量的精度，可以達到 10 ms 左右精度。接下來給大家介紹一下，關(guān)鍵技術(shù)方案。

支付寶首頁貼圖技術(shù)

首頁貼圖的原理，就是應(yīng)用冷啟動后，給用戶展示上一次首展示的內(nèi)容，其實就是圖片，這些圖片記錄著各個區(qū)域的點擊事件。用戶可以直接點擊頁面任何區(qū)域。這樣就減少了頁面刷新等待的時間。極大提升了冷啟動速度。

貼圖技術(shù)的原理就是把首頁拆成幾個部分，比如四大金剛、九宮格、消息提醒、腰封廣告、首頁推薦 feed 流。在用戶使用完支付寶后，壓后臺的時機，把對應(yīng)區(qū)域的圖片截圖，并保存。下一次冷啟動的時候會判斷是否截圖成功，如果成功就直接貼圖。

支付寶首頁貼圖

溫控

做過性能專項的同學(xué)，肯定會有這樣的體會，做幾次冷啟動之后，或者重復(fù)操作某一個場景的時候，手機是會發(fā)熱的。手機發(fā)熱會影響手機 CPU 的處理頻率，如果溫度過高，CPU 會降頻，以至于影響計算效率。所以我們需要保持手機保持恒溫。還要一點就是，不要用太老舊的手機，尤其電池不抗用的手機，如果手機是在充下電狀態(tài)下，有的手機 CPU 也會降頻，優(yōu)先保障快速充電，同時電池也會發(fā)熱。在溫控方面，我們也做了很多嘗試，一開始用冰袋，后臺用小風(fēng)扇 + 空調(diào)，現(xiàn)在我們用專業(yè)游戲玩家用的降溫設(shè)備，這種手機背夾，溫控效果還是不錯的。

手機溫控示例圖

CPU 鎖定主頻

還有一種控制手機溫度的方式，就是 CPU 鎖頻，但是需要手機 root, 我這里就不展開說了，感興趣的同學(xué)可以了解一下 。https://developer.android.google.cn/jetpack/androidx/releases/benchmark

分階段采集數(shù)據(jù)

支付寶冷啟動場景，被拆分成了 2 個大階段和 90+ 個小階段。有同學(xué)會問題為啥要拆成若干個小階段呢？場景階段才分是按照代碼功能模塊拆分的，為了更好的定位是哪個代碼快導(dǎo)致的性能劣化，我們采用拆分階段的手段。

支付寶冷啟動場景階段拆分 冷啟動場景，被拆分成 pre_launch 和 time_startup 兩個大階段，在版本場景階段對比的過程中，優(yōu)先比較兩個大場景是否變差，如果某個大場景變差，再去找其中的子階段是否變差，定位出劣化代碼快。

場景階段對比

性能數(shù)據(jù)采集方案

現(xiàn)在面臨一個問題就是，如何不影響線上，還要把場景性能階段數(shù)據(jù)取出來？冷啟動場景是應(yīng)用最早的啟動時機，常規(guī)的手段，無法在啟動的時機做初始化。又考慮到以后其他場景的兼容，于是有了線下重打包的技術(shù)方案，可以靈活的把抽象和實現(xiàn)分離，線上調(diào)用的是空方法，只有在線下打入實現(xiàn)的代碼，才會把具體方法的實現(xiàn)打入支付寶。當(dāng)然這里也要借助 Spider SDK，這里先簡單提一下，后續(xù)將詳細介紹。接下來介紹一下我們的黑科技，重打包技術(shù)。

首先我們準(zhǔn)備一個獨立的apk, 給他起個名字叫 patch apk,這個 apk 就像 patch 一樣會打包支付寶主體APK中。主要實現(xiàn)的功能有：

1、HookApplication，做初始化工作，這里包括 Spider SDK 初始化、DexAop 初始化、性能診斷邏輯初始化、配置初始化；

2、性能數(shù)據(jù)采集邏輯實現(xiàn)，以及線下數(shù)據(jù)采集邏輯；

3、性能診斷邏輯和數(shù)據(jù)采集邏輯，這里性能的診斷數(shù)據(jù)包括，線程、service、開關(guān)配置、動態(tài) bundle 加載

Patch APK 內(nèi)部實現(xiàn)原理圖?

那么我們來看下 Patch ?APK 是如何打進支付寶主體 APK 的，首先把兩個 APK 解壓，然后把對應(yīng)的資源文件進行 merge 1、Merge Manifest 替換原來 Application，使用代理 Application ；2、Merge so 和 Dex, 讀取 DexAOP 配置并進行 Dex AOP，采集診斷數(shù)據(jù)；3、最后一步就是重新打包、簽名 APK，生成待測 APK。

Repack APK 流程圖?

重打包機制給線下獲取性能數(shù)據(jù)， 包括耗時、診斷數(shù)據(jù)，提供了很大的方便。線上、線下分離，互不干擾。通過在打包過程中可以進行 DexAOP，可以任意獲取場景需要的度量及診斷數(shù)據(jù)。

工程效能提升

工程效能提升這方面，這里主要做了兩件事情，CI 流程改進和代碼變更查看功能完善。

第一、構(gòu)建流程改善，每次業(yè)務(wù)集成，基于當(dāng)前基線 + 業(yè)務(wù)集成代碼， 構(gòu)建安裝包，后面的安裝包基線依次遞增，保證基線是按順序遞增的，才能做到逐集成性能檢測，也就是集成 CI 能力；

第二、展示每次集成詳情信息，包括每位研發(fā)的 commit 代碼和代碼 diff 信息，這樣才能更好定位問題。

問題：

開發(fā)代碼集成，會把其他開發(fā)者代碼帶入集成，但是看不到其他開發(fā)者的代碼變更信息。

解決方案：

在每次集成申請列表，添加代碼變更信息入口，打開之后，展示當(dāng)前 commit 基線和主集成基線之間所有的代碼 diff 信息，便于定位問題。這個功能不僅僅用戶排查性能問題，研發(fā)同學(xué)也可以用于排查功能、穩(wěn)定性等問題，一勞永逸。

??三、場景性能診斷

前面介紹了場景的度量能力，如果場景耗時劣化，我們就需要去定位哪里問題原因。場景的階段拆分，目的就是縮小問題范圍。但是只縮小問題范圍還不夠，性能體驗問題，比功能的 bug 難解很多，比如冷啟動慢了 20ms，業(yè)務(wù)方也很頭痛，也不知道為啥就慢了 20ms, 問題分析速度又慢，所以我們也在想是否有能夠輔助定位性能問題的手段。

3.1 常規(guī)維度性能診斷

支付寶場景常規(guī)性能診斷

常規(guī)的性能診斷維度，包括線程，IO, 動態(tài) Bundle 加載，Service，開關(guān)讀取。具體的時間是通過 AOP 的方式，去切對應(yīng)的接口，來獲取相應(yīng)的診斷數(shù)據(jù)。這部分實現(xiàn)也是在 Patch APK 中。

1、對于線程，Hook Runnable run 方法， AsyncTask ，new Thread 實例創(chuàng)建，獲取線程的耗時、名稱、次數(shù)；

2、開關(guān)的讀取，Hook ConfigService，拿到對應(yīng)的 SP, 讀取開關(guān)值即可，mock 也是同樣的原理，拿到對應(yīng)的sp ，通過開關(guān)的 key 寫進 value 即可；

3、動態(tài) bundle 主線程加載，Hook BundleClassLoader 即可，判斷一下是否在主線程 ，獲取 bundle 名稱和堆棧；

4、Service 是支付寶錢包的服務(wù)，Hook CreateExtermalService ，獲取 service 初始化時間及調(diào)用鏈；

5、IO 主要是 Hook read/write 接口，是否有讀寫 buffer 過小，讀寫泄漏等 IO 問題。

Patch APK 及內(nèi)部實現(xiàn)原理圖

3.2 AOP 技術(shù)簡介

AOP 是 Aspect Oriented Programming 的縮寫，譯為面向切向編程。我們在支付寶內(nèi)使用的 DexAOP, 原理簡單來說就是，在打包構(gòu)建過程中，讀取需要 Hook 的類和方法，并生成對應(yīng)的代理函數(shù)，把目標(biāo)函數(shù)，只想帶來函數(shù)，我們在代理函數(shù)中實現(xiàn) Hook。

其他 Hook 工具，有 APT, AspectJ, ASM, Javasis, DexMaker, ASMDEX, ?有想了解的可以看一下，都有對應(yīng)的優(yōu)缺點，這里就不詳細介紹了，這幾個工具在APK構(gòu)建的不同時機中，Hook 的時機是不一樣的。下面是安卓 APK 的構(gòu)建流程和不同工具 Hook 的時機。

Android APK 構(gòu)建流程

常用 AOP 工具及?Hook?時機

DexAOP

不同 AOP 的工具，在不同構(gòu)建時期的注入實現(xiàn)，DexAOP 是在 class 轉(zhuǎn)換成 dex 后，對 dex 直接操作，添加代理函數(shù)。支持函數(shù) invoke, 函數(shù)體切面和實例創(chuàng)建切面。切面類型包括方法 invoke 切面, 方法 body 切面, 對象 new instance 切面。

3.3?代碼變更性能診斷

在研發(fā)過程中，一切問題都是代碼變更導(dǎo)致的，代碼變更信息是最重要的定位問題有效途徑?；貋眢w驗耗時劣化的問題上，如何場景耗時劣化，或者某個子階段劣化，無非是新增代碼對原有函數(shù)的改動導(dǎo)致的耗時增加；再者就是新增函數(shù)方法，導(dǎo)致場景耗時劣化。從精細化問題分析角度來看，我們可以把整個場景細化成若干個階段，那么我們能否做到函數(shù)級別耗時分析呢？這是一個技術(shù)挑戰(zhàn)點，在這個問題上也嘗試過幾種方案，最后很幸運，做成功了，接下來介紹一下代碼變更診斷的技術(shù)方案。

期間我也嘗試很多技術(shù)手段，AOP 手段全量對代碼函數(shù)做插裝，JVMTI 運行時拿到所有函數(shù)執(zhí)行前后的回調(diào)。

首先 DexAOP 的手段是不適合對全量函數(shù)做切面的，生成代碼函數(shù)會超過限制。JVMTI 是一個安卓把虛擬機提供給對外的調(diào)試接口，全稱是 Java VM Tool Interface，底層是 C++ 實現(xiàn)，對外接口也是。最終經(jīng)過幾番折騰，完成了 demo,經(jīng)過實際的嘗試還是失敗了，支付寶運行時函數(shù)太多了，啟動的時候就直接卡黑屏了。后來又想了想，不如把問題簡化，并不需要全量的函數(shù)數(shù)據(jù)，只要把變更相關(guān)的代碼的耗時以及對其他函數(shù)影響的耗時計算出來，即可定位此代碼變更哪個函數(shù)導(dǎo)致了場景劣化。

第一步，能夠通過版本基線對比，獲取兩個版本間的變更代碼，變更代碼信息包括，Bundle 信息、類、方法名稱，參數(shù)和和返回值類型，是新增、更改、還是刪除類型。

第二步，針對變更代碼，做插裝，前面的章節(jié)里面已經(jīng)提到過各種AOP的技術(shù)手段，這里采用的是ASM插裝技術(shù)，整體采用 Gradle Plugin + Transform + ASM 的技術(shù)方案。

1、再來回顧一下 APK 的構(gòu)建流程，ASM 的插裝時機是在 class files 期間。

Android APK 構(gòu)建流程圖

2、Android App 都是采用 gradle 構(gòu)建，所以需要了解一下，Gradle 構(gòu)建的生命周期和 Gradle 構(gòu)建插件。Gradle 在的構(gòu)建時機，對我提供了對應(yīng)的回調(diào)時機?？梢栽跇?gòu)建的初始化、配置和執(zhí)行的時機，初始化和配置 Gradle Plugin。

Gradle 構(gòu)建生命周期 接下來了解一下 Gradle 提供的 Transform 機制。

Transform 機制流程?

每個 Transform 其實都是一個gradle task，Android 編譯器中的 TaskManager 將每個 Transform 串連起來，第一個 Transform 接收來自 javac 編譯的結(jié)果，以及已經(jīng)拉取到在本地的第三方依賴（jar. aar），還有 resource 資源。這些編譯的中間產(chǎn)物，在 Transform 組成的鏈條上流動，每個 Transform 節(jié)點可以對 class 進行處理再傳遞給下一個 Transform。我們常見的混淆，Desugar 等邏輯，它們的實現(xiàn)如今都是封裝在一個個 Transform 中，而自定義的 Transform，會插入到這個 Transform 鏈條的最前面。

自定義 Transform 原理圖，字節(jié)碼的插裝過程就是通過 Transform 的機制，找到對應(yīng)的類、函數(shù)，以便進行代碼插裝。

Transform 機制原理

支付寶變更代碼插裝原理

1、Gradle 配置部分?

可以通過配置，是否開啟插件，主要配置對哪些代碼進行插裝，插件版本，構(gòu)建插裝輸出目錄，需要依賴的jar包。

2、Spider 部分?

提供函數(shù)運行前后的回調(diào)函數(shù)，在需要插裝的代碼執(zhí)行前后，插入回調(diào)靜態(tài)方法，既可以獲取代碼函數(shù)的執(zhí)行時機，記錄時間戳，計算函數(shù)耗時。

3、AlipayGradlePerformancePlugin?

核心部分，就是自定義性能插件部分，通過前面講到的 Transform 機制，在構(gòu)建過程中，找到對應(yīng)的目標(biāo)函數(shù)，通過 ASM 字節(jié)碼操作手段，在目標(biāo)函數(shù)執(zhí)行前后，插入靜態(tài)回調(diào)函數(shù)。

Gradle plugin + ASM 插裝構(gòu)建原理圖

4、ASM 字節(jié)碼操作?

在 gradle 構(gòu)建 Transform 的時機，通過實現(xiàn) ClassVisitor，重寫 visitMethod 方法，把 ASM 切面適配器加入方法訪問流中。通過實現(xiàn) ASM AdviceAdpter ，可以通過回調(diào)函數(shù)，訪問到方法進入和方法退出的時機，就在這個時機，插入需要回到的代碼，通過 MethodVisitor 這個實例，操作字節(jié)碼。

APM 性能平臺代碼變更診斷工程

下面是整個平臺之間的交互、請求流程，共涉及到 3 個系統(tǒng)，和一個構(gòu)建插件相互配合來完成。當(dāng)性能平臺發(fā)現(xiàn)集成導(dǎo)致的劣化問題，先觸發(fā)常規(guī)性能診斷任務(wù)，判讀是否是有線程、開關(guān)、service 等導(dǎo)致的性問題，然后觸發(fā)代碼變更檢測任務(wù)。首先請求代碼diff系統(tǒng)，計算出來變更代碼。把變更的代碼存儲起來，請求伙伴構(gòu)建系統(tǒng)，通過構(gòu)建插件的配合，針對變更代碼進行插裝，最后輸出兩個 APK，一個是基線版本已插裝 APK，二是目標(biāo)版本已插裝 APK，把兩個 APK 返回被 APM 性能平臺，通過場景覆蓋，即可知道變更代碼的改動是否影響到的場景耗時性能。

代碼變更診斷解決方案

案例

Step 1: 10.1.92.4310 版本集成導(dǎo)致冷啟動 startup 階段變慢 60 ms?

Step 2：常規(guī)性能診斷報告分析出來，多跑了一個 486.4 ms 的線程

Step 3：代碼變更診斷任務(wù)報告，可定位到問題代碼 （4310 集成變更文件 14 個，代碼變更 538 行）

??四、Spider SDK

4.1 原理詳解

Spider SDK 實現(xiàn)原理

為了把冷啟動的能力，擴展到其他場景，我們把場景拆分能力和數(shù)據(jù) dump 能力，抽象成 SDK，也就是現(xiàn)在的 Spider SDK。其他業(yè)務(wù)場景只要接入 SDK 即可擁有冷啟動度量和診斷能力，比如掃碼、首頁等業(yè)務(wù)。下面是 Spider 場景拆分示例圖：

Spider SDK 場景拆分示例?

一個場景，比如冷啟動、掃碼、首頁渲染，可以拆分成若干個大階段，比如圖中有 3 個大階段，BizName 1,BizName 2, BizName3, ?每個大階段，還可以拆分成若干個子階段，具體需要根據(jù)業(yè)務(wù)邏輯模塊進行拆分。每個業(yè)務(wù)或階段分為開始( start )和結(jié)束( end )，開始和結(jié)束要一一對應(yīng)，即：有開始就要有結(jié)束，如果不對應(yīng)，則最終生成的數(shù)據(jù)里不包含該階段的數(shù)據(jù)統(tǒng)計，注意：子階段在業(yè)務(wù)start之后，end之前，如果超出范圍，則不統(tǒng)計。在業(yè)務(wù) end 之后使用方需要調(diào)用 justDumpSpiderweb()，進行接口回調(diào)，線下可以通過這個時機落性能數(shù)據(jù)。Properties 作為可擴展字段，根據(jù)業(yè)務(wù)需求，可以定制化傳遞數(shù)據(jù)告知線下數(shù)據(jù)統(tǒng)計。

Spider SDK 實現(xiàn)

Spider ?SDK 特點

1、具備場景拆分度量能力，還可以采集性能診斷數(shù)據(jù)；

2、具備場景還原功能，通過打點的時間，可以把整個場景代碼模塊的執(zhí)行順序進行現(xiàn)場還原；

3、支撐線上場景耗時度量 + 線程診斷能力，輔助線上問題定位；

4、數(shù)據(jù)采集模塊實現(xiàn)線上、線下分離，不影響線上用戶。

??五、APM 性能平臺

有了端上的度量、診斷能力，以及 SDK 的能力，當(dāng)然還缺不了平臺能力的支撐。貫穿整個個研發(fā)、灰度、發(fā)布流程。下面是 APM 性能平臺整體架構(gòu)圖，主要包括和研發(fā)流程打通的持續(xù)集成能力，和伙伴代碼 diff 系統(tǒng)、構(gòu)建系統(tǒng)、真機平臺的任務(wù)調(diào)度系統(tǒng)之間請求和交互。

APM 性能平臺架構(gòu)圖?

通過持續(xù)集成能力，做到逐集成性能維度度量、診斷，同時提供手工觸發(fā)任務(wù)，開發(fā)者可嘗試優(yōu)化性能，以及研發(fā)項目中驗證代碼改動是否對性能有影響。

每個版本大量的持續(xù)集成任務(wù)，和人工驗證任務(wù)，離不開平臺的任務(wù)調(diào)度能力和任務(wù)隊列管理，采用了任務(wù)狀態(tài)+ 設(shè)備鎖的機制，保障了任務(wù)有序執(zhí)行。真機實驗采用場景設(shè)備分組的方式，讓特定的場景在特定的設(shè)備組上跑任務(wù)，巧妙的分散了任務(wù)集中的問題。

有了 Spider SDK 客戶端上的擴展能力，平臺的可擴展性支撐也是不可或缺的，平臺的配置中心，已經(jīng)自動化驅(qū)動腳本的可擴展性支撐，為新場景接入提供了便利。新場景接入只需要在平臺上配置即可， 通過配置場景、對應(yīng)的設(shè)備組以及驅(qū)動腳本，即可完成新場景接入，而平臺無需改動任務(wù)代碼，新場景接入只需要 2 小時即可。

??六、總結(jié)

支付寶 APM 性能平臺，支撐了多次性能體驗優(yōu)化戰(zhàn)役，比如支付場景及鏈路性能體驗優(yōu)化，喚端拉新性能優(yōu)化，端內(nèi)首跳、線程治理，功耗治理，及低端機優(yōu)化。保障了各個端內(nèi)場景性能體驗優(yōu)化的順利完成，保持住優(yōu)化成果，優(yōu)化成果 0 倒退。提供的 SDK 及性能診斷能力賦能了研發(fā)同學(xué)。

支付寶端內(nèi) APM，從重點場景逐步覆蓋到端整體性能監(jiān)測，內(nèi)存、卡頓、線程等維度的性能檢測、度量、診斷，也將納入 APM。

支付寶 APM 平臺也在不斷升級，擁有了獨立的系統(tǒng)和域名，采用了 zsearch + OB 存儲，在數(shù)據(jù)存儲量和效率方面都比之前有了很大的提升。UI 設(shè)計及報告展示變得更加友好?？蛻舻谝唬瑸榱私o用戶更好的用戶體驗，我們還會不斷去努力，在低端機優(yōu)化和發(fā)現(xiàn)細微性能問題方面繼續(xù)探索、深挖。

??七、相關(guān)技術(shù)資料

https://developer.android.com/studio/build?hl=zh-cn?

https://asm.ow2.io/?

https://developer.android.com/reference/tools/gradle-api/7.0/com/android/build/api/transform/Transform?

https://docs.gradle.org/current/userguide/artifact_transforms.html

https://docs.gradle.org/current/javadoc/index.html?

https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#whatIs?

https://developer.android.google.cn/jetpack/androidx/releases/benchmark?

https://developer.android.com/reference/android/view/ViewTreeObserver.OnGlobalLayoutListener?

https://developer.android.google.cn/reference/android/app/Activity#reportFullyDrawn()?

https://ffmpeg.org/?

https://opencv.org/