📚 课程目录第1章认识Lifecycle与内存泄漏

第1章：认识Lifecycle与内存泄漏

Lifecycle组件是Android Jetpack的核心工具，它帮助Activity/Fragment感知生命周期变化，但若使用不当，反而成为内存泄漏的重灾区。本章从问题排查视角，带您建立“现象→数据→原因→修复→复测→预防”的六步闭环思维。

1.1 现象识别：哪些信号暗示Lifecycle泄漏？

内存泄漏定义：不再需要的对象因被强引用链持续持有，导致GC无法回收，最终耗尽堆内存。在Lifecycle场景中，最常见的是LifecycleObserver未正确注销，或ViewModel持有了Activity/Context长生命周期对象。

现象	典型表现	排查信号
GC日志频繁	Logcat中连续出现`GC_FOR_ALLOC`或`GC_CONCURRENT`，且堆大小持续增长	`I/art: Heap trimmer : trimmed 32MB I/art: Background partial concurrent mark sweep GC freed 1048576 objects`
OOM崩溃	特定页面反复打开后出现`OutOfMemoryError`，堆栈指向`LifecycleRegistry`或`ObserverWrapper`	`java.lang.OutOfMemoryError: Failed to allocate a 16384 byte allocation with 16 free bytes`
卡顿/丢帧	页面切换时出现明显停顿，且频繁触发GC	结合`dumpsys meminfo`观察`Native Heap`或`Dalvik Heap`异常增长
LeakCanary告警	LeakCanary检测到`LifecycleObserver`实例泄漏，引用链为`Activity → LifecycleRegistry → ObserverWrapper → Observer`	`GC ROOT androidx.lifecycle.LifecycleRegistry.mObserverMap → androidx.lifecycle.LifecycleRegistry$ObserverWrapper.mLifecycleObserver`

判断规则：若应用在低内存设备上出现上述任一现象，且通过adb shell dumpsys meminfo 观察到Activities数量持续增加但不回收，即可列为Lifecycle泄漏嫌疑。

1.2 数据采集：如何锁定泄漏证据？

定位Lifecycle泄漏需要两种核心数据：内存快照（Heap Dump）和LeakCanary分析链。

生成Heap Dump：在应用进入泄漏场景后，使用Android Studio Profiler或adb shell am dumpheap命令快速抓取。
检查LeakCanary报告：集成LeakCanary 2.x后，泄漏时自动生成通知，点击即可看到引用链。
手动分析引用：使用MAT或Android Studio分析.hprof文件，搜索泄漏对象（如Activity实例），查看GC Roots路径。

关键采集命令：

# 1. 触发泄漏后，立即抓取堆转储
adb shell am dumpheap com.example.app /data/local/tmp/dump.hprof

# 2. 拉取到本地
adb pull /data/local/tmp/dump.hprof .

# 3. 使用MAT或Android Studio分析
# 4. 若使用LeakCanary，开启通知后查看引用链：
adb shell am broadcast -a com.squareup.leakcanary.HEAP_DUMP_FOUND

1.3 原因定位：Lifecycle泄漏的三种常见模式

根据大量案例统计，Lifecycle相关内存泄漏可归纳为三类，使用下面的故障树进行快速分类：

onDestroy中移除，再看ViewModel是否持有Context，最后排查单例。案例：在某新闻App中，MainFragment反复进出后OOM， LeakCanary显示LifecycleRegistry.mObserverMap持有2个Activity实例。

1.4 修复动作：针对三种模式的解决方案

重要提示：在修改代码前，务必通过Heap Dump确认引用链，不要盲目添加removeObserver。

泄漏模式修复方案示例代码（修复前 → 修复后）

