耗时大半年，开源一本 Android 电子书《Android 技术内幕：系统机制、性能优化与工具实战》

Android Android Performance AOSP Framework AIW Open Source

Word count: 4.3kReading time: 15 min

 2026/09/19

Android 内部机制的资料，网上不缺。AOSP、官方文档、博客、论文、trace 讨论，想找都找得到。麻烦的是各说各的版本：这篇是 Android 12 的结论，那篇没写版本，再一篇是某台机器上的现象。

AIW 想补的就是这个缺口。全称 Android Internal Wiki，中文书名是《Android 技术内幕：系统机制、性能优化与工具实战》，五部分二十六章，正文钉在 Android 17。仓库准备开源：

https://github.com/Gracker/android-internals-wiki

打开仓库能拿到的是二十六章正文、一份完整目录，和每周编一次的 EPUB。

这二十六章现在到了可以拿出来给人读的程度。读到哪一段和源码对不上，欢迎提 issue 或者 PR。

这本书想解决什么

做 Android 性能或者系统的人大概都遇到过：官方文档讲的是 API 和平台行为，博客讲的是某一次排查，源码解析贴的是一串调用关系。三种材料各有各的用处，但拼不出一条从应用代码追到内核、每一步还能回源码核对的完整路径。

每一章尽量回答四件事：这个机制为什么存在、现在怎么跑、用什么工具观察、结论在哪些版本和条件下成立。

读者主要是这三类人：

应用工程师：启动慢、滑动卡、ANR、内存抖动、功耗异常，想从应用层追到系统层原因。
系统工程师：需要把 Framework、Native、HAL、Kernel 放在同一个视角里看。
性能工程师：需要一套稳定的知识框架，用来读 trace、判断瓶颈、解释优化收益和风险。

这本书不适合当入门课。Android 18 以后的结论书里也没有，正文停在 Android 17。

AIW 要做的是一套对照源码的中文整理

现在写到哪了

全书五部分、二十六章，外加少量附录。完整目录在仓库的 src/SUMMARY.md。下面把每一章讲什么列出来，挑和自己相关的那几章看就行。

第一部分：Android 系统运行机制

系统怎么把应用跑起来，画面、输入、内存、调度和存储分别在哪一层等待。

第 1 章系统架构全景：进程模型、Zygote、Binder、cgroup 和系统服务边界。慢启动、ANR 或 native 崩溃时，先确认代码跑在哪个进程、跨过哪条 IPC。
第 2 章渲染系统：从主线程、RenderThread、BufferQueue、SurfaceFlinger 到 HWC 和面板。掉帧、首帧晚、SurfaceView 错位，要先分清帧走哪条生产和合成路径。
第 3 章输入系统：点击无响应、滑动不跟手、返回动画晚一拍。帧率正常也不能证明输入及时到达应用，要把事件和产生反馈的那一帧放在同一条时间线上。
第 4 章内存管理：GC、缺页、direct reclaim、zram、进程冻结和图形缓冲。OOM 只是其中一种结局，内存压力也会变成卡顿和后台重建。
第 5 章 CPU 调度与能耗管理：可运行却排队、大小核放置、DVFS、温控和后台执行政策。只看 CPU 使用率分不清这些原因。
第 6 章存储与 I/O：page fault、fsync、块设备争用，以及共享存储上的 MediaProvider / FUSE。只看 Java 栈，容易把存储等待当成业务计算。

第二部分：性能问题与优化

用户能感觉到的卡、慢、无响应、耗电和网络差，分别对应哪类系统行为。

