词元星图TokenAtlas
返回案例库

精选案例 · Agent / 实践案例

潘智勇 — AI 辅助 eBPF + Perfetto 系统追踪工具开发

这个案例围绕「潘智勇 — AI 辅助 eBPF + Perfetto 系统追踪工具开发」记录了一条真实 AI 实践线索，正文重点集中在「项目：TracePilot — Frame-Centric 调度观测系统」「相关 AI 工具」，适合先按任务意图阅读再判断复用。

案例速读

README 标题「潘智勇 — AI 辅助 eBPF + Perfetto 系统追踪工具开发」下已经出现运行/配置路径、脚本或接口线索、结果证据，正文重点集中在「项目：TracePilot — Frame-Centric 调度观测系统」「相关 AI 工具」，比纯概念介绍更适合进入精选阅读流。 这篇案例的阅读价值在于，它把真实任务、模型辅助过程和可迁移做法放在同一个上下文里，读者可以从 「潘智勇 — AI 辅助 eBPF + Perfetto 系统追踪工具开发」、「项目：TracePilot — Frame-Centric 调度观测系统」、「相关 AI 工具」、「开发过程」 进入正文。

  • 建议重点看 可参考其中的运行与配置路径、包含可迁移的命令、脚本或接口线索、已有结果或观测证据可用于判断复用价值。结合 Agent / 实践案例 和「任务驱动用户、AI 实践者」这一受众定位，它更适合作为任务检索后的精读材料，而不是只看一句短摘要后快速跳过。
  • 正文目录和原始材料仍然是判断依据；导读只帮助你更快定位阅读重点。
看点
潘智勇 — AI 辅助 eBPF + Perfetto 系统追踪工具开发
读者
任务驱动用户、AI 实践者
复用
可参考其中的运行与配置路径
结构
10 个目录入口

原文内容

潘智勇 — AI 辅助 eBPF + Perfetto 系统追踪工具开发

项目：TracePilot — Frame-Centric 调度观测系统

TracePilot 是一个基于 eBPF + Perfetto 的 Android App 卡顿根因定位工具，整体开发过程大量使用 AI 辅助。

背景：Android App 页面切换时出现卡顿（jank），传统 perf/systrace 只能看到哪个线程运行时间长，无法精确归因——是调度延迟、中断抢占、还是应用自身逻辑问题？需要一套以帧为窗口、融合内核调度事件和系统事件的观测工具。

相关 AI 工具

  • Claude Code / opencode — 核心开发工具，负责代码生成、Bug 修复、架构重构
  • DeepSeek-V4 / Qwen — 辅助代码理解与调试

开发过程

1. eBPF 内核态程序

使用 AI 编写了 6 个 raw_tp 类型的 eBPF hook：

  • sched_switch / sched_wakeup：追踪任务调度与唤醒
  • irq_entry / irq_exit：追踪硬中断
  • softirq_entry / softirq_exit：追踪软中断

关键决策：使用 raw_tp 而非 tp_btf，避免对 vmlinux.h 中 trace_event_raw_* 结构体完整定义的依赖，提升跨内核版本兼容性。

2. 用户态 Loader

AI 协助用原生 libbpf API（bpf_object__open_file() 等）替代 bpftool skeleton，解决 WSL 环境下 skeleton 生成失败的问题。实现双 ring buffer（sched 16MB + sys 4MB）并行事件采集。

3. 评分模型设计

设计了综合评分公式，融合帧参与度、可运行延迟（runnable_delay_p95）、唤醒延迟（wakeup_latency_p95）和系统开销折扣。其中 runnable_delay 从最初硬编码 1ms 优化为 BPF 侧 preempt_times 追踪实际抢占→重新调度的真实延迟。

4. AI 辅助 Bug 修复

项目中共计修复 15+ 个 Bug，典型场景：

  • jank_frame_count 从未递增：AI 分析代码后发现缺少去重逻辑，添加 last_jank_token 机制
  • 系统事件聚合顺序导致折扣失效：AI 建议先聚合 sys events 再聚合 sched events
  • strstr 子串匹配误判包名：AI 建议改为精确 strcmp

5. 完整工具链编译

AI 协助编写 Makefile，涵盖三种编译目标：

  • make bpf：clang -target bpf 编译内核态
  • make loader：gcc + libbpf 编译宿主机 x86_64
  • make android：NDK r26b 交叉编译 aarch64 静态二进制

心得

  1. AI 擅长技术细节，人做架构决策 — 如选择 raw_tp vs tp_btf、评分公式权重分配，这些需要领域经验；代码实现细节交给 AI
  2. 迭代式修 Bug 效率极高 — 把错误现象、日志丢给 AI，它能快速定位根因并给出修复
  3. 低层次语言也能用好 AI — eBPF/C 这类底层编程，AI 对内核 API、内存模型的理解往往比开发者更全面
  4. 交叉编译等繁琐配置适合 AI — NDK 路径、链接依赖等机械操作交给 AI，避免人工拼写错误
  5. 需求描述质量决定输出质量 — 给出明确的架构图和数据结构定义，AI 生成的代码几乎可直接使用
返回顶部