在本地测试 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 中进行了扩展，可在所有 build 类型上使用
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 访问权限的 build 上通过
adb访问。（您的应用仍会在其自己的/data/user/0/<app>/files/profiling/目录中收到经过隐去处理的配置文件，您的应用代码可以在任何 build 上读取或复制该文件，但使用adb pull直接从/data/user/0/...中拉取需要 root 访问权限，或在可调试 build 上使用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 模块版本的设备上，您可以通过 adb 使用 cmd profiling_service 工具，直接从命令行启用详细日志记录、触发按需配置文件收集和测试触发器。
启用详细调试日志记录
如需在 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 中的整数常量值（例如，1 表示 TRIGGER_TYPE_APP_FULLY_DRAWN，2 表示 TRIGGER_TYPE_ANR，7 表示 TRIGGER_TYPE_OOM）。运行 add-trigger 会注册具有 0 小时冷却时间的触发器，并覆盖该触发器类型的任何现有注册。模拟保存后台跟踪记录快照的触发器（例如 1 或 2）需要有效的后台跟踪记录（请参阅强制启用后台跟踪记录以进行触发器测试）。
收集 ProfilingManager 的整体状态
在搭载 Android 16（API 级别 36）及更高版本且安装了最新 Profiling 模块版本的设备上，您可以针对 profiling_service 运行 dumpsys，以诊断问题并检查 ProfilingManager 的当前状态：
adb shell dumpsys profiling_service
dumpsys profiling_service 输出仅用于提供信息和调试，其格式可能会发生变化。它提供服务内部状态的快照，包括：
- 活跃的限制和速率限制器状态。
- 活跃设备配置。
- 已注册的应用触发器及其速率限制冷却期。
- 活跃和已加入队列的性能分析会话。
- 近期性能分析请求、触发器发生情况和结果传送事件。