-
概述
我们知道，页面中引用的数据放在ViewModel中，那么当ViewModel中的数据改变的时候怎样通知界面呢？我们可以通过持有Activity或者Fragment的实例来实现，但是在Android中组件实例的生命周期通常是易变的，随时可能销毁或者更改，所以按照原则，不能在生命周期长的类中引用生命周期短暂或者不可控的类的实例；并且，ViewModel中通常含有网络请求等异步操作，所以线程间异步通信也要考虑UI线程的问题，这些问题LiveData都做了很好的处理。
-
注册监听
通过调用LiveData的observe方法添加回调接口：
mViewModel.userId.observe(this, { ToastUtil.showDefaultToast(this, it) })public void observe(@NonNull LifecycleOwner owner, @NonNull Observer observer) { assertMainThread("observe"); if (owner.getLifecycle().getCurrentState() == DESTROYED) { // ignore return; } LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer); ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper); if (existing != null && !existing.isAttachedTo(owner)) { throw new IllegalArgumentException("Cannot add the same observer" + " with different lifecycles"); } if (existing != null) { return; } //添加到生命周期组件中 owner.getLifecycle().addObserver(wrapper); }回调接口owner是带有生命周期的组件实例，默认的ComponentActivity和Fragment都实现了这个接口，LifecycleBoundObserver持有了owner和observer，相当于把他们对应在一起，可见，回调接口实例被添加到了mObservers中。
-
关于数据变化的通知
在LiveData中，有两个通知改变数据的方法：setValue和postValue。但其实postValue最后也是调用了setValue：
protected void postValue(T value) { boolean postTask; synchronized (mDataLock) { postTask = mPendingData == NOT_SET; mPendingData = value; } if (!postTask) { return; } ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable); } private final Runnable mPostValueRunnable = new Runnable() { @SuppressWarnings("unchecked") @Override public void run() { Object newValue; synchronized (mDataLock) { newValue = mPendingData; mPendingData = NOT_SET; } setValue((T) newValue); } };可以看到postValue只不过是通过Handler把回调接口放在队列中，以确保在主线程执行。
所以主要看一下setValue方法：
@MainThread protected void setValue(T value) { assertMainThread("setValue"); mVersion++; mData = value; dispatchingValue(null); }注意必须是主线程，保存数据。
void dispatchingValue(@Nullable ObserverWrapper initiator) { if (mDispatchingValue) { mDispatchInvalidated = true; return; } mDispatchingValue = true; do { mDispatchInvalidated = false; if (initiator != null) { considerNotify(initiator); initiator = null; } else { for (Iterator注意此时dispatchingValue传入的是null，所以所有的mObservers中的监听回调都会被尝试执行：
private void considerNotify(ObserverWrapper observer) { if (!observer.mActive) { return; } // Check latest state b4 dispatch. Maybe it changed state but we didn't get the event yet. // // we still first check observer.active to keep it as the entrance for events. So even if // the observer moved to an active state, if we've not received that event, we better not // notify for a more predictable notification order. if (!observer.shouldBeActive()) { observer.activeStateChanged(false); return; } //决定着数据是否已更新 if (observer.mLastVersion >= mVersion) { return; } observer.mLastVersion = mVersion; observer.mObserver.onChanged((T) mData); }上面为什么说尝试呢？因为我这里看到，在开头首先会判断observer的mActive是否为true，不为true则不会执行。注意observer.mLastVersion >= mVersion的判断，这是数据更新的关键:
public LiveData(T value) { mData = value; mVersion = START_VERSION + 1; } public LiveData() { mData = NOT_SET; mVersion = START_VERSION; } @MainThread protected void setValue(T value) { assertMainThread("setValue"); mVersion++; mData = value; dispatchingValue(null); }可以看到只有在带有初始化值构造或者调用setValue方法更新值之后mVersion才会在原有基础上+1，所以每次dispatch的时候都要判断这个版本号，它决定着是否数据已更新，如果更新了才会通知回调方法执行，如果都通过了，最终执行到了我们监听回调接口的onChanged方法，显示Toast。
-
绑定监听的时候也会触发监听回调
除了setValue和postValue这种手动的通知监听的方式，当LiveData调用observe方法绑定到组件生命周期时也会触发监听回调，只不过在页面可见的时候（onStart之后）才会执行监听回调代码。
前面注册监听的时候我们看到，在observe方法中还有一句owner.getLifecycle().addObserver(wrapper)代码，用于把回调接口绑定到生命周期组件的监听回调集合里。
owner.getLifecycle()方法得到的是当前界面组件的LifecycleRegistry，看一下它的addObserver方法：
@Override public void addObserver(@NonNull LifecycleObserver observer) { State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED; ObserverWithState statefulObserver = new ObserverWithState(observer, initialState); ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver); if (previous != null) { return; } LifecycleOwner lifecycleOwner = mLifecycleOwner.get(); if (lifecycleOwner == null) { // it is null we should be destroyed. Fallback quickly return; } boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent; State targetState = calculateTargetState(observer); mAddingObserverCounter++; while ((statefulObserver.mState.compareTo(targetState) < 0 && mObserverMap.contains(observer))) { pushParentState(statefulObserver.mState); statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState)); popParentState(); // mState / subling may have been changed recalculate targetState = calculateTargetState(observer); } if (!isReentrance) { // we do sync only on the top level. sync(); } mAddingObserverCounter--; }statefulObserver持有observer的状态在当前状态不是DESTROYED的时候是INITIALIZED，不存在的情况下存入mObserverMap中，这个是生命周期组件中持有的所有监听回调的集合，targetState是生命周期组件及其父组件中最新的状态，while是判断当前的observer的状态是否在生命周期最新状态之前，把执行状态在当前状态之前的所有Observer都尝试执行dispatchEvent，并且是已添加到mObserverMap的前提下，会执行statefulObserver.dispatchEvent方法：
void dispatchEvent(LifecycleOwner owner, Event event) { State newState = getStateAfter(event); mState = min(mState, newState); mLifecycleObserver.onStateChanged(owner, event); mState = newState; }upEvent(statefulObserver.mState)：
private static Event upEvent(State state) { switch (state) { case INITIALIZED: case DESTROYED: return ON_CREATE; case CREATED: return ON_START; case STARTED: return ON_RESUME; case RESUMED: throw new IllegalArgumentException(); } throw new IllegalArgumentException("Unexpected state value " + state); }所以这里传入的event是ON_CREATE。
ObserverWithState持有的是前面传入的LifecycleBoundObserver和初始状态INITIALIZED：
ObserverWithState(LifecycleObserver observer, State initialState) { mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer); mState = initialState; }对于LifecycleEventObserver类型的observer来说，Lifecycling.lifecycleEventObserver得到的就是observer本身，所以mLifecycleObserver.onStateChanged也就是LifecycleBoundObserver的onStateChanged方法：
@Override public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) { if (mOwner.getLifecycle().getCurrentState() == DESTROYED) { removeObserver(mObserver); return; } activeStateChanged(shouldBeActive()); }看一下activeStateChanged方法：
void activeStateChanged(boolean newActive) { if (newActive == mActive) { return; } // immediately set active state, so we'd never dispatch anything to inactive // owner mActive = newActive; boolean wasInactive = LiveData.this.mActiveCount == 0; LiveData.this.mActiveCount += mActive ? 1 : -1; if (wasInactive && mActive) { onActive(); } if (LiveData.this.mActiveCount == 0 && !mActive) { onInactive(); } if (mActive) { dispatchingValue(this); } }如果mActive是true的话会执行dispatchingValue方法，mActive通过shouldBeActive()赋值：
@Override boolean shouldBeActive() { return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED); }可以看到，onStart之后才会触发事件回调。注意这里dispatchingValue传入的是this，即当前的ObserverWrapper，所以只会尝试执行当前Observer的回调。
我们可以从代码中看到，添加监听的时候会尝试dispatch回调，但是，我们前面的注册监听放在onCreate中，那么按照逻辑，在onStart之前的并不会被执行，但实际上为什么我们的监听在页面显示的时候自动执行了呢？其实自动执行是由Activity的生命周期方法触发的，使用ReportFragment来通知，ComponentActivity在onCreate的时候会调用ReportFragment.injectIfNeededIn(this)：
public static void injectIfNeededIn(Activity activity) { if (Build.VERSION.SDK_INT >= 29) { // On API 29+, we can register for the correct Lifecycle callbacks directly activity.registerActivityLifecycleCallbacks( new LifecycleCallbacks()); } // Prior to API 29 and to maintain compatibility with older versions of // ProcessLifecycleOwner (which may not be updated when lifecycle-runtime is updated and // need to support activities that don't extend from FragmentActivity from support lib), // use a framework fragment to get the correct timing of Lifecycle events android.app.FragmentManager manager = activity.getFragmentManager(); if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) { manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit(); // Hopefully, we are the first to make a transaction. manager.executePendingTransactions(); } }在sdk29以上会额外添加LifecycleCallbacks来回调，为了兼容以前的版本，下面的代码是添加一个没有任何界面的ReportFragment，只用它来处理生命周期通知的相关工作。
@Override public void onActivityCreated(Bundle savedInstanceState) { super.onActivityCreated(savedInstanceState); dispatchCreate(mProcessListener); dispatch(Lifecycle.Event.ON_CREATE); } @Override public void onStart() { super.onStart(); dispatchStart(mProcessListener); dispatch(Lifecycle.Event.ON_START); } @Override public void onResume() { super.onResume(); dispatchResume(mProcessListener); dispatch(Lifecycle.Event.ON_RESUME); } ... ... ... ...可见是利用Fragment的生命周期来处理回调，看一下dispatch方法：
private void dispatch(@NonNull Lifecycle.Event event) { if (Build.VERSION.SDK_INT < 29) { // Only dispatch events from ReportFragment on API levels prior // to API 29. On API 29+, this is handled by the ActivityLifecycleCallbacks // added in ReportFragment.injectIfNeededIn dispatch(getActivity(), event); } }可以看到，29以下的通过ReportFragment的dispatch方法发送生命周期回调通知：
static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) { if (activity instanceof LifecycleRegistryOwner) { ((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event); return; } if (activity instanceof LifecycleOwner) { Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle(); if (lifecycle instanceof LifecycleRegistry) { ((LifecycleRegistry) lifecycle).handleLifecycleEvent(event); } } }我们看到调用了LifecycleRegistry的handleLifecycleEvent方法，这个方法中又调用了moveToState方法，moveToState又调用了sync方法，在sync中会调用forwardPass或backwardPass方法，这两个方法中都会调用和前面addObserver方法中类似的代码遍历mObserverMap，对符合执行时机的Observer调用dispatchEvent方法。
所以当界面显示的时候执行onStart回调时就会再次dispatchEvent，所以我们的监听回调此时就符合了“onStart之后执行”这个触发条件。
那么29以上的生命周期回调怎么处理呢？上面的注释也有提到，是根据ActivityLifecycleCallbacks来处理的。上面我们已经看到在ComponentActivity的onCreate的时候通过ReportFragment的injectIfNeededIn方法已经添加了一个LifecycleCallbacks：
static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks { @Override public void onActivityCreated(@NonNull Activity activity, @Nullable Bundle bundle) { } @Override public void onActivityPostCreated(@NonNull Activity activity, @Nullable Bundle savedInstanceState) { dispatch(activity, Lifecycle.Event.ON_CREATE); } ... ... }然后在Activity的生命周期方法中都会调用相关的通知方法，以onStart来说：
protected void onStart() { if (DEBUG_LIFECYCLE) Slog.v(TAG, "onStart " + this); mCalled = true; mFragments.doLoaderStart(); dispatchActivityStarted(); if (mAutoFillResetNeeded) { getAutofillManager().onVisibleForAutofill(); } }其中调用了dispatchActivityStarted方法：
private void dispatchActivityStarted() { getApplication().dispatchActivityStarted(this); Object[] callbacks = collectActivityLifecycleCallbacks(); if (callbacks != null) { for (int i = 0; i < callbacks.length; i++) { ((Application.ActivityLifecycleCallbacks) callbacks[i]).onActivityStarted(this); } } }可以看到，这里调用了每个ActivityLifecycleCallbacks的onActivityStarted方法，达到了生命周期通知回调的目的。
不管是ReportFragment中生命周期方法内调用还是LifecycleCallbacks调用，最后调用的都是同一个diapatch方法，都会走到LifecycleRegistry的handleLifecycleEvent中去。
-
和组件生命周期绑定
当调用LiveData的observe方法时：
@MainThread public void observe(@NonNull LifecycleOwner owner, @NonNull Observer observer) { assertMainThread("observe"); if (owner.getLifecycle().getCurrentState() == DESTROYED) { // ignore return; } LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer); ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper); if (existing != null && !existing.isAttachedTo(owner)) { throw new IllegalArgumentException("Cannot add the same observer" + " with different lifecycles"); } if (existing != null) { return; } owner.getLifecycle().addObserver(wrapper); }LiveData里面的mObservers会保存这个observer，这是为了数据改变的时候会调用这个observer来通知界面组件更新。
同时owner.getLifecycle().addObserver(wrapper)会在界面组件的LifecycleRegistry里的mObserverMap中也会保存一个observer：
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState); ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);而这里保存就是为了在组件销毁的时候自动解除绑定，避免内存泄露。
Activity通过LifecycleRegistry来通知生命周期变化的，在它的setCurrentState方法流程中，拿前进时的生命周期方法forwardPass方法来说（backwardPass也一样）：
private void forwardPass(LifecycleOwner lifecycleOwner) { Iterator这里会读取mObserverMap中所有的Observer来调用dispatchEvent方法，前面提到addObserver的时候mObserverMap保存的是ObserverWithState，所以会调用ObserverWithState的dispatchEvent方法：
void dispatchEvent(LifecycleOwner owner, Event event) { State newState = getStateAfter(event); mState = min(mState, newState); mLifecycleObserver.onStateChanged(owner, event); mState = newState; }mLifecycleObserver就是前面构造ObserverWithState时传入的observer，也就是LifecycleBoundObserver，所以会调用它的onStateChanged方法：
@Override public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) { if (mOwner.getLifecycle().getCurrentState() == DESTROYED) { removeObserver(mObserver); return; } activeStateChanged(shouldBeActive()); }可以看到，如果当前界面组件已经销毁的话，这里会从LiveData的mObserver中移除当前的observer。
