第3章 识别内存泄漏的典型现象：持续增长的内存曲线、频繁GC、OOM崩溃日志

3.1 现象识别 — 三种典型预警信号

内存泄漏不会直接打印“泄漏”二字，但会在运行时持续暴露三个特征级现象。下表列出每种现象的观测维度和判定阈值，便于你在 Profiler 或日志中快速对号入座。

预警现象	Profiler 内存曲线特征	GC / 日志特征	紧急程度
持续增长的内存曲线	每次操作（页面跳转、数据刷新）后内存基线不回落，呈阶梯式或45°斜线上涨	GC 日志偶发，但总内存（Total Memory）持续走高，Native + Java堆同步增长	⚠️ 中高风险
频繁 GC 事件	内存曲线呈现“锯齿状”——陡升后骤降，但谷值一次比一次高	logcat 中 GC_CONCURRENT / GC_FOR_ALLOC 每秒出现多次，GC 耗时 > 5ms	⚠️ 中风险
OOM 崩溃日志	内存曲线在崩溃前急速拉升至设备阈值（如 256MB / 512MB），然后突降至零	OutOfMemoryError 堆栈明确指向 java.lang.OutOfMemoryError，或 native memory 耗尽	🔴 高风险

3.1.1 持续增长的内存曲线 — 深度辨识

在 Android Profiler Memory 面板中，将视图切换到 “Live Allocation” 模式，执行三次同一业务路径（如打开→关闭详情页）。如果每次关闭后内存比前一次高 0.5 MB 以上且不回落，说明存在对象滞留。关键指标：“Delta Memory” 持续为正。

3.1.2 频繁 GC — 日志级判定

使用 ADB 实时捕获 GC 日志，判断是否存在 “无效回收” 模式：

# 过滤 GC 日志，观察频率和回收量
adb logcat -s GC:* -v time | grep -E "GC_CONCURRENT|GC_FOR_ALLOC"

# 典型泄漏模式输出示例（同一进程）：
# 03-15 10:00:01.234 GC_CONCURRENT  freed 2MB, 80% free  (仍保留 48MB)
# 03-15 10:00:02.345 GC_FOR_ALLOC   freed 1MB, 82% free  (仍保留 47MB)
# 03-15 10:00:03.456 GC_CONCURRENT  freed 2MB, 79% free  (仍保留 49MB)
# ↑ 释放量小，常驻堆一直增长

当 GC 间隔 < 3 秒 且每次回收后堆大小没有阶梯式下降，即可判定为“频繁无效 GC”。

3.1.3 OOM 崩溃日志 — 捕获现场

OOM 日志是内存泄漏的终局信号，必须保留完整的堆栈信息：

# 捕获 OOM 时刻的 logcat 快照
adb logcat -b crash -d > oom_crash.log

# 典型 OOM 日志片段：
# --------- beginning of crash
# FATAL EXCEPTION: main
# java.lang.OutOfMemoryError: Failed to allocate a 33554452 byte allocation with 16777216 free bytes and 16MB until OOM
#     at android.graphics.BitmapFactory.nativeDecodeStream(Native Method)
#     at com.example.app.ImageLoader.loadImage(ImageLoader.java:45)
#     ...

注意：OOM 不一定全是 Java 堆泄漏，也可能是 Native 内存（通过 dumpsys meminfo 区分）。

3.2 数据采集 — 用 Profiler 与 ADB 固化证据

发现预警信号后，立刻执行以下数据采集动作，锁定现场：

1. 附加 Android Profiler：在 AS 中点击 Profile → 选择进程 → Memory 面板，记录 30 秒内存曲线。
2. 触发堆转储：

# 方式一：通过 Profiler UI 点击 "Dump Java heap" 按钮
# 方式二：通过 ADB 命令触发（适合自动化）
adb shell am start -n com.google.android.apps.mtaas.profiler/.MainActivity
# 手动触发 dump (需 root 或 debuggable 应用)
adb shell kill -10 <pid>
# 或使用 dumpsys 获取内存快照
adb shell dumpsys meminfo <package_name> -d > meminfo_dump.txt

3. 捕获 GC 日志：

adb logcat -s GC:* -v threadtime > gc_log_<timestamp>.txt

4. 保存堆转储文件：

# Profiler 中点击左侧 "Export" 按钮保存 .hprof 文件
# 或使用 ADB 导出
adb exec-out run-as <package_name> cat /data/data/<package_name>/dump.hprof > dump.hprof

3.3 原因定位 — 故障树分析（FTA）

将三种现象作为顶层事件，向下拆解直接原因与排查方向。下图故障树帮助你在看到现象时快速定位最可能的泄漏根因。

3.4 修复动作 — 针对三种现象的处置策略

现象匹配	常见根因	修复动作
持续增长 + 内存不回落	静态集合持有 Activity / Fragment、单例未释放、缓存无上限	WeakReference 替代强引用、onDestroy() 中清空集合、LRU 缓存上限
频繁 GC + 回收效率低	大量临时 String / 短生命周期对象、Handler 内部类泄漏	对象池复用、Handler 改为静态 + WeakReference、减少 += 字符串拼接
OOM + 大对象分配失败	Bitmap 未复用 / 未回收、大文件加载、线程池无限创建	BitmapFactory.Options.inSampleSize、Glide 图片库、Executors.newFixedThreadPool

3.5 复测 — 验证修复效果

修复后必须通过以下 “三通过” 标准才算闭环：

1. 内存曲线平坦化：重复 10 次相同业务路径，使用 Profiler 观察基线漂移 < 0.3 MB。
2. GC 频率正常化：logcat 中 GC 间隔 > 10 秒，且每次回收后堆大小降回基线。
3. OOM 零重现：在低端设备（如 2GB RAM）上运行原触发场景 30 分钟无崩溃。

# 复测自动化脚本示例（循环执行关键路径）
for i in {1..20}; do
  adb shell am start -W com.example.app/.MainActivity
  sleep 2
  adb shell input keyevent KEYCODE_BACK
  sleep 1
  adb shell dumpsys meminfo com.example.app | grep "TOTAL"
done

3.6 预防 — 建立监控与规范

将现象识别前置到开发阶段，避免泄漏流入生产：

• 内存基线看板：每次 CI 构建后自动运行 adb shell dumpsys meminfo，对比基线偏差 > 5% 则告警。
• GC 日志巡检：集成 LeakCanary 或 Matrix 并在测试环境开启 GC 日志上传。
• OOM 降级：在关键路径捕获 OutOfMemoryError 并尝试清理缓存 + 友好提示，而非直接崩溃。

// 代码级预防：在 Application 中注册未捕获异常处理器
Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {
    if (throwable instanceof OutOfMemoryError) {
        // 清理最大缓存
        ImageCache.getInstance().clear();
        // 记录现场
        Log.e("OOM_PREVENT", "OutOfMemory caught, cache cleared");
    }
});