This is the historical English version of Yingyun’s article. See the Chinese original or the English-site version.
I am starting a series about the decisions involved in OS architecture. The same questions arise when designing other large software systems too.
My knowledge and experience have limits, and these views are subjective. There will be gaps. I would like to hear other views and see what I have missed.
2022.3.25 ，周五晚上九点，The Performance 知识星球(付费版本)举办了第一次线上茶话会，3 位星球主理人 + 5 位星球嘉宾，50 多位球友参加，非常感谢各位！
第一次茶话会没有预设主题，预计 1 个小时就可以结束，结果聊了 2 个半小时，光是主理人和嘉宾的个人介绍就花了一个小时。平时大家在群里和星球里交流很多，但是通过语音在线交流还是第一次，再者大家的公司基本上涵盖了 Android 上下游：既有 App 大厂的大佬，也有一线手机厂商的系统大咖，也有芯片公司和造车新势力的资深专家。所以在每个人自我介绍的时候，会聊一些公司相关的东西，再发散一下，其他人再问一些问题，时间就过去了。
当时我们还计划不定期举办星球茶话会，把主题定得更明确，也邀请更多嘉宾一起聊，不局限于技术。考虑到隐私问题，这次没有录屏；下面的文字稿根据聊天内容部分还原，不涉及各位的隐私。
Android 12 源码于 2021 年发布，我当时用来折腾的测试机是 Pixel 3 XL。本文保留那次实操记录，并将可复现的发布版示例固定为 android-12.0.0_r3。版本对应关系以 AOSP tags/build numbers 为准。
本文介绍这条历史分支的下载、编译和刷机。本地编译便于查看/修改系统源码、增加调试信息，主要用途如下：
本文参考了目前大部分 Android 应用启动优化的方案，将大家的方案做一个汇总，如果你有这方面的需求，只需要对照这篇文章，看看其他人的方案，查漏补缺。很多方案是要根据具体的业务去做优化的，所以这里也没有对每一种方案进行详细的介绍，要用到哪一个方案的时候，可以具体去网上查找对应方案的具体实现方法，这里只是做一个汇总
另外我还加上了部分系统厂商所做的启动相关的优化，不过只写了一些我知道的，还有一些厂商有黑科技，就不在这里的讨论范围了。知道厂商做的事情，可能也会帮助到你，比如联系厂商做白名单、接入厂商 SDK 等
在Android 中的卡顿丢帧原因概述 - 系统篇 这篇文章中, 实际案例这里我们有列举一些由于系统低内存导致的卡顿, 由于 Android 低内存对整机性能影响比较大, 所以单独写一篇文章, 来概述系统低内存对整机性能的影响 .
随着 Android 系统版本的更迭, 以及 App 的代码膨胀, Android 系统对内存的需求越来越大, 在写作当年的 2019 年，市面上还存在着大量 4GB 内存及以下的机器, 这部分用户就很容易遇到整机低内存的情况, 尤其是在系统大版本更新、同时运行的应用和服务增多的情况下 .
Android 内存压力可能导致性能问题, 具体表现就是响应慢和卡顿 . 比如启动一个应用要花比平时更长的时间 ; 滑动列表会掉更多帧 ; 后台的进程减少导致冷启动变多 ; 额外回收和重启工作也可能增加功耗，但发热本身不能证明低内存, 下面我会概述发生这些性能问题的原因 . Debug 的方法, 以及可能的优化措施 .
2018 年初写了一篇<2017 年度最推荐-给辛勤工作的自己一点奖励>, 最近有人问我今年是否会有 2018 年的年度推荐，我想了想，2018 年虽然不景气，但是还是有一些好东西可以推荐给大家，于是便有了这一篇文章。
跟 2017年一样，我会把 2018 年里面我觉得体验很棒或者对工作生活很有帮助的东西推荐给大家，或许 2019 你会需要他们。推荐的内容包含了 App、硬件、书籍、博客、专栏等，希望能帮助到看到这篇文章的你
历史推荐（2026-10 核查）：本文记录 2018 年的使用体验，书目、评分、价格、课程海报和购买建议均保留当年语境。软件支持范围与会员权益的变化在下文补充；旧二维码不作为当前报名入口。
本文是 MAT 工具使用系列的第三篇，这个系列共三篇，详细介绍了如何使用 MAT 来分析内存问题，既可以是 Java 应用的内存问题，也可以是 Android 应用的内存问题：
技术复核（2026-10-13）：这是依赖旧 Bitmap 实现的历史技巧，保留原截图。下文以 AOSP android-4.4.4_r2 核对
mBuffer，以 Android 8.0 / API 26 说明 native 像素的变化，并补充 GIMP 3.2.6 导入参数及现代调试入口。
在 MAT 里查图片相关的内存问题时，如果能知道“到底是哪张图”，排查起来会方便很多。这里的“原图”指 Bitmap 在运行时保存的像素，不能恢复下载前的 JPEG/PNG 文件、压缩参数或 EXIF。MAT 能帮我们找到是谁留着这个对象，再把图像和业务场景对应起来；单凭一个 Bitmap 很大，还不能判断它泄漏了。
本文介绍从旧 heap dump 导出像素的步骤。前提是快照确实包含像素数组；只有 Java 包装对象和 native 地址时，不能从不存在的数据还原图片。
技术复核（2026-10-13）：这是一篇 Nexus 5 / Android Lollipop 的历史教程，设备与工具链已过期。文中的 LRX22C 二进制对应 **Android 5.0.1 / AOSP
android-5.0.1_r1**，下文据此明确源码、驱动和刷机条件。新学习环境另补 Android 16 Cuttlefish 示例；不要把新版本的构建命令与旧真机固件混用。
接前一篇文章使用Android Studio查看Android Lollipop源码, 我们知道,仅仅看代码,提高是比较有限的,而且理解起来也比较肤浅,往往过目就忘. 而自己写过的代码,往往会印象比较深刻,在写的时候也会比较容易理解流程. 所以我们在看代码的同时, 如果能修改代码, 在手机上跑起来并看到修改的效果,这无疑会加快看代码的效率和积极性. 所以这篇文章,就讲解一下如何自己编译AndroidL的源码,并且在Nexus5上跑起来. 至于为何需要自己编译固件，而不是直接安装 Google 给出的工厂固件？这里的目的是获得便于平台调试的 userdebug 构建。user 版本限制 ADB root 等调试能力；userdebug 支持更多调试操作，但并不等于任意分区都能不受限制地写入。
本文假设你已准备好版本一致的 Lollipop 源码和一台 Nexus 5。环境可参考 旧版本 AOSP 构建说明和源码下载说明。Android 5.x 在 Linux 上使用 OpenJDK 7；旧系统与依赖应放在专门的历史构建环境中，不能直接作为当前开发机的安装建议。如果访问官方文档或下载源码不顺畅，需要先处理网络与源码获取环境。
AOSP 是 Android Open Source Project，即 Android 开源项目。它包含平台和开源应用，不包含 Google Mobile Services（GMS）这组专有应用与服务。厂商二进制、GMS 授权和 Android 兼容性是不同问题：满足 CDD 并通过 CTS 是兼容性要求，不等于自动获得 GMS。具体要求可以参见 Android 兼容性说明。
技术复核（2026-10-13）：本文原写于 2015 年。Systrace 的事件时间线仍有参考价值，Eclipse / Device Monitor 入口已过期；旧脚本参数以下文核对的 AOSP
android-5.0.0_r1为准。新增命令以 Android 11 / API 30 及以上的 Perfetto 为例，旧系统差异另列。后续文章见 Android Perfetto 系列目录。
| 旧流程 | 现在的对应方式 |
|---|---|
| Eclipse / Device Monitor 的 Systrace 按钮 | Android 9 / API 28 起可用设备端 System Tracing；也可通过 ADB 采集 |
systrace.py 调用 atrace 并生成 HTML |
Perfetto 采集命令生成二进制 trace；具体事件由类别或配置文件决定 |
| 浏览器直接打开旧 HTML | 使用 Perfetto UI 导入 trace，也可用 Trace Processor 做 SQL 分析 |
| 把 user 构建理解为不能采集 | user 构建可以采集系统 trace；可见数据取决于系统、数据源、应用配置与厂商策略 |
本文是Android性能优化工具系列的第一篇，这个系列主要介绍Android性能优化过程中会使用到的一些工具，以及如何用这些工具来发现问题和解决问题。在性能优化方面，Android有不少性能工具供大家来使用，按照我们一贯地 “发现问题-解决问题”的思路来看，发现问题才是最主要的，一上来就想着如何去解决问题，反而会事倍功半。
这一篇先来简单介绍一下Systrace这个工具。
Systrace 随 Android 4.1 / SDK Tools R20 推出，是系统事件跟踪与可视化工具。它把 CPU 调度、SurfaceFlinger、WindowManager、View 等已启用的事件放到同一条时间线上，帮助开发者寻找系统行为之间的关系。它不会自动采样每一个 Java 方法，也不等于完整调用栈分析器。当年的 SDK Tools R20 公告
旧流程主要由三部分组成：
atrace 配置类别并读取跟踪数据。应用添加自己的区间可使用 android.os.Trace.beginSection() / endSection()；这组公开 API 从 Android 4.3 / API 18 才提供，不是从 Android 4.1 就能直接调用。systrace.py 通过 ADB 调用设备的 atrace，处理数据并生成带查看器的 HTML。采集已有系统事件不要求先修改应用代码；只有自定义业务区间需要相应埋点。当前 Perfetto 还能接入更多数据源，不能把它的全部功能概括为 ftrace 封装。android.os.Trace 的标记仍可被 Perfetto 读取，接口说明见 Trace 和 Perfetto ATrace 文档。
这篇写于 2014 年，当时用的是 Nokia X 和旧版 Android SDK。2026-10-13 更新了 Ubuntu 24.04 LTS 下的 udev 和用户组配置；旧
SYSFS规则、Upstart 重启方式已经不适用，adb_usb.ini的办法留在文末作历史记录。
最近开发Nokia项目，遇到的问题如下：
插入Nokia x后，电脑没有反应，即不识别，同事的windows也不识别，最后在谷歌上搜索了良久，才找到了解决方案，但是没有记录，后来又要给别人配置的时候，发现忘记怎么配置了。想想这也是一个具有通性的问题，还是记录下来，分享给大家。
先在设备上开启 USB 调试，并使用支持数据传输的 USB 线。用 adb version 确认调用的 Platform-Tools 版本，再运行 adb devices -l 查看设备状态。
no permissions：优先检查 Linux 的 udev 规则和当前用户组。unauthorized：设备已经被发现，解锁设备并确认 RSA 调试授权弹窗。offline：设备未正常响应 ADB；重新插拔或重启 ADB 后再观察。