在本機測試 ProfilingManager 整合時，要求可能會受到頻率限制，或在測試觸發條件時，背景追蹤可能不會啟用。您可以使用本頁的 adb 指令，在測試裝置上停用節流、提取設定檔、保留未遮蓋的追蹤記錄、觸發擷取，以及檢查服務狀態。
停用頻率限制器
如要在本機測試期間停用 requestProfiling 要求的應用程式程序和系統頻率限制器，請執行下列 device_config 指令：
adb shell device_config put profiling_testing rate_limiter.disabled true
測試完成後，請重設標記：
adb shell device_config delete profiling_testing rate_limiter.disabled
使用 ADB 提取設定檔
如要在具有 Root 權限的裝置上，檢查經過遮蓋的設定檔，請使用 getResultFilePath 傳回的路徑執行 adb
pull：
# Pull a profile
adb pull /data/user/0/<com.example.myapp>/files/profiling/<profile-file-name>
保留暫時和未遮蓋的結果
在本機測試剖析時，您可以將結果保留在 /data/misc/perfetto-traces/profiling/ 的暫存目錄中。比較未遮蓋和已遮蓋的系統追蹤記錄，有助於瞭解遮蓋期間捨棄的資料。
暫時和未遮蓋結果的保留方式，取決於裝置搭載的 Android 版本：
Android 16 (API 級別 36) 以上版本：您可以在暫存目錄中保留未遮蓋 (如適用) 和遮蓋的結果。Android 16 擴充了暫存目錄，可在所有建構類型上使用
adb pull存取，不需具備 Root 權限 (Android 15 則需要 Root 權限才能讀取/data/misc/perfetto-traces/profiling/)。如要防止系統刪除暫存結果，請執行下列指令：adb shell device_config put profiling_testing delete_temporary_results.disabled trueAndroid 15 (API 級別 35)：在暫存目錄中，您只能保留未遮蓋的結果，且只有在具備 Root 存取權的版本上，才能透過
adb存取。(應用程式仍會在自己的/data/user/0/<app>/files/profiling/目錄中收到經過遮蓋的設定檔，應用程式程式碼可在任何版本上讀取或複製該設定檔，但直接使用adb pull從/data/user/0/...提取時，需要具備根層級存取權，或在可偵錯版本上使用adb shell run-as <app>)。如要防止系統刪除未遮蓋的追蹤記錄，請執行下列指令：adb shell device_config put profiling_testing delete_unredacted_trace.disabled true
擷取設定檔後，請從暫存目錄中提取保留的檔案：
# Pull a retained redacted profile (Android 16 and higher)
adb pull /data/misc/perfetto-traces/profiling/<trace-name>.<profile-type-ext>
# Pull an unredacted system trace
adb pull /data/misc/perfetto-traces/profiling/<trace-name>.perfetto-trace-unredacted
在這些指令中，<trace-name> 是 ProfilingResult.getResultFilePath 傳回路徑中的基本檔案名稱 (不含副檔名)，而未遮蓋的系統追蹤記錄副本會將 -unredacted 附加至 .perfetto-trace 副檔名。如要進一步瞭解檔案名稱結構和 <profile-type-ext> 值，請參閱「檔案位置和命名格式」。
adb shell device_config delete profiling_testing delete_temporary_results.disabled
adb shell device_config delete profiling_testing delete_unredacted_trace.disabled
強制啟用背景追蹤記錄，以便測試觸發條件
由於系統背景追蹤記錄在正式環境中會隨機執行，因此在本機測試觸發條件式剖析可能會有難度。如要強制系統執行連續背景追蹤，並略過應用程式觸發條件的系統層級頻率限制器，請設定 system_triggered_profiling.testing_package_name：
adb shell device_config put profiling_testing system_triggered_profiling.testing_package_name <com.example.myapp>
使用 setRateLimitingPeriodHours 設定的每個觸發條件冷卻時間仍適用。這個模式會持續執行，直到您清除為止，因此請在測試完成後移除旗標：
adb shell device_config delete profiling_testing system_triggered_profiling.testing_package_name
實用的偵錯指令
在搭載 Android 16 (API 級別 36) 以上版本，且 Profiling 模組版本較新的裝置上，您可以使用 cmd profiling_service 工具 (而非 adb) 啟用詳細記錄、觸發隨選設定檔收集，以及直接從指令列測試觸發條件。
啟用詳細偵錯記錄檔
如要在 logcat 中啟用詳細的 ProfilingService 記錄，並診斷要求處理和傳遞作業，請執行下列指令：
adb shell cmd profiling_service enable-logs true
要求隨選設定檔集合
如要從指令列立即擷取特定套件的設定檔，請執行下列指令：
adb shell cmd profiling_service request-profiling <profiling_type> <com.example.myapp> [--user <user_id>] [--duration <duration_ms>] [--sources <sources>]
在這個指令中，<profiling_type> 是 ProfilingManager 的整數常數值 (1 代表 Java 記憶體快照資料、2 代表堆積快照、3 代表堆疊取樣，或 4 代表系統追蹤記錄)。目標應用程式程序必須執行記憶體和堆疊設定檔，除非停用，否則要求會受到頻率限制器限制，且完成的 ProfilingResult 只會傳送至向 registerForAllProfilingResults 註冊的全域事件監聽器。
登錄及模擬觸發條件
如要為套件註冊觸發條件或觸發模擬觸發事件，並驗證觸發條件回呼處理，請執行下列指令：
adb shell cmd profiling_service add-trigger <trigger_type> <com.example.myapp> [--user <user_id>]
adb shell cmd profiling_service trigger <trigger_type> <com.example.myapp> [--user <user_id>]
在這些指令中，<trigger_type> 是 ProfilingTrigger 的整數常數值 (例如 TRIGGER_TYPE_APP_FULLY_DRAWN 的 1、TRIGGER_TYPE_ANR 的 2 或 TRIGGER_TYPE_OOM 的 7)。執行 add-trigger 會註冊觸發條件，並設定 0 小時的冷卻時間，覆寫該觸發條件類型的任何現有註冊。如要模擬儲存背景追蹤記錄快照的觸發條件 (例如 1 或 2)，必須有有效的背景追蹤記錄 (請參閱「強制啟用背景追蹤記錄以測試觸發條件」)。
收集整體 ProfilingManager 狀態
在搭載 Android 16 (API 級別 36) 以上版本，且 Profiling 模組版本較新的裝置上，您可以對 profiling_service 執行 dumpsys，診斷問題並檢查 ProfilingManager 的目前狀態：
adb shell dumpsys profiling_service
dumpsys profiling_service 輸出內容僅供參考和偵錯，格式可能隨時變更。提供服務內部狀態的快照，包括：
- 有效的節流和頻率限制器狀態。
- 使用中的裝置設定。
- 已註冊的應用程式觸發條件，以及頻率限制等待期。
- 執行中和已排入佇列的剖析工作階段。
- 最近的剖析要求、觸發事件和結果傳送事件。