3、工具准备:Android Studio Profiler、MAT、LeakCanary的安装与基本使用

工欲善其事,必先利其器。排查内存泄漏,说白了就是跟看不见的「内存黑洞」打交道。你手头没有趁手的兵器,光靠猜是搞不定的。

我个人习惯把这三大工具比作「侦探三件套」:Android Studio Profiler 是现场勘查的放大镜,MAT 是实验室里的显微镜,而 LeakCanary 则是自动报警器。今天我就带你挨个装好、用起来。

3.1 Android Studio Profiler:实时监控的「心电图」

这个工具其实就藏在 Android Studio 底部工具栏里。你点那个绿色的「Profiler」图标就能打开。我刚开始用的时候,总觉得它数据太多眼花缭乱。后来发现,你只需要盯住三个关键指标:Java HeapNative MemoryGC 事件

安装与启动

不需要额外安装。只要你用的是 Android Studio 3.0 以上版本,它就在那。运行你的 App,点击底部「Profiler」标签,再选中你的设备进程,就开始了。

基本使用流程

  1. 录制一段操作:比如反复打开关闭某个 Activity。
  2. 手动触发 GC:点击 Profiler 界面上的「垃圾桶」图标。
  3. 观察内存曲线:如果 GC 后内存没有回落到基线,说明有泄漏。

我的经验:有一次我排查一个图片加载导致的泄漏,用 Profiler 发现每次切换 Fragment 后,Java Heap 都会涨 2MB 且不回落。我立刻意识到是某个 Bitmap 没有被回收。后来定位到是 Glide 的缓存策略没配好。

小技巧:录制时记得勾选「Record Java/Kotlin allocations」。这样你能看到具体是哪些对象在占用内存。不过注意,这个操作会拖慢 App 运行速度,建议只在 Debug 包上用。

3.2 MAT:内存快照的「解剖刀」

MAT 全称是 Memory Analyzer Tool。它不直接跑在手机上,而是分析你导出的 .hprof 文件。说白了,Profiler 是看「动态」,MAT 是看「静态快照」。

安装步骤

  1. 去 Eclipse 官网下载 MAT(独立版,不需要 Eclipse)。
  2. 解压后直接运行 MemoryAnalyzer.exe(Windows)或 MemoryAnalyzer.app(Mac)。
  3. 注意:MAT 需要 JDK 11 以上。我遇到过因为 JDK 版本太低打不开的情况,折腾了半天。

基本使用流程

  1. 导出 hprof 文件:在 Profiler 界面点击「Dump Java Heap」,然后点击左上角的「Export」按钮。
  2. 转换格式:Android 导出的 hprof 不是标准格式。你需要用 hprof-conv 工具转换一下。这个工具在 Android SDK 的 platform-tools 目录下。
  3. 打开分析:用 MAT 打开转换后的文件,点击「Leak Suspects」报告。
// 转换命令示例
hprof-conv dump.hprof dump_standard.hprof

避坑指南:我曾经直接拿 Android 导出的 hprof 丢进 MAT,结果报错说文件格式不对。后来才发现必须用 hprof-conv 转一下。这个坑我踩过,你别再踩了。

MAT 核心视图

视图名称 作用
Histogram 列出所有类的实例数量。你可以按「Retained Heap」排序,找到占用内存最大的类。
Dominator Tree 显示对象之间的支配关系。说白了,就是谁「持有」谁。
Leak Suspects 自动分析出最可能的泄漏点。适合新手入门。

我的习惯:我一般先看「Leak Suspects」报告,它会直接告诉我「某某对象占用了 80% 的内存,可能泄漏」。然后我再切到「Dominator Tree」去追根溯源,看是谁引用了它。

3.3 LeakCanary:自动报警的「看门狗」

LeakCanary 是 Square 公司开源的神器。它不需要你手动 dump 内存,也不需要你盯着曲线看。你只管正常操作 App,一旦发生泄漏,它就会弹出通知告诉你:「嘿,这里漏了!」

集成步骤

build.gradle 里加一行依赖就行:

dependencies {
    // 2.x 版本
    debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.12'
}

嗯,就这么简单。不需要写任何初始化代码。LeakCanary 2.x 会自动注册一个 ContentProvider 来完成初始化。

基本使用流程

  1. 运行 App:正常操作你的页面。
  2. 等待通知:如果发生泄漏,系统通知栏会弹出「Memory Leak Detected」。
  3. 查看详情:点击通知,会跳转到 LeakCanary 的 Activity,里面展示了泄漏对象的引用链。

我的经验:有一次我集成 LeakCanary 后,发现每次打开一个 WebView 页面都会报泄漏。我一开始以为是 WebView 的问题,后来仔细看引用链,发现是某个第三方 SDK 持有了 Activity 的引用。如果没有 LeakCanary,这种隐蔽的泄漏我可能要排查好几天。

注意:LeakCanary 只建议在 Debug 包中使用。Release 包一定要去掉,否则会影响性能。你可以用 debugImplementation 来确保只在 Debug 构建中生效。

3.4 三件套的配合使用

你可能会问:「这三个工具到底该用哪个?」我的答案是:全都要

  • 日常开发:开着 LeakCanary,让它自动帮你盯着。有泄漏就报,省心。
  • 定位问题:用 Profiler 录制操作,观察内存曲线。找到可疑点后,dump 一份快照。
  • 深度分析:把快照丢进 MAT,用 Dominator Tree 或 Leak Suspects 找到根因。

说白了,LeakCanary 是「巡逻兵」,Profiler 是「侦察兵」,MAT 是「法医」。各司其职,配合起来才能高效。

最后一个小建议:别等到线上出问题了才想起用这些工具。平时写代码时,养成随手用 Profiler 看一眼内存的习惯。你会发现很多潜在问题在早期就被扼杀了。