perfetto-trace-analysis

资源

• 领域提示： 针对特定性能领域的参考文件：CPU、Graphics、I/O、IPC、Memory、Power。每个文件都包含多种经过专家审核的强大轨迹分析技术，可为分析提供指导和帮助。
• Perfetto SQL 参考： 将意图转换为有效查询的参考指南位于 SQL 参考。你必须阅读此参考，并在生成所有 SQL 时遵循其中的执行协议。

设置阶段（必需）

1. 初始化暂存文件（证据链）：
   • 在目标轨迹文件所在的同一目录中，使用本地暂存文件保存工作记忆。
   • 使用轨迹文件名加上 _analysis.md 作为文件名（例如，[trace_filename]_analysis.md）。创建文件之前，先列出目录内容，检查是否已存在同名文件——为避免影响调查，请勿读取文件内容来检查其是否存在。如果已存在，则追加递增的版本号（例如，_v2.md、_v3.md），直到找到可用的文件名。之后的所有工具调用中都必须硬编码使用此确切文件名。
   • 暂存文件仅用于记录已验证的事实：时间戳、切片名称、线程 ID（utid/tid）和线程状态。
   • 请勿在暂存文件中写入初步假设或过早得出的结论。它是严格的证据链。
2. 查看领域提示： 阅读每个文件中的领域提示，了解可能使用的技术概况。在后续调查中研究和检索提示时，务必将这些基础知识纳入考量。
3. 查看 SQL 参考： 阅读 references/sql.md 中的 SQL 参考，并在生成所有 SQL 时遵循其中的执行协议。不要猜测数据库架构。
4. 确定目标： 如果用户的请求较宽泛（例如“为什么应用很慢？”），且未指定包名：
   • 执行查询以识别活动应用：sql INCLUDE PERFETTO MODULE android.startup.startups; SELECT package FROM android_startups;
   • 如果返回多个包，请让用户选择一个。将选定的 package_name 保存到暂存文件中。

调查协议

重复执行以下循环，直到确定明确的根本原因：

1. 制定假设

• 优先级： 根据以下信息制定假设：用户提示 >“领域提示”（CPU、Graphics、I/O、IPC、Memory、Power) > 一般知识。务必利用这些经过专家审核的“领域提示”分析技术。
• 来源说明： 明确说明假设的来源（例如，“基于 hints_io.md 中的提示……”）。
• 关注重点： 聚焦于主要瓶颈。除非用户明确要求，或不存在其他明显瓶颈，否则不要深入调查 binder 事务。
• 推理说明： 生成新查询之前，简要说明基于先前发现的推理过程。

2. 规划并收集数据

• 先看指标： 先使用轨迹指标了解整体情况，再深入编写自定义 SQL（例如，./trace_processor --run-metrics android_startup）。
• 由宽到窄： 从过滤条件最少的宽泛查询开始。优先使用模糊匹配（例如，GLOB '*abc*'），而非精确匹配。
• 时间重叠： 按时间筛选时，必须检查与目标时间范围重叠的事件（例如，start1 < end2 AND start2 < end1），以免遗漏跨越边界的切片。

3. 分析并深入排查（深度优先）

• 证据严谨性： 没有明确数据时，不要得出结论。
• 耗时与 CPU 时间： 不要假设运行时间较长的切片正在积极计算。你必须查询 thread_state 表中可疑切片对应的确切时间窗口，确认线程处于 Running、Runnable（等待 CPU）还是 Sleeping/Uninterruptible Sleep（阻塞）状态。
• 追踪依赖关系： 如果线程处于阻塞/等待状态，你必须查明它在等待什么（Binder、锁、I/O 等）。必要时跨进程追查。未找出阻塞原因前，不能结束对等待线程的调查。

4. 彻底调查（不要过早放弃）

• 多个瓶颈： 复杂的性能问题很少只有一个原因。发现第一个异常后，不要停止调查。即使你发现了主要瓶颈（例如模拟器图形卡顿），也必须继续查找其他独立的系统级问题（例如锁竞争、I/O 停滞）。要发现其他瓶颈，请搜索“Domain Hints”文件（CPU、Graphics、I/O、IPC、Memory、Power）的内容，获取并运用经过专家审查的高效跟踪分析技术。深入调查每条相关提示。
• 全局验证： 定期在全系统范围内查询运行时间最长的切片（ORDER BY slice.dur DESC）和最常见的 D 状态，确保局部调查没有遗漏影响巨大但无关的系统停滞。
• 遇到死路也要继续： 如果某个假设被证伪，或查询结果为空，不要就此下结论。调整调查方向，放宽搜索条件（模糊匹配、更宽的时间窗口），继续排查。

最终报告

只有在追踪完整个依赖链并找到根本原因，而且通过彻底搜索确认不存在其他重大瓶颈后，才能：1. 总结调查结果，详细说明已验证的证据链。2. 以以下内容结尾：“本次跟踪分析到此结束。你可以在 [scratchpad_filename] 中查看完整证据链。如果你希望我深入分析其中任何特定线程，或需要我协助起草错误报告，请告诉我。”