Fragment 收集 Flow 时 binding 空指针：把界面订阅绑定到 View 生命周期

页面第一次打开正常，跳到下一页再返回却在 binding.status.text = ... 处崩溃，堆栈指向 _binding!!。如果 Flow 在 Fragment 的 lifecycleScope 中收集，而 _binding 在 onDestroyView() 清空，需要先区分 Fragment 和它的 View 两套生命周期。

Fragment 实例可以比当前 View 活得更久。View 被销毁时，Fragment 的协程作用域未必已经取消；旧订阅仍可能收到数据，尝试读取已经清空的 binding。再次创建 View 后，旧订阅还可能与新订阅一起更新页面。

下文针对 AndroidX Fragment、View Binding 与 Kotlin Flow，使用 Lifecycle 2.4.0 及以上的 repeatOnLifecycle。示例假定项目已启用 View Binding，并具备 Fragment KTX、Lifecycle Runtime KTX、ViewModel 和协程依赖；依赖版本应与项目现有 AndroidX 组合兼容。

对照崩溃点确认作用域和 View 的寿命

检查三个位置：onViewCreated 中由谁启动订阅；collect 内是否访问 View 或 binding；onDestroyView 是否清空了 binding。下面这段写法的作用域属于 Fragment：

// 反例：即使写在 onViewCreated 中，作用域也没有自动变成 View 的。
lifecycleScope.launch {
    viewModel.title.collect { value ->
        binding.status.text = value
    }
}

只把代码挪到 onViewCreated 不会改变 scope。应使用 viewLifecycleOwner.lifecycleScope；若希望页面不可见时停止收集，再配合当前 View 的 repeatOnLifecycle(STARTED)。scope 决定最终何时取消，repeatOnLifecycle 决定在这段寿命内何时开始和停止。

用当前 View 的 owner 启动一次可重启订阅

下面示例用布局文件 fragment_status.xml 生成 FragmentStatusBinding。将包名 com.example.app.databinding 替换为项目自己的 namespace；布局中的 TextView ID 为 status：

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <TextView
        android:id="@+id/status"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />
</FrameLayout>

模块的 android 配置中需启用 buildFeatures { viewBinding = true }。以下 ViewModel 提供一份当前状态，Fragment 只订阅并展示它：

import android.os.Bundle
import android.view.LayoutInflater
import android.view.View
import android.view.ViewGroup
import androidx.fragment.app.Fragment
import androidx.fragment.app.viewModels
import androidx.lifecycle.Lifecycle
import androidx.lifecycle.ViewModel
import androidx.lifecycle.lifecycleScope
import androidx.lifecycle.repeatOnLifecycle
import com.example.app.databinding.FragmentStatusBinding
import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.StateFlow
import kotlinx.coroutines.flow.asStateFlow
import kotlinx.coroutines.flow.collect
import kotlinx.coroutines.launch

class StatusViewModel : ViewModel() {
    private val _title = MutableStateFlow("等待数据")
    val title: StateFlow<String> = _title.asStateFlow()

    fun updateTitle(value: String) {
        _title.value = value
    }
}

class StatusFragment : Fragment() {
    private var _binding: FragmentStatusBinding? = null
    private val binding get() = checkNotNull(_binding)
    private val viewModel: StatusViewModel by viewModels()

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        _binding = FragmentStatusBinding.inflate(inflater, container, false)
        return binding.root
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        viewLifecycleOwner.lifecycleScope.launch {
            viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.title.collect { value ->
                    binding.status.text = value
                }
            }
        }
    }

    override fun onDestroyView() {
        super.onDestroyView()
        _binding = null
    }
}

每次 View 创建时建立这一份订阅。View 低于 STARTED 后取消收集，再回到该状态时重新收集；销毁 View 时，属于它的 scope 也会取消。新 View 会有自己的 owner，不应把旧 owner 或 binding 长期保存在 ViewModel 中。

不要在 onStart 或 onResume 每次再创建一组 repeatOnLifecycle。它本身会随状态重启，重复注册可能得到多个订阅。清空 binding 仍需保留，不能用一直持有旧 View 的办法消除空指针。

多个 Flow 要分别启动子协程

在一个 repeatOnLifecycle 块里先 collect 长期运行的 StateFlow，再顺序 collect 第二个 Flow，第二个通常不会执行到。若两份数据都需要持续收集，应在该块中分别启动：

// uiState 和 messages 为业务中已有的两份 Flow。
viewLifecycleOwner.lifecycleScope.launch {
    viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
        launch { uiState.collect { state -> render(state) } }
        launch { messages.collect { message -> showMessage(message) } }
    }
}

这里的 render、showMessage 是项目自己的界面方法，不能直接照搬为现成 API。两个子协程都属于本次生命周期块，停止收集时一起取消。不要改成 GlobalScope 或额外独立 scope 绕开这个约束。

仍有回调到达时，检查它是否真的属于订阅协程

改完 scope 后仍崩溃，要核对堆栈是不是其他监听器、网络回调、finally 清理或另一个旧订阅。协程取消有协作性；自行吞掉取消异常、使用不可取消区间更新 UI，或把 binding 捕获到不受管理的回调，都可能越过这条边界。清理阶段可以释放资源，不能无条件继续更新已销毁的 View。

_binding?.status?.text = value 只能让一次无效访问被跳过，不能证明旧订阅已经释放。使用内存分析工具检查时，还应确认旧 View 没有被外部监听器、Adapter 或长寿命对象继续持有。

订阅停止也会改变数据接收时机。StateFlow 在重新收集时提供当前值，适合页面状态；没有重放的事件流可能错过页面停止期间的事件。需要持续完成的保存、上传等工作应放到适当的业务作用域，由页面观察结果，不能因为界面停止订阅就假定操作已经完成或应当取消。

验收时走完“打开页面、离开、期间数据变化、返回、再次离开”，检查没有 binding 异常、没有重复渲染，返回后能显示最新状态。若恢复旧代码，也要继续保留 binding 清理，并明确取消旧订阅；不能用删除 _binding = null 作为回退办法。