It's not a bug, it's a feature. Read why!

观察员的方法 void onChanged(@Nullable T t) 被调用了两次。这很好。

第一次是在启动时被调用。第二次则是在Room加载完数据后立即调用。因此，在第一次调用时， LiveData 对象仍然是空的。这样设计是有原因的。

Second call

让我们从第二个电话开始，即你的第7点。替换代码2】的文件说。

当数据库更新时，Room会生成所有必要的代码来更新LiveData对象。 当数据库被更新时。生成的代码在需要时在后台线程上异步运行查询 需要时在后台线程上异步运行查询。

生成的代码是其他帖子中提到的 ComputableLiveData 类的一个对象。它管理着一个 MutableLiveData 对象。在这个 LiveData 对象上，它调用 LiveData::postValue(T value) ，然后调用 LiveData::setValue(T value) 。

LiveData::setValue(T value) 调用 LiveData::dispatchingValue(@Nullable ObserverWrapper initiator) 。这时调用 LiveData::considerNotify(ObserverWrapper observer) ，以观察者包装器为参数。最后在观察者身上调用 onChanged() ，并以加载的数据为参数。

First call

现在是第一个电话，你的第6点。

你在 onCreateView() 钩子方法中设置你的观察者。在这一点上，生命周期会改变它的状态两次，以使其可见， on start 和 on resume 。内部类 LiveData::LifecycleBoundObserver 在这种状态变化时被通知，因为它实现了 GenericLifecycleObserver 接口，它拥有一个名为 void onStateChanged(LifecycleOwner source, Lifecycle.Event event); 的方法。

这个方法调用 ObserverWrapper::activeStateChanged(boolean newActive) ，因为 LifecycleBoundObserver 扩展了 ObserverWrapper 。该方法 activeStateChanged 调用 dispatchingValue() ，后者又调用 LiveData::considerNotify(ObserverWrapper observer) ，并将观察者包装器作为参数。最后在观察者身上调用 onChanged() 。

所有这些都是在特定条件下发生的。我承认，我没有调查过方法链中的所有条件。有两个状态变化，但 onChanged() 只被触发了一次，因为条件是检查这样的事情。

这里的底线是，有一连串的方法，在生命周期的变化中被触发。这是对第一次调用的负责。

Bottomline

我认为你的代码没有任何问题。这很好，观察者在创建时被调用。所以它可以用视图模型的初始数据填充自己。这就是观察者应该做的，即使视图模型的数据库部分在第一次通知时仍然是空的。

Usage

第一个通知基本上告诉我们，视图模型已经准备好显示，尽管它还没有从底层数据库加载数据。第二个通知告诉我们，这些数据已经准备好了。

当你考虑到缓慢的数据库连接时，这是一个合理的方法。你可能想从通知触发的视图模型中检索和显示其他数据，这些数据并不来自数据库。

安卓系统有一个如何处理缓慢的数据库加载的指导原则。他们建议使用占位符。在这个例子中，差距很短，所以没有理由去做这样的事情。

Appendix

两个片段都使用它们自己的 ComputableLiveData 对象，这就是为什么第二个对象没有从第一个片段预装。

也要考虑到旋转的情况。视图模型的数据并没有改变。它不会触发一个通知。只有生命周期的状态变化才会触发新的新视图的通知。

我把Vasiliy的叉子的叉子抢过来，做了一些实际调试，看看会发生什么。

可能与ComputableLiveData将onActive()的计算卸载给Executor的方式有关。

关闭。Room的 LiveData<List<T>> 暴露的工作方式是，它创建了一个 ComputableLiveData ，它跟踪你的数据集是否在Room中被废止。

trashedNotesLiveData = NoteplusRoomDatabase.instance().noteDao().getTrashedNotes();
所以当note表被写入时，那么绑定到LiveData的InvalidationTracker将在写入发生时调用invalidate()。
  @Override
  public LiveData<List<Note>> getNotes() {
    final String _sql = "SELECT * FROM note where trashed = 0";
    final RoomSQLiteQuery _statement = RoomSQLiteQuery.acquire(_sql, 0);
    return new ComputableLiveData<List<Note>>() {
      private Observer _observer;
      @Override
      protected List<Note> compute() {
        if (_observer == null) {
          _observer = new Observer("note") {
            @Override
            public void onInvalidated(@NonNull Set<String> tables) {
              invalidate();
          __db.getInvalidationTracker().addWeakObserver(_observer);
现在我们需要知道的是，ComputableLiveData的invalidate()将实际上刷新数据集，如果LiveData是积极.
// invalidation check always happens on the main thread
@VisibleForTesting
final Runnable mInvalidationRunnable = new Runnable() {
    @MainThread
    @Override
    public void run() {
        boolean isActive = mLiveData.hasActiveObservers();
        if (mInvalid.compareAndSet(false, true)) {
            if (isActive) { // <-- this check here is what's causing you headaches
                mExecutor.execute(mRefreshRunnable);
Where liveData.hasActiveObservers() is:
public boolean hasActiveObservers() {
    return mActiveCount > 0;
So refreshRunnable 实际上 runs only if there is an 积极 observer (afaik means lifecycle is at least started, and observes the live data).
这意味着，当你在TrashFragment中订阅时，那么发生的情况是，你的LiveData被存储在Activity中，所以即使TrashFragment消失了，它也会保持活力，并保留之前的值。
However, when you open TrashFragment, then TrashFragment subscribes, LiveData becomes 积极, ComputableLiveData checks for invalidation (which is true as it was never re-computed because the live data was not 积极), computes it asynchronously on background thread, and when it is complete, the value is posted.
所以你得到两个回调，因为。
1.) 第一个 "onChanged "调用是先前保留的LiveData的值，在Activity的ViewModel中保持活力。
2.) second "onChanged" call is the newly evaluated result set from your database, where the computation was triggered by that the live data from Room became 积极.
所以从技术上讲，这是设计上的问题。如果你想确保你只得到 "最新和最大 "的价值，那么你应该使用一个片段范围的ViewModel。
你可能还想在onCreateView()中开始观察，并在你的LiveData的生命周期中使用viewLifecycle（这是一个新增加的内容，这样你就不需要在onDestroyView()中删除观察者。
If it is important that the Fragment sees the latest value even when the Fragment  is NOT 积极 and NOT observing it, then as the ViewModel is Activity-scoped, you might want to register an observer in the Activity as well to ensure that there is an 积极 observer on your LiveData.