第 7 章流畅性：掉帧、输入延迟、合成降级和温控限制。相似的「卡」背后，要改的位置可能完全不同。
第 8 章响应速度：从操作到可见反馈或恢复可交互的时间。和流畅性分开：一个看首响，一个看连续帧间隔。
第 9 章 ANR：系统判定应用没有在时限内完成输入、广播或服务回调。机制、Kernel Trace 联合诊断和典型路径。
第 10 章内存性能：从应用性能视角看 OOM、频繁 GC、换页和图形内存。先分清增长发生在哪类内存、谁持有、怎样变成可感知延迟。
第 11 章功耗：功耗速率和一段时间的耗电量。WakeLock、蓝牙扫描、后台执行和用户设置，时间窗口通常比卡顿更长。
第 12 章网络性能：请求进入网络栈之后的排队、DNS、连接复用、TLS 和 netd。
第 13 章渲染管线专题：View、SurfaceView、Vulkan、Compose、Flutter、WebView、Camera、视频 Overlay、游戏引擎和 XR。先确认谁生产 buffer、写入哪个 Surface、合成发生在哪一层。

第三部分：性能工具与方法论

怎么采集证据、读懂工具，以及怎样把一次调查写到能复查。

第 14 章 Perfetto：把渲染、输入、调度、Binder、I/O 和功耗放到同一条时间轴。目标是采到够用的数据，读懂 track / slice，并写成可复核的 SQL。
第 15 章其他分析工具：Android Studio Profiler、simpleperf、HPROF、dumpsys、Battery Historian、GPU capture、Winscope 和 eBPF。Perfetto 覆盖不了的证据形态在这里。
第 16 章方法论：现象怎么定义，现有证据能证明什么，App、系统和测试环境各影响哪一段，修复后怎么验证。
第 17 章 APM 工具与性能监控生态：Firebase、Matrix、KOOM、LeakCanary、Benchmark 和崩溃 / ANR / 耗电采集机制。面向选型和实现，不替代第 14 到 16 章的线下分析。

第四部分：系统与厂商优化

平台和量产设备上还能改什么，以及不能把 AOSP 基线当成某台机器的行为。

第 18 章 AOSP 性能优化：系统服务、编译调试、Kernel 6.18、AutoFDO、Profile 安装编译和开机耗时。面向可以改系统代码的人。
第 19 章 OEM 与设备差异：Power HAL、SoC、游戏模式、Media Performance Class，以及 Private Space、车机等产品形态。量产设备会叠加内核、固件和散热差异。

第五部分：应用性能实践

应用团队能改的启动、渲染、内存、I/O、功耗和线上观测。

第 20 章应用稳定性治理：Java / Native Crash、ANR、OOM、FD 和线程泄漏。保留能确定责任模块的日志、堆栈和版本信息。
第 21 章启动优化：进程创建、初始化、首帧和后台任务。冷 / 温 / 热启动、页面可见和业务可用要分开计时。
第 22 章渲染优化实战：布局、列表、Compose、动画、图片、WebView、CameraX 和 Media3。改动要放进当前刷新周期的帧预算里验证。
第 23 章内存实践：Java Heap、泄漏、Native Heap、Bitmap 和端侧大模型预算。对象泄漏、分配过快和图形缓冲堆积，处理方式不一样。
第 24 章 I/O 与网络优化：文件、数据库、序列化、连接和缓存。把主线程阻塞、系统调用、协议往返和失败重试分开量，不要都写成「接口慢」。
第 25 章功耗与包体积优化：后台任务、定位、音频、ADPF、热节流，以及 DEX / SO / 资源体积。同一设备和同一测试条件下比较改动前后。
第 26 章应用可观测性：崩溃上报、性能采集、线上排查和发布质量门禁。第 17 章讲 APM 怎么实现，这一章讲应用团队怎么把证据用起来。

附录目前保留一份性能分析 Checklist。

书里的结论覆盖到 Android 17 / API 37，对应 AOSP android-17.0.0_r1 这个公开标签。再往上的不在正文里：预览版 API 和尚未合入的平台行为，最多写成「尚未作为本书结论」。

版本上仍标 alpha：目录还会调整，发现的错还会继续改，英文版要等 v1.0 之后。

