第17章 内存优化

从可控泄漏场景出发，依次使用Memory Monitor、Allocation Tracker、Heap Dump、MAT和LeakCanary形成发现到根因的证据链

第17章 内存优化

在《第17章 内存优化》中，本课程对应刘望舒《Android进阶解密》，电子工业出版社2018年10月初版，468页、702千字，ISBN 9787121348389。原书以Android 8.0系统源码为主；本页不会用Android 10后的ATMS、现代ART实现、Perfetto或新隐藏API政策替换原书链路。

从可控泄漏场景出发，依次使用Memory Monitor、Allocation Tracker、Heap Dump、MAT和LeakCanary形成发现到根因的证据链。源码实验固定AOSP Android 8.0与作者出版仓库提交 3860d9e1；后续版本只作为迁移差异，不改变正式目录分母。

学习目标

  • 能解释“第17章 内存优化”全部正式目录节点，并定位Android 8.0中的入口类、函数与源码路径。
  • 能绘制进程、线程、Binder/JNI/加载边界和关键状态转移，区分请求发出与系统完成。
  • 能设计单变量故障实验，验证“泄漏结论必须显示预期销毁对象仍被GC Root路径持有；优化后重复场景中对象可回收、堆稳态恢复且无功能回归”。
  • 能写出包含版本、源码、日志/追踪、反例、停止、恢复、回退和复核人的独立交接记录。

机制总览

第17章 内存优化：机制路径

  1. 1

    从一条可证伪的调用链开始

    先预测：把一次堆增长当泄漏或只贴LeakCanary结论会混淆缓存、抖动与真实不可达失败，也无法证明修复后的稳定状态。把预测写成入口、对象身份、进程/线程、状态和完成回调五列，再去读源码。若结果与预测不同，先修正模型，不要选择性截取调用栈。

  2. 2

    核心词汇与版本门

    以上词汇都固定在Android 8.0语义。在《第17章 内存优化》中，Android 7.0只在原书明确比较AMS家族时出现；Android 9以后反射/隐藏API限制、Android 10的ActivityTaskManager、现代Profiler/Perfetto等只能写进迁移备注，不能改写本页正式链路。

  3. 3

    原书目录核对清单

    本节把「原书目录核对清单」放回《第17章 内存优化》的输入、状态变化与输出路径中理解。

先按顺序建立机制，再进入实验切换阶段并检查失效证据。

章级决策实验

第17章 内存优化：机制与证据

切换《第17章 内存优化》的三个关键教学阶段，先解释机制，再用运行与失败证据验证结论。

选择推理阶段

当前阶段 · 从一条可证伪的调用链开始

先预测：把一次堆增长当泄漏或只贴LeakCanary结论会混淆缓存、抖动与真实不可达失败，也无法证明修复后的稳定状态。把预测写成入口、对象身份、进程/线程、状态和完成回调五列，再去读源码。若结果与预测不同，先修正模型，不要选择性截取调用栈。

可核验证据

在固定 AOSP 8.0 标签上追踪「从一条可证伪的调用链开始」的入口与状态对象，用 PID/TID、源码符号、正常/单变量失败日志和最终系统状态交叉核对。

学完《第17章 内存优化》后，应能从输入和前置条件推导状态变化，并用可重复的构建、运行或边界测试证明结果。

失效—证据矩阵

第17章 内存优化：失效与核验

从一条可证伪的调用链开始

典型失效

若只背诵「从一条可证伪的调用链开始」的类名而不固定 Android 8.0 源码、进程线程、对象身份和完成回调，跨 Binder、JNI 或加载边界后就会把请求误判为结果。

核验证据

在固定 AOSP 8.0 标签上追踪「从一条可证伪的调用链开始」的入口与状态对象，用 PID/TID、源码符号、正常/单变量失败日志和最终系统状态交叉核对。

核心词汇与版本门

典型失效

若只背诵「核心词汇与版本门」的类名而不固定 Android 8.0 源码、进程线程、对象身份和完成回调，跨 Binder、JNI 或加载边界后就会把请求误判为结果。

核验证据

在固定 AOSP 8.0 标签上追踪「核心词汇与版本门」的入口与状态对象，用 PID/TID、源码符号、正常/单变量失败日志和最终系统状态交叉核对。

原书目录核对清单

典型失效

若只背诵「原书目录核对清单」的类名而不固定 Android 8.0 源码、进程线程、对象身份和完成回调，跨 Binder、JNI 或加载边界后就会把请求误判为结果。

核验证据

在固定 AOSP 8.0 标签上追踪「原书目录核对清单」的入口与状态对象，用 PID/TID、源码符号、正常/单变量失败日志和最终系统状态交叉核对。

每个判断都必须能落到观测、测试或产物，不能只凭代码表面推测。

从一条可证伪的调用链开始

先预测：把一次堆增长当泄漏或只贴LeakCanary结论会混淆缓存、抖动与真实不可达失败，也无法证明修复后的稳定状态。把预测写成入口、对象身份、进程/线程、状态和完成回调五列，再去读源码。若结果与预测不同，先修正模型，不要选择性截取调用栈。

