Android 内部机制的资料，网上不缺。AOSP、官方文档、博客、论文、trace 讨论，想找都找得到。麻烦的是各说各的版本：这篇是 Android 12 的结论，那篇没写版本，再一篇是某台机器上的现象。
AIW 想补的就是这个缺口。全称 Android Internal Wiki，中文书名是《Android 技术内幕：系统机制、性能优化与工具实战》，五部分二十六章，正文钉在 Android 17。仓库准备开源：
https://github.com/Gracker/android-internals-wiki
打开仓库能拿到的是二十六章正文、一份完整目录，和每周编一次的 EPUB。
这二十六章现在到了可以拿出来给人读的程度。读到哪一段和源码对不上，欢迎提 issue 或者 PR。
本博客内容主要集中在 Android 开发和优化相关的话题，包括一些性能工具的使用、Android App 优化知识、Android Framework 知识讲解，性能理论知识讲解等，这里整理了一份目录供大家参考，大家可以挑感兴趣的部分来看。这里不仅仅包含博客中的内容，一些我在 知乎 或者 知识星球 - The Performance 的回答也会放到这里，不过这个目录里面放的都是我原创的博客，另外还收集了一些优秀文章，我也会不定期更新 Android 性能优化必知必会。
文章索引在前，工具、App 和内容项目集中在后面的个人项目。新增：AIW 开源介绍 · AIW GitHub 仓库。
这篇文章记录了 Android 性能优化所必须掌握的知识（主要是对应的优秀文章、公众号、博客、技术团队等），涵盖性能优化相关的方方面面。本文会持续更新，欢迎各位自荐或者推荐。
上一篇更新写到 2026 年 8 月 21 日的 v1.7.0。从 8 月 21 日的 v1.7.0 到 9 月 17 日的 v1.12.0，这 28 个日历日内，SmartPerfetto 发布了 9 个新版本，仓库合入 141 个非 merge 提交。
这段时间增加了任意双 Trace 工作台、无需预建索引的源码分析、Auto/Fast/Full 显式模式、跨会话调查检查点，以及贯穿 Web、CLI、报告和快照的结论核验。变化很多，但方向很集中：让一次分析从「模型给出答案」变成「请求、工具执行、证据、断言和最终交付都能核对」。
上一篇更新停在 2026 年 7 月 17 日的 v1.1.1。当时 SmartPerfetto 已经有双 Trace 工作台、Quick Mode、私有分析上下文、统一 Agent runtime，以及 Camera、Heap、GPU 等专项分析能力。
从 7 月 18 日到 8 月 21 日，仓库又向前走了五周，版本来到 v1.7.0。这一轮继续增加功能，也把更多精力放在知识来源、分发质量、权限隔离、结果完整性和可回滚改进上。
SmartPerfetto 正在从“能完成一次分析”走向“能在更多环境里稳定、可追溯地完成分析”。
本文以公开发布的 v1.7.0 代码为准，回顾 v1.1.1 之后加入的主要能力。
项目与上篇文章：
本文复盘 上一篇三周更新（2026-06-04，v1.0.28）之后，到 2026-07-17（v1.1.1）为止 SmartPerfetto 的全部主要改动。看完这篇文章，可以知道这六周每个功能解决什么问题、边界在哪里，以及当前版本的完整功能全景。项目地址：github.com/Gracker/SmartPerfetto。
5 月 17 日写上一篇 SmartPerfetto 更新时，重点已经从“Perfetto UI 里的 AI Assistant”转向“可复用的 Trace 分析平台”。到 6 月 4 日，新增内容主要集中在五块：Smart 模式、选区快问、CLI 采集、Power / ANR / Input / IO / Network 证据规则，以及四条 Agent runtime。
本文基于 2026 年 6 月 4 日的 SmartPerfetto 主分支状态，公开发布版本是 v1.0.28。读者看完应该能知道三件事：5 月 17 日之后新增了什么、现在的运行时和证据来源怎么处理、反馈问题时该给哪些信息。
项目地址：
4 月 29 日写 SmartPerfetto 开源介绍时，重点还是“在 Perfetto UI 里放一个能查 SQL、跑 Skill、生成报告的 AI Assistant”。两周后的仓库状态已经变了不少：功能从单条 trace 的问答，扩到了分析结果复用、多 trace 横向比较、Claude/OpenAI 双 runtime、SQL guardrail、证据来源索引、免安装包、渲染管线教学和更完整的 Provider 诊断。
本文基于 2026 年 5 月 17 日的 SmartPerfetto 当前仓库状态，补一篇新的功能说明。读者看完应该能知道三件事：这两周新增了什么、现在完整功能边界在哪里、报 bug 时该提供哪些信息。
项目地址：
这篇文章只做一件事：把我长期维护、正在推进、已经公开和暂未公开的项目集中到一个地方。范围包括 Android 性能分析、Perfetto 工具、AI 自动化、iOS App、Android Demo、测试套件、博客系列、社群和各个平台账号。
第一次来到这个博客，可以按需求直接跳转：学 Android 性能分析，看 Perfetto / Systrace 系列；找工具项目，看 SmartPerfetto、TraceFix、Android App Memory Analysis；了解 AI 如何参与知识管理和日常工作，看 OpenClaw 与 AI Field Notes；联系我或查看其它平台账号，看文末。
项目按四条线划：性能分析方向有 SmartPerfetto、Android App Memory Analysis、TraceFix、Perfetto Auto-Pin 这类工具，以及 High Performance Friends Circle 社群；AI 与自动化方向有 OpenClaw、AI Field Notes、Gracker Skills、Open Design；正在做的 App 包括 100Years、iBattery、Juju 三款 iOS 项目；内容项目则是博客和 Android Weekly 两处主阵地。下面每个项目都会注明状态：日常维护、近期重点、还是已经暂停。
按钮按下后，按压态何时出现？滑动列表时，内容何时第一次跟着手指移动？这两个问题都要找到输入事件和对应的第一帧反馈；启动总耗时与后续动画帧率回答的是别的问题。
本文用 Perfetto 把 InputReader 读到事件、InputDispatcher 派发、App 处理、帧提交和 SurfaceFlinger 呈现分开计时。每一步的起止点要能回到 Trace 核对。
从 InputReader 的 read_time 到关联帧 present，可以得到系统内部延迟的候选值 estimated_input_to_present_ms。只有确认目标 layer、业务状态确实在那一帧发生视觉变化，才把它写成 input_to_present_ms。这段时间不包含触控 IC、驱动上报前延迟、显示扫描和面板响应。
点击和滑动还需要不同的终点定义：按压态、转场首帧和内容第一次位移不能混成一个数。App marker 能说明业务动作，高速相机可补外部可见时点。
Camera 打开慢要区分 API 返回、HAL 首个 Buffer 和预览画面显示；Audio underrun 要看 App 写入与 mixer 周期是否稳定。这些事件分散在 App、系统服务、HAL 和调度轨道里，单列一张 Top slice 表还原不了顺序。
这里用 Camera 和 Audio 两个场景说明：先确认一次操作涉及哪些进程和线程，再按阶段或真实周期计算耗时，最后把异常时间点、来源轨道和质量限制写进报告。平台侧还要维护稳定的事件名和采集配置，下一次 Trace 才能复用查询。
FrameTimeline 标出一帧晚了，主线程和 RenderThread 没有明显长任务，下一步可以查 GPU 工作与 fence。GPU 频率、电池电流和电源轨只能提供同一窗口的硬件状态，不能单独证明某个 App 帧为何晚呈现。
这篇把 GPU render stages、devfreq、电池计数器和电源轨放到同一段 Trace 窗口里，说明各自能回答什么、设备不支持时报告该怎么写。帧和线程的判读可接着第 7 篇与第 8 篇的例子读。
Counter 名称、单位和采样周期由设备 producer 决定。跨设备比较前先核对 descriptor；同一设备上也要确认目标帧与 GPU 工作是否能通过 token、layer 或 fence 关联。
开机慢、亮屏后偶发卡顿或几小时后才出现的音频断续，通常等不到工程师连上电脑再按「开始录制」。要保留问题发生前的调度、帧或音频事件，采集配置必须提前在设备上运行。
现场抓取要先确定触发点前后各保留多久，再选 Ring Buffer、周期写文件或 trigger。文件写出后，还要确认问题窗口没有被覆盖、关键数据源没有丢失。设备开机属于更早的特殊窗口，单独处理。
dumpsys meminfo 显示进程内存上涨，Java heap dump 却没有对应的对象增长时，下一步先查上涨落在 Native Heap、图形 Buffer，还是其他映射。若可疑部分来自 malloc/new，heapprofd 可以把分配与调用栈对应起来。
heapprofd 的分配、释放和调用栈记录能与业务事件放在同一条 Perfetto 时间轴上，便于核对一次操作前后哪些分配仍未释放。
heapprofd 是采样工具，看到的 native allocation 不能直接当作 RSS，也不覆盖 Java 对象引用或所有图形 backing 内存。先分清内存账，再决定是否抓 profile。我更倾向先用 meminfo 和 smaps 把上涨来源拆开，再打开 flamegraph；若涨的是 GraphicBuffer，盯着 malloc 调用栈改代码就找错了方向。
系统 Trace 能显示线程、CPU、帧和 Binder 等系统事件；播放器的 frame id、游戏 scene 名称或业务队列里的等待时间，需要应用自己提供。缺少这些标记时，一段主线程耗时只能定位到系统活动，难以对应业务阶段。
Perfetto SDK 的 Track Event 可以记录解码、纹理上传、队列深度和跨线程任务 ID。与系统轨道放在同一个时间窗口后，能先找到业务候选阶段，再用 RenderThread、GPU 和 FrameTimeline 验证它是否影响了可见帧。
接入前要先定事件名称、参数单位和采样频率。否则埋点虽然能显示在 UI 中，后续 SQL 仍无法稳定地按业务阶段聚合。