每周会把正文编成 EPUB，放到 GitHub Releases，只保留章节正文，去掉 YAML 标签和导航页。

https://github.com/Gracker/android-internals-wiki/releases

五部分二十六章，当前基准钉在 Android 17

材料是从哪儿来的

书里的判断，依据来自这几处：AOSP 源码、官方文档、可复现实验，以及已经公开的工程讨论。

日常进来的材料大致有这几类：

长期收藏的技术文章和笔记
RSS、掘金 Android、公开的技术讨论
论文和针对单一主题的调研
Android Weekly 一类的链接扫描
围绕具体章节去读的 AOSP 与工具文档

资料多不等于能用。过时的结论、没写版本条件的经验，还有跟目标章节对不上的，都进不了正文。

材料进正文的方式是提取事实、用自己的结构重写、标上原始出处，不整段搬运。AOSP 源码遵循 Apache License 2.0；他人内容只用于技术说明。属于我个人判断的地方，会把条件和边界一起写出来。

材料只认公开依据，写进章节时提取事实、标注出处，不搬运原文

一章是怎么写出来的

8327 次提交里，写初稿的只有 467 次，剩下四千九百多次是审稿、回炉和抽检。写一稿，平均要过十次审和改。

早期这套东西跑在 OpenClaw 上，一批定时任务每天收材料、归类、写初稿、做检查。任务多、频率高，产能上来了，问题也上来了：几条任务可能同时改同一章，状态文件互相覆盖，提交记录看不清这一次到底改了什么。后来迁到 Hermes Agent，高频并行写稿停掉，改成一次只处理一章——收集和归类还是脚本每天跑，写作、技术审稿、中文复审、抽检、回炉排成几条串行车道。

现在一节正文要走完的路大概是这样。初稿写完，先过一轮深度技术审稿，按六个维度分开打分、分开记问题：文里的类名和路径在核对的那个标签里存不存在、机制讲通了还是只摆了个结论、哪几个版本变过、读者读完会卡在哪、数字有没有单位和基线、和别的章节说的是不是同一件事。问题分三级，P0 是事实错误，P1 是重要缺失，P2 是建议改进。P0 不清掉，这一节回不到定稿。定稿也不算完：闲时抽检每四小时一轮，随机拎一篇已经定稿的重看，有问题就降回去重修。

这些审稿累计记下了 1894 个 P0。挡下来的主要是三类：引用了已经被移除或者根本不存在的类和路径；把示意性的代码标成真实源码；用旧版本才成立的前提去解释当前行为。三类有个共同点——单看句子读不出毛病，得回到源码和版本上才判断得了。

模型不会在没把握的地方放慢语速，它把不确定的事和确定的事说得一样顺。所以写稿和审稿不用同一个模型：中文复审走 DeepSeek，技术侧另外跑了 862 篇外部 review。

核对结果记在每篇正文的头部：last_verified_against 说这一节对着哪份源码快照核过，sources 说依据从哪儿来——314 篇里 283 篇填了前者，281 篇填了后者。这些字段的用处是定位：真写错了，能查到是哪一节、对着哪个标签核的、依据是哪条。

AI 干的是收集、初稿、格式检查、回炉这类能重复的活。往哪写、留什么删什么、最后出了错谁负责，还是人的事。定稿只说明当前版本过了检查，后面照样可以被推翻。

从密集定时任务改成一次只改一章

当前的边界

书里逐节记了把握度，其中 122 节还没到能拍胸脯的程度，多半卡在同一类原因：缺实测数据、缺真机复现，或者厂商侧的行为拿不到公开依据。

最薄的一块是数据。机制怎么跑写得比较细，但不少地方给不出量化：某个阶段实际耗时多少、某条路径比另一条贵多少，书里只能给方向，给不出实测数字。这类缺口靠读源码补不上，要靠真机实测。全书的机制部分比数字部分扎实，这个差距现在还在。

