往期文章：
你好，我是朱涛。最近我打算系统化梳理下 Android Jetpack 的一些核心组件。在上一篇博客《深入理解 Jetpack Lifecycle（用法篇）》当中，我简单介绍了 Jetpack Lifecycle 的用法，今天我们来看看 Lifecycle 的底层原理。
如果你对 Lifecycle 的底层逻辑非常清楚，那么下面这张动图的逻辑你一看就会懂。如果看不懂呢？没关系，坚持看到最后，相信你会有所收获的。
在Jetpack这个系列博客里，我们会着重探索Jetpack核心组件的原理，Lifecycle的原理更是重中之重。
我们只有透彻理解Lifecycle，才能更好理解其他架构组件。由于Lifecycle和Activity的源码每个版本都不一样，大家跟着我的博客先理解整体思路，以后自己去看源码就不会慌了。
LifecycleOwner ，LifecycleObserver，Lifecycle
Lifecycle组件的设计，是典型的面向抽象编程的设计。在整个Lifecycle组件中，最核心的就是这三个核心成员：LifecycleOwner ，LifecycleObserver，Lifecycle。它们当中两个是接口，还有一个是抽象类。Lifecycle通过它们三个制定了一套抽象的规则。
LifecycleOwner，它是一个接口，作为生命周期的宿主，即拥有生命周期的主体，代表我们的Activity、Fragment，它会产生生命周期事件，作为被观察者。
LifecycleObserver，它是一个接口，作为生命周期的监听者。看到这里你应该马上能想到：这是典型的观察者模式，它订阅Activity、Fragment的生命周期状态。而我们前面使用的DefaultLifecycleObserver也是属于这一范畴。这样子，我们的“被观察者”、“观察者”就都有了。
Lifecycle，它是一个抽象类，作为LifecycleOwner和LifecycleObserver它们之间连接的桥梁，也就是“被观察者”和“观察者”它们两者之间的桥梁。它的作用是维护它们之间的订阅关系，帮助分发订阅事件。
有趣的是，Lifecycle三个接口之间的关系，和我们之前画的图结构非常类似。这并不是巧合，因为它们背后的思想都是一样的：都是通过增加一层抽象，将两个原本不相干的两组事物连接了起来。这样的例子在计算机世界里数不胜数。
现在我们已经从整体的角度对LifecycleOwner ，LifecycleObserver，Lifecycle这三个接口有了一定了解，接下来我们一个个分析它们的源码。
public interface LifecycleOwner {
@NonNull
Lifecycle getLifecycle();
}
从以上代码我们可以看到，LifecycleOwner接口很简单，它只有一个方法：“getLifecycle”，返回对象的类型是“Lifecycle”，我们回过头看上面的结构图就会发现，它们的角色分别是“被观察者”、“连接桥梁”。
这个接口从抽象层面上定义了它们两者之间的关系：LifecycleOwner持有Lifecycle，并且LifecycleOwner提供了一个公开的方法能够对外暴露Lifecycle。对应到具体的代码当中，这个接口的含义就变成了这样：Activity、Fragment拥有生命周期，它们作为LifecycleOwner，即“被观察者”，它们对外提供生命周期事件。具体怎么提供呢？通过将内部持有的桥梁“Lifecycle”暴露出来，方便其他观察者来订阅。
到目前为止，我们以上结构图的上半部分就已经得到印证了：
接下来，让我们来看看Lifecycle的源码，它的源码有大约300行，我们一点点来分析。首先我们来看看它作为连接LifecycleOwner和LifecycleObserver的桥梁，会有哪些方法：
public abstract class Lifecycle {
// 省略部分代码
public abstract void addObserver(LifecycleObserver observer);
public abstract void removeObserver(LifecycleObserver observer);
public abstract State getCurrentState();
}
看到这里，你应该就恍然大悟了。正如我们前说过的，Lifecycle就是连接LifecycleOwner和LifecycleObserver的桥梁。怎么连接的？就是通过addObserver、removeObserver这两个抽象方法来实现的，这两个方法的参数类型正好就是LifecycleObserver。
所以，我们之前画的结构的下半部分也得到印证了：
所以，我们可以看出来，Lifecycle这个抽象类在整个组件当中扮演了一个“承上启下”的角色。Lifecycle这个抽象类的源码较多，在深入挖掘Lifecycle之前，我们先来看看LifecycleObserver的源码。
public interface LifecycleObserver {
}
LifecycleObserver这个接口居然是空的。
你大可不必觉得意外，Android团队这么设计是有原因的。在前面的使用案例当中，我们的LocationManagerAnnotation就是直接实现的这个接口。如果你足够细心，你就会注意到：LocationManagerAnnotation这个类里面并没有实现任何生命周期函数的回调。因为我们完全不需要这些回调，我们直接在start、stop函数上使用了“OnLifecycleEvent”这个注解，以这种方式绑定了生命周期回调。这就是LifecycleObserver接口为空的第一个原因：通过注解处理器，我们并不需要任何形式的生命周期回调接口。
LifecycleObserver接口为空的第二个好处，它可以作为“观察者最底层的抽象”。这句话的意思是说，LifecycleObserver可以有很多的“子接口”，其他“子接口”完全可以在它的基础上做扩展，用于提供所需的生命周期回调。源码当中的FullLifecycleObserver、LifecycleEventObserver、DefaultLifecycleObserver都是在这个基础上扩展出来的。我们甚至还在前面的案例当中使用过DefaultLifecycleObserver。
public interface LifecycleEventObserver extends LifecycleObserver {
void onStateChanged(LifecycleOwner source, Lifecycle.Event event);
}
至此，LifecycleOwner、Lifecycle、LifecycleObserver它们三者之间的关系，我们就梳理清楚了。同时，由于前面的案例当中我们已经使用过自定义的LifecycleObserver，所以接下来就只剩下LifecycleOwner、Lifecycle的具体细节了。
Activity、Fragment如何实现LifecycleOwner？
我们都知道，LifecycleOwner只是一个接口，它代表了生命周期的宿主，即拥有生命周期回调的组件。它只是一个抽象的定义，而Activity、Fragment才是它的具体实现。这也就意味着，Activity、Fragment必须要实现这两个接口。对应的源码我们也非常容易找到。
public class ComponentActivity extends androidx.core.app.ComponentActivity implements
LifecycleOwner
{
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
// 省略无关代码
}
Fragment当然也必须实现LifecycleOwner接口。
public class Fragment implements LifecycleOwner {
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
// 省略无关代码
}
需要注意的是，以上的ComponentActivity和Fragment都是来自androidx这个包下面的，不是Android系统源码。Androidx相当于是从前support库的升级。
到目前为止，LifecycleOwner的实现，以及LifecycleObserver的实现，我们都已经接触过了，然而我们还并没有接触到整个组件的核心。现在就只剩下Lifecycle这个抽象类了，它才是整个组件的核心。
Lifecycle与LifecycleRegistry
前面我们已经分析过了Lifecycle的几个方法：addObserver、removeObserver、getCurrentState，这是整个架构当中承上启下的纽带。不过，Lifecycle这个抽象类里面的代码远不止这些。比如说，这里面还定义了State，也就是getCurrentState这个方法需要返回的类型：
//代码：Lifecycle.java
public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
public boolean isAtLeast(@NonNull State state) {
return compareTo(state) >= 0;
}
}
- State是一个枚举类，它代表着LifecycleOwner的生命周期状态。让我们一个个来分析：
- INITIALIZED状态，代表了LifecycleOwner已经被实例化了，举个例子，如果是Activity，这就代表了Activity已经被创建了，但它的onCreate生命周期方法还没执行。
- CREATED状态，这里需要注意，它并不是代表了onCreate执行后的所有状态。准确来讲，它代表了“onCreate生命周期后，一直到onStart生命周期前”以及“onStop生命周期后，一直到onDestroy生命周期前”的状态。
- STARTED状态，也需要注意，它并不代表onStart生命周期后的所有状态。你应该猜到了，它代表了“onStart生命周期后，一直到onResume生命周期前”以及“onPause生命周期后，一直到onStop生命周期前”的状态。
- RESUMED状态，则容易理解一些，它代表了“onResume生命周期，一直到onPause生命周期之前”的状态。
- DESTROYED状态，则更容易理解了，它代表Activity之类的组件被销毁后的状态，也就是onDestroy生命周期后的状态。我们的组件一旦到达这个状态，Lifecycle组件内的生命周期事件将停止转发，也就是说，LifecycleObserver将不再收到任何订阅消息。
Lifecycle这个抽象类的内部，除了State这个枚举类以外，还有一个Event枚举类。State代表的生命周期的状态，Event则代表的生命周期事件本身。
// 代码：Lifecycle.java
public enum Event {
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY;
}
对于Event里面的枚举，想必你一看就能明白。唯一比较特殊的就是ON_ANY这个Event。我们Android开发者并不会直接使用它，它是用于在注解处理器内匹配任意其他状态的。看到这里，我们就不难理解Android官网上面的这张状态图了：
Lifecycle这个抽象类里比较关键的代码我们差不多就分析清楚了。但是不要忘了，它是一个抽象类，抽象类在Java当中是不能直接用的，必须要有一个类继承自它，实现它的抽象方法才行。这时候，轮到Lifecycle里最关键的类出场了，那就是LifecycleRegistry。
在这个类当中，它不仅实现了addObserver、removeObserver、getCurrentState这几个抽象方法。同时，它还负责了观察者的维护，以及生命周期的监听，还有对应生命周期变更事件的派发。可以说，这个类是整个Lifecycle组件当中最核心的类。与此同时，这个部分的代码也是最难理解的。
让我们将其中最核心的代码抽出来一点点来消化：
// 代码：LifecycleRegistry.java
public class LifecycleRegistry extends Lifecycle {
private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap = new FastSafeIterableMap<>();
private State mState;
private final WeakReference<LifecycleOwner> mLifecycleOwner;
private ArrayList<State> mParentStates = new ArrayList<>();
public void addObserver(LifecycleObserver observer) {
// 省略代码
}
public void removeObserver(LifecycleObserver observer){
// 省略代码
}
public State getCurrentState(){
// 省略代码
}
}
我们先从成员变量开始看：
- 第一个重要成员，mObserverMap，它的本质是一个简版的LinkedHashMap，里面以Key-Value的形式存放着LifecycleObserver和它对应的状态ObserverWithState。这里的ObserverWithState是LifecycleRegistry里的一个静态内部类。它是由LifecycleObserver以及State组成的一个新的类。这样的设计让它既是Observer同时还拥有自己的状态。在后面的内容当中，我们会深入分析ObserverWithState。
- 第二个重要成员，mState，它的类型是State，这个枚举类我们在前面介绍过，它里面有一系列代表宿主状态的值。很明显，mState就是代表着宿主生命周期状态的成员变量。
- 第三个重要成员，mLifecycleOwner，它的类型是LifecycleOwner。需要注意的是，这个变量是由WeakReference<*>包裹的，这样的设计是为了防止内存泄漏。我们都知道LifecycleOwner只是一个接口，而在代码实际运行的时候，它将会是Activity或者是Fragment的实例。
- 第四个重要成员，mParentStates，它的类型是ArrayList，这是一个线性数据结构，在LifecycleRegistry的源码当中，被当做栈在使用。栈顶的存放的状态，永远是最近处理过的Observer的state。而且mParentStates的入栈与出栈都是成对出现的。
接着，让我们来看看addObserver方法的具体实现。
// 代码：LifecycleRegistry.java
public class LifecycleRegistry extends Lifecycle {
public void addObserver(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;
}
// 初始化判断，结束
// 状态对比和分发，开始
// 代码暂时省略，后面解释
// 状态对比和分发，结束
}
}
由于addObserver的代码量较大，我们根据它的逻辑分为两个部分来看，第一个部分是：初始化判断，第二个部分是：状态对比与分发。
- 第一个部分，初始化判断。首先是initialState，我们根据当前宿主的生命周期mState来判断当前宿主是否已经处于DESTROYED状态，如果是，则initialState也会被赋值为DESTROYED状态。这样一来，我们的来，我们的Observer虽然还是会继续被添加，但由于它的初始状态就是DESTROYED，它将不会分发任何生命周期事件。
- 接着就是statefulObserver，它的类型是ObserverWithState，我们通过构造函数来实例化这个变量，传入的参数是Observer以及initialState。它是State和Observer的结合体，它是一个静态内部类，定义LifecycleRegistry当中。在让我们看看它的具体定义：
// 代码：LifecycleRegistry.java
public class LifecycleRegistry extends Lifecycle {
// 省略代码
static class ObserverWithState {
State mState;
LifecycleEventObserver mLifecycleObserver;
ObserverWithState(LifecycleObserver observer, State initialState) {
mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
mState = initialState;
}
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = event.getTargetState();
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}
}
我们可以看到，构造函数里作为参数传进来的observer，最终被传入到了“Lifecycling.lifecycleEventObserver”这个方法当中，并且返回了一个LifecycleEventObserver对象。这里面使用了适配器模式，后面我们会再介绍Lifecycling这个类里面的细节。
让我们回到addObserver方法的分析，statefulObserver变量的初始化完成以后。之后我们就需要将observer与statefulObserver它们两个作为Key-Value存放到mObserverMap当中。前面我们说过，它是一个简版的LinkedHashMap，它的方法“putIfAbsent”的作用是，在存储之前，先看看是否已经存在对应的Key，如果是，则返回对应的Value。如果不存在，就将Value存放进去，最后返回null。
所以，previous这个变量如果等于null，就代表当前observer以前没添加过。反之，则代表当前这个observer已经存在了。对于已经存在的observer我们当然是不希望重复处理的，所以这个是否会根据previous判断，执行return，结束整个函数的执行。
最后则是lifecycleOwner，我们是通过弱引用持有的Activity或者Fragment，它的特性决定了这个实例不会阻止垃圾回收。如果弱引用当中的Activity或者Fragment已经变成null了，这也说明当前的宿主已经被销毁了。这时候我们也应该return，结束整个函数的执行。
接下来我们看看第二部分，状态对比和分发：
代码：LifecycleRegistry.java
public class LifecycleRegistry extends Lifecycle {
public void addObserver(LifecycleObserver observer) {
// 初始化判断，开始
// 省略，刚分析完
// 初始化判断，结束
// 状态对比和分发，开始
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
State targetState = calculateTargetState(observer);
mAddingObserverCounter++;
while ((statefulObserver.mState.compareTo(targetState) < 0
&& mObserverMap.contains(observer))) {
pushParentState(statefulObserver.mState);
final Event event = Event.upFrom(statefulObserver.mState);
if (event == null) {
throw new IllegalStateException("no event up from " + statefulObserver.mState);
}
statefulObserver.dispatchEvent(lifecycleOwner, event);
popParentState();
// mState / subling may have been changed recalculate
targetState = calculateTargetState(observer);
}
if (!isReentrance) {
// we do sync only on the top level.
sync();
}
mAddingObserverCounter--;
}
// 状态对比和分发，结束
}
首先，是状态对比前的一些准备工作。第一个变量是isReentrance，它标记了我们的addObserver函数是否发生了重入。我们根据当前正在添加的观察者数量，以及是否正在处理生命周期事件，这两个指标，来判断是否需要在后面的while循环里对所有的Observer同步。isReentrance的逻辑是，如果当前正在添加的Observer数量大于0，或者当前正在处理生命周期事件，那么就不对Observer做整体的同步。这两个判断主要是防止在多线程的情况下出现重入而导致的问题。最新版本的Lifecycle已经强制要求addObserver等相关函数必须在主线程执行，因此理想情况下，isReentrance会一直出于false状态。
接着是targetState，它代表了新添加的这个statefulObserver的目标状态。statefulObserver的内部还维护着初始状态。targetState是通过calculateTargetState这个方法计算出来的。
接下来的while循环，就是状态对比和分发的核心了。在while循环前面和后面，分别有两行代码对mAddingObserverCounter进行了加一和减一的操作。这正好就是判断addObserver函数是否已发生重入的标准之一。
接着，我们在while循环的判断条件里对比statefulObserver以及targetState，如果statefulObserver的生命周期状态落后了，我们就需要将statefulObserver的状态一步步提升起来。正常情况下，statefulObserver刚创建的时候，它的状态都是INITIALIZED。如果当前宿主的生命周期是RESUMED状态，那么这就意味着，我们的程序需要分发出以下几个事件：ON_CREATE、ON_START、ON_RESUME。
它具体的逻辑是，通过“Event.upFrom”这个方法，计算出statefulObserver移动到下一个状态所对应的Event。随后对这个Event做了一个判断，看它是否为空。接着就是最关键的分发生命周期事件的代码：“statefulObserver.dispatchEvent”。这个方法的源代码我们前面已经提供过了，它的作用就是，更新statefulObserver内部的状态，同时将这个生命周期事件分发给它对应的LifecycleObserver。
随着while循环一次次的执行，statefulObserver内部的状态，会一步步从INITIALIZED变成：CREATED、STARTED、RESUMED。这样，我们刚通过addObserver方法添加进来的观察者就已经成功接受到了之前的生命周期状态了。
从这里我们也能看出，即使我们在Activity的onResume生命周期后才调用addObserver。我们的观察者照样可以接受到onCreate、onStart之类的生命周期回调。
最后，当我们跳出while循环以后，程序来到最后的sync函数。这个函数是用来同步所有Observer和生命周期状态的。我们将在后面的内容里再介绍它。
生命周期是如何传递的？
到目前为止，我们已经分别研究了LifecycleOwner、Lifecycle、LifecycleObserver，以及它们对应的实现类。同时也分析了addObserver的流程，也知道了LifecycleRegistry是如何维护我们的观察者集合的。不过，我们仍然不知道生命周期函数是如何从Activity当中传递到LifecycleRegistry的。
实际上，ComponentActivity的源码中就有明确的答案。
代码：ComponentActivity.java
protected void onCreate(Bundle savedInstanceState) {
// 省略
ReportFragment.injectIfNeededIn(this);
}
如果你看过其他开源项目，你一定不会对这样的代码感到陌生。这个ReportFragment，就承担着收集Activity生命周期的职责，负责将Activity的生命周期转发给LifecycleRegistry。
让我们来看看ReportFragment内部的具体逻辑。
代码：ReportFragment.java
public static void injectIfNeededIn(Activity activity) {
if (Build.VERSION.SDK_INT >= 29) {
ReportFragment.LifecycleCallbacks.registerIn(activity);
}
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();
}
}
当系统版本大于等于29的时候，ReportFragment 通过直接注册一个生命周期监听的方式来捕获Activity的生命周期事件，这是新版本的特性。对于低于29的系统，我们直接往Activity里注入一个Fragment，也就是ReportFragment自身。考虑到ReportFragment并没有实际View需要展示，因此，它只是单纯的为了监听Activity生命周期而存在的。毕竟，当Activity生命周期发生改变的时候，出于Activity内部的ReportFragment马上就能接受到对应的生命周期回调了。
让我们看看ReportFragment的生命周期回调函数里做什么事情。
代码：ReportFragment.java
@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);
}
@Override
public void onPause() {
super.onPause();
dispatch(Lifecycle.Event.ON_PAUSE);
}
@Override
public void onStop() {
super.onStop();
dispatch(Lifecycle.Event.ON_STOP);
}
@Override
public void onDestroy() {
super.onDestroy();
dispatch(Lifecycle.Event.ON_DESTROY);
// just want to be sure that we won't leak reference to an activity
mProcessListener = null;
}
我们可看到，在ReportFragment的生命周期函数当中，它直接将对应的生命周期做了转发。最终dispatch函数会调用到LifecycleRegistry当中的handleLifecycleEvent方法。所以，绕了一圈后，我们又回到了LifecycleRegistry。
代码：LifecycleRegistry.java
public void handleLifecycleEvent(Lifecycle.Event event) {
enforceMainThreadIfNeeded("handleLifecycleEvent");
moveToState(event.getTargetState());
}
private void moveToState(Lifecycle.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;
}
在handleLifecycleEvent方法里面它只是简单的对线程做了一个检查，然后将所有的事情都交给了moveToState这个方法。
在moveToState这个方法里面，我们一行行分析。首先，它对比了当前状态和目标状态，如果两者已经一样了，那就没有必要继续进行了。接着，做了一个判断，“mHandlingEvent || mAddingObserverCounter != 0”这个判断的逻辑和addObserver方法里面判断重入的逻辑是一样的。它的意思就是，如果发生了重入，那么我们就直接结束这个方法的执行。
最后，就是这个sync方法。
代码：LifecycleRegistry.java
private void sync() {
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
// throw exception
}
while (!isSynced()) {
mNewEventOccurred = false;
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
backwardPass(lifecycleOwner);
}
Map.Entry<LifecycleObserver, LifecycleRegistry.ObserverWithState> newest = mObserverMap.newest();
if (!mNewEventOccurred && newest != null
&& mState.compareTo(newest.getValue().mState) > 0) {
forwardPass(lifecycleOwner);
}
}
mNewEventOccurred = false;
}
让我们来梳理一下前面所有的代码逻辑，从而帮助我们更好的分析sync函数。
首先，在ComponentActivity的onCreate函数当中，我们通过ReportFragment来捕获Activity的生命周期。在ReportFragment的生命周期函数当中，我们通过dispatch方法将生命周期事件传递给了LifecycleRegistry。
这时候，假设我们这时候捕获到的是Activity的onResume事件。那么当程序执行到sync的时候，mState已经是RESUMED 状态了。但是mObserverMap当中所有的ObserverWithState对象，它们里面的状态仍然停留在STARTED状态。它们状态不一样，准确来说，Observer当中的状态滞后了。
让我们看看sync函数的while循环里都做了什么。while循环的执行条件是“!isSynced()”，意义也很明显，只要mObserverMap与mState之间的状态没有同步，循环就一直执行。
而循环体内部的代码逻辑，其实很简单，那就是判断当前mObserverMap的状态是超前与mState，还是滞后于mState。如果是超前，那就会执行“backwardPass”，如果是滞后，那就会执行“forwardPass”。从我们刚刚举的例子来看，mObserverMap很明显是滞后于mState的。所以，最终sync函数会执行“forwardPass(lifecycleOwner)”这行代码。
代码：LifecycleRegistry.java
private void backwardPass(LifecycleOwner lifecycleOwner) {
while (descendingIterator.hasNext() && !mNewEventOccurred) {
// 省略
while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred && mObserverMap.contains(entry.getKey()))) {
// 省略
pushParentState(event.getTargetState());
observer.dispatchEvent(lifecycleOwner, event);
popParentState();
}
}
}
void dispatchEvent(LifecycleOwner owner, Lifecycle.Event event) {
Lifecycle.State newState = event.getTargetState();
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
forwardPass这个函数当中，有两个while循环，它会遍历mObserverMap当中所有的Observer，将它们的生命周期调整到与mState一致。在调整Observer状态的同时，也会通过observer.dispatchEvent，将对应的生命周期事件分发出去，最终调用“mLifecycleObserver.onStateChanged(owner, event)”方法。以我们刚刚举的例子来看，被分发出去的生命周期事件将会是：ON_RESUME。
分析到这里，我们就只剩下最后一个问题了，mLifecycleObserver.onStateChanged是如何将生命周期事件传递给我们的LifecycleObserver。换个说法，生命周期事件是如何传递到我们示例代码LocationManagerDefault当中来的？ 它里面的onStart、onStop方法为什么会接受到生命周期事件？这里貌似还没有完全连接上。
代码：LifecycleExampleActivity.kt
internal class LocationManagerDefault(
private val context: Context,
private val callback: (Location) -> Unit
): DefaultLifecycleObserver {
override fun onStart(owner: LifecycleOwner) {
start()
}
override fun onStop(owner: LifecycleOwner) {
stop()
}
private fun start() {
// 使用高德之类的 SDK 请求地理位置
}
private fun stop() {
// 停止
}
}
这就不得不说说Lifecycling这个工具类的lifecycleEventObserver方法。这个方法的调用时机是在addObserver时，我们构造ObserverWithState的时候，在它的内部进行了一次调用。
代码：Lifecycling.java
static LifecycleEventObserver lifecycleEventObserver(Object object) {
boolean isLifecycleEventObserver;
boolean isFullLifecycleObserver;
if (isLifecycleEventObserver && isFullLifecycleObserver) {
return new FullLifecycleObserverAdapter((FullLifecycleObserver)object, (LifecycleEventObserver)object);
} else if (isFullLifecycleObserver) {
return new FullLifecycleObserverAdapter((FullLifecycleObserver)object, (LifecycleEventObserver)null);
} else if (isLifecycleEventObserver) {
return (LifecycleEventObserver)object;
} else {
// 注解处理器逻辑
}
}
}
可以看到，lifecycleEventObserver内部，本质是适配器思想。它根据传入的LifecycleObserver对象的具体类型，去创建不同的适配器。比如在我们前面的例子当中，我们的LocationManagerDefault使用的是DefaultLifecycleObserver。那么在运行这个方法的时候isLifecycleEventObserver的值会是false，而isFullLifecycleObserver的值会是true。这时候程序就会执行对应的分支，并创建FullLifecycleObserverAdapter的对象。
所以，当程序执行mLifecycleObserver.onStateChanged的时候，实际上执行的是FullLifecycleObserverAdapter的onStateChanged方法。而这个部分的代码也非常的简单。
代码：FullLifecycleObserverAdapter.java
public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
switch (event) {
case ON_CREATE:
mFullLifecycleObserver.onCreate(source);
break;
case ON_START:
mFullLifecycleObserver.onStart(source);
break;
case ON_RESUME:
mFullLifecycleObserver.onResume(source);
break;
case ON_PAUSE:
mFullLifecycleObserver.onPause(source);
break;
case ON_STOP:
mFullLifecycleObserver.onStop(source);
break;
case ON_DESTROY:
mFullLifecycleObserver.onDestroy(source);
break;
case ON_ANY:
throw new IllegalArgumentException("ON_ANY must not been send by anybody");
}
if (mLifecycleEventObserver != null) {
mLifecycleEventObserver.onStateChanged(source, event);
}
}
在以上这些switch case语句当中，FullLifecycleObserverAdapter成功的将onStateChanged方法的调用适配到了FullLifecycleObserver的每一个生命周期回调上。而我们的LocationManagerDefault其实就是间接实现的FullLifecycleObserver这个接口。所以，Activity的生命周期变动，最终经过一系列的传递，经过FullLifecycleObserverAdapter，成功的传递到了LocationManagerDefault的onStart、onStop当中。当然，由于我们在LocationManagerDefault当中只重写了两个生命周期事件，其他的生命周期事件就不会传递不过来了。
最后，老规矩，我们用一张动图做个总结：
结尾
到目前为止，整个Lifecycle组件当中关键的源码，我们就都已经分析完毕了。如果你一遍看下来没有完全看懂，那也没关系，我建议你打开Android Studio配合源码慢慢读，效果肯定会更好。
我始终认为，读源码的精髓在于理解设计者背后的思路。因此，我们不需要纠结于某一行特定的代码，因为这里面的细节太多了，今天记住了明天就忘了。我们只需要记住整体流程，以后遇到问题需要 debug 了，再去看对应部分的代码细节即可。
另外，在最新的 Lifecycle 版本里，Google 团队用 Kotlin 重写了 Lifecycle，如果你通过本文理解了 Lifecycle 的核心，那么去看看最新的 Kotlin 实现也是不错的。我因为某些特殊原因，就不给大家梳理 Kotlin 源码了。
好啦，Lifecycle的章节到这里就正式结束了，在彻底理解了这个组件以后，我想你在后面的学习过程中会更加的得心应手。
下一篇，我们聊聊 LiveData，敬请期待。
