利用AI如何自主分析perfetto trace

ljmsun
0 阅读8分钟

AI 自主分析 Trace 使用说明

我们在 Perfetto UI 里接入了一个新的 AI Analysis 页面，用来做 trace 的自主分析。它不是简单把整份 trace 丢给模型让模型猜，而是在当前 Perfetto 页面内，由 AI 自己按需生成 Perfetto SQL，查询当前 trace，读取结果，再继续下一轮分析，最后给出带证据的结论。

直达地址： aihub2ai-perfetto

AIHbu2API地址： aihub2ai

B站演示视频： 利用AI如何自主分析perfetto trace

image.png

它解决什么问题

传统 trace 分析通常需要先知道 Perfetto 表结构、知道该查哪些表、会写 SQL，还要反复在 Query 页面里试查询。对很多性能问题来说，真正费时间的不是打开 trace，而是定位应该从哪里开始看。

AI Analysis 的目标是把这部分流程自动化：

  • 你用自然语言描述问题，例如“帮我看这段启动为什么慢”。
  • AI 会先理解当前 trace 的上下文。
  • AI 会自主探索表结构，例如查看 slice、thread、sched、process 等相关表。
  • AI 会生成只读 Perfetto SQL，并在当前 trace 上执行。
  • AI 会根据查询结果继续追问数据，而不是一次性下结论。
  • 最终回答会给出结论、证据 SQL 编号、不确定性和下一步建议。

核心能力

1. 当前 trace 内分析

AI 分析运行在已打开的 Perfetto trace 上，直接复用当前页面的 trace engine 查询能力。不需要把 trace 导出到另一个分析工具，也不需要手动复制 SQL 结果。

2. 多轮自主 SQL 分析

AI 不会只回答一段泛泛的文字。它会在内部循环中使用这些工具：

  • get_trace_context：读取当前 trace 的基础上下文。
  • list_tables：列出可查询的 trace 表和 view。
  • describe_table：查看指定表字段。
  • run_sql：执行只读 SQL 查询。
  • finish_analysis：基于已收集证据输出最终结论。

默认自主分析轮数为 20 轮，每次点击 Add Rounds 会追加 5 轮。如果问题复杂，可以继续追加，让 AI 深挖更多证据。

3. 受控 SQL，避免危险操作

AI 只能执行安全查询，不允许修改 trace 数据：

  • 只允许单条 SQL。
  • 只允许 SELECT、WITH 或表结构探查类查询。
  • 行级查询必须带 ORDER BY。
  • 行级查询必须带 LIMIT 100 或更小。
  • 不允许 SELECT * 这类粗暴查询。
  • 查询结果最多发送前 100 行给 AI。

这能减少无意义的大结果集，也避免模型凭空猜测。

4. 证据可追溯

每次执行过的 SQL 都会记录在右侧 Executed SQL 区域。最终回答会引用对应的 SQL 编号。你可以展开每条 SQL，查看：

  • SQL 内容
  • 查询原因
  • 查询状态
  • 返回行数
  • 前几行原始结果

这意味着 AI 的结论可以回到具体数据上验证，而不是只看一段无法追踪的自然语言总结。

快速开始

第一步：打开页面

访问：

https://aihub2api.com/perfetto/

第二步：加载 trace

在 Perfetto UI 中打开你的 trace 文件。支持的方式和原版 Perfetto 基本一致，例如：

  • 从本地选择 trace 文件。
  • 拖拽 trace 文件到页面。
  • 通过 URL 参数打开远程 trace。

加载完成后，左侧侧边栏会出现 AI Analysis 入口。

第三步：配置模型

进入 Perfetto 的设置页，找到 AI Analysis 相关配置。

image.png

部署在 aihub2api.com 时，默认配置如下：

Provider Type: openai
Base URL: https://api.aihub2api.com/v1
Model ID: gpt-5.4
Reasoning Level: xhigh
Request Timeout: 30000 ms
Default Max Rounds: 20
Round Increment: 5

通常你只需要填入自己的 API Key。如果你要使用其他 OpenAI 兼容服务，也可以修改 Base URL 和 Model ID。

注意：如果你曾经在浏览器里手动保存过旧配置，页面会继续使用本地旧配置。遇到模型或 Base URL 不符合预期时，请先检查设置页里的实际值。

第四步：进入 AI Analysis

打开 trace 后，点击左侧侧边栏的 AI Analysis。

页面主要分成三部分：

  • 顶部状态卡片：显示 trace、状态、轮数、模型等信息。
  • 中间对话区：输入问题并查看 AI 的分析过程和结论。
  • 右侧 SQL 区：查看 AI 执行过的 SQL 和结果摘要。

第五步：开始提问

在底部输入框中输入问题，然后按 Enter 或点击 Ask。

输入框支持多行：

  • Enter：提交问题。
  • Shift + Enter：换行。

AI 会开始自主分析。如果默认轮数不够，可以点击 Add Rounds 继续追加分析预算。如果发现方向不对，可以点击 Stop 停止当前分析。

推荐提问方式

