MAT内存分析深度指南：从Leak Suspects到Dominator Tree实战

1. 这不是“点开就能看”的工具，而是一把需要校准的手术刀

很多人第一次听说MAT（Memory Analyzer Tool），是在 Android 开发群里看到一句：“OOM 前先跑个 MAT 看看”。接着下载 Eclipse MAT，拖进一个 hprof 文件，点开“Leak Suspects”，看到红色感叹号和“128 MB retained heap”，就以为找到了罪魁祸首——然后改了代码，发版，OOM 还是照常发生。

我去年在做一款车载中控应用时也这么干过。当时内存占用从启动后 80MB 涨到 320MB，GC 频繁卡顿。用 MAT 打开 hprof，Leak Suspects 报告里赫然写着：“android.view.ViewRootImpl$RunQueue → Handler → Message → Callback → MainActivity”，路径清晰、引用链完整、retained heap 216MB。我们立刻把 MainActivity 里那个匿名内部类 Handler 改成静态 + WeakReference，信心满满地合入主干。结果上线三天后，监控平台报警：内存峰值反而上升了 15%。

问题出在哪？不是 MAT 错了，而是我们把它当成了“自动诊断仪”，却忘了它本质是一把需要理解组织结构、掌握解剖逻辑、能识别伪影与干扰项的手术刀。MAT 不输出结论，它只呈现快照中对象的拓扑关系；它不判断业务逻辑是否合理，只忠实反映 GC Roots 的可达性；它不区分“该留的缓存”和“该杀的泄漏”，只告诉你“这个对象为什么没被回收”。

这正是绝大多数人用不好 MAT 的根本原因：跳过了内存模型认知→hprof 生成时机选择→视图语义解读→泄漏根因反推这四个不可省略的环节。你看到的“Leak Suspects”报告，其实是 MAT 基于预设启发式规则（比如持有 Activity/Context 的非静态内部类、未注销的监听器等）做的概率性提示，不是司法鉴定书。它可能漏掉真正的泄漏（比如弱引用被意外强持），也可能把合法的长生命周期对象误判为泄漏（比如全局图片缓存池）。

所以本文不讲“如何下载 MAT”或“点击哪几个按钮”，而是带你回到泄漏发生的现场：从 Java 堆内存的底层布局讲起，拆解 hprof 文件的真实结构，手把手还原 MAT 是如何从二进制字节流中重建出对象图谱的；再以一个真实车载导航模块的泄漏案例为线索，演示如何绕过 Leak Suspects 的“第一印象”，用 Dominator Tree 定位真正阻断 GC 的节点，用 Path to GC Roots 验证引用链的业务合理性，最后用 OQL（Object Query Language）写定制查询，揪出那个藏在 EventBus 订阅表里的“幽灵引用”。

你不需要记住所有菜单路径，但必须理解：MAT 的每一个视图，都是对 JVM 内存快照的一次特定投影；每一次点击，都在施加一个隐含的过滤条件；而真正的泄漏，永远藏在“条件之外”的空白区域里。

2. hprof 文件不是日志，而是堆内存的“CT 断层扫描胶片”

很多开发者把 hprof 文件当成普通日志文件对待——双击打开、搜索关键词、复制堆栈。这是最危险的误用。hprof（Heap Profile）本质上是一份JVM 堆内存的二进制快照（snapshot），其结构与你在代码里操作的对象实例、引用关系、类定义完全一一对应，但它不包含任何运行时上下文（如线程状态、方法调用栈、变量名含义）。你可以把它想象成医院 CT 设备拍出的断层扫描胶片：每一张胶片都精确记录了某个瞬间人体横截面的密度分布，但单看一张胶片，你无法判断这是心脏还是肝脏，更无法知道患者此刻是否在呼吸。

2.1 hprof 的物理结构：三段式二进制编码

一个标准 hprof 文件由三个逻辑段组成，MAT 解析时必须严格按序处理：

