耗时大半年,开源一本 Android 电子书 :《Android 技术内幕:系统机制、性能优化与工具实战》
- 2026-10-02 05:46:58
AIW 想补的就是这个缺口。全称 Android Internal Wiki，中文书名是《Android 技术内幕：系统机制、性能优化与工具实战》，五部分二十六章，正文钉在 Android 17。仓库准备开源：
https://github.com/Gracker/android-internals-wiki
打开仓库能拿到的是二十六章正文、一份完整目录，和每周编一次的 EPUB。
这二十六章现在到了可以拿出来给人读的程度。读到哪一段和源码对不上，欢迎提 issue 或者 PR。
这本书想解决什么
做 Android 性能或者系统的人大概都遇到过：官方文档讲的是 API 和平台行为，博客讲的是某一次排查，源码解析贴的是一串调用关系。三种材料各有各的用处，但拼不出一条从应用代码追到内核、每一步还能回源码核对的完整路径。
每一章尽量回答四件事：这个机制为什么存在、现在怎么跑、用什么工具观察、结论在哪些版本和条件下成立。
读者主要是这三类人：
这本书不适合当入门课。Android 18 以后的结论书里也没有，正文停在 Android 17。
本书目录
全书五部分、二十六章，外加少量附录。完整目录在仓库的 src/SUMMARY.md。下面把每一章讲什么列出来，挑和自己相关的那几章看就行。
第一部分：Android 系统运行机制
系统怎么把应用跑起来，画面、输入、内存、调度和存储分别在哪一层等待。
fsync、块设备争用，以及共享存储上的 MediaProvider / FUSE。只看 Java 栈，容易把存储等待当成业务计算。第二部分：性能问题与优化
用户能感觉到的卡、慢、无响应、耗电和网络差，分别对应哪类系统行为。
netd。第三部分：性能工具与方法论
怎么采集证据、读懂工具，以及怎样把一次调查写到能复查。
第四部分：系统与厂商优化
平台和量产设备上还能改什么，以及不能把 AOSP 基线当成某台机器的行为。
第五部分：应用性能实践
应用团队能改的启动、渲染、内存、I/O、功耗和线上观测。
附录目前保留一份性能分析 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
材料是从哪儿来的
书里的判断，依据来自这几处：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：
i18n/TRANSLATION-PLAN.md，想参与的可以先在 Issue 里认领章节。合并的 PR 会记进 README 的贡献者名单和书的致谢章节。Issue 和 PR 按章节优先级分档 review，核心章节最快、附录最慢，具体时限写在 CONTRIBUTING.md。
最快能动手的纠错一般带着版本和路径，比如「Android 17 上 InputDispatcher 这条路径和正文不一致，AOSP 路径是 frameworks/native/...，我在某某版本上看到的行为是……」。像「这一章太浅了」这种，我定位不到要改哪一句，只能再回过去问一轮。
提 issue 或 PR 时，下面这些信息会让处理快很多：
厂商定制的现象和 AOSP 通用行为在书里是分开的，第四部分专门讲厂商差异，条件写在那一章前面。
仓库和电子书获取
GitHub 下载不方便的话，网盘上也放了一份，后续版本同步更新。关注公众号 Android Performance，回复「电子书」「书」「AIW」或「Android Internals Wiki」任意一个，就能拿到链接。
许可分两条线：社区使用走 CC BY-NC-SA 4.0，商业使用要另外拿书面授权。下载仓库或电子书，不等于获得商业授权。引用的 AOSP 代码仍按 Apache License 2.0。
如果这本书对你有用，给仓库点个 star。点的人多了，更多做 Android 的人能刷到它，想纠错、想补材料的人也知道该去哪儿找。
书会继续更新，结论也可能被后来的版本推翻。读到哪一段和源码对不上，开个 issue，把 Android 版本和源码路径写上就够了。
