新绑定的LiveData Observer为何被触发两次？

你对LiveData的核心理解完全正确——LiveData只会在数据当前状态发生变化时通知活跃的Observer，不会回溯发送历史状态序列。这是它专为Android生命周期设计的核心特性，和RxJava这类侧重流式事件推送的库有本质区别。

针对你描述的场景，我们可以一步步拆解逻辑：

场景回顾 #

• 初始状态：Room数据库中标记为已删除的数据为0条
• 当前活跃页面是MainFragment，TrashFragment尚未被创建（也就没有注册任何Observer到已删除数据的LiveData上）
• MainFragment执行Room写入操作，将若干未删除数据标记为已删除，此时已删除数据数量变为N条（N>0）

关键流程分析 #

1. MainFragment执行更新时：
   Room对应的查询LiveData（比如TrashFragment要观察的SELECT * FROM items WHERE is_deleted = 1）会感知到数据变化，但此时TrashFragment还不存在，没有任何Observer订阅这个LiveData，所以这次状态变化不会触发任何通知，也不会被LiveData额外缓存（LiveData仅持有当前最新数据，不会保存历史变更记录）。

2. 创建并启动TrashFragment时：
   当TrashFragment初始化并向该LiveData注册Observer（通常会绑定viewLifecycleOwner以跟随Fragment生命周期），LiveData会立即检查当前数据的最新状态（也就是已经是N条已删除数据的状态），并将这个当前最新值推送给刚注册的活跃Observer。

   这是LiveData的默认行为：只要Observer处于活跃状态（比如Fragment在onResume到onPause之间），首次注册时就会自动获取当前数据的最新值，不管这个值是在Observer注册前还是之后产生的。

代码示例参考 #

比如TrashFragment中观察已删除数据的典型实现：

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    
    // 假设ViewModel通过Repository获取到观察已删除数据的LiveData
    viewModel.deletedItems.observe(viewLifecycleOwner) { deletedItemList ->
        // 首次注册时会立即收到MainFragment修改后的最新数据列表
        trashItemAdapter.submitList(deletedItemList)
    }
}

额外注意点 #

• 如果你的需求是不想让TrashFragment收到注册前的数据变更（这种场景很少见，比如仅关注注册后的新删除操作），可以自定义LiveData来过滤这种初始推送，或者使用MediatorLiveData做二次处理。但对于回收站展示已删除数据的场景，LiveData的默认行为完全符合预期——用户打开页面就应该看到当前所有已删除的内容。
• 务必使用viewLifecycleOwner作为Observer的生命周期所有者，避免Fragment销毁后仍持有引用导致内存泄漏，同时确保只有Fragment处于活跃状态时才会收到通知。

内容的提问来源于stack exchange，提问作者Cheok Yan Cheng