JankMan-極致的卡頓分析系統(tǒng)
1.卡頓分析系統(tǒng)介紹
此系統(tǒng)擁有了端上采集兩個維度數(shù)據(jù)的能力
- 方法運行數(shù)據(jù)：系統(tǒng)在編譯期間基于ASM9+AGP7+自定義方法ID映射+自定義字節(jié)碼指令集實現(xiàn)了方法運行數(shù)據(jù)的采集。
- 幀性能數(shù)據(jù)：系統(tǒng)在運行期間基于FrameMatrix+自定義數(shù)據(jù)結(jié)構(gòu)體實現(xiàn)了端上幀數(shù)據(jù)的采集。
當(dāng)APP發(fā)生運行卡頓時，系統(tǒng)可自動分析堆棧，并且關(guān)聯(lián)卡頓幀的方法調(diào)用鏈，并作出記錄最終導(dǎo)出至文件。整體基于協(xié)程制作，性能損耗僅需1%。
基于Compose KMP獨創(chuàng)了多端可用的線下還原器，將采集到的數(shù)據(jù)做格式效驗，并作出二次還原解析，進行了perfetto的二次開發(fā)，實現(xiàn)了可視化展示整體信息的能力。
2.思路介紹
2.1方法運行數(shù)據(jù)采集
2.1.1方法ID映射
由于系統(tǒng)會在運行期間會采集大量數(shù)據(jù)，所以需要將龐大的方法名映射為指定ID的能力，如下
//方法ID`方法具體全路徑和行參 24`com.d.hookplus.HookApplication$onCreate$1.onActivitySaveInstanceState[android.app.Activity,android.os.Bundle,]
此處的方法名包含了全路徑和行參，如果通過字符串記錄是十分龐大的，所以在編譯期間使用ASM技術(shù)將其對應(yīng)成ID，降低空間復(fù)雜度
2.2.2函數(shù)記錄能力
在ASM輪訓(xùn)期間，在方法開始和結(jié)束位置各插入對應(yīng)的指令用于實現(xiàn)標(biāo)記功能
override fun onMethodEnter() {
//方法進入
methodVisitor?.perfettoVisitMethodDelegate(PerfettoCentre.const.METHOD_ENTER, methodId)
super.onMethodEnter()
}
?
override fun onMethodExit(opcode: Int) {
//方法退出
methodVisitor?.perfettoVisitMethodDelegate(PerfettoCentre.const.METHOD_EXIT, methodId)
super.onMethodExit(opcode)
}處理退出指令時，catch和return指令也有對應(yīng)的記錄
在對應(yīng)的時機插入對應(yīng)的代碼
this.let { methodVisitor ->
methodVisitor.visitFieldInsn(
GETSTATIC,
"com/d/hookcore/perfetto/PerfettoCore",
"Companion",
"Lcom/d/hookcore/perfetto/PerfettoCore$Companion;"
)
methodVisitor.visitIntInsn(BIPUSH, enterOrExit)
methodVisitor.visitIntInsn(SIPUSH, methodId)
methodVisitor.visitMethodInsn(
INVOKEVIRTUAL,
"com/d/hookcore/perfetto/PerfettoCore$Companion",
"getTraceLine",
"(II)V",
false
)
}
例：
private fun initRecycler() {
//方法開始，第一個參數(shù)用于標(biāo)記進入或者退出，第二個參數(shù)用于標(biāo)記映射的方法ID
PerfettoCore.getTraceLine(0,12)
var recyclerView: RecyclerView = findViewById(R.id.rec)
recyclerView.adapter = NodeAdapter(messageList)
PerfettoCore.getTraceLine(1,12)
}
- 插入完代碼的例子如下：
2.2.3.運行方法記錄內(nèi)容
方法記錄后的結(jié)果如下
如：main-1,942155.120954153,1,39,1
| 說明 | 例 |
|---|---|
| 當(dāng)前線程 | Main |
| 當(dāng)前線程ID | 1 |
| 當(dāng)前時間秒值 | 942155.120954153 |
| 當(dāng)前方法標(biāo)記(進入或退出) | 1 |
| 當(dāng)前方法ID | 39 |
| 當(dāng)前幀位下標(biāo) | 1 |
2.2幀數(shù)據(jù)采集
2.2.1于傳統(tǒng)方式的區(qū)別
區(qū)別于Choreographer Hook的方式，系統(tǒng)采用了FrameMatrix實現(xiàn)了幀數(shù)據(jù)采集
Choreographer的Hook點是在Looper.loop之中的Printer.println下，
final Printer logging = me.mLogging;
if (logging != null) {
//Hook點
logging.println(">>>>> Dispatching to " + msg.target + " " +msg.callback + ": " + msg.what);
}
缺點如下：
每次都需要字符串匹配，性能損耗嚴(yán)重
在API31之中被封掉了
2.2.2FrameMatrix的能力
FrameMatrix通過addOnFrameMetricsAvailableListener實現(xiàn)了幀數(shù)據(jù)獲取的能力
window.addOnFrameMetricsAvailableListener({ window, frameMetrics, dropCountSinceLastInvocation ->
//do something
}, frameMetricsHandler)
如果不對window進行addOnFrameMetricsAvailableListener，數(shù)據(jù)也會保留在平臺層，所以沒有性能損耗
FrameMatrix是Android平臺層提供的幀數(shù)據(jù)采集，包含如下信息
| 類別 | 參數(shù) | 說明 |
|---|---|---|
| 獲取每幀性能數(shù)據(jù) | FIRST_DRAW_FRAME | 表示當(dāng)前幀是否是當(dāng)前 Window 布局中繪制的第一幀 |
| INTENDED_VSYNC_TIMESTAMP | 當(dāng)前幀的預(yù)期開始時間, 如果此值與 VSYNC_TIMESTAMP 不同，則表示 UI 線程上發(fā)生了阻塞，阻止了 UI 線程及時響應(yīng)vsync信號 | |
| TOTAL_DURATION | 表示此幀渲染并發(fā)布給顯示子系統(tǒng)所花費的總時間, 等于所有其他具有時間價值的指標(biāo)的值之和 | |
| VSYNC_TIMESTAMP | 在所有 vsync 監(jiān)聽器和幀繪制中使用的時間值(Choreographer 的幀回調(diào), 動畫, View＃getDrawingTime等) | |
| cpuDuration | COMMAND_ISSUE_DURATION | 表示向 GPU 發(fā)出繪制命令的耗時 |
| SWAP_BUFFERS_DURATION | 表示將此幀的幀緩沖區(qū)發(fā)送給顯示子系統(tǒng)所花的時間 | |
| uiDuration | UNKNOWN_DELAY_DURATION | 表示等待 UI 線程響應(yīng)并處理幀所經(jīng)過的時間, 大多數(shù)情況下應(yīng)為0 |
| INPUT_HANDLING_DURATION | 表示處理輸入事件回調(diào)的耗時 | |
| ANIMATION_DURATION | 表示執(zhí)行動畫回調(diào)的耗時 | |
| LAYOUT_MEASURE_DURATION | 表示對 View 樹進行 measure 和 layout 所花的時間 | |
| DRAW_DURATION | 表示將 View 樹轉(zhuǎn)換為 DisplayList 的耗時 | |
| SYNC_DURATION | 表示將 DisplayList 與渲染線程同步所花的時間 |
2.3.同步算法
同步算法是將方法運行數(shù)據(jù)和幀性能數(shù)據(jù)自動分析，裁剪，合并出問題堆棧，并保存到指定位置的過程
在開發(fā)者自定義連續(xù)卡頓多少幀后進行Dump
如果每卡頓一幀就Dump，信息量太密集，并且意義不大，建議開發(fā)者連續(xù)卡頓5幀起步
2.3.1.同步算法細節(jié)
整個同步的過程是在單獨的一個HandlerThread中進行的，所以面臨了兩個難題：
由于HandlerThread接受幀數(shù)據(jù)的時機是不確定的，即可能方法數(shù)據(jù)已經(jīng)收集到很多幀以后了，但是幀數(shù)據(jù)才剛剛到來。如何精準(zhǔn)定位到卡頓范圍內(nèi)的全部函數(shù)
如何盡可能減小性能損耗，降低時間復(fù)雜度和空間復(fù)雜度
所以我們整個同步的過程是圍繞著這兩個問題進行設(shè)計的
2.3.2.算法合并過程
如果卡頓幀連續(xù)個數(shù)到達了開發(fā)者定義的個數(shù)，那么開始還原
將首個卡頓幀的開始時間和連續(xù)卡頓幀后的第一個不卡頓幀的開始時間作為時間范圍，與函數(shù)運行數(shù)據(jù)的時間點進行校準(zhǔn)。匹配到函數(shù)運行的范圍區(qū)域，并通過兩個指針進行標(biāo)記
具體匹配的過程是通過魔改版的二分查找實現(xiàn)
將標(biāo)記出的函數(shù)運行范圍進行導(dǎo)出
導(dǎo)出的能力是基于NIO實現(xiàn)的
導(dǎo)出完畢后將函數(shù)指針位移到開始位置，重復(fù)利用空間
上述過程均在子線程進行，對主線程無影響，現(xiàn)階段損耗為3%左右
2.4.可視化展示
- 將Dump出的數(shù)據(jù)進行二次改造，支持可視化展示
2.4.1.線下還原器
- 基于perfetto的構(gòu)造格式進行二次改造，用于支持可視化展示
2.4.2.支持多端的線下還原器
基于Compose KMP實現(xiàn)了多端的可視化還原器，效果如下：
參數(shù)說明如下：
- MappingFile：函數(shù)ID映射文件
- SourceFile：后綴為.zy_trace的文件，是系統(tǒng)自動采集的格式
- OutputPath：輸出為perfetto識別格式的文件目錄
還原格式細節(jié)
如下：
com.d.hookplus|11116 main-1,942155.105176549,0,29,0 main-1,942155.105229674,1,29,0 main-1,942155.105313008,0,29,0 main-1,942155.105322383,1,29,0 main-1,942155.105492174,0,29,0 main-1,942155.105503112,1,29,0 main-1,942155.105524466,0,30,0 .......
# tracer: nop # # entries-in-buffer/entries-written: 30624/30624 #P:4 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID TGID CPU# |||| TIMESTAMP FUNCTION # | | | | |||| | | com.d.hookplus-main-1 [000]... 942155.105177: tracing_mark_write: B|11116|0com.d.hookplus.NodeAdapter.getItemCount.[] com.d.hookplus-main-1 [000]... 942155.105230: tracing_mark_write: E|11116|0com.d.hookplus.NodeAdapter.getItemCount.[] com.d.hookplus-main-1 [000]... 942155.105313: tracing_mark_write: B|11116|0com.d.hookplus.NodeAdapter.getItemCount.[] com.d.hookplus-main-1 [000]... 942155.105322: tracing_mark_write: E|11116|0com.d.hookplus.NodeAdapter.getItemCount.[] com.d.hookplus-main-1 [000]... 942155.105492: tracing_mark_write: B|11116|0com.d.hookplus.NodeAdapter.getItemCount.[] com.d.hookplus-main-1 [000]... 942155.105503: tracing_mark_write: E|11116|0com.d.hookplus.NodeAdapter.getItemCount.[] com.d.hookplus-main-1 [000]... 942155.105524: tracing_mark_write: .....
- 改造前：
- 改造后：
2.4.3.可視化展示
- 最終將還原器輸出的文件直接導(dǎo)入至perfetto系統(tǒng)中，效果如下
以上就是JankMan-極致的卡頓分析系統(tǒng)的詳細內(nèi)容，更多關(guān)于JankMan卡頓分析系統(tǒng)的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
Android直播軟件搭建之實現(xiàn)背景顏色滑動漸變效果的詳細代碼
這篇文章主要介紹了Android直播軟件搭建之實現(xiàn)背景顏色滑動漸變效果的詳細代碼,代碼簡單易懂，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2021-09-09
朋友圈實現(xiàn)圖片+文字轉(zhuǎn)發(fā)功能(必看篇)
下面小編就為大家?guī)硪黄笥讶崿F(xiàn)圖片+文字轉(zhuǎn)發(fā)功能(必看篇)。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-03-03
AndroidStudio 配置 AspectJ 環(huán)境實現(xiàn)AOP的方法
本篇文章主要介紹了AndroidStudio 配置 AspectJ 環(huán)境實現(xiàn)AOP的方法，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2018-02-02
這篇文章主要介紹了Android圖像處理之霓虹濾鏡效果的相關(guān)資料，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2016-11-11
這篇文章主要整理了Android的activity學(xué)習(xí)筆記,總共有八大亮點，推薦給大家，需要的朋友可以參考下2015-09-09
Android JNI 調(diào)用時緩存字段和方法ID示例
這篇文章主要介紹了Android JNI 調(diào)用時緩存字段和方法ID示例，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2018-07-07
Android webview和js互相調(diào)用實現(xiàn)方法
這篇文章主要介紹了 Android webview和js互相調(diào)用實現(xiàn)方法的相關(guān)資料,需要的朋友可以參考下2016-10-10
這篇文章主要介紹了Android實現(xiàn)仿魅族日歷首頁功能的實現(xiàn)過程以及相關(guān)代碼講解分享，對此有興趣的朋友參考下。2018-02-02
在App開發(fā)中，通常為了省流提高加載速度提升用戶體驗我們通常在列表中或新聞中的插圖都是以縮略圖壓縮過的圖片來進行展示，當(dāng)用戶點擊圖片時我們再去加載真正像素的大圖讓用戶預(yù)覽。本文將利用Flutter實現(xiàn)這一功能，需要的可以參考一下2022-04-04
這篇文章主要為大家詳細介紹了基于popupWindow實現(xiàn)懸浮半透明效果，具有一定的參考價值，感興趣的小伙伴們可以參考一下2018-04-04