Trace me if you can: Automated instrumentation and field profiling

Rahul Ravikumar

各位午安。

我是 Rahul。

我是 Android 開發人員體驗團隊的工程師。

我專注於應用程式和程式庫效能，這場演講的主題是追蹤。

在深入探討追蹤之前，我想先介紹一些共同詞彙，方便您理解。

因此，我在這場演講中提到的追蹤，都是指明確追蹤，也就是手動檢測程式碼，以便瞭解應用程式的運作情況。

我不是指自動分析器，這部分我會再說明。

因此，手動追蹤就像是在程式碼集中留下麵包屑，方便您在遇到效能問題或其他問題時，能回溯並找出原因。

通常比記錄更實用。

我不知道您是否看過大型應用程式的 Logcat 輸出內容。

通常是一大段文字，很難理解。

相較之下，追蹤功能就方便多了。

更容易想像。

您有時間長度。

你已建立一些結構。

您可以使用一些工具，甚至可以切片和切塊，並確切查看何時發生了什麼事。

因此，這項功能非常實用。

您可以將代理指向追蹤記錄，然後提出問題。

您可以使用 Trace Processor、基準等工具，甚至將追蹤記錄轉換為指標。

因此，這些都是您可以使用追蹤記錄執行的操作，但很難使用 Logcat 執行。

另一方面，剖析 (我指的是自動剖析) 通常是為了因應已知問題。

舉例來說，您可能注意到應用程式啟動速度緩慢，或是有卡頓情形，因此想縮小範圍，找出問題所在。

此時，如果沒有手動追蹤記錄可供參考，自動剖析功能就能派上用場。

您可以使用 ART 方法追蹤記錄等工具，檢測每個方法的進入和退出。

或者，您可能正在使用 Simpleperf 等工具查看堆疊取樣。

因此，您不必使用每個方法進入點和結束點，也不必承擔高昂的負擔，只要查看呼叫堆疊樣本，就能瞭解應用程式熱門路徑上的內容。

現在是 2026 年，RAM 是到處都會遇到的問題，因此您可能會查看記憶體、記憶體流失和堆積快照。

因此，這是另一個可以善用的分析器。

你可以查看堆積保留路徑。

您可以查看哪些程式碼正在分配記憶體，這些都是您可以透過這項工具進行的分析。

好

現在，我們有這個詞彙了。

接著來談談我們建構新程式庫的原因。

追蹤 API，1.0 API 最初是在 Android Jelly Bean 中推出。

那是 2012 年的事。

距今超過 14 年。

自此之後，API 的發展並不如您想像。

我們新增了幾項額外資訊。

Android 10 新增了非同步事件和計數器。

那是 2019 年的事。

這樣就好了

API 之後就沒有再更新。

不過，生態系統已大幅演變。

因此，平台追蹤功能已有大幅改善，但您並未獲得任何 API 新增功能。

我們希望改變這種情況。

另一個大問題是，追蹤在 1.0 中有固定的追蹤後端，這表示每當您在程式碼中新增追蹤區段時，它一律會出現在系統追蹤緩衝區中。

Atrace 是擁有該資料的 Android 追蹤子系統。

因此，如果想將追蹤記錄轉換為欄位遙測資料，難度非常高，因為你必須先瞭解 atrace 如何儲存資料。

這種格式有完善的文件說明，但可能難以使用。

因此，我們希望解決這個問題。

因此，我們希望提供工具，讓您將追蹤資料傳送至任何位置。

此外，追蹤 1.0 還有一個限制，就是標籤長度不得超過 128 個字元。

這項限制在 2012 年可能合理，但在 2026 年就顯得相當奇怪。

更糟的是，您也無法在追蹤記錄中加入任何額外的中繼資料，這會造成額外的問題。

此外，還有額外負擔。

因此，每當您追蹤應用程式時，都必須特別注意負擔，因為觀察系統的行為不應改變系統在背景執行的作業。

因此，如果您想重現競爭狀況，追蹤不應使競爭狀況消失。

因此，請務必保留所有語意。

Tracing 1.0 的負擔相對較高，我們希望改善這點。

好的。

我談了很多問題。

現在，我們來看看一些問題的視覺化呈現，以及這些問題在實際操作中如何複合。