泄漏模式	修复方案	示例代码（修复前 → 修复后）
模式1 Observer未注销	在`onDestroy`中显式调用`lifecycle.removeObserver(observer)`	`// 修复前：onDestroy中未移除 @Override public void onDestroy() { super.onDestroy(); // 缺少 removeObserver } // 修复后： @Override public void onDestroy() { super.onDestroy(); lifecycle.removeObserver(myObserver); }`
模式2 ViewModel持有Activity	使用`WeakReference<Context>`或`LiveData`间接传递，避免直接持有`Activity`	`// 修复前：DialogViewModel持有Activity public class DialogViewModel extends ViewModel { private Activity activity; } // 修复后：改用LiveData+Event包装 public class DialogViewModel extends ViewModel { private MutableLiveData<DialogEvent> event = new MutableLiveData<>(); public LiveData<DialogEvent> observeEvent() { return event; } }`
模式3 静态/单例观察	使用`Application`的`ProcessLifecycleOwner`代替，避免注册到短暂Activity；或让单例内部使用`WeakReference`	`// 修复前：单例注册了Activity的生命周期 class AnalyticsManager { void register(Activity activity) { activity.getLifecycle().addObserver(this); } } // 修复后：改用Application级别观察 class AnalyticsManager { void registerGlobal() { ProcessLifecycleOwner.get().getLifecycle().addObserver(this); } }`

模式1
Observer未注销

在onDestroy中显式调用lifecycle.removeObserver(observer)

// 修复前：onDestroy中未移除
@Override public void onDestroy() {
    super.onDestroy();
    // 缺少 removeObserver
}

// 修复后：
@Override public void onDestroy() {
    super.onDestroy();
    lifecycle.removeObserver(myObserver);
}

模式2
ViewModel持有Activity

使用WeakReference<Context>或LiveData间接传递，避免直接持有Activity

// 修复前：DialogViewModel持有Activity
public class DialogViewModel extends ViewModel {
    private Activity activity;
}

// 修复后：改用LiveData+Event包装
public class DialogViewModel extends ViewModel {
    private MutableLiveData<DialogEvent> event = new MutableLiveData<>();
    public LiveData<DialogEvent> observeEvent() { return event; }
}

模式3
静态/单例观察

使用Application的ProcessLifecycleOwner代替，避免注册到短暂Activity；或让单例内部使用WeakReference

// 修复前：单例注册了Activity的生命周期
class AnalyticsManager {
    void register(Activity activity) {
        activity.getLifecycle().addObserver(this);
    }
}

// 修复后：改用Application级别观察
class AnalyticsManager {
    void registerGlobal() {
        ProcessLifecycleOwner.get().getLifecycle().addObserver(this);
    }
}

1.5 复测：如何确认泄漏已修复？

压力测试：快速进出目标页面20次以上，操作各种导航和配置变更。
Heap Dump对比：修复前后分别抓取堆转储，对比目标Activity实例数量。
LeakCanary验证：确保LeakCanary不再报告相关泄漏；若仍报告，分析新引用链是否排除干净。
自动化测试：编写Espresso测试，反复执行页面的生命周期操作，结合Instrumentation监控Activity引用计数。

复测脚本示例：

# 快速进出页面20次，并抓取堆转储
for i in $(seq 1 20); do
  adb shell am start -n com.example.app/.MainActivity
  sleep 1
  adb shell input keyevent 4  # 返回
  sleep 0.5
done
# 最后抓取堆转储
adb shell am dumpheap com.example.app /data/local/tmp/postfix.hprof
# 分析hprof中的Activity数量
# 期望：Activity数量稳定在合理范围

1.6 预防：让Lifecycle泄漏永不发生

编码规范：团队约定所有LifecycleObserver必须在onDestroy中同步注销；使用@OnLifecycleEvent注解方式时，确保引用安全。
自动化检测：接入LeakCanary的CI流水线，每次Merge Request触发泄漏检测。
IDE检查：使用Android Lint的"LifecycleObserverCleanup"规则，开启“未注销观察者”警告。
架构反思：尽量使用LiveData或Flow替代自定义LifecycleObserver，减少手动管理生命周期。

核心原则：谁注册，谁注销。在onCreate/onStart中注册的观察者，必须在对应的onDestroy/onStop中注销，不要依赖系统自动清理。