Activity 生命周期概览：从创建到销毁

讲 Flow 订阅泄漏，绕不开 Activity 生命周期。为什么呢？因为大多数泄漏都发生在 Activity 重建或销毁的时候。我就吃过这个亏——好多次。

这一节我们快速过一下 Android 官方给出的六大生命周期回调。别嫌基础，我敢说你项目中至少有 30% 的泄漏都跟没理解透这几个回调的执行顺序有关。

六大回调，一个流程图

先看一张我手绘的生命周期流转图，后面所有的分析都围绕它展开。

每个回调在做什么

我把它们分成三组来说，这样你更容易记住。

为什么这跟 Flow 泄漏有关？

你想想看，一个 Flow 在 Activity 里被 collect，默认情况下会持有一个 Job。如果你在 lifecycleScope.launch 里 collect，这个 Job 的生命周期是绑定在 LifecycleOwner 上的。但如果你用 GlobalScope.launch 或者自己创建了一个 CoroutineScope 忘了取消——那么即使 Activity 调用了 onDestroy，那个协程依然在后台跑，它持有的 Activity 引用永远不会被回收。

我遇到过最典型的例子：有一个同事（嗯，就是我自己）在 onCreate 里直接启动了一个 flow.collect，用的 lifecycleScope，但他忘了用 WhenStarted 或者 repeatOnLifecycle。结果旋转屏幕时，onDestroy 被调用，但协程还在跑，因为它绑定的 Lifecycle 从 DESTROYED 变成了 INITIALIZED？不，问题出在生命周期没处理好。我们后面会细讲。

生命周期的两种流转路径

很多人只记得「创建→开始→恢复→暂停→停止→销毁」这条直线。但实际项目里还有两条重要路径：

1. 配置变更（旋转屏幕）：onPause → onStop → onDestroy → onCreate → onStart → onResume。整个 Activity 重建，所有旧引用必须完全释放。
2. 按 Home 键再返回：onPause → onStop → onRestart → onStart → onResume。注意没有 onDestroy，所以不能指望在 onDestroy 里清理所有东西。

Flow 订阅泄漏的重灾区就是路径 1。Activity 被销毁了，但协程还活着，导致旧 Activity 实例泄漏。

每个回调中 Flow 订阅的「雷区」

我把常见的错误姿势列出来，你对照一下自己的代码：

• onCreate 中启动 collect：如果你没有使用 lifecycleScope 或 viewModelScope，Activity 旋转重建时会产生多个并发的 collect 实例。我第一次做登录页面时就踩了这个坑——每次旋转都多一个网络请求。
• onResume 中启动 collect 但 onPause 没停止：这种情况会导致 collect 在 Activity 不可见时仍在执行，既浪费电量，又可能更新已经不可见的 UI（因为 View 已经 detached 了）。
• onDestroy 中才释放：对于按 Home 键再返回的场景，onDestroy 不触发，泄漏就永久存在了。

最佳实践：一张表格搞定

说白了，这一章就是要让你脑子里刻下一个印象：Activity 的每一次重建都是一次「新出生」，旧实例必须被彻底遗忘。如果旧实例还被某个 Flow 的 collect 协程引用着，那它就会变成内存里的「僵尸」，你的 App 就会越来越卡。

下一节我们正式开始分析第一个案例——在 onCreate 中直接 collect 并旋转屏幕会发生什么。这里我先留个悬念：你猜猜看，如果不用 repeatOnLifecycle，Activity 重建时会同时存在多少个并发在跑的 collect？答案会让你吓一跳。