第2章 Android Profiler界面导览：内存分析器布局、堆转储按钮、对象列表与引用树

2.1 现象识别 — 从内存曲线捕捉异常信号

打开 Android Profiler 并切换到 Memory Profiler 后，最直观的排查入口是顶部的实时内存曲线图。曲线呈现的是当前进程的Java堆、Native堆、Graphics、Stack等内存分区的总和。问题排查的第一步就是观察曲线形态，判断是否存在内存异常征兆。

2.2 数据采集 — 堆转储按钮与快照捕获

当曲线出现异常信号后，点击 Android Profiler 上方的 Dump Java Heap 按钮（垃圾桶图标右侧的圆形箭头按钮），即可触发一次完整的 GC 并捕获当前堆快照。采集的数据会以 .hprof 文件形式显示在左侧的 Heap Dump 列表中。

除了可视化按钮，也可以通过 ADB 命令手动触发堆转储，适用于自动化测试或批量采集场景：

# 强制 GC 并 dump 指定进程的堆
adb shell am dumpheap <package_name> /data/local/tmp/heap_dump.hprof

# 将 .hprof 文件拉到本地
adb pull /data/local/tmp/heap_dump.hprof ./heap_dumps/

# 使用 Android Studio 的 sdk 工具转换格式（如果需要在 MAT 中分析）
hprof-conv heap_dump.hprof heap_dump_std.hprof

2.3 原因定位 — 对象列表与引用树深度解析

堆转储加载完成后，Profiler 底部面板会呈现两个核心视图：对象列表（Instance List）和引用树（Reference Tree）。两者配合使用，才能从海量对象中精准定位到泄漏或大对象。

2.3.1 对象列表：排序与筛选策略

对象列表默认按 Shallow Size（浅堆）降序排列，显示每个类的实例数量、总大小和分布情况。排查时应切换为 Retained Size（保留堆） 排序，因为它能反映“如果该对象被回收，实际释放的内存大小”。

# 对象列表关键列说明
列名            含义
─────────────────────────────────────
Class Name      Java 类全限定名
Instance Count  当前堆中该类的实例总数
Shallow Size    所有实例的浅堆总和（对象自身占用的内存）
Retained Size   所有实例的保留堆总和（对象及其引用的所有子对象的总内存）
%               占总堆的百分比

2.3.2 引用树：从实例到 GC Root 的路径追踪

在对象列表中选中一个可疑实例，右侧即显示该实例的引用树。引用树以该实例为根，向上展开所有引用它的对象（Referrers），直到 GC Root。常见的 GC Root 类型包括：

• Thread 对象 — 活着的线程持有引用
• 静态变量 — 类加载后一直存在的引用
• JNI Global Reference — Native 层持有的引用
• 系统类 — Android Framework 持有的引用

排查时沿着引用树向上展开，观察每一层的对象类型和字段名称。如果引用链中出现了本应被销毁的 Activity、Fragment、View 或大型业务对象，则泄漏点就在该层。

2.4 修复动作 — 从引用链到代码修复

定位到引用链后，修复动作需要根据持有者的类型制定策略：

• 静态变量持有：在适当时机（如 onDestroy、onStop）将静态变量置为 null，或使用 WeakReference 包装。
• 内部类持有：将内部类改为 static 内部类，外部引用通过 WeakReference 传入。
• 系统服务/回调未解注册：在 onPause / onDestroy 中执行反注册操作（如 unregisterReceiver、removeObserver）。
• 集合缓存未清理：设置最大容量限制，或使用 LRUCache 替换 HashMap。

// 示例：静态内部类 + WeakReference 避免 Activity 泄漏
public class MyActivity extends AppCompatActivity {
    private static class MyRunnable implements Runnable {
        private final WeakReference<MyActivity> activityRef;

        MyRunnable(MyActivity activity) {
            activityRef = new WeakReference<>(activity);
        }

        @Override
        public void run() {
            MyActivity activity = activityRef.get();
            if (activity != null) {
                // 执行操作
            }
        }
    }
}

2.5 复测 — 验证修复后的内存表现

修复完成后，需要重复执行现象识别 → 数据采集 → 原因定位的闭环，对比修复前后的堆转储数据：

1. 在修复后的版本上执行相同的用户操作序列。
2. 等待 3~5 秒后点击 Dump Java Heap 采集新快照。
3. 在对象列表中搜索之前定位的类名，观察实例数是否下降。
4. 展开引用树，确认该类的 GC Root 路径是否已切断。
5. 对比两次堆转储的 Retained Size，确认释放的内存是否达到预期。

2.6 预防 — 建立内存监控基线

将内存分析器纳入日常开发流程，通过以下手段建立长期预防机制：

• 基线记录：为每个页面/功能模块记录正常状态下的内存曲线、GC 频率和堆分布数据。
• 自动化堆转储：在 CI 流程中集成 ADB 命令，在关键操作后自动 dump 堆并比对基线。
• 对象数告警：针对 Activity、Fragment、Bitmap 等关键类设置实例数阈值，超出即标记为失败。
• 定期 Profiler 扫描：每个迭代周期至少执行一次完整的 Profiler 堆转储分析，输出泄漏报告。

# 自动化基线比对示例脚本（伪代码）
#!/bin/bash
# 1. 启动应用并执行核心场景
adb shell am start -n com.example/.MainActivity
# 2. 等待场景稳定
sleep 5
# 3. 抓取堆转储
adb shell am dumpheap com.example /data/local/tmp/baseline.hprof
adb pull /data/local/tmp/baseline.hprof ./baseline/
# 4. 使用 MAT 或自定义脚本对比当前堆与基线堆的差异
# 5. 如果新出现的类实例数 > 阈值，则触发告警