前言
在Android推出的架构组件Architecture Components中，LiveData和ViewModel无疑是最核心的。它们最神奇的地方就在于：
- LiveData：能够在数据发生变化时及时通知View去更新界面，并且如果当界面不可见或者被销毁时，LiveData是不会通知UI的。言下之意，LiveData是能够感知生命周期的。
- ViewModel：它能够为我们保存数据，即使Activity由于某些原因需要重建，保存在ViewModel中的数据也不会因此被销毁。这带来的好处就是页面重建后，数据无需重新加载，直接用原来保存下来的数据即可。
但其实在它们的背后还有一个默默付出的Lifecycle，可以说Lifecycle才是这个架构的灵魂。
Lifecycle
前面说了，LiveData是可以感知Android生命周期的，而LiveData是通过Lifecycle来感知生命周期的。从Lifecycle的字面意思来看，它就是跟生命周期有直接关系的。我们知道，具有Android生命周期的最常见的就是Activity和Fragment。所以要想了解LiveData，需要先了解Android的生命周期是如何传递给Lifecycle的才行。下面这些例子都是以Fragment来展开分析的。
在刚接触这个框架的时候，出现了很多与Lifecycle有关的类，比如说：LifecycleOwner, LifeCycle, LifecycleRegistry, LifecycleObserver...讲真的，对于一个不熟悉的东西，一下子又扔过来这么几个看起来有点关联的东西，头是有点大的。所以有必要花些时间来理一理这些东西先。先上一张类图（这里只是把一些比较重要的属性和方法罗列出来）：
- LifecycleOwner：这是一个接口，它只有一个方法
getLifecycle()。从名字上理解它就是一个拥有生命周期的组件，比如说Fragment，所以Fragment实现了这个接口，也可以这么理解，Fragment就是一个生命周期的拥有者。 - Lifecycle：这是一个抽象类。主要是添加和移除观察者，和获得当前生命周期的状态。它还有两个内部的枚举类：State和Event，分别表示生命周期的状态和相应的事件。
- LifecycleObserver：这是一个接口，并且是空的，暂时知道它是一个观察者就好了。
- LifecycleRegistry：这个类继承了Lifecycle类并实现了所有的方法。成员变量
mObserverMap用来管理观察者队列。handleLifecycleEvent()方法用来设置当前的生命周期状态，并通知观察者更新状态。LifecycleOwner需要通过handleLifecycleEvent()这个方法，将自己的生命周期状态传递给Lifecycle，从而让Lifecycle拥有感知生命周期的能力。 - Fragment：它有一个
mLifecycleRegistry属性, 类型正是Lifecycle。实现的getLifecycle()就是返回了mLifecycleRegistry。
用一句话来解释它们之间的联系就是：Fragment是一个LifecycleOwner，它在自己的生命周期的各个阶段中，通过mLifecycleRegistry，将自己的状态告诉了Lifecycle，让Lifecycle拥有了感知生命周期的能力。
讲到这里了，再来深入一下研究LifecycleRegistry$handleLifecycleEvent()这个方法吧。看之前得先知道下mObserverMap的结构。
private FastSafeIterableMap mObserverMap =
new FastSafeIterableMap<>();
这是一个特殊的Map，它能够在遍历的时候执行添加或者删除操作。它的key值是LifecycleObserver，没什么好说的。value值是ObserverWithState，在addObserver()的时候，会将LifecycleObserver和初始状态State封装成一个ObserverWithState然后放进value值中。OK，这只是一个小插曲而已，有助于我们后面的理解，接着进入正题吧。
/**
* Sets the current state and notifies the observers.
*
* Note that if the {@code currentState} is the same state as the last call to this method,
* calling this method has no effect.
*
* @param event The event that was received
*/
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
State next = getStateAfter(event);
moveToState(next);
}
收到一个事件后，根据当前的事件获取下一个状态，然后跳转到下一个状态。
private void moveToState(State next) {
if (mState == next) {
return;
}
mState = next;
if (mHandlingEvent || mAddingObserverCounter != 0) {
mNewEventOccurred = true;
// we will figure out what to do on upper level.
return;
}
mHandlingEvent = true;
sync();
mHandlingEvent = false;
}
代码也很简单，一眼就能看出重点在sync()方法上。
private void sync() {
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
Log.w(LOG_TAG, "LifecycleOwner is garbage collected, you shouldn't try dispatch "
+ "new events from it.");
return;
}
while (!isSynced()) {
mNewEventOccurred = false;
// no need to check eldest for nullability, because isSynced does it for us.
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
backwardPass(lifecycleOwner);
}
Entry newest = mObserverMap.newest();
if (!mNewEventOccurred && newest != null
&& mState.compareTo(newest.getValue().mState) > 0) {
forwardPass(lifecycleOwner);
}
}
mNewEventOccurred = false;
}
方法内先是判断LifecycleOwner是否被回收，接着再判断所有的观察者状态是否都同步了。判断依据是最新的观察者和最老的观察者之间状态是否一致。
private boolean isSynced() {
if (mObserverMap.size() == 0) {
return true;
}
State eldestObserverState = mObserverMap.eldest().getValue().mState;
State newestObserverState = mObserverMap.newest().getValue().mState;
return eldestObserverState == newestObserverState && mState == newestObserverState;
}
如果还没有完成同步，则走while循环继续同步。可以看到循环体内有backwardPass()和forwardPass()，我们只看一个就好了，之所以会有两个，是因为FastSafeIterableMap这个数据结构的特性决定的。
private void backwardPass(LifecycleOwner lifecycleOwner) {
Iterator> descendingIterator =
mObserverMap.descendingIterator();
while (descendingIterator.hasNext() && !mNewEventOccurred) {
Entry entry = descendingIterator.next();
ObserverWithState observer = entry.getValue();
while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey()))) {
Event event = downEvent(observer.mState);
pushParentState(getStateAfter(event));
observer.dispatchEvent(lifecycleOwner, event);
popParentState();
}
}
}
外面的都是一些判断，直接看到observer.dispatchEvent(lifecycleOwner, event)这里，看到dispatchXXX有没有觉得有点熟悉和激动？需要注意的是这里的observer是一个ObserverWithState来着。
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
看到这里，总算可以有个了结了。LifecycleObserver通过onStateChanged()方法将状态改变发送给了观察者，观察者由此可以得知Android生命周期的变化。
等等，好像哪里不对。上面不是说LifecycleObserver是一个空接口吗？怎么这里就冒出了onStateChanged()这个方法来了？这不是打自己的脸吗？
其实这里的LifecycleObserver是一个LifecycleEventObserver，也是一个接口来着，继承了LifecycleObserver，另外还有一个FullLifecycleObserver也继承了LifecycleObserver。
展望未来
这里仅仅只是做了一个开篇，为接下来分析LiveData和ViewModel做铺垫，为了不让自己拖太久，先来一篇Lifecycle的分析打打鸡血。