第2章 内存泄漏根本原因：强引用未释放、生命周期管理错误、未注册回调、静态集合、非静态内部类

2.1 现象识别：直观感受与性能拐点

内存泄漏并非一蹴而就，它具有累积性。早期可能只是轻微的卡顿，随着泄漏对象增多，GC频率上升，最终导致OOM。下表列出了不同阶段的典型现象，用于快速诊断是否进入泄漏排查流程。

2.2 数据采集：锁定强引用链

在这一步中，我们需要收集两个维度的数据：

• 自动化快照：集成 LeakCanary 库，当疑似泄漏发生时自动触发 dumpHprofData()。
• 手动对照：在关键业务入口和出口分别执行一次 adb shell am start -W com.xxx/.Activity 操作，对比多次 Heap Dump。

下图为五种根本原因及其触发的排查流程，请先通过这张故障树建立全局印象，后续章节将逐一展开。

2.3 原因定位：五类根本原因的比对排查表

当数据采集完成后，使用表格中的判断规则迅速缩小范围，这是避免在错误方向上浪费时间的关键。

2.4 修复动作：针对五种原因的 SOP

根因不同，修复手段差异很大。以下按优先级给出标准化操作流程。

2.4.1 消除强引用未释放

• 将强引用改为 WeakReference<T> 或 SoftReference<T>，尤其是单例持有的 Context。
• 在长生命周期对象中提供 release() 或 clear() 方法，由短生命周期对象显式调用。

// 错误写法
public class AppManager {
    private static AppManager instance;
    private Activity currentActivity;  // 强引用导致泄漏
    // ...
}

// 修复写法
public class AppManager {
    private static AppManager instance;
    private WeakReference<Activity> currentActivityRef;
    public void setCurrentActivity(Activity activity) {
        this.currentActivityRef = new WeakReference<>(activity);
    }
    public Activity getCurrentActivity() {
        return currentActivityRef != null ? currentActivityRef.get() : null;
    }
}

2.4.2 生命周期管理修正

• 在 onDestroy() 中调用 handler.removeCallbacksAndMessages(null)。
• 在 Kotlin 协程中使用 viewModelScope 或 lifecycleScope，避免自定义生命周期。
• Thread 或 AsyncTask 应并入 Lifecycle 观察，使用 getLifecycle().addObserver() 控制存活周期。

// 典型修复：清理 Handler
@Override
protected void onDestroy() {
    super.onDestroy();
    // 移除所有未处理的消息，防止延迟消息持有 Activity
    if (myHandler != null) {
        myHandler.removeCallbacksAndMessages(null);
    }
    // 对于 AsyncTask，立即取消
    if (myTask != null && myTask.getStatus() != AsyncTask.Status.FINISHED) {
        myTask.cancel(true);
    }
}

2.4.3 未注册回调修复

• 明确配对注册/反注册：onCreate 对应 onDestroy，onResume 对应 onPause。
• 使用 LifecycleEventObserver 在 DESTROY 时自动清除回调，或使用 AutoDispose/RxLifecycle。

// 配对注册写法
@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    EventBus.getDefault().register(this);
}

@Override
public void onDestroy() {
    super.onDestroy();
    EventBus.getDefault().unregister(this);
}

2.4.4 静态集合清理

• 静态集合使用 WeakHashMap<K, WeakReference<V>> 或 LRUCache + 软引用。
• 每次 add 对象时，按业务生命周期设置 Remove 回调或使用 Lifecycle 观察。

// 使用 WeakHashMap 避免静态集合强引用泄漏
static Map<String, WeakReference<Activity>> sActivityCache = new WeakHashMap<>();
// 添加时
sActivityCache.put(tag, new WeakReference<>(activity));
// 获取时
Activity act = sActivityCache.get(tag).get();

2.4.5 非静态内部类转静态

• 将内部类定义为 static class，使其不持有外部类引用。
• 如果必须持有外部引用，对外部类使用 WeakReference 显式传入。

// 错误：非静态匿名内部类
postDelayed(new Runnable() {
    @Override
    public void run() {  // 隐式持有 Activity
        updateUI();  
    }
}, 5000);

// 修复：改为静态内部类
static class MyRunnable implements Runnable {
    private WeakReference<Activity> activityRef;
    MyRunnable(Activity activity) {
        this.activityRef = new WeakReference<>(activity);
    }
    @Override
    public void run() {
        Activity act = activityRef.get();
        if (act != null) {
            act.updateUI();
        }
    }
}

// 或者直接使用 Lambda + 静态方法引用（需确保上下文不泄漏）

2.5 复测：验证方案

执行“进入页面 → 触发泄漏操作 → 反复退出/进入 5 次 → 手动 GC → 导出 Heap”的循环，使用 LeakCanary 自检进行回归对比。若 LeakCanary 未触发任何 Notification，且 MAT 上对应 Activity 实例数为 0，则判定修复通过。

2.6 预防：编码规范与自动化

在修复一轮后，团队应建立以下机制避免同类问题重复发生：

• 编译期检查：使用 Lint 规则或自定义 Pitest/SpotBugs 检测非静态内部类、未注销的 BroadcastReceiver。
• 编码规范：禁止非静态内部类持有 Activity；单例必须通过 WeakReference 获取 Context。
• 静态代码分析：将 LeakCananry 引入 CI 流程，merge 前若出现任何泄漏 notification，则终止构建。
• 测试卡点：在 UI 自动化测试脚本中加入页面跳转后的内存快照对比，阈值设为 +3MB。

至此，第 2 章已完成了从现象识别、数据采集、原因定位、修复动作、复测到预防的全部排查链路，接下来的章节将以具体场景驱动，逐一深入到 LeakCanary 和 MAT 的联合操作细节。