一、method tracing介紹

概述

這個是谷歌提供的對java的函數級trace工具，和systrace只支持打點不同，method tracing能支持到函數，看到具體的函數執行時間，準確的分析出來執行的時間短板。

1.生成trace的方式

sampling方式：

sampling方式采用sample任務，定期抓取各個線程的調用棧，采集精度和采集的頻次正相關，同時由于java stack采集的時候需要做suspend，因此還是有一部分的效率損失。

我們可以看到，原生單次采集使用的是suspendall，而不是對threadlist上的線程逐個做getStackTrace，因此效率損失會比較嚴重。

trace方式：

通過在執行流程插入enter-exit來觀測：

相比于sample 方式，trace可以準確的獲取到每個函數的進入和退出時間，精度可以非常高。

由于art虛擬機執行特點，這個方案相較于sample方式復雜度要高不少，下文會著重介紹trace方式的實現原理

2.trace啟動流程

我們從trace方式的啟動入口開始看起

幾個關鍵的流程分別是

1.停用掉JIT GC，這個是防止stub方式替換之后，因為JIT GC引起的重新指定執行方式，釋放JIT code和entry之間存在競爭。

2.進行suspend all，這是因為后續真正開啟trace的時候，會對所有的函數入口做重新指定，必然要對整個java世界進行停頓，保證安全性。

3.注冊listener

然后進入EnableMethodTracing，真正發起tracing的核心流程。

根據是否要回切解釋執行，有兩種不同的處理方式。

具體內部流程有兩個關鍵的處理：

1.構造一個InstallStubsClassVisitor，這個的作用是遍歷所有類，然后對每個類做執行方法入口的重定向，也就是stub回填。

2.對各個線程的當前棧做一下處理，主要是植入exit frame。為什么exit point要單獨處理，我們后文詳細介紹，這個地方谷歌采用了一個非常trick的方式。

接下來我們繼續看InstallStubsClassVisitor遍歷class替換入口的處理：

真正的核心處理流程其實是下述：

如果是解釋執行方式，則把入口都換成GetQuickToInterpreterBridge

如果是stub方式，則換成了GetQuickInstrumentationEntryPoint

3.trace采集的分類

從前面的代碼流程中，我們能發現，分成了兩個類型。

采集的方式分類

interpretor only：這是最簡單粗暴的方式，直接強制整個系統回退到解釋執行。

stubs方式：這個方式是希望提升tracing開啟之后的性能表現，因此在支持解釋執行的基礎上，對JIT和AOT的函數，也做了特殊處理進行支持，而不需要強制回退到解釋執行。相比純解釋執行，這部分的技術細節更豐富，使用了一些“奇技淫巧”，本文后續著重介紹stub對JIT和AOT支持的方式。

trace執行主要是在函數進出的地方植入enter-exit對來實現對函數執行流程的打點。

因為要在一個java 方法的入口和出口植入事件的記錄，所以trace的實現就和虛擬機的執行方式強相關，我們先簡單介紹下虛擬機的幾種執行方式。

虛擬機的執行方式

解釋執行：解釋執行ART能夠全程介入java函數的執行，這就包括了函數的入棧和出棧，因此設置觀測點非常容易，直接在虛擬機執行流程中增加enter/exit埋點即可。

JIT：經過JIT編譯的dex code其實target已經是asm了，這個時候的java函數調用和arm64的native函數是非常類似的。

AOT：同JIT，區別在AOT是提前構建而JIT是運行時構建的。

我們看到啟動階段的實現，是直接插入了enter，那真正的函數入口是怎么路由處理的，這里面其實由于虛擬機設計的特殊性，直接插入wrapper有一些問題，具體的下文先補充一些虛擬機的相關知識，然后結合這些背景知識慢慢道來。

二、背景補充

要知道enter和exit的具體植入和運行原理，我們先補充一點art虛擬機的知識。

1.java函數入口

每個java方法，在虛擬機層面都維持著一個ArtMethod數據結構，每次調用一個方法，實際上是通過ArtMethod找到真正的入口，然后進行調用的。

java動態性的方式也是通過：

object->class->art method ->entrypoint來實現的

我們每次對一個對象call function，實際上就是找到對象的類型，類型里面回填了真正的artmethod，然后查找到正確的入口。