还有一条和查证有关：来源是按节列的，不是按句标的。想追某一句话的出处，得自己翻这一节的来源列表，书里没有逐句挂标注。

开源协作流程

前面那套审稿流程能挡住大部分事实错误，挡不住全部。Android 这么大一个系统，二十六章跨 App、Framework、Native 和 Kernel，总有我没跑过的设备、没见过的厂商改动。开源之后，这些地方可以被手上有真机、踩过真坑的人再核一遍。

社区可以从四个方向参与，细节在 CONTRIBUTING.md：

纠错：事实错误、过时描述、坏掉的链接、不准确的类名和方法。欢迎直接提 PR，不用先开 Issue。
补材料：高质量文章、trace 案例、源码分析、官方文档或论文。附上它该进入哪一章、能支持哪句判断，比贴原文更有用。
新章节或大改：先开 Issue 讨论。当前的重点是精修已有二十六章，目录暂时不往外扩。
翻译：英文版在 v1.0 之后启动，计划写在 i18n/TRANSLATION-PLAN.md，想参与的可以先在 Issue 里认领章节。

合并的 PR 会记进 README 的贡献者名单和书的致谢章节。Issue 和 PR 按章节优先级分档 review，核心章节最快、附录最慢，具体时限写在 CONTRIBUTING.md。

最快能动手的纠错一般带着版本和路径，比如「Android 17 上 InputDispatcher 这条路径和正文不一致，AOSP 路径是 frameworks/native/...，我在某某版本上看到的行为是……」。像「这一章太浅了」这种，我定位不到要改哪一句，只能再回过去问一轮。

提 issue 或 PR 时，下面这些信息会让处理快很多：

Android 版本，最好能对上 AOSP 标签
源码路径或官方文档 URL
期望行为、实际行为
如有条件，附上 Perfetto / dumpsys / logcat 里能复核的观察点

厂商定制的现象和 AOSP 通用行为在书里是分开的，第四部分专门讲厂商差异，条件写在那一章前面。

Android 性能分析生态

Android Performance Ecosystem 通过导航 Hub 与七个核心项目，把可选插桩、采集、分析、系统知识与可复现案例连接成一套完整路径。

阶段	项目	作用	地址
导航	Android Performance Ecosystem	维护统一项目地图、交接元数据、README 导航区块与漂移检查。	GitHub
插桩	TraceFix	在编译期注入 App 侧 android.os.Trace section，让方法执行在运行时 Trace 中可见。	GitHub
采集与测量	Perfetto Tools	抓取可复现的 Perfetto Trace，并采集 FPS 或 Simpleperf 测量结果。	GitHub
分析	SmartPerfetto	通过 AI 辅助 Web UI、CLI、报告、会话、对比和证据工作流分析 Trace。	GitHub
Agent 分析	Perfetto Skills	为 Agent 提供可移植的 Android、Linux、Chromium Perfetto 分析 Skill，并通过固定版本流程同步选定资产。	GitHub
学习	Android Performance Blog	通过文章、系统原理和案例复盘讲解 Perfetto 与 Systrace 分析。	AndroidPerformance.com · GitHub
系统知识	Android Internal Wiki（AIW）	处于 alpha 阶段的 Android 系统知识库，覆盖 App、Framework、Native 与 Kernel 机制。	GitHub
复现	Trace for Blog (SystraceForBlog)	提供文章使用的 Perfetto、Systrace 及相关案例文件，支持动手复现。	GitHub

查机制可以从 AIW 和博客入手；需要动手验证时，到 SystraceForBlog 找案例，或用 Perfetto Tools 抓取自己的 Trace。分析可以选择 SmartPerfetto 的 Web UI、CLI，也可以让已有 Agent 使用 Perfetto Skills。只有需要补充 App 侧方法轨道时，才需要接入 TraceFix。各项目独立使用、独立发布。

更多文章和个人项目见博客文章目录 + 个人项目。