第4章：触发堆转储的正确时机

堆转储是定位内存泄漏和过度分配的核心手段，但“什么时候转储”直接决定了分析结论的有效性。大量案例表明：90%以上的无效堆转储是因为触发时机选择了空窗期（对象已被回收）或干扰期（GC正在回退）。本章按问题排查型课程结构，从现象识别到预防，建立一套可执行的时机决策系统。

现象识别：堆转储无效的典型表现

数据采集：三种正确时机及操作指令

时机1：应用稳定状态

场景：冷启动完成、列表首次渲染结束、无动画运行时。确保主线程空闲、GC 未触发。

# Android Profiler 内操作
1. 启动 App 并等待首页完全加载（LayoutInspector 显示 no activity update）
2. 点击 "Dump Java Heap" 按钮
# 或命令行
adb shell am dumpheap $(adb shell ps | grep com.your.app | awk '{print $2}') /data/local/tmp/stable.hprof
adb pull /data/local/tmp/stable.hprof

时机2：可疑操作后立即转储

场景：怀疑某个按钮点击、列表滑动、Fragment 切换后产生了泄漏。在操作结束的 50ms 内触发。

# 自动化触发（需被测 App 注入）
adb shell "echo 'trigger_dump' | tee /dev/input/event3"  # 需替换为实际 event 节点或使用 ADB 脚本
# 推荐：在代码中增加 Debug.startMethodTracing() 包裹操作，结束后自动 dump
// Android Profiler 手动时机：点击操作后立即在 Profiler 界面点击 "Dump"

时机3：OOM 发生前（Pre-OOM 窗口）

场景：通过 ActivityManager.getMemoryInfo() 监控系统低内存，或利用 ComponentCallbacks2.onTrimMemory(TRIM_MEMORY_RUNNING_CRITICAL) 回调触发。

// 在 Application 中注册
@Override
public void onTrimMemory(int level) {
    if (level >= TRIM_MEMORY_RUNNING_CRITICAL) {
        // 在此处触发堆转储（注意异步，避免卡主线程）
        android.os.Debug.dumpHprofData("/data/local/tmp/pre_oom.hprof");
    }
}
// 同时监控阈值
ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
ActivityManager.MemoryInfo mi = new ActivityManager.MemoryInfo();
am.getMemoryInfo(mi);
if (mi.availMem < mi.threshold * 1.5) {
    // 接近 OOM 阈值，触发 dump
}

原因定位：通过故障树诊断时机问题

当分析结果不符合预期时，依照下面的故障树逐层排查。

修复动作：针对三个时机的调整方案

adb shell dumpsys meminfo | grep "threshold"

adb shell date +%s >> /data/local/tmp/timestamp.txt

复测：验证时机正确性

执行以下检查清单确认堆转储时机符合要求。

• 检查1：hprof 文件大小是否 > 3MB（正常中等应用）？若过小说明时机太晚或 App 不在前台。
• 检查2：对比两次 dump 的 java.lang.Class 数量，若变化小于 5% 说明未捕获到对象新增。
• 检查3：使用 hprof-conv heap.hprof heap-converted.hprof 后通过 MAT 或 Perfetto 查看 GC Root 链，确认目标对象处于 GCRoot 可到达状态。

# 快速验证命令
hprof-conv -z dump.hprof dump_converted.hprof  # 转换为MAT可用格式
jhat -port 7000 dump_converted.hprof
# 打开 http://localhost:7000 检查实例数

预防：建立堆转储时机检查清单