为了让 AI 更快定位问题，建议问题里包含三类信息：

  • 现象：例如“启动慢”“滑动卡顿”“首帧慢”“ANR 前卡住”。
  • 范围：例如“看xxx应用”“重点看 0 到 8 秒”“重点看主线程”“重点看 RenderThread”。
  • 期望输出：例如“列出证据 SQL”“给出最可疑原因”“告诉我下一步该看哪里”。

比较好的提问：

这是一段xxx应用冷启动 trace。请分析 0 到 10 秒内启动慢的主要原因，优先关注主线程、RenderThread、binder 调用和 CPU 调度情况。请给出证据 SQL 编号和下一步排查建议。

不太好的提问：

这个 trace 怎么了？

原因是问题太宽，AI 需要花更多轮数先猜分析方向。

结果怎么看

AI 最终回答通常包含这些部分：

  • Conclusion：主要结论。
  • Evidence：支撑结论的 SQL 编号。
  • Uncertainty：当前证据不足或需要人工确认的点。
  • Next Steps：建议下一步如何继续排查。
  • Confidence：模型对当前结论的置信程度。

右侧 Executed SQL 是非常重要的区域。建议不要只看最终回答，也展开关键 SQL 看一下具体结果。推广给团队使用时，也建议把最终结论和关键 SQL 一起贴到问题单或复盘文档里。

常见问题

为什么提示缺少配置？

通常是 API Key 没填，或者 Base URL、Model ID 被清空了。进入设置页检查 AI Analysis 相关配置。

为什么请求失败或 502？

常见原因包括：

  • 网络到模型服务不稳定。
  • API Key 无效或额度不足。
  • Base URL 配错，例如少了 /v1。
  • 所选模型不支持当前接口形态。
  • 第三方服务没有开放浏览器 CORS。

在 aihub2api.com 部署下，默认 Base URL 是：

https://api.aihub2api.com/v1

为什么 AI 分析到一半停止？

可能是达到了当前轮数预算。默认是 20 轮，可以点击 Add Rounds 每次追加 5 轮。

也可能是请求超时、网络失败，或者模型没有按工具调用格式继续输出。

为什么 AI 不直接给答案，而是一直查 SQL？

这是刻意设计的。trace 分析必须依赖证据。AI 通过 SQL 一步步收集证据，能降低“看起来合理但没有数据支撑”的风险。

能不能支持其他模型服务？

可以，前提是目标服务兼容 OpenAI 的接口格式。当前支持两种 provider 形态：

  • openai：使用 /chat/completions
  • openai-response：使用 /responses

如果配置其他网站的 Base URL，需要确认它支持对应接口、支持浏览器跨域请求，并且模型能正确使用 function calling / tools。

当前限制

这个功能适合辅助分析，不应该替代工程师判断。

当前限制包括：

  • AI 只看到它查询到的数据，不会自动理解未查询部分。
  • 如果问题描述太宽，AI 可能消耗很多轮数在探索表结构上。
  • 查询策略依赖模型能力，不同模型效果会有差异。
  • 最终结论需要结合业务背景和人工经验复核。
  • 超大 trace 的分析速度仍受 trace processor 查询性能影响。

适用场景

推荐用于：

  • Android 启动性能分析。
  • 卡顿、掉帧、长任务初筛。
  • 主线程阻塞定位。
  • CPU 调度异常排查。
  • binder、锁等待、线程状态分析。
  • trace 初学者快速理解 Perfetto 数据。
  • 团队内 trace 复盘前的第一轮自动归因。

不推荐用于：

  • 对安全合规要求极高且未脱敏的 trace。
  • 必须 100% 自动定责的场景。
  • 没有明确问题现象的大范围泛问。

一个完整使用示例

假设你有一段应用启动 trace，可以这样问：

这是一段 xxx Android 应用冷启动 trace。请分析启动慢的主要原因，重点关注主线程、RenderThread、binder 调用、CPU 调度和长耗时 slice。请输出结论、证据 SQL 编号、不确定性和下一步建议。

AI 可能会做这些事情：

  • 读取 trace 上下文。
  • 查询有哪些表可用。
  • 查看 slice、thread、process 等表结构。
  • 聚合耗时最长的 slice。
  • 查找主线程和 RenderThread 的关键时间段。
  • 检查是否存在长时间 binder 调用或调度延迟。
  • 输出带 SQL 证据编号的结论。

你可以再追问：

请继续只看主线程，把最可疑的 10 个耗时片段按时间顺序列出来，并解释它们可能对应的业务阶段。

也可以追问：

刚才结论里提到 binder 等待，请继续分析 binder 等待发生在哪些线程之间，是否集中在某个时间段。

总结

AI Analysis 把 Perfetto trace 分析从“人工写 SQL 找线索”推进到“AI 自主查 SQL 收集证据”。它的价值不在于替代性能工程师，而是把第一轮探索、表结构查询、可疑区间筛选、证据整理自动化。

对于复杂 trace，建议把它当作一个能写 Perfetto SQL 的分析助手：让它先跑第一轮定位，再由工程师结合业务上下文复核结论。这样既能节省初筛时间，也能让 trace 分析过程更容易沉淀和复盘。

avatar
文章
阅读
粉丝