這裡有 Perfetto 追蹤記錄。

這是應用程式「com.example.app」的通知。

我們有一個主執行緒，以及一個名為 initializeComponent 的配量。

現在，我們希望取得更多詳細資料。

所以，我們來新增細節。

現在我們知道 initializeComponent 會呼叫 performInitialize。

我們仍不知道正在初始化哪個元件。

現在，工具帶中唯一具有追蹤 1 的工具是名稱，因此我們將其新增至切片的名稱。

請注意，追蹤記錄切片名稱長度上限為 128 個字元，因此在追蹤記錄中會遭到截斷。

雪上加霜的是，追蹤時也會產生截斷作業的負擔。

因此，您很快就會遇到這個問題。

因此，我們非常想解決這個問題。

您已看過 Perfetto 追蹤記錄，也看過視覺化呈現的結果。

現在，我們來看看如何編寫程式碼，以發出這些追蹤記錄區段。

同樣地，我們有 initializeComponent API。

它會接收結構定義和名稱，並呼叫 performInitialize。

到目前為止都很順利。

現在，我們要使用 Tracing 1.0 API 新增追蹤記錄，因此請匯入 androidx.tracing.trace 並使用追蹤記錄區塊。

輸入名稱。

這裡的溫度是 performInitialize。

不過，就像我們先前想做的一樣，我們想知道元件的名稱，因此會使用 Kotlin 的字串插補，並新增名稱。

第一個問題是

因此，這裡有 128 個字元的限制。

Rahul Ravikumar

我們可以使用 Tracing 2 修正這個問題。

請改用 Tracer，而非 androidx.tracing.trace。

API 看起來非常相似。

您有 Tracer.global.trace，而不是 trace。

您有一個類別。

我們稍後會進一步說明類別，但基本上，您需要一個名稱。

接著，您仍有要追蹤的程式碼區塊。

現在，您不再受限於 128 個半形字元的限制。

我提過追蹤負擔。

我想進一步說明我們如何改善這項功能。

在搭載 Android 16 的 Pixel 6a 上，插入單一開頭和結尾區段的動作約需 1,200 奈秒。

這看起來可能不多，但如果您的程式碼非常熱門，會新增許多追蹤區段，那麼應用程式可能會花費更多時間來算繪影格。

因此，我們不想佔用您的時間。

我們透過 AndroidX Perfetto SDK 大幅改善了這項功能。

這是我們為 Composition Tracing 推出的實驗性 SDK，實際上大幅改善了情況。

我們不希望您發布這個 SDK，因為這是 Perfetto C SDK 搭配 JNI 繫結，而 C SDK 在 APK 中約為 4 MB。

我們絕不希望你寄出這類商品。

現在，Tracing 2 提供了專門建構的程式庫。

我們大幅改善了負擔，現在 Tracing 2 的速度快了 7 倍，這表示您有更多時間可以做想做的事，而基礎架構所需的時間也更少。

這項技術能實現哪些過去無法做到的事？

舉例來說，Metro 的執行階段追蹤功能就是其中之一。

Metro 是依附元件插入程式庫。

支援 Kotlin Multiplatform。

使用 Kotlin 編譯器外掛程式。

它會產生所有依附元件插入程式碼，並與 Tracing 2.0 整合，讓您更輕鬆地以視覺化方式呈現程式碼中每個 @Inject 的成本。

舉例來說，

假設我們有一個應用程式圖表。

在 Metro 中，所有項目的範圍都限定在圖表內，因此我們只有一個欄位：AnalyticsTracker。

我們也有提供繫結。

我們有一個網路用戶端，其 OkHttpClient 為 impl，而 AnalyticsTracker 的實作來自 AnalyticsTrackerImpl，我們需要網路用戶端的執行個體，圖表知道如何提供。

因此，編譯器外掛程式會在幕後產生類似這樣的程式碼。

因此，如果您有 AnalyticsTracker，getter 會建立網路用戶端的執行個體，並將其傳遞至 AnalyticsTrackerImpl 的建構函式，這是不錯的做法。

但現在啟用追蹤功能後，您不僅可以查看建立追蹤器 impl 的成本，還能查看其所需的每項依附元件。

