SmartPerfetto 开源：面向 Android Trace 分析的 Perfetto AI Assistant
SmartPerfetto 已经完整开源。打开仓库能看到当前可运行的主干工程：Perfetto UI fork、后端 agentv3、MCP 工具、YAML Skill、场景策略、脚本和文档。没有保留私有核心模块，也没有只放一层 demo 壳。
这个项目来自一个很具体的日常场景：手里有一條 trace，Perfetto 已经把事实摆出来，但从事实到判断还要翻表、写 SQL、对线程、看 FrameTimeline、找 Binder 对端，再回到时刻线上确认一遍。SmartPerfetto 想把这些重复动作固化成工具，让实力工程师把時間花在判断上。
它还处在打造阶段。现在放出来，是因为 trace 分析靠真实样本长出来：真实设备、真实厂商差异、真实业务 trace、真实 PR，都会改变 Skill 和策略该怎么写。等所有能力都稳定后再单向亮相，反而会错过最需要样本的阶段。
如果你日常会打开 Perfetto 看滑动卡顿、启动、ANR、Binder、CPU 调度或渲染管线，SmartPerfetto 提供的是一个带 AI Assistant 的 Perfetto UI：加载 trace 后，用自然語言提问，后端查询 trace_processor_shell、调用 YAML Skill、组织证据，再把结论和统计结果表格流式显示在瀏覽器里。
项目地址：
- 主仓库：https://github.com/Gracker/SmartPerfetto
- Perfetto UI fork：https://github.com/Gracker/perfetto
普通试用只需要看主仓库。Gracker/perfetto 是 perfetto/ submodule 对应的前端 fork，主要给需要改 AI Assistant 插件 UI 的开发者使用。
前两篇技术文档更适合想看工程细节的读者：
- 从 Trace 到洞察：SmartPerfetto AI Agent 的 Harness Engineering 实战：SmartPerfetto AI Agent 的架构和 Harness Engineering 过程。
- SmartPerfetto 架构文章 Q&A：8 个深度技术手段问答：围绕 Agent、Workflow、YAML Skill 的问答。
前两篇把内部架构讲得比较细，但源码放出来以后，读者更关心的是仓库里到底有什么、能不能跑、哪些地方还没稳。这篇主要补开源这件事：开放了什么、当前能做什么、内部怎么分工、怎样在本地跑起来、哪些地方适合一起改。
开源的是什么
SmartPerfetto 开源的是从 UI 到分析规则的一整套工程。它保留 Perfetto 的时段线、SQL 和 trace 可视化能力，在 UI 里增加一个 AI Assistant 面板，再由 TypeScript 后端負责 Agent 编排、MCP 工具调用、Skill 执行、报告生成和 SSE 流式输出。
仓库里包含这些部分：
- Perfetto UI 插件和预构建前端：
perfetto/submodule 里集成com.smartperfetto.AIAssistant，仓库同时提交frontend/预构建产物，日常试用不需要重新编译 Perfetto UI。 - 后端 Agent 运行时：
backend/src/agentv3/下的场景路由、Prompt 构建、MCP Server、Verifier、Artifact Store、SSE Bridge。 - YAML Skill 平台：
backend/skills/下当前有 165 个*.skill.yaml，覆盖滑动、启动、ANR、内存、CPU、GPU、Binder、渲染管线等方向。 - 场景策略：
backend/strategies/下有 12 个.strategy.md，用于给不同议题注入不同分析步骤和输出约束。 - 工程脚本和文档：Docker Hub Compose、源码构建 Compose、
start.sh、前端插件打造脚本、MCP 工具参考、Skill 指南、技术架构文档、渲染管线参考文档。
这次开放的是全部工程。如果某个能力目前还不够好，那就是打造阶段的真实狀態。仓库外没有另一套私有核心实现。UI、后端运行时和 Skill 系统已经可用，公开 API 和内部协议还会继续调整。
为什么现在开源
Perfetto trace 分析很依赖样本。不同 Android 版本、不同厂商、不同渲染框架、不同业务场景，会让同一类卡顿呈现出不同数字形态。一个人或一个队伍很难覆盖这些分支。
SmartPerfetto 在开发里反复遇到的情况是：SQL 能查到事实，但事实不会自动变成结论。很多分析错误看起来像模型“不够聪明”，实际原因常常是 Skill 少了一條分支、某张表没覆盖、trace 样本太少、策略里默认了某种设备行为。
现在开源，是希望先把三类东西放出来，让它们接受真实 trace 的考验：
- 可运行的工具：让读者能在本地加载自己的 trace，验证 AI Assistant 对真实数字的处理方式。
- 可审查的规则：YAML Skill、场景策略和 MCP 工具都放在仓库里，结论背后的 SQL 和策略可以被检查、修改和复用。
- 可积累的样本：复杂性能状况需要 trace 样本和回归测试长期积累，开源仓库更适合长期儲存这些案例。
对 Android 性能工程师来说，一條能复现问题的 trace、一个更准的 Perfetto SQL、一个更可靠的 Skill 分支，或者一次指出错误归因的 hands-on，常常比大段功能代码更有用。
开发阶段开源的意义也在这里：SmartPerfetto 不需要等到每條分析路径都成熟后才接受外部反馈。越早接触真实设备、真实厂商差异和真实业务 trace，越容易把 Skill、策略和回归样本补到该补的位置。
它解决的是哪类问题
Perfetto 的数据很强，但分析 trace 的工作并不轻松。一个几十 MB 到几百 MB 的 trace 里可能有数百万條事件，线程、slice、counter、FrameTimeline、Binder、CPU 频率、SurfaceFlinger 合成狀態分散在不同表和 track 里。
最耗人的部分通常出现在中间：看到一帧超预算以后，要判断是主线程排队、RenderThread 忙、GPU 慢、SurfaceFlinger 合成卡住，还是 Binder、调度、IO 把前面的阶段拖慢了。
SmartPerfetto 把重复的统计结果收集和初步判断交给工具系统，把需要经验的归因留给 Agent 和工程师共同完成。
适合它处理的状况包括：
本文由News整理發布，僅供參考。
