选择合适的分析方法
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
您可以使用两种主要方法来收集性能分析文件:手动收集性能分析文件和使用 ProfilingManager
API。
我们建议使用 ProfilingManager
来收集和分析来自许多用户的数据,或用于调试罕见的问题。不过,对于更容易重现的问题,手动分析可能是一个更好的选择。
下表显示了这两种记录个人资料的方法有何不同:
|
ProfilingManager |
手动收集个人资料 |
个人资料时间控制 |
更多 |
收起 |
个人资料来源 |
本地设备和公开用户 |
仅限本地设备 |
个人资料输出 |
已隐去 |
未隐去 |
基于事件的分析 |
支持 |
否 |
个人资料可自定义程度 |
收起 |
更多 |
可伸缩性 |
高 |
低 |
以下部分简要介绍了各种分析记录方法之间的区别。
个人资料时间控制
与手动分析相比,ProfilingManager
API 可以更好地控制应用何时开始或停止分析,而手动分析可能难以确定时间分析的初始化时间。ProfilingManager
还可以更轻松地分析意外行为,因为即使您无法在本地重现该行为,也可以收集配置文件。
个人资料来源
借助 ProfilingManager
,您可以从公开用户那里收集数据,以查找和修复性能问题。相比之下,手动分析仅允许您在自己的设备上重现问题。
个人资料输出
ProfilingManager
和手动收集会生成不同类型的性能剖析输出:
ProfilingManager
生成已遮盖的轨迹。经过编辑的轨迹会显示有关应用进程的信息,但会隐藏系统上其他应用的数据。由于 ProfilingManager
会在返回之前收集并编辑这些数据,因此您可以从公开用户处收集轨迹,同时通过不显示其他应用的数据来保护他们的隐私。
手动收集的配置文件会生成未经过编辑的轨迹。手动记录系统轨迹时,输出可能包含系统上运行的所有进程。虽然这些未经过编辑的轨迹可提供更完整的数据以供调试,但出于隐私方面的考虑,您只能在本地访问它们。
基于事件的分析
ProfilingManager
还可以在发生特定事件(例如“应用无响应”(ANR) 错误或应用启动)时收集性能分析文件。ProfilingManager
将处理基于事件的收集的配置文件启动和停止。
个人资料可自定义程度
手动分析提供最丰富的自定义选项,而 ProfilingManager
提供的自定义选项较少。
可伸缩性
ProfilingManager
是扩展跟踪的最佳方式,因为它是唯一允许应用开发者记录公开用户配置的选项。借助 ProfilingManager
,您可以设置大规模的轨迹收集和分析。
手动分析仅限本地使用。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-09-04。
[null,null,["最后更新时间 (UTC):2025-09-04。"],[],[],null,["You can collect profiles using two primary methods: manual profile collection\nand the `ProfilingManager` API.\n\n- Manual profile collection involves manually running Perfetto on your local device to record profiles. You can do this using commands as described in [Recording system traces with Perfetto](https://perfetto.dev/docs/getting-started/system-tracing) or by using the Quick Settings tile, as explained in [Record using Quick Settings tile](/topic/performance/tracing/on-device#quick-settings).\n- `ProfilingManager` lets apps collect profiles in production.\n\nWe recommend using `ProfilingManager` for collecting and analyzing data from\nmany users or for debugging rare issues. However, for issues that are easier to\nreproduce, manual profiling might be a better choice.\n\nThe following table shows how these two methods for recording profiles differ:\n\n| | **ProfilingManager** | **Manual profile collection** |\n|-------------------------|-------------------------------|-------------------------------|\n| Profile timing control | More | Less |\n| Profile source | Local device and public users | Local device only |\n| Profile output | Redacted | Unredacted |\n| Event based profiling | Yes | No |\n| Profile customizability | Less | More |\n| Scalability | High | Low |\n\nThe following sections briefly describe the differences between the profile\nrecording methods.\n\nProfile timing control\n\nThe `ProfilingManager` API provides more control over when an app starts or\nstops a profile compared to manual profiling, where timing profile\ninitialization might be difficult. `ProfilingManager` also makes it easier to\nprofile unexpected behavior because you can collect a profile even if you cannot\nreproduce the behavior locally.\n\nProfile source\n\nWith `ProfilingManager`, you can gather data from public users to find and fix\nperformance issues. In contrast, manual profiling only lets you reproduce issues\non your own device.\n\nProfile output\n\n`ProfilingManager` and manual collection produce different types of profile\noutputs:\n\n- `ProfilingManager` produces redacted traces. Redacted traces show\n information about your app's process but hide data from other apps on the\n system. Because `ProfilingManager` collects and redacts before returning\n them, you can collect traces from public users while protecting their\n privacy by not showing data from other apps.\n\n- Manual profile collection produces unredacted traces. When you manually\n record a system trace, the output might include all processes running on the\n system. While these unredacted traces offer more complete data for\n debugging, you can only access them locally due to privacy concerns.\n\nEvent-based profiling\n\n`ProfilingManager` can also collect profiles when specific events happen, such\nas an Application Not Responding (ANR) error or app startup. `ProfilingManager`\nwill handle the starting and stopping of profiles for event-based collection.\n\nProfile customizability\n\nManual profiling provides the most customization, while `ProfilingManager`\noffers fewer customization options.\n\nScalability\n\n`ProfilingManager` is the best way to scale tracing because it's the only option\nthat lets app developers record profiles from public users. With\n`ProfilingManager`, you can set up large-scale trace collection and analysis.\nManual profiling is limited to local use."]]