現在，您不僅能查看例項化類型的成本，還能查看追蹤記錄中的所有依附元件，這項功能非常強大。

因此，Wise 這款財經應用程式利用這項資訊，將應用程式啟動速度提升了 45%。

他們可以延後應用程式啟動時不需初始化的項目，並找出一些範圍錯誤的項目，例如不小心將應為單例模式的項目設為非單例模式，這些都是您可以在程式碼中查看並輕鬆修正的問題。

如果查看他們的啟動指標，會發現數據相當驚人。

不僅縮短了初始影格的顯示時間，也縮短了完整顯示的時間。

另一家合作夥伴 BandLab 則使用相同的資訊，

因此，您不僅能知道每個 @Inject 繫結的費用，還能知道是哪個執行緒產生了該費用。

因此，一旦知道這一點，您就可以在主執行緒和 CI 中找到所有昂貴的 @Inject 繫結，您可以執行查詢，例如，給我所有昂貴繫結的清單，然後將其歸因於引入它們的變更，然後您現在可以歸咎於實際變更並嘗試修復它。

Rahul Ravikumar

好的。

到目前為止，我已介紹過 Tracing 2 相較於 Tracing 1 的所有改良功能，現在我要介紹 Tracing 2 的新功能，這些功能是以前無法實現的。

因此，其中一項核心功能稱為「情境傳播」，由於現代應用程式越來越複雜，工作負載會在多個執行緒、多個協同程式和多個程序中執行。

您想以視覺化方式呈現要求在每個執行緒和程序之間的傳播方式。

這就是情境傳播的功能。

因此，如果我只提供切片清單，而不說明因果關係，雖然這些資訊很有用，但不太容易推論。

但如果我告訴您，這是事件的因果鏈，您就能更輕鬆地瞭解發生了什麼事，然後將每個切片的成本建立關聯。

這就是背景資訊傳播的功能。

很高興告訴您，我們完全支援情境傳播，以下是實際範例。

回顧 com.example.app Perfetto 追蹤記錄，假設 performInitialize 耗費太多時間，而您想延遲成本或將其移至其他執行緒。

你一定能做到。

假設我將 performInitialize 移至其他執行緒。

現在，您已失去切片的階層性質。

因此，除非查看程式碼，否則您無法再判斷 initializeComponent 是導致 performInitialize 發生的原因。

在理想情況下，您會希望有箭頭指出 A 導致 B，然後您就可以推論事件的因果鏈。

您可能也看過系統追蹤，我們實際上會針對平台上的繫結器交易執行這項操作。

因此，您可以在這裡看到 Compose 基準測試會對 system_server 進行繫結器交易，以準備影格。

因此，從平台追蹤的角度來看，這項功能一直都可行，但我們從未向應用程式開發人員提供這些工具。

因此，Tracing 2.0 現在完全支援 Kotlin 協同程式 Context Propagation。

您不必採取任何行動。

開箱即可使用。

因此，這裡有一個名為 fetchProfile 的單一暫停方法。

它會呼叫 client.get，這是另一個暫停方法，然後切換至 Dispatchers.Default 以反序列化回應。

這是非常制式的協同程式程式碼，您可能每天都會處理。

現在，假設我們要追蹤這個。

我們新增了追蹤記錄區段。

因此，我們在這裡不使用追蹤記錄，而是使用 traceCoroutine API，因為這是一段暫停的程式碼區塊，然後在內容切換至 Dispatchers.Default 之前，我們會使用相同的 traceCoroutine API 新增另一個內部追蹤記錄區段。

現在，您會在追蹤記錄中看到類似下方的內容。

您會看到工作從 worker-1 開始，然後實際切換情境並移至 worker-3，追蹤記錄中會顯示有用的箭頭指向該處。

不僅如此，如果放大中間的方塊，您會發現 deserialize 實際上是在 worker-1 中啟動，而對 withContext 的呼叫導致了內容切換，然後繼續在 worker-3 上執行，接著 fetchProfile 在 worker-3 上恢復，因為協同程式機制希望盡量減少內容切換的次數。

您可以確切查看協同程式暫停和繼續的時間，以及完整的事件因果鏈。

Tracing 2 還能讓您在追蹤記錄中新增自訂中繼資料。

