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 read_time 起算，到 App 收到事件，再到第一帧 present。主指标叫 input_to_present_ms，只度量 input read 到关联帧 present；它不覆盖触控 IC、驱动上报前延迟、显示扫描和面板响应。读完之后，你应该能给一个点击或滑动场景定义起点、终点、采集配置、SQL 指标和 App 侧补充 marker。
文章把响应慢拆成 read/dispatch、handling、ACK→first frame、滑动跟手四个独立指标，每个指标都配上采集配置、UI 上先看哪几条轨道和 SQL 写法，最后归纳五条常见归因路径，以及高速相机和 Perfetto 各自的边界。
Camera open 慢、Audio underrun、WebView 首屏卡住、Flutter/游戏掉帧，这类问题的证据会散在 App、system_server、cameraserver/audioserver、HAL、SurfaceFlinger 和调度轨道里。只在 UI 里多看几条轨道，很容易漏掉关键时间点。
这一篇用 Camera 和 Audio 举例，讲一套可复用的专项分析方法：先抓对数据，再识别对象，再算阶段和阻塞，报告里保留能跳回 UI 复查的时间点。Camera/Audio 是例子，核心是领域 schema 和平台 tracing 协作。读完之后，至少能把 Camera open 慢拆成可复查阶段，把 Audio underrun 拆成周期异常，而不是只交一个 Top slice 表。
FrameTimeline 标出一帧晚了，主线程、RenderThread、SurfaceFlinger 看起来都没有明显越界，这时很容易写出一句“可能是 GPU 瓶颈”。这句话风险很高：GPU 频率、GPU 计数器、电池电流、电源轨都不是 App 单帧归因工具。
第 07、08 篇已经讲了 App 到 SurfaceFlinger 的渲染路径，第 06、09 篇已经讲了刷新率和 CPU 调度/频率。这一篇不重复这些内容，只补一个经常被跳过的环节：当问题看起来已经压到硬件资源层时，GPU、devfreq、battery counter（电池计数器）、power rail（电源轨）这些数据该怎么进入同一段 trace 分析。
这类 counter 的麻烦在于：不是每台设备都有，不同 GPU 厂商的 counter 名称也不一样。写结论时不能说“GPU 高就是 GPU 瓶颈”，只能把 FrameTimeline、RenderThread、SurfaceFlinger、GPU timeline、频率和功耗数据放到同一段时间里看。
很多性能问题不是点一下就能复现的。开机慢、偶发卡顿、亮灭屏后异常、几小时后音频断续、车机周期性抖动、温升后的性能下降，都不适合靠 10 秒手工 trace 解决。
这一篇讲现场长 Trace：怎么提前定义窗口，怎么用 trigger 封存问题现场，怎么让文件安全写完，怎么拿回来之后判断数据是否可信。Boot Trace 放在后面作为特殊窗口处理。基础的交互式抓取方式（命令行、官方脚本、开发者选项、网页端）第 02 篇已经讲过，本文只讨论现场和长时间运行带来的差异。
内存问题最麻烦的地方在于：数字涨了，不代表马上能知道谁在涨。dumpsys meminfo 能告诉你 RSS/PSS，Java heap dump 能告诉你对象保留关系，但 JNI/C++、Skia/Bitmap 的 CPU 侧分配、播放器里的 native wrapper 这些问题，经常还需要知道“哪个调用栈发起了 malloc/new”。
这一篇讲 heapprofd。它的价值是把 native allocation、free 和调用栈放进 Perfetto Trace，再和业务事件、线程调度、Binder 放到同一个时间轴里看。
heapprofd 适合放在趋势确认之后。先用 RSS/PSS、meminfo 或线上监控确认趋势，再用 heapprofd 找 malloc/new 调用栈；这篇不解决 Java 对象引用和图形 backing 内存。
下文的顺序是：什么时候上 heapprofd、怎么抓、UI 和 SQL 怎么读、采样间隔和符号化怎么理解，最后是发布报告前的检查清单。
系统 Trace 能告诉你线程什么时候运行、CPU 跑在哪个核、FrameTimeline 哪一帧超时；在启用 Binder/ftrace/sched 证据时，也能还原 Binder 调用和等待线索。但它不知道播放器正在解哪一个 frame id，也不知道游戏引擎正在加载哪个 scene，更不知道一个业务任务在队列里排了多久。
这一篇只回答一个问题：业务语义怎么进入 Trace。系统能告诉你主线程慢了，Track Event 负责告诉你当时在 decode 哪一帧、哪个队列堵住、哪个请求跨线程流转。两边合在一起，才能把“主线程慢了 18ms”缩小到 frame 1082 附近的纹理上传候选区间，再结合 RenderThread/HWUI、GPU 和 FrameTimeline 继续验证。
文章按接入的实际顺序展开：先想清楚要不要接、接到哪一层，再定业务阶段字典和 backend，然后是最小接入骨架、category 开关、和系统 Trace 合抓、跨线程 flow，最后是控制写入量和 App 侧现场 Trace 协议。