這個布局我們在看替換stub的整體流程的時候就發現了，替換stub就是沿著遍歷class-遍歷method的方式來完成的執行入口重定向。

在只有一個入口可以插入的情況下，我們很容易想到做一個wrapper，在wrapper中調用art_method同時完成跟蹤：

圖示中的stack frame 1 2 3就是對應了我們棧上的棧幀，可以看到如果要使用wrapper方式，會在caller和真正的執行函數之間引入一個新的wrapper棧幀，我們結合下面一個點，就會發現問題。

2.walkstack

在anr，拋出異常的時候，都會對java調用棧進行遍歷，此種遍歷的邏輯主要在walkstack中完成的，這個如果加入了wrapper，會導致穿透的情況變得復雜如下圖：

這種棧結構要兼容起來就非常的痛苦，在已有的JNI-解釋，JNI-quick，quik-quik，quik-解釋之上每種都要考慮棧內有wrapper的場景。

總結

通過上述的虛擬機的特征有如下兩個問題：

1.art_method的入口只有一個掛載點，JIT和AOT處理后的java函數調用方式也并不能提供exit事件的記錄時機。

2.最好不要導致stack結構發生變化，否則在進行棧遍歷的時候會帶來非常大的兼容負擔。

1和2看似是矛盾的，因為常規的手段，只有一個函數入口的話，需要使用wrapper，但是如果使用wrapper函數，棧結構就會發生改變。這個矛盾android使用了一個非常巧妙的方法解決，我們下文就對stub的解決方法做個詳細的介紹。

三、stub技術原理探究

因為jit和odex執行的對象實際上都是匯編，我們在匯編中調用一個函數，實際上只能insert一個entrypoint，那出棧如何實現呢？

此處其實就是使用了arm64的calling conversion偷雞，我們先看下替換的函數art_quick_instrumentation_entry，這個函數是純匯編寫的，我們看下匯編的核心處理：

匯編中使用bl指令調用了artInstrumentationMethodEntryFromCode（BL指令在函數結束后，ret會回到此處，而BR則是直接基于當前的contexts做跳轉，ret后就回到caller了），在artInstrumentationMethodEntryFromCode中主要做了三個事情

1.抓取并且查詢到了真實java函數的入口地址

2.記錄enter事件

3.記錄返回地址的PC(LR寄存器)

artInstrumentationMethodEntryFromCode通過x0把真正java方法的入口返回，然后art_quick_instrumentation_entry做了如下兩個事情：

1.把x30設置為art_quick_instrumentation_exit的入口地址（adr x30, 0x21a6a0）

2.通過BR跳轉到獲取的java方法入口（br x16）

這樣，在真正的被調函數完成之后ret，就會定向到exit的匯編上下文中：

在exit函數里面

1.記錄了出棧事件

2.還原了caller PC

通過改寫棧上位置（str x0, [sp, #504]），然后restore的時候（ldp x29, x30, [sp, #496]），就自然讀到目標lr了，同時這樣不會有寄存器污染的問題

還原lr之后，直接使用br指令跳轉到caller原始的位置。

以上就是android利用arm callingconversion實現的exit植入。

總結

如下圖所示，android通過篡改調用前的lr，結合BL和BR指令的不同ret方式，完成了單入口，在破壞棧結構的情況下，記錄了enter和exit事件對。

四、安卓最新的演進

1.演進概述

因為復雜度和對jit的沖突，導致了不太好

目前谷歌在最新的安卓版本做出了重大的更新：

1.關閉了對odex的支持

2.在jit code生成的時候，如果開啟了tracing，會生成出帶有enter和exit的code，直接在code gen層面支持。

3.對于stub方式，不做全量的替換，使能trace的時候整個系統回退到解釋執行，然后清理jit cache，新的jit函數會直接生成帶有enter和exit的code

2.谷歌最新變更相關合入：

1.jit code中直接生成enter/exit hook調用

https://cs.android.com/android/_/android/platform/art/+/5097f83c4719a76fdfab1044ab745273841aca45

2.instrument替換掉trace odex的支持

https://cs.android.com/android/_/android/platform/art/+/890b19bd625be5d0e4a876e3eb11b8b893fb0c13

相關引用

method trace概述/舉例：https://juejin.cn/post/7107137302043820039

谷歌method trace介紹：https://developer.android.com/studio/profile/generate-trace-logs?hl=zh-cn

審核編輯：湯梓紅