在以下情况下，性能分析请求可能无法立即完成或提供结果：
- 速率限制：为保护设备性能，系统会限制收集速率（请参阅速率限制的工作原理）。
应用在结果传送前终止：如果您的应用在捕获期间关闭或崩溃，系统会在后台停止并保存配置文件，并在您的应用下次运行（在前台或后台）并注册全局监听器时传送已加入队列的结果。系统会将未传送的已加入队列的结果保留最多 7 天，等待监听器注册；如果您的应用在 7 天内未注册监听器，则已加入队列的结果会被舍弃。
其他错误：如果收集失败（例如，由于请求无效或内部错误），
ProfilingResult会报告错误代码和消息。
速率限制的运作方式
由于捕获配置文件会占用大量资源，因此 ProfilingManager 会在进程级和系统级强制执行速率限制，以保护设备性能和电池续航时间。不同的配置文件类型会产生不同的资源费用，系统会在两个级别跟踪滚动时间窗口内的配额：
- 进程速率限制：根据每个应用的配额，跟踪单个应用收集的配置文件的资源费用。每个应用都会获得相同的配额，设备上其他应用的性能分析活动不会影响您应用的限制。如果您的应用在任何时间窗口内达到其配额，请求将失败并显示
ERROR_FAILED_RATE_LIMIT_PROCESS。 - 系统速率限制：根据共享的全局配额，跟踪设备上所有应用收集的配置文件的总资源费用。
由于所有应用都会占用此设备级限制，因此即使您的应用尚未用尽其自身的进程配额，请求也可能会失败并显示
ERROR_FAILED_RATE_LIMIT_SYSTEM。
管理生产环境中的个人资料数量
由于设备级速率限制取决于配置文件类型和整体系统活动，因此请勿尝试在应用内跟踪或预测确切的本地速率限制配额。相反，请专注于在发生相关用户体验历程或异常时发出性能分析请求，并让 ProfilingManager 处理设备端限制。
为了在保持上传带宽和存储费用可控的同时最大限度地提高现场覆盖率，请使用群体细分和实验平台（例如远程配置或 A/B 测试标志）控制总体配置文件数量：
- 在用户群中进行抽样：为一小部分随机的用户会话启用性能分析，而不是在每次运行时都请求每个用户的性能分析。
- 按同类群组细分：针对您正在调查回归问题的特定应用版本、设备层级、操作系统版本或区域（例如，在 OOM 率升高的低 RAM 设备上启用 Java 堆转储收集）。
- 跨用户细分触发器和直接请求：将不同的性能分析触发器和直接性能分析请求分配给不同的细分用户群，以便一些用户记录一个性能分析文件，而其他用户记录另一个性能分析文件。由于设备上的所有捕获操作都共享相同的每个应用配额，因此在细分用户群中隔离这些操作可防止频率较高的触发器或请求耗尽单个设备上频率较低的捕获操作所需的配额。