📚 课程目录第2章 MAT工具安装与基础操作

MAT工具安装与基础操作：从现象到定位的实战路径

在Kotlin应用出现运行卡顿、频繁GC甚至OOM时，通常已形成内存泄漏链。MAT（Memory Analyzer Tool）是分析堆转储文件的标准利器。本章按照“现象识别 → 数据采集 → 原因定位 → 修复动作 → 复测 → 预防”六步闭环，带你完成从安装到使用Histogram和Dominator Tree对泄漏根因进行初筛的完整流程。

1. 现象识别：哪些症状指向堆泄漏？

症状1：应用在连续打开/关闭某些Activity（特别是Kotlin协程或Fragment）后，堆内存只增不减。
症状2：Retained Heap占用量超过预期，且GC Root路径存在非预期强引用。
症状3：日志中出现OutOfMemoryError，或通过Runtime.getRuntime().totalMemory()监控到内存持续上涨。

⚠ 常见误区：不要只依赖GC日志判断泄漏，大量临时对象也会导致GC频繁。只有堆转储快照才能区分“泄漏”和“暂时膨胀”。

2. 数据采集：安装MAT并获取堆转储

2.1 下载与安装Eclipse MAT

操作系统	下载方式	安装说明
Windows	从 Eclipse MAT Releases 下载 `MemoryAnalyzer-*.exe`	双击安装，选择JDK/JRE路径（推荐JDK 11+）
macOS	下载 `MemoryAnalyzer-*.dmg`	拖拽到Applications文件夹，首次打开需安全设置允许
Linux	下载 `MemoryAnalyzer-*.linux.gtk.x86_64.tar.gz`	解压后运行 `MemoryAnalyzer` 脚本，需预装GTK库

安装完成后，通过MAT菜单栏 Help → Install New Software 可额外安装“Android Developer Tools”插件以识别Android Dump格式（可选）。

2.2 获取堆转储文件（dump）

根据应用运行环境选择获取命令。以下为三种常用方案：

方案A（JVM进程）：使用 jmap 工具（推荐JDK自带）：

# 查看Java进程PID（Linux/macOS）
jps -l
# 生成堆转储，指定格式hprof
jmap -dump:format=b,file=app_leak.hprof <PID>

方案B（Android模拟器/真机）：使用 adb 与 am dumpheap：

# 获取包名（如 com.example.app）
adb shell ps | grep com.example
# 指定进程PID强制dump
adb shell am dumpheap <PID> /data/local/tmp/dump.hprof
# 拉取到本地
adb pull /data/local/tmp/dump.hprof ./

方案C（自动触发）：在Kotlin代码中注入OnLowMemory或自定义阈值时自动dump：

// 开发版开启自动dump
android.os.Debug.dumpHprofData(getExternalFilesDir(null)?.path + "/auto_dump.hprof")

💡 最佳实践：在重现泄漏场景后，连续抓取2～3个dump（例如操作前、操作后、GC后），对比增量对象可快速锁定泄漏源。

3. 原因定位：Histogram与Dominator Tree入门

打开MAT并加载dump文件（File → Open Heap Dump），MRI会提示“Leak Suspects Report”，此时可先跳过，直接进入基础功能。

3.1 Histogram（直方图）

功能：列出所有类的实例数量与浅堆（Shallow Heap）、保留堆（Retained Heap）。用于发现异常大的类。

列名	含义	排查关注点
Class Name	类全限定名（Kotlin类会展开为$内部类）	聚焦`Activity`、`Fragment`、`ViewModel`、自定义单例
Objects	实例数量	若某个类的实例数远超预期（如Activity应有1个，却出现5个），极大可能泄漏
Shallow Heap	对象自身占用的堆（不含引用）	通常较小
Retained Heap	对象被GC回收时能释放的总堆大小	用于量化泄漏影响程度

典型排查动作：

在Histogram顶栏输入Activity或Fragment名，筛选出所有Activity子类。
右键某个异常数量的类 → Merge Shortest Paths to GC Roots → exclude all phantom/weak/soft etc. 查看强引用路径。
若路径中出现static字段、外部类、匿名内部类或Lambda，则为泄漏嫌疑点。

  📋 排查判断规则（适用于Kotlin）：
  规则1：如果Activity实例数 > 已启动次数，且持有ViewModel或LiveData未清除 → 泄漏。
规则2：如果object（Kotlin单例）直接引用Activity → 必泄漏。
规则3：如果coroutineContext未取消，但Activity已销毁 → 协程泄漏。

3.2 Dominator Tree（支配树）

功能：以“支配对象”为根展示对象引用树，直接反映谁“占着最大内存”。

操作手法：

从 Open Query Browser 选择 Dominator Tree（或右键Histogram某类 → List objects → with outgoing references）。
按 Retained Heap 降序排序，查看哪些对象保留了最多内存。
展开节点 → 查找 GC Root 标记（如 Thread、System Class、JNI Global）。

元素	说明	Kotlin常见泄漏案例
GC Root	不被GC回收的起点对象	静态字段、活动线程、类加载器
Dominator树	谁支配谁	Static集合 → List → Activity实例
Path to GC Roots	从对象到GC Root的引用链	匿名内部类持有外部Activity引用

🎯 实战技巧：在Dominator Tree中找到疑似泄漏对象后，使用 Calculate Precise Retained Size 计算实际被保留的对象集合，然后对比两次dump的差异。

4. 修复动作：基于MAT定位的常见修复模式

一旦在Dominator Tree中发现泄漏路径（例如静态集合持有Activity、内部类持有外部引用、协程未取消），可采取以下措施：

泄漏类型	Kotlin代码示例（错误）	修复方案
静态集合泄漏	`object Cache { val list = mutableListOf<Activity>() }`	改用 `WeakReference<Activity>` 或 `PhantomReference`
内部类/Listener泄漏	`class MyActivity { val runnable = Runnable { doSomething() } }`	使用 `LifecycleCoroutineScope` 替代匿名内部类
协程作用域未取消	`GlobalScope.launch { ... }`	改用 `viewModelScope` 或 `lifecycleScope`

5. 复测：验证修复是否有效

在相同场景下再次生成dump（确保操作次数与修复前一致）。
在MAT中加载新dump，打开Histogram，对比同一类的Objects列数值。
使用Compare Base Line功能（File → Open Heap Dump → 选择之前dump作为Baseline），查看增量对象数量是否归零。

  ✅ 复测通过标准：原来异常多的类实例数量恢复至1～2个（无持久泄漏）；Retained Heap不再持续增长。

6. 预防：将MAT分析嵌入开发流程

持续集成：在CI流水线中加入内存泄漏检测步骤，使用MAT的 ParseHeapDump.bat 脚本自动解析dump并输出报告。
开发阶段：使用Android Studio的Profiler配合MAT，在提交代码前手动执行一次“打开→返回→GC→dump”的探测流程。
知识沉淀：建立团队内部的 .mat 组件库，将常用查询（如“所有Activity”、“所有ViewModel”）保存为OQL脚本并共享。