原书面向应用开发者学习系统源码，重点不是抄完整函数，而是抓住跨层调用的关键节点。每个节点都要回答：谁发起、在哪个进程和线程执行、哪份状态被修改、后续如何被唤醒、失败如何返回、什么现象代表真正完成。

验收不变量是：泄漏结论必须显示预期销毁对象仍被GC Root路径持有；优化后重复场景中对象可回收、堆稳态恢复且无功能回归。只有源码版本、符号关系、运行轨迹与最终状态四类证据一致，结论才可以进入下一章。

核心词汇与版本门

、、、、

以上词汇都固定在Android 8.0语义。在《第17章 内存优化》中，Android 7.0只在原书明确比较AMS家族时出现；Android 9以后反射/隐藏API限制、Android 10的ActivityTaskManager、现代Profiler/Perfetto等只能写进迁移备注，不能改写本页正式链路。

原书目录核对清单

本页承担20个目录或复习节点，正文、图解、实验和题目必须能反向定位每一项：

  • 17.1 避免可控的内存泄漏
  • 17.1.1 什么是内存泄漏
  • 17.1.2 内存泄漏的场景
  • 17.2 Memory Monitor
  • 17.2.1 使用Memory Monitor
  • 17.2.2 大内存申请与GC
  • 17.2.3 内存抖动
  • 17.3 Allocation Tracker
  • 17.3.1 使用Allocation Tracker
  • 17.3.2 alloc文件分析
  • 17.4 Heap Dump
  • 17.4.1 使用Heap Dump
  • 17.4.2 检测内存泄漏
  • 17.5 内存分析工具MAT
  • 17.5.1 生成hprof文件
  • 17.5.2 MAT分析hprof文件
  • 17.6 LeakCanary
  • 17.6.1 使用LeakCanary
  • 17.6.2 LeakCanary应用举例
  • 17.7 本章小结

分步追踪：源码、运行与反例

分步1 / 3

定位源码入口与责任边界

固定Android 8.0标签，从公开入口向下追踪，不跳过Binder代理、JNI注册、ClassLoader查找或system_server状态对象。

可复现实验

scenario loop -> destroy Activity -> force GC -> heap dump -> GC-root path -> fix -> repeat
static final List<Activity> leaked = new ArrayList<>(); // controlled failing fixture
object | expected release | actual root path | retained bytes | fix | repeat result

动手试：在同一镜像、同一构建和同一输入上重复正常、冷启动/首次加载、热路径、单变量失败与恢复五轮。在《第17章 内存优化》中，记录PID/TID、调用入口、对象或token、状态前后值、耗时、异常/返回码和最终可见结果；性能章再记录P50/P95/P99，内存章保留GC Root路径。

独立证据门

  • 节点覆盖内存优化
  • 最小切片贯通全链路
  • 故障实验对比泄漏结论必须显示预期销毁对象仍被GC Ro…
  • 凭证据完成交接

练习

练习

问题 1：为什么“第17章 内存优化”必须固定Android 8.0？

问题 2：怎样构造“把一次堆增长当泄漏或只贴LeakCanary结论会混淆缓存、抖动与真实不可达失败，也无法证明修复后的稳定状态”的最小反例？

问题 3：何时可以认为本页完成独立交接？

本章回顾

“第17章 内存优化”的核心是从可控泄漏场景出发，依次使用Memory Monitor、Allocation Tracker、Heap Dump、MAT和LeakCanary形成发现到根因的证据链。把一次堆增长当泄漏或只贴LeakCanary结论会混淆缓存、抖动与真实不可达失败，也无法证明修复后的稳定状态是必须保留的反证；源码阅读只有连接运行时的进程、线程、状态与最终结果，才从“知道类名”升级为“能诊断”。

名词解释

本章出现的专业名词，用大白话再讲一遍。

内存泄漏

内存泄漏服务于“从可控泄漏场景出发，依次使用Memory Monitor、Allocation Tracker、Heap Dump、MAT和LeakCanary形成发现到根因的证据链”。掌握标准是能定位Android 8.0源码、画出运行轨迹、构造单变量反例，并用“泄漏结论必须显示预期销毁对象仍被GC Root路径持有；优化后重复场景中对象可回收、堆稳态恢复且无功能回归”独立验收。

Memory Monitor

Memory Monitor服务于“从可控泄漏场景出发，依次使用Memory Monitor、Allocation Tracker、Heap Dump、MAT和LeakCanary形成发现到根因的证据链”。掌握标准是能定位Android 8.0源码、画出运行轨迹、构造单变量反例，并用“泄漏结论必须显示预期销毁对象仍被GC Root路径持有；优化后重复场景中对象可回收、堆稳态恢复且无功能回归”独立验收。

Allocation Tracker

Allocation Tracker服务于“从可控泄漏场景出发，依次使用Memory Monitor、Allocation Tracker、Heap Dump、MAT和LeakCanary形成发现到根因的证据链”。掌握标准是能定位Android 8.0源码、画出运行轨迹、构造单变量反例，并用“泄漏结论必须显示预期销毁对象仍被GC Root路径持有；优化后重复场景中对象可回收、堆稳态恢复且无功能回归”独立验收。

Heap Dump

Heap Dump服务于“从可控泄漏场景出发，依次使用Memory Monitor、Allocation Tracker、Heap Dump、MAT和LeakCanary形成发现到根因的证据链”。掌握标准是能定位Android 8.0源码、画出运行轨迹、构造单变量反例，并用“泄漏结论必须显示预期销毁对象仍被GC Root路径持有；优化后重复场景中对象可回收、堆稳态恢复且无功能回归”独立验收。

LeakCanary

LeakCanary服务于“从可控泄漏场景出发，依次使用Memory Monitor、Allocation Tracker、Heap Dump、MAT和LeakCanary形成发现到根因的证据链”。掌握标准是能定位Android 8.0源码、画出运行轨迹、构造单变量反例，并用“泄漏结论必须显示预期销毁对象仍被GC Root路径持有；优化后重复场景中对象可回收、堆稳态恢复且无功能回归”独立验收。

← 上一页：第16章 绘制优化 · 下一页：Android 8.0源码总复习 →

原版目录概念补充核对

以下条目补齐官方目录中容易被示例主线掩盖的概念。它们不重复罗列目录，而是明确每项概念的机制、适用边界和验收证据。

17.1.1 什么是内存泄漏：机制、边界与证据

第17章 内存优化中的17.1.1 什么是内存泄漏需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.1.2 内存泄漏的场景：机制、边界与证据

第17章 内存优化中的17.1.2 内存泄漏的场景需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.2 Memory Monitor：机制、边界与证据

第17章 内存优化中的17.2 Memory Monitor必须落回 Android 8.0 源码中的入口、对象、进程/线程、状态变化与完成点。固定版本和输入，先预测正常链路，再只注入一个失败条件，以源码符号、运行日志和最终系统状态三方核对。

17.2.1 使用Memory Monitor：机制、边界与证据

第17章 内存优化中的17.2.1 使用Memory Monitor必须落回 Android 8.0 源码中的入口、对象、进程/线程、状态变化与完成点。固定版本和输入，先预测正常链路，再只注入一个失败条件，以源码符号、运行日志和最终系统状态三方核对。

17.2.2 大内存申请与GC：机制、边界与证据

第17章 内存优化中的17.2.2 大内存申请与GC涉及 Java、Native、加载器身份与运行时内存边界；同名类型、引用或方法在不同加载器和线程中并不自动等价。用源码符号、类加载日志、JNI 引用计数、堆/GC 轨迹或正反加载案例验证对象身份、生命周期和释放条件。

17.2.3 内存抖动：机制、边界与证据

第17章 内存优化中的17.2.3 内存抖动需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.3 Allocation Tracker：机制、边界与证据

第17章 内存优化中的17.3 Allocation Tracker需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.3.1 使用Allocation Tracker：机制、边界与证据

第17章 内存优化中的17.3.1 使用Allocation Tracker需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.3.2 alloc文件分析：机制、边界与证据

第17章 内存优化中的17.3.2 alloc文件分析必须落回 Android 8.0 源码中的入口、对象、进程/线程、状态变化与完成点。固定版本和输入，先预测正常链路，再只注入一个失败条件，以源码符号、运行日志和最终系统状态三方核对。

17.4 Heap Dump：机制、边界与证据

第17章 内存优化中的17.4 Heap Dump需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.4.1 使用Heap Dump：机制、边界与证据

第17章 内存优化中的17.4.1 使用Heap Dump需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.4.2 检测内存泄漏：机制、边界与证据

第17章 内存优化中的17.4.2 检测内存泄漏需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.5 内存分析工具MAT：机制、边界与证据

第17章 内存优化中的17.5 内存分析工具MAT需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.5.1 生成hprof文件：机制、边界与证据

第17章 内存优化中的17.5.1 生成hprof文件必须落回 Android 8.0 源码中的入口、对象、进程/线程、状态变化与完成点。固定版本和输入，先预测正常链路，再只注入一个失败条件，以源码符号、运行日志和最终系统状态三方核对。

17.5.2 MAT分析hprof文件：机制、边界与证据

第17章 内存优化中的17.5.2 MAT分析hprof文件需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.6 LeakCanary：机制、边界与证据

第17章 内存优化中的17.6 LeakCanary需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.6.1 使用LeakCanary：机制、边界与证据

第17章 内存优化中的17.6.1 使用LeakCanary需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.6.2 LeakCanary应用举例：机制、边界与证据

第17章 内存优化中的17.6.2 LeakCanary应用举例需要把工具读数连接到用户可见结果与责任对象，而不是把一张截图当作根因。固定场景并保存帧时间或堆基线，单独改变布局、分配或引用路径，再用 P50/P95/P99、GC Root、过度绘制或首帧状态交叉验证。

17.7 本章小结：机制、边界与证据

第17章 内存优化中的17.7 本章小结必须落回 Android 8.0 源码中的入口、对象、进程/线程、状态变化与完成点。固定版本和输入，先预测正常链路，再只注入一个失败条件，以源码符号、运行日志和最终系统状态三方核对。

复习本章（6 题）

讨论

评论区加载中…