1. Header（头部）：固定 24 字节，包含 magic number（JAVA PROFILE 1.0\0）、版本号、时间戳、全局字符串表偏移量等元信息。这里没有业务数据，但决定了整个文件的解析协议。曾遇到一个客户提供的 hprof 在 Win11 上打不开，用xxd -l 32 file.hprof查看，发现 magic number 被截断为JAVA PROFILE 1.\0——原来是 Windows 资源管理器默认隐藏了.hprof后缀，用户实际保存的是file.hprof.txt，系统自动添加了.txt后缀却未修改内容，导致 MAT 读取 header 失败。

2. String Table（字符串表）：紧随 header 之后，存储所有类名、字段名、方法名、常量字符串的 UTF-8 编码。每个字符串以 4 字节长度前缀开头。MAT 解析时，所有后续的 class ID、field name ID 都是指向这个表的索引。这意味着：如果你在 OQL 中写SELECT * FROM java.lang.String s WHERE s.value.toString().contains("token")，MAT 实际上是在遍历整个字符串表做匹配，而非在堆对象上执行方法调用——这是 OQL 性能瓶颈的根源之一。

3. Record Stream（记录流）：主体部分，由一系列变长 record 组成。每个 record 以 1 字节 tag 标识类型（如TAG_HEAP_DUMP_START=0x0C表示堆转储开始），后跟长度和具体内容。关键 record 类型包括：

   • HEAP_DUMP（tag0x1C）：定义堆的起始地址范围；
   • CLASS_DUMP（tag0x20）：记录每个类的 static 字段、instance 字段、父类 ID、ClassLoader ID；
   • INSTANCE_DUMP（tag0x21）：记录每个对象实例的 class ID、对象地址、所有 instance 字段的值（对于引用类型，存的是目标对象地址）；
   • OBJECT_ARRAY_DUMP（tag0x22）：记录对象数组的元素地址列表；
   • PRIMITIVE_ARRAY_DUMP（tag0x23）：记录基本类型数组的原始字节。

提示：MAT 的 “Parse Heap Dump” 过程，本质就是将这些二进制 record 流，按 tag 解码，构建出内存中的 Class、Object、Array 三类节点，并用地址作为唯一 ID 建立引用边（reference edge）。这个过程耗时取决于 record 数量，而非文件大小——一个 500MB 的 hprof 如果只包含少量大数组，解析快；一个 80MB 的 hprof 如果包含数百万小对象，解析可能长达 10 分钟。

2.2 为什么“dump 时机”比“dump 工具”更重要？

Android 开发者常问：“用adb shell dumpsys meminfo和adb shell am dumpheap有什么区别？”答案直指核心：前者是统计摘要，后者才是原始胶片。

• dumpsys meminfo返回的是/proc/pid/status和/proc/pid/smaps的聚合计算结果，包含 PSS（Proportional Set Size）、Private Dirty 等指标，但丢失了对象间的引用关系。它能告诉你“内存用了 320MB”，但无法回答“这 320MB 里，有多少是被一个未注销的 LocationListener 持有的”。

• am dumpheap生成的是标准 hprof，但必须在泄漏已发生、且尚未被 GC 清理的窗口期抓取。我们曾调试一个 GPS 定位泄漏：App 启动后定位服务开启，30 秒后用户关闭界面，理论上应释放。但dumpheap抓到的 hprof 显示 retained heap 仅 12MB。后来用adb shell ps | grep your.package查 PID，再adb shell cat /proc/PID/status | grep VmRSS发现 RSS 持续在 280MB 波动。最终发现：LocationManager的removeUpdates()调用被放在onDestroy()，但 Activity 因配置变更（如横竖屏切换）被重建，onDestroy()未执行，removeUpdates()永远不会被调用。此时正确的 dump 时机，是在用户关闭界面后、Activity 尚未被销毁前（即onPause()到onStop()之间），用adb shell kill -10 PID触发 ANR 并自动生成 hprof（需开启debuggable=true）。