過去，您只能使用追蹤記錄區段的名稱，但現在您還可以新增中繼資料區塊，以便新增任意數量的中繼資料項目。

您可以將其新增至追蹤記錄。

查看實際追蹤記錄時，您會發現新增的所有中繼資料都包含在追蹤記錄中，可供所有工具使用。

現在，您可以嵌入所有知識，以及一直想加入的所有額外資訊。

我剛才介紹了追蹤功能可實現的許多抽象功能，但其中最亮眼的是 Jetpack Compose 的新功能：重組追蹤。

這項功能隨 Compose 1.13 一併推出，現在即可使用。

舉例來說，

這就是大家可能都很熟悉的組合追蹤功能。

這項功能自 Compose 早期就已存在。

這項資訊會顯示可組合項和所有子切片的相對成本，以及每個子切片在發生執行緒上的成本。

這相當簡單。

但無法提供背景資訊。

但不會說明原因。

不會說明重新組成的原因。

如果縮小檢視，就會看到上一張投影片中顯示的感興趣區域。

左側則會顯示已發生的調度輸入事件。

這可能就是狀態變更的原因，也可能是造成重組的原因。

但目前還不清楚。

你無法確定。

不過，有了重組追蹤功能，我們現在可以在追蹤記錄中加入自訂中繼資料，確切說明重組的原因。

不僅如此，現在您也能輕鬆判斷這些事件是否相關。

點選後，系統會顯示確切的狀態變更。

系統會顯示這是一個狀態，也就是可變動狀態值，已從先前的 true 切換為 false。

不只如此，我們還會指出造成問題的確切呼叫堆疊。

如您所見，AbstractClickableNode.performClick 發生後，可變動狀態會隨之變更，進而觸發重組。

這項功能非常實用，是我們以前無法做到的。

這些工具也提供，抱歉，所有這些功能也提供在新的 Android Performance Analyzer 工具中，如果您想試用一些代理工具。

右邊。

我曾提過，Kotlin 協同程式完全支援情境傳播。

但如果程式碼混合使用協同程式和非協同程式，或者您自行執行執行緒，或者您有一些舊程式碼，基於某些原因使用回呼，該怎麼辦？

好的。

好消息是，您仍可享有情境傳播的所有好處。

假設我們有一個使用回呼和執行器的 brownfield API。

實作會使用 executor.execute，呼叫 runCatching (這是實作詳細資料)，取得回應，然後將回應告知回呼。

好的。

如果我想追蹤這個區塊，可以輸入 Tracer.global.trace、加上標籤，然後將區塊包起來。

不過，由於我也想保留事件的因果鏈，因此會接受新的選用類型，稱為傳播權杖。

接著，我會將權杖傳遞至內部追蹤記錄 API。

因此，無論是誰呼叫這個方法，都可以選擇提供傳播權杖，以便保留發生的事件因果鏈。

好的。

現在，該 API 的呼叫端可以是暫停 API。

這裡有一個暫停函式 profileRequest，現在會呼叫使用回呼和執行器的 API。

在這裡，由於我要橋接兩個世界，也就是暫停世界和回呼世界，因此我會使用 suspendCoroutine 建構工具。

我會取得接續，然後叫用 API，並在收到回應後，在回呼中繼續接續。

接著，我定義的執行器稱為 profileRequestContext。

這是單一執行緒執行器。

由於 traceCoroutine 會在協同程式內容中嵌入傳播權杖，因此我可以從協同程式內容中取得傳播權杖，然後將其做為輸入內容傳遞至 brownfield API，這樣我仍然可以保留事件的因果鏈。

在追蹤記錄中，這點非常明顯。

因此，這裡有一個從 worker-3 開始的工作，在我們執行內容切換後，切換到單一執行緒執行器，然後在 worker 上繼續執行。

非常方便。

Rahul Ravikumar

好的。

您也可以自訂 Tracer.global。

到目前為止，Tracing 2.0 API 為 Tracer.global 提供非常好的預設值，但如果您想自訂，也可以。

此外，Tracing 2.0 支援 JVM 和 Android，因為我們希望 Java 和 Android 程式庫都能完整支援追蹤功能。

因此，初始化的三個步驟是：建立追蹤記錄接收器。

追蹤記錄接收器實際上是追蹤記錄封包的儲存方式。

定義傳輸格式和輸出追蹤記錄的儲存位置。

我們提供支援 Perfetto 格式的追蹤接收器現成實作，但您也可以自行編寫追蹤接收器。

這可以追溯到嘗試解決的問題，即 atrace 是 Tracing 1 中唯一可用的後端。

我們想解決這個問題。

因此，現在您可以編寫 OpenTelemetry 接收器，或自備接收器。

您可以選擇覆寫這項設定。

有了接收器後，您可以建立追蹤驅動程式，並將接收器提供給它。

你也可以選擇要啟用哪些類別。

這正是類別發揮作用的地方。

因此，您可以決定在發布版本中，某些類別比其他類別更重要 (與偵錯版本相比)，並指定要啟用這些類別。

或者，您也可以直接說：「我想啟用所有類別，無論來源為何。」

這完全沒問題。

您也可以新增追蹤記錄的全域自訂屬性。

因此，您可以使用 addAttribute API 嵌入建構版本、變種版本等資訊，或任何其他要附加至追蹤記錄的中繼資料。

最後，您可以呼叫 setGlobalTracer 來註冊追蹤器。

這會將 Tracer.global 繫結至這個追蹤器執行個體，隨後程序即可使用。

在 Android 上，由於程序有更明確定義的生命週期，因此您只需實作 AbstractTraceDriver.Factory、覆寫其 create 方法，並執行與先前相同的操作。

因此，您要先建立接收器，再建立驅動程式。

因此不必在此註冊。

我們會為您註冊，因為我們知道這是最先發生的事件。

好的。

好的，我想重申，追蹤功能已支援多平台。

這是我們刻意做出的選擇，因為我們知道 Compose 會在多個平台上執行，因此希望您能在盡可能多的位置進行追蹤。

目前我們支援 Android 和 JVM，但我們的實作方式完全開放，日後可視需要支援其他平台。

Rahul Ravikumar

您會很高興知道，R8 是用於縮減及最佳化 Android 原始碼的工具，使用 Tracing 2.0。

我們也利用追蹤記錄，將 R8 最佳化，實際縮減程式碼並加快最佳化速度 25%。

這表示建構時間更短，等待最佳化作業的時間也更短。

我不會逐一介紹 R8 的所有最佳化功能，但我想介紹其中一項，讓您瞭解追蹤功能可以帶來什麼效果。

因此，R8 的核心是來源對來源轉換器。

因此，您會取得一堆 JAR，並將其縮減和最佳化，然後產生另一組可進行 dex 的 JAR。

因此，AGP 會先讀取 JAR，這不只是應用程式，還包括所有依附元件。

因此，它會使用 Gradle worker 開始讀取所有輸入 JAR。

您有許多 JAR 檔案需要讀取。

讀取 JAR 檔案後，R8 會開始剖析程式碼，並建構程式碼代表的模型及其所有進入點，以便開始最佳化及縮減程式碼。

現在，這個「await」片段代表 R8 真正準備好開始最佳化程序的時間，對吧？

您可能會看到中間有一些空白空間，並想知道為什麼有未使用的 CPU 作業時間。

這是因為舊版 API 的運作方式是，先等待所有 worker 讀取完所有檔案，再剖析任何內容。

我們當然可以修正這個問題，而這正是我們所做的。

因此在 AGP 9 中，您可以看到讀取輸入 JAR 後，我們立即開始處理。

而且不必等待每個 worker 完成輸入內容讀取作業。

這實際上大幅縮短了等待讀取所有輸入內容的時間。

因此，這項最佳化作業顯而易見，您可以在追蹤記錄中清楚看到，但如果只查看原始碼，就不太容易看出哪些部分值得最佳化。

AndroidX 工程師每天使用的另一項工具是 Metalava。

Metalava 是我們用來確保我們提供的任何 API 都具有您預期的 API 相容性保證，且外部人員可以完全使用，而不會出現我們想要避免的任何問題。

這項工具會在每個公開 API 和受限 API 上執行，因此我們在這裡節省的時間，實際上就是 AndroidX 工程師省下的時間。

Metalava 也使用追蹤功能，將提交後時間大幅縮短 15%。

接著，我們來看看追蹤記錄，瞭解發生了什麼事。Metalava 會執行兩種類型的檢查：第一種是檢查受限制的 API，第二種是檢查公開 API。

不過，您可能已經注意到一個模式。

我們做了許多設定，只為了執行兩次檢查。

因此，系統會讀取所有程式輸入內容，並建構 PSI (程式結構介面)，也就是程式碼的確切形狀，以便進行推論。

接著，我們會先建構 AST，再開始套用所有需要的 Lint 檢查。

而且這項高成本作業會執行兩次。

我們如何修正這個問題？

我們只做過一次。

因此，我們只需執行一次設定工作，並將這些輸入內容重複用於受限檢查和公開檢查，就能省下所有費用。

是啊

好的。

Rahul Ravikumar

現在，我已經大致介紹了 Tracing 2.0 的功能，但請務必瞭解，雖然追蹤很重要，但知道要追蹤什麼也同樣重要。

請勿在各處散布追蹤記錄。

您必須謹慎選擇，我會嘗試提供一些準則，說明哪些內容值得追蹤。

因此，您應該先找出追蹤記錄中無法解釋的間隔。

因此，只要執行緒處於執行中或可執行狀態，而您在系統追蹤中看到明顯的間隔，卻無法解釋原因，也不知道應用程式在做什麼，就可能值得調查。

這時，我可能會擷取方法追蹤記錄，並與系統追蹤記錄重疊，看看有哪些值得追蹤，然後加入相關追蹤記錄區段。

您也需要根據使用者歷程排定優先順序。

因此，您需要查看應用程式啟動情形。

您需要查看核心應用程式使用者歷程，並嘗試判斷是否能透過查看追蹤記錄來解釋這些歷程。

因此，只要無法推論某個問題，就值得追蹤。

您也應該查看追蹤記錄中的深層呼叫堆疊或不明 CPU 使用率，並嘗試找出確切原因，然後將程式碼集的這些部分轉換為追蹤記錄。

因此您可以追蹤這些要求。

此外，每當執行緒處於休眠狀態時，請務必瞭解休眠原因。

它們應該在等待 I/O、等待繫結器交易，或等待您預期發生的某些外部輸入事件。

但如果出現無法解釋的睡眠狀態，就非常值得調查，因為顯然可能有潛在問題。

接著，在程式碼中加入所有追蹤區段後，請將這些區段轉換為基準，以便追蹤其中的變更。

因此，隨著程式碼集演進，您可以查看指標是否有所變化，以及資訊主頁是否確實反映重大變更，因為這代表有重要內容發生變化。

或者，您也可以略過上述所有步驟，直接交由代理執行。

將這些指南轉化為技能，然後指派給您最愛的代理，讓它執行。

是啊

Rahul Ravikumar

如果我成功說服您追蹤是值得嘗試的做法，以下是專案設定。

這段程式碼非常容易理解。

追蹤功能只是傳統的 Java 程式庫，因此您需要定義 androidx.tracing:tracing-wire 的依附元件，也就是與 Perfetto 相容的追蹤驅動程式和追蹤組合，目前的穩定版本是 2.0.5。

如果您是 Java 程式庫，這也是完全相同的；同樣地，這是一個完全多平台的 API。

我們希望在適當情況下，將這項功能擴展到其他平台。

最後，我想快速總結一下。

我剛才介紹了所有新增的實用功能。

因此，情境傳播功能非常強大。

我們能嵌入自訂資訊、中繼資料、呼叫堆疊資訊，以及其他各種內容。

我還有很多事情沒說。

您當然可以變更追蹤格式、追蹤接收器，以及將追蹤資料傳送至 OpenTelemetry。

這些都是你可以採取的行動。

追蹤功能適用於多平台。

這也是我們深思熟慮後的決定，因為我們希望盡可能讓更多人受惠。

我們提供的所有工具，無論是 Perfetto、AndroidX 基準、新的效能分析器，還是舊的 Android 分析器，都支援 Tracing 2.0。

以上就是今天的內容，感謝收聽。

祝您在開發人員高峰會收穫滿滿，謝謝。