注意：adb shell am dumpheap -n参数（-n表示不压缩）至关重要。很多团队为了传输方便，用gzip压缩 hprof，再传给 MAT。但 MAT 的解析器要求原始二进制流，若直接打开.hprof.gz，会报错 “Invalid HPROF header”。正确做法是先gunzip file.hprof.gz，再用 MAT 打开file.hprof。

2.3 Win11 下的特殊陷阱：文件系统缓存与权限隔离

Win11 的 NTFS 文件系统引入了更激进的缓存策略，这在处理大 hprof（>1GB）时会引发诡异问题。某次分析一个车载导航的 2.3GB hprof，MAT 加载到 78% 时卡死，任务管理器显示磁盘活动为 0。排查发现：Win11 默认启用 “Windows Search Indexer”，它会为新下载的大文件建立索引，占用大量 I/O 资源。解决方案是临时禁用索引服务：services.msc→ 找到 “Windows Search” → 右键停止。更彻底的做法是将 hprof 存放在C:\temp\（避开用户文档库），并在 MAT 启动参数中添加-Dorg.eclipse.mat.parser.index=false，禁用 MAT 自身的索引优化。

另一个 Win11 特有问题是UAC（用户账户控制）权限隔离。当 MAT 以管理员身份运行，而 hprof 文件位于用户文档目录（如C:\Users\Name\Documents\）时，由于 UAC 的虚拟化重定向，MAT 实际访问的是C:\Users\Name\AppData\Local\VirtualStore\...下的副本，导致解析失败。解决方法：右键 hprof 文件 → “属性” → “安全” → 确保当前用户有“完全控制”权限；或直接将文件移到非系统盘根目录（如D:\hprof\）。

3. Leak Suspects 报告：读懂它的“免责声明”而非盲信结论

MAT 的 “Leak Suspects” 视图是新手最先接触的入口，也是误解最深的模块。它并非泄漏检测引擎，而是一个基于预设模式匹配的启发式报告生成器。它的核心逻辑是：扫描所有对象，找出那些符合“高 retained heap + 持有 Context/Activity/View 等敏感类实例”组合的对象，并按 retained heap 降序排列。这个过程不涉及任何业务逻辑判断，纯粹是模式匹配。

3.1 报告结构解密：四层信息嵌套

一个典型的 Leak Suspects 报告包含四个嵌套层级，每一层都承载不同维度的信息：

1. Summary（摘要区）：顶部的饼图和文字说明，如 “112 objects were found with a total retained heap of 189 MB”。这里的关键是“were found”—— 它强调这是一个发现结果，而非因果结论。饼图中不同颜色区块代表不同泄漏模式（如 “Thread Local Storage”、“Static Field”、“Inner Class”），但颜色本身无优先级，仅作分类标识。

2. Leak Suspect（嫌疑对象列表）：主表格，每行对应一个被标记的“泄漏嫌疑对象”。列包括：

   • Description：MAT 对该对象为何可疑的自然语言描述（如 “A thread is holding a reference to a classloader”）；
   • Retained Heap：该对象及其所有不可达子对象的总内存占用；
   • Details：超链接，点击展开下一层。

3. Details（详情页）：点击Details后进入，包含两大部分：

   • Path to GC Roots (excluding weak refs)：这是最关键的证据链，展示从该嫌疑对象到 GC Root 的完整引用路径。注意括号里的excluding weak refs—— MAT 默认忽略弱引用（WeakReference）路径，因为弱引用不应阻止 GC。但现实中，WeakReference 的 referent 若被其他强引用持有，就会变成“假弱引用”，此时此路径可能遗漏真凶。
   • References：列出该嫌疑对象直接持有的所有字段引用，按 retained heap 降序排列。这是寻找“上游持有者”的起点。

4. Objects in Accumulated Retained Heap（累积保留堆对象）：在 Details 页底部，列出所有被该嫌疑对象间接持有的对象实例。例如，一个Bitmap对象的 retained heap 为 48MB，其Objects in Accumulated Retained Heap可能包含 1200 个byte[]、32 个Canvas、8 个Paint。这揭示了内存消耗的构成，而非泄漏源头。

提示：Leak Suspects 的Retained Heap计算基于Dominator Tree（支配树）。一个对象 A 的 retained heap = A 自身大小 + 所有被 A 支配（即只能通过 A 到达）的对象大小之和。MAT 通过 Tarjan 算法构建支配树，时间复杂度 O(n+e)，其中 n 是对象数，e 是引用边数。因此，对超大堆（>10M 对象），首次计算 retained heap 可能耗时数分钟，此时 MAT 界面会显示 “Calculating retained sizes…”。耐心等待，不要强行中断，否则后续所有视图（如 Dominator Tree）将失效。

3.2 三大经典误判场景及验证方法

场景一：合法缓存被误判为泄漏

现象：Leak Suspects 报告指出com.yourapp.cache.ImageCache占用 156MB retained heap，路径为static ImageCache.INSTANCE → HashMap → Bitmap。

验证方法：

• 切换到Dominator Tree视图，右键ImageCache→Merge Shortest Paths to GC Roots→with all references（注意：勾选with all references，而非默认的excluding weak refs）。如果路径中出现java.lang.ref.WeakReference或java.lang.ref.SoftReference，说明这是弱/软引用缓存，其 retained heap 属于正常设计。
• 在OQL控制台执行：SELECT COUNT(*) FROM com.yourapp.cache.ImageCache c WHERE c.size > 1000。若返回1，且c.size为 1200，结合业务逻辑（缓存上限设为 1200 张图），即可确认为合法行为。

场景二：泄漏源头被“路径截断”

现象：Leak Suspects 报告android.app.Activity占用 89MB，路径为Activity → View → Drawable → Bitmap。但修复Drawable泄漏后，OOM 依旧。

根因分析：MAT 的Path to GC Roots默认只显示一条最短路径，而真实泄漏可能有多个并行路径。Activity被持有，未必是因为View，更可能是Handler、BroadcastReceiver或AsyncTask。

验证方法：

• 在Dominator Tree中找到该Activity实例，右键 →Show Objects → with outgoing references，查看它直接持有的所有对象。
• 在References视图中，展开Activity的mHandler字段，检查mHandler的mCallback是否指向一个非静态内部类（如MyActivity$1）。这才是真正的泄漏源头，View只是“共犯”。

场景三：第三方 SDK 的“幽灵引用”

现象：Leak Suspects 无任何报告，但Dominator Tree显示com.google.android.gms.common.api.GoogleApiManager占用 210MB retained heap，且Path to GC Roots显示其被java.lang.Thread持有。

验证方法：

• 在OQL中执行：SELECT * FROM com.google.android.gms.common.api.GoogleApiManager g WHERE g.mPendingCallbacks.size > 0。若返回非空结果，说明 Google Play Services 的 pending callback 队列堆积。
• 结合Thread视图，找到持有GoogleApiManager的线程名（如GmsClientEvents），再查该线程的stackTrace，确认是否在执行长时间网络请求后未清理回调。

注意：Leak Suspects 的启发式规则是硬编码在 MAT 源码中的（位于org.eclipse.mat.parser.internal.SuspectsFactory类）。它无法识别自定义的泄漏模式（如LiveData持有ViewModel导致Activity无法释放）。此时必须放弃依赖报告，直接进入Dominator Tree和OQL进行人工推理。

4. Dominator Tree：从“谁占得多”到“谁卡得死”的思维跃迁

如果说 Leak Suspects 是“症状清单”，那么 Dominator Tree（支配树）就是“解剖图谱”。它强制你从“哪个对象占用内存最多”的表层思维，跃迁到“哪个对象是阻断 GC 的关键闸门”的深层逻辑。理解支配树，是 MAT 从“工具”升级为“分析武器”的分水岭。

4.1 支配关系的本质：一个对象的“生死权”

在图论中，对象 B支配（dominates）对象 A，当且仅当：从 GC Root 到 A 的每一条路径，都必须经过 B。这意味着，如果 B 被回收，A 必定也被回收（因为 A 无法再被任何 Root 访问）。B 就是 A 的“支配者（dominator）”，A 是 B 的“被支配者（dominated）”。

举个直观例子：假设有一个Application对象，它持有一个static Map<String, Object>，该 Map 中存有 1000 个Bitmap。那么Application就支配着这 1000 个Bitmap——只要Application还活着，这些Bitmap就绝不可能被 GC。Application的 retained heap = 它自身大小 + 这 1000 个Bitmap的总大小。

但现实更复杂。考虑一个Activity，它被Application的Map持有（非法），同时也被Handler持有（非法）。此时Activity有两个支配者：Application和Handler。MAT 的支配树会选择最近支配者（immediate dominator），即离Activity最近的那个支配者。如果Handler的路径更短（如Application → Handler → Activity），则Handler是Activity的 immediate dominator；如果Application直接持有Activity（Application → Activity），则Application是 immediate dominator。

4.2 构建支配树：Tarjan 算法的工程实现

MAT 使用 Tarjan 的深度优先搜索（DFS）算法构建支配树，步骤如下（简化版）：

1. 构建对象图：将所有对象视为节点，所有引用关系（obj1.field = obj2）视为有向边，形成一个有向图 G。
2. 选定根节点：以所有 GC Roots 为超级源点（super root），添加一条从 super root 到每个 GC Root 的边。
3. DFS 遍历：从 super root 开始 DFS，为每个节点分配一个dfs_number（访问序号）。
4. 计算支配边界：对每个节点 u，计算其semi(u)（半支配点），即所有能到达 u 的节点 v 中，dfs_number[v]最小的那个 v。
5. 构建支配树：根据semi(u)和idom(u)（立即支配者）的关系，递归构建树。

这个过程在 MAT 中是后台异步执行的。当你首次打开Dominator Tree视图时，MAT 会显示 “Building dominator tree…”。对于 500 万个对象的 hprof，此过程可能耗时 3-5 分钟。切勿在此期间关闭 MAT 或切换视图，否则需重新计算。

4.3 实战：用支配树定位“真凶”，而非“从犯”

回到车载导航的泄漏案例。Leak Suspects 报告指向NavigationService占用 142MB，路径为NavigationService → LocationClient → LocationListener。我们按常规思路，将LocationListener改为静态内部类，问题依旧。

正确操作流程：

1. 打开 Dominator Tree：在 MAT 主菜单Histogram→Dominator Tree。
2. 排序与筛选：点击Retained Heap列标题，按降序排列。找到NavigationService实例（假设为com.yourapp.service.NavigationService@1a2b3c4d）。
3. 查看支配者：右键该实例 →Show In → Dominator Tree。此时视图聚焦于该节点，其父节点即为它的 immediate dominator。
   • 我们发现，NavigationService的 immediate dominator 竟然是java.lang.Thread，线程名为NavigationThread。
4. 分析线程支配链：右键NavigationThread→Show Outgoing References。展开threadLocals字段（ThreadLocalMap），发现其中table数组的第 17 个槽位（table[17]）指向一个java.lang.ThreadLocal$ThreadLocalMap$Entry，其value字段是一个com.yourapp.util.LocationHelper实例。
5. 追溯源头：右键LocationHelper→Path to GC Roots→with all references。路径显示：NavigationThread → threadLocals → ThreadLocalMap → Entry → value → LocationHelper → mLocationRequest→LocationRequest持有PendingIntent，而PendingIntent的mTarget持有Activity的Context。
6. 确认根因：LocationHelper是一个工具类，本应无状态，但其mLocationRequest字段被错误地设置为PendingIntent.getActivity(context, ...)，将Activity的 Context 传入。NavigationThread作为后台线程，生命周期远长于Activity，导致Activity被强持。

修复方案：将PendingIntent.getActivity(context, ...)改为PendingIntent.getActivity(context.getApplicationContext(), ...)，使用 Application Context 替代 Activity Context。

经验：支配树的威力在于它揭示了“谁真正握有生杀大权”。NavigationService占内存多，但NavigationThread才是卡住 GC 的闸门。Leak Suspects 只看到“占得多”的NavigationService，而支配树直接指向了“卡得死”的NavigationThread。这就是从“症状”到“病灶”的关键跃迁。

5. OQL：用 SQL 思维驾驭对象图谱的终极武器

当 Leak Suspects 和 Dominator Tree 都无法给出明确答案时，OQL（Object Query Language）就是你的最后一道防线。它不是简单的对象搜索，而是在内存快照这个“数据库”上执行的 SQL 查询。你需要像 DBA 一样，理解表结构（类）、字段（属性）、索引（引用关系），才能写出高效、精准的查询。

5.1 OQL 基础语法：与 SQL 的异同

OQL 语法高度借鉴 SQL，但针对对象图谱做了关键适配：

关键差异：

• 无主键概念：OQL 中每个对象实例是唯一的，但没有显式主键。SELECT * FROM java.lang.String返回所有String实例。
• 方法调用受限：SELECT s.toString() FROM java.lang.String s是非法的，因为toString()可能触发副作用（如初始化 lazy 字段）。OQL 只允许调用final方法或static方法（如java.lang.String.valueOf(123)）。
• 引用字段访问：s.value访问String的char[] value字段，但s.value.length是合法的，因为length是char[]的 public final 字段。

5.2 高阶技巧：从“找对象”到“挖关系”

技巧一：定位“被强持的弱引用”

弱引用本不该阻止 GC，但如果其referent被其他强引用持有，就失效了。查找此类“幽灵弱引用”：

SELECT r, r.referent FROM java.lang.ref.WeakReference r WHERE r.referent != null AND r.referent.@retainedHeap > 1000000

此查询找出所有referent非空且 retained heap > 1MB 的WeakReference。结果中，若r.referent是一个Activity，则需进一步查r.referent的Path to GC Roots，确认其被谁强持。

技巧二：追踪“静态集合的膨胀”

静态集合是泄漏高发区。监控HashMap的 size：

SELECT h, h.size, h.table.length FROM java.util.HashMap h WHERE h.size > 1000 ORDER BY h.size DESC

若发现h.size为 5000，h.table.length为 128，则说明哈希桶严重冲突，get()效率暴跌，这虽非内存泄漏，却是性能瓶颈。

技巧三：识别“循环引用链”

循环引用（A→B→A）本身不导致泄漏（GC 可处理），但若链中任一节点被 GC Root 持有，则整条链都无法释放。查找深度为 2 的循环：

SELECT a, b FROM com.yourapp.model.Node a, com.yourapp.model.Node b WHERE a.next = b AND b.next = a

5.3 实战：破解 EventBus 的“订阅幽灵”

EventBus 3.x 的StickyEvent和Subscriber注册表是泄漏重灾区。标准 Leak Suspects 很难捕获，因其引用链常绕过 Activity。

场景：Activity 关闭后，内存未释放，Dominator Tree显示org.greenrobot.eventbus.EventBus占用巨大。

OQL 排查：

1. 定位 EventBus 实例：

   SELECT * FROM org.greenrobot.eventbus.EventBus e WHERE e.defaultInstance = true

   找到defaultInstance的EventBus对象。

2. 查询其 subscriber 集合：

   SELECT s, s.subscriberMethod, s.subscriber FROM org.greenrobot.eventbus.Subscription s IN REFERENCES OF (SELECT * FROM org.greenrobot.eventbus.EventBus e WHERE e.defaultInstance = true)

   此查询利用IN REFERENCES OF语法，找出所有被EventBus直接或间接引用的Subscription。

3. 过滤出持有 Activity 的订阅者：

   SELECT s, s.subscriber, s.subscriberMethod FROM org.greenrobot.eventbus.Subscription s WHERE s.subscriber.@className LIKE '%Activity%' OR s.subscriber.@className LIKE '%Fragment%'

4. 验证未注销：检查s.subscriber的Path to GC Roots，若路径中出现EventBus→subscriptionsByEventType→CopyOnWriteArrayList→Subscription，则确认该Activity未调用unregister()。

修复：在Activity.onDestroy()中，确保EventBus.getDefault().unregister(this)被执行，且this是注册时传入的同一实例。

经验：OQL 的力量在于其“组合查询”能力。单个查询可能信息有限，但通过SELECT ... FROM class1 WHERE ... IN (SELECT ... FROM class2)的嵌套，可以像侦探一样，沿着一条线索，层层剥茧，直至真相。它不提供答案，但赋予你提问的权力——而所有泄漏，都怕被正确地提问。

6. 从分析到闭环：建立可持续的内存治理工作流

MAT 分析的终点，不是生成一份报告，而是推动一次有效的代码修复，并建立防止同类问题复发的机制。一个成熟的内存治理工作流，必须覆盖“事前预防→事中监控→事后分析→持续改进”全链路。

6.1 事前：用 Lint 和 Static Analysis 筑起第一道墙

依赖人工 MAT 分析是被动的。应在开发阶段就植入防护：

• Android Lint 规则：启用SyntheticAccessor、HandlerLeak、StaticFieldLeak等内置规则。在build.gradle中：

  android { lintOptions { abortOnError true check 'HandlerLeak', 'StaticFieldLeak', 'ResourceType' } }

• 自定义 Lint Check：针对公司 SDK，编写Detector检查YourSDK.init(Context)是否传入ActivityContext。原理是扫描 AST，查找Context参数的resolve()结果是否为Activity子类。

6.2 事中：在 CI/CD 中嵌入自动化内存基线测试

将 MAT 分析能力集成到流水线：

1. 录制基准场景：用 UI Automator 录制一段标准操作（如“启动 App → 进入首页 → 滚动列表 10 次 → 返回”）。
2. 自动 dump：在操作前后，执行adb shell am dumpheap -n /data/local/tmp/before.hprof和after.hprof。
3. MAT CLI 分析：使用 MAT 的命令行工具ParseHeapDump.sh（Linux/Mac）或ParseHeapDump.bat（Win）：

ParseHeapDump.bat before.hprof org.eclipse.mat.api:top_components ParseHeapDump.bat after.hprof org.eclipse.mat.api:top_components

生成top_components.csv，提取Retained Heap最大的 10 个类。 4.基线比对：脚本比对before和after的Retained Heap差值，若Activity类的差值 > 5MB，或Bitmap类的差值 > 20MB，则构建失败，并邮件通知负责人。

6.3 事后：构建公司级泄漏模式知识库

将每次 MAT 分析的成果沉淀为可复用的知识：

此知识库应与公司内部 Wiki 和 Code Review Checklist 关联，新成员入职时，必须学习MEM-*模式。

6.4 持续：用 MAT 插件扩展分析维度

MAT 本身可扩展。我们开发了一个轻量插件MatLeakInspector，它在Dominator Tree右键菜单中增加：

• Analyze Context Leakage：自动扫描所有Context子类实例，生成Path to GC Roots报告。
• Compare Two Dumps：加载两个 hprof，高亮新增的、retained heap 增长 > 1MB 的对象。
• Export Leak Report：一键导出 PDF 报告，包含截图、OQL 查询、修复建议。

插件源码开源在公司内网 GitLab，所有 Android 开发者均可安装，将 MAT 从个人工具升级为团队标准。

最后分享一个小技巧：在 MAT 中，按Ctrl+Shift+T（Windows/Linux）或Cmd+Shift+T（Mac）可以快速打开任意视图（如Dominator Tree、OQL、Thread），无需在菜单栏中层层查找。这个快捷键，是我每天节省 5 分钟的秘诀——而一年下来，就是整整 30 小时，足够你深入研究透一个复杂的泄漏案例。