一、Lifecycle 介绍

Lifecycle是一个生命周期感知组件，一般用来响应Activity、Fragment等组件的生命周期变化，并将变化通知到已注册的观察者。有助于更好地组织代码，让代码逻辑符合生命周期规范，减少内存泄漏，增强稳定性。

这些组件可帮助您生成更易于组织且通常更轻量级的代码，这些代码更易于维护。

按照国际规范，我们先讲使用，后解析源码。

二、使用方法

先来看一下如何使用，这样再去分析源码就能有的放矢

1.添加依赖：

在app或者module目录下的build.gradle中，添加依赖：

这里介绍Androidx 项目引入lifecycle

dependencies {implementation "androidx.lifecycle:lifecycle-runtime-ktx:2.2.0"// Annotation processorkapt "androidx.lifecycle:lifecycle-compiler:2.2.0"
}

2.LifecycleObserver接口

实现LifecycleObserver 接口，使用 @OnLifecycleEvent注解在方法上，注解值表示该方法对应生命周期的哪个函数

//特别注意，这里不需要传入Lifecycle，本例是为了测试嵌套添加LifecycleObserver 的生命周期，才故意这样写
class P1(var mLifecycle: Lifecycle) : LifecycleObserver {@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)fun p1Create() {Log.i("P1 ", "执行了p1 的 create 生命周期")}@OnLifecycleEvent(Lifecycle.Event.ON_START)fun p1Start() {//注意，这里是嵌套添加LifecycleObserver，//会在P1 Start 阶段完全执行完，才去执行P2 Start阶段mLifecycle.addObserver(P2(mLifecycle))Log.i("P1 ", "执行了p1 的 start 生命周期")}@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)fun p1Resume() {Log.i("P1 ", "执行了p1 的 resume 生命周期")}@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)fun p1Pause() {Log.i("P1 ", "执行了p1 的 pause 生命周期")}
}

3.将LifecycleObserver添加到Lifecycle的观察者列表

class MainActivity : AppCompatActivity() {override fun onCreate(savedInstanceState: Bundle?) {super.onCreate(savedInstanceState)Log.i("MainActivity ", "onCreate 生命周期 开始执行")setContentView(R.layout.activity_main)//这句很重要，如果不填加的话就收不到activity状态回调,lifecycle为AppCompatActivity的getLifecycle方法lifecycle.addObserver(P1(lifecycle))  Log.i("MainActivity ", "onCreate 生命周期 执行完成")}override fun onStart() {super.onStart()Log.i("MainActivity ", "start 生命周期 执行完成")}
}

输出日志

 I/MainActivity: onCreate 生命周期 开始执行I/MainActivity: onCreate 生命周期 执行完成I/P1: 执行了p1 的 create 生命周期I/MainActivity: start 生命周期 执行完成I/P1: 执行了p1 的 start 生命周期I/P1: 执行了p1 的 resume 生命周期

当然也可以自己实现 LifecycleOwner接口，需要做3件事情

1、实现LifecycleOwner 接口的方法：getLifecycle()
2、注册Lifecycle new LifecycleRegistry(this)
3、在Activity生命周期函数中分发事件

public class MainActivity extends Activity implements LifecycleOwner {private LifecycleRegistry mLifecycleRegistry;@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);mLifecycleRegistry = new LifecycleRegistry(this);mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);mLifecycleRegistry.addObserver(new TestObserver());}@NonNull@Overridepublic Lifecycle getLifecycle() {return mLifecycleRegistry;}@Overridepublic void onStart() {super.onStart();mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START);}@Overridepublic void onResume() {super.onResume();mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_RESUME);}@Overridepublic void onPause() {mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_PAUSE);super.onPause();}@Overridepublic void onStop() {mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);super.onStop();}@Overridepublic void onDestroy() {mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_DESTROY);super.onDestroy();}
}

4. 监听应用前后台切换

前面讲解的都是处理一个activity生命周期，那如果要是想要监听整个应用的生命周期该怎么办呢？
一些银行 app 都有这样的功能，当切换应用到后台，会给用户一个提示，“xx 手机银行正在后台运行，请注意安全！” 。用我 LifeCycle 来实现的话，异常的简单。

class KtxAppLifeObserver : LifecycleObserver {@OnLifecycleEvent(Lifecycle.Event.ON_START)fun onForeground() {Ktx.app.toast("应用进入前台")}@OnLifecycleEvent(Lifecycle.Event.ON_STOP)fun onBackground() {Ktx.app.toast("应用进入后台")}
}

然后在应用启动时，如 ContentProvier，Application 中，调用如下代码：

 ProcessLifecycleOwner.get().lifecycle.addObserver(KtxAppLifeObserver())

通过代码你也发现了是通过我的家族成员 ProcessLifecycleOwner 来实现的。它可以感知整个应用进程的生命周期，这样一来，监听应用前后台切换就轻而易举了。3.3和3.4小节将会带领我们分析这个问题。

5. 全局管理 Activity

相信你们都做过这样的功能，特定情况下要 finish 掉打开过的所有 Activity，或者要关闭指定的 Activity 。通常的做法是在 BaseActivity 的生命周期回调中保存已经打开或关闭的 Activity 。虽然实现也还算优雅，但是如何给日益臃肿的 BaseActivity 减负呢？又到我 LifeCycle 出场了。

class KtxLifeCycleCallBack : Application.ActivityLifecycleCallbacks {override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {KtxManager.pushActivity(activity)"onActivityCreated : ${activity.localClassName}".loge()}override fun onActivityStarted(activity: Activity) {"onActivityStarted : ${activity.localClassName}".loge()}override fun onActivityResumed(activity: Activity) {"onActivityResumed : ${activity.localClassName}".loge()}override fun onActivityPaused(activity: Activity) {"onActivityPaused : ${activity.localClassName}".loge()}override fun onActivityDestroyed(activity: Activity) {"onActivityDestroyed : ${activity.localClassName}".loge()KtxManager.popActivity(activity)}override fun onActivitySaveInstanceState(activity: Activity, outState: Bundle?) {}override fun onActivityStopped(activity: Activity) {"onActivityStopped : ${activity.localClassName}".loge()}
}

通过我的另一个家族成员，Application.ActivityLifecycleCallbacks ，你可以监听到所有的 Activity 的所有生命周期。在 Application 中注册这个 Callback 就行了。

application.registerActivityLifecycleCallbacks(KtxLifeCycleCallBack())

根据 单一职责原则，一个类做一件事情，这种写法将 Activity 的管理职责集中到一个类中，降低代码耦合。而原来的写法有两个问题，第一，你必须得继承 BaseActivity 才能具备管理当前 Activity 的功能。这又涉及到合作开发，不想继承，或者忘记继承。第二，让 BaseActivity 承担了过多的职责，并不符合基本的设计原则。

6. 配合协程使用

协程作为 Android 异步处理方案的新贵，不仅仅是我 LifeCycle ，ViewModel，LIveData 等其他 Jetpack 组件都为其提供了特定的支持。
要使用 LifeCycle 的协程支持，需要添加androidx.lifecycle:lifecycle-runtime-ktx:2.2.0-alpha01 或更高版本。该支持库为每个 LifeCycle对象定义了 LifecycleScope 。在此范围内启动的协程会在 LifeCycle 被销毁时自动取消。你可以通过 lifecycle.coroutineScope 或 lifecycleOwner.lifecycleScope 属性访问 Lifecycle 的 CoroutineScope。下面是一个简单的示例：

class MyFragment: Fragment() {override fun onViewCreated(view: View, savedInstanceState: Bundle?) {super.onViewCreated(view, savedInstanceState)viewLifecycleOwner.lifecycleScope.launch {...}}}

三、源码分析

3.1 Lifecycle相关的类图

先来看一下 Lifecycle相关的类图

自定义的Activity都继承自AppCompatActivity ，AppCompatActivity 继承了FragmentActivity，FragmentActivity继承了ComponentActivity。上图全部用AppCompatActivity代表了这个３个Activity。

ComponentActivity实现了LifecycleOwner接口，同时持有实现了Lifecycle的LifecycleRegistry对象，这个对象就可以将其理解为观察者模式中的Subject，LifecycleRegistr聚合多个LifecycleObserver，生命周期改变时通知LifecycleObserver进行相应的方法调用。

public class ComponentActivity extends androidx.core.app.ComponentActivity implementsLifecycleOwner,ViewModelStoreOwner,SavedStateRegistryOwner,OnBackPressedDispatcherOwnerprivate final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);@Override
public Lifecycle getLifecycle() {//返回构造好的LifecycleRegistry对象，正常在使用过程中我们会调用这个方法并添加Observer，从这里可以看到。//实际上我们最终是把实现了LifecycleObserver的对象添加到了LifecycleRegistry中return mLifecycleRegistry;
}

FragmentActivity在Activity生命周期函数中分发事件

 @Overrideprotected void onCreate(@Nullable Bundle savedInstanceState) {...mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);mFragments.dispatchCreate();}

我们看到，ComponentActivity实现了LifecycleOwner这个接口，那么表明它就是一个宿主类了。

//作为一个拥有生命周期的宿主，这些生命周期可以被其他自定义的组件进行监听，
//但是这些组件不需要在Activity或者Fragment中编写任何与生命周期相关的代码实现
public interface LifecycleOwner {@NonNullLifecycle getLifecycle();
}

3.2、生命周期感知

Lifecycle是一个生命周期感知的框架，那么它是如何感知Activity的生命周期呢？

看AppCompatActivity 继承的ComponentActivity 中的onCretae方法

protected void onCreate(@Nullable Bundle savedInstanceState) {super.onCreate(savedInstanceState);ReportFragment.injectIfNeededIn(this);
}

ReportFragment 类是一个Fragment，它负责分派生命周期的时间.
injectIfNeededIn()就是在当前的Activity里添加一个ReportFragment。

    public static void injectIfNeededIn(Activity activity) {if (Build.VERSION.SDK_INT >= 29) {//API29+,直接使用LifecycleCallbacks// On API 29+, we can register for the correct Lifecycle callbacks directlyLifecycleCallbacks.registerIn(activity);}//在 API 29 之前，为了保持与旧版本的 ProcessLifecycleOwner 的兼容性//（生命周期运行时更新时可能不会更新并且需要支持不从支持库中的 FragmentActivity 扩展的活动），// 使用框架片段来获取正确的 生命周期事件的时间安排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();}}

在API29+,直接使用LifecycleCallbacks来回调生命周期，后面会讨论，本篇主要探讨API29以下的版本。再看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);
}@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 activitymProcessListener = null;
}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.injectIfNeededIndispatch(getActivity(), event);}
}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);}}
}

你会发现都调用了dispatch()方法，而dispatch()方法则会判断Activity是否实现了LifecycleOwner接口，如果实现了该接口就调用LifecycleRegister的handleLifecycleEvent()，这样生命周期的状态就会借由LifecycleRegistry通知给各个LifecycleObserver从而调用其中对应Lifecycle.Event的方法。这种通过Fragment来感知Activity生命周期的方法其实在Glide的中也是有体现的。
大概流程图如下所示

3.3、LifecycleRegister分析

把LifecycleObserver （观察者）添加到 Lifecycle（被观察者）的列表中，使用的是addObserver，而在源代码中，实现Lifecycle接口的是LifecycleRegister

    getLifecycle().addObserver(new LifecycleObserver1 ());

LifecycleRegister#addObserver()

来看一下LifecycleRegister 类中的addObserver方法

@Override
public void addObserver(@NonNull LifecycleObserver observer) {enforceMainThreadIfNeeded("addObserver");//这个状态值是一个枚举类型的，生命周期越靠后，值越小 DESTROYED < INITIALIZED < CREATED < STARTED < RESUMEDState initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);if (previous != null) {return;}//由上面的使用可知，LifecycleOwner相当于是观察者模式中的被观察者，它来向各LifecycleObserver发送生命周期消息LifecycleOwner lifecycleOwner = mLifecycleOwner.get();if (lifecycleOwner == null) {// it is null we should be destroyed. Fallback quicklyreturn;}/*重点：两件事，1. 循环对齐状态，这里的While循环主要的目的在于通过循环保证Lifecycle中的事件和状态对齐，不遗漏。什么意思呢比如你是在onResume中调用addObserver添加监听的，那么通过这个循环进行处理，onCreate和onStart对应的事件也会被分发，这样一来监听者同样会处理ON_CREATE和ON_START事件===============================================2. 处理嵌套事件mAddingObserverCounter 表示正在添加的观察者的数量，开始添加新的observe之前，对该变量进行 ++ 操作，添加完成后，进行 -- 操作。如果mAddingObserverCounter 不为0 ，说明在添加observe A时，在while循环中更新observe A的生命周期时，又添加了新的observe B。这就是嵌套事件。而由于B 是后添加的，所以同一生命周期的回调顺序，要保证B在A后被回调。mHandlingEvent  表示是否正在处理事件中*/boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;State targetState = calculateTargetState(observer);mAddingObserverCounter++;//这里是while 循环，新添加的LifecycleObserver ，会不断更新自己的生命周期到指定的targetStatewhile ((statefulObserver.mState.compareTo(targetState) < 0&& mObserverMap.contains(observer))) {pushParentState(statefulObserver.mState);//注意这里的upEvent，获取statefulObserver.mState下一状态的值,//也就是说mParentStates中的状态比即将执行的生命周期要小一个阶段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);}// 没有事件正在处理，或者是添加了observe,就需要重新同步一次状态// 嵌套添加observer，只有最先添加的observer,isReentrance 才是false，才会执行sync()// 也就是说嵌套添加observer，sync 只会被执行一次。if (!isReentrance) {// we do sync only on the top level.//防止在添加过程中，生命周期发生了变化，状态不一致的问题sync();}mAddingObserverCounter--;
}

LifecycleRegister#FastSafeIterableMap

其中mObserverMap 是FastSafeIterableMap

    private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap = new FastSafeIterableMap<>();

这里生成了一个ObserverWithState，然后放入FastSafeIterableMap里，这个类
是一个自定义列表，用于保存观察者并可在遍历期间处理删除/添加。
观察者1和观察者2的任何时刻：如果addition_order（observer1）<addition_order（observer2），那么 state（observer1）> = state（observer2）

LifecycleRegister#calculateTargetState

/*** 计算出的 targetState 一定是小于等于当前 mState 的*/
private State calculateTargetState(LifecycleObserver observer) {//前面observer 都会被添加到一个Map中， 这里是在map中获取到当前observer的前一个observerEntry<LifecycleObserver, ObserverWithState> previous = mObserverMap.ceil(observer);// 获取前一个observer 的最终状态State siblingState = previous != null ? previous.getValue().mState : null;// 如果是嵌套添加observer，获取父级observer的状态，这个状态是当前父级状态的前一个状态（详见addObserver 的while循环中的代码）， 无重入情况下可不考虑 parentState ，为 nullState parentState = !mParentStates.isEmpty() ? mParentStates.get(mParentStates.size() - 1): null;//获取最小状态，DESTROYED < INITIALIZED < CREATED < STARTED < RESUMED     return min(min(mState, siblingState), parentState);
}

我们可以添加多个生命周期观察者，这时候就得注意维护它们的状态。每次添加新的观察者的初始状态是 INITIALIZED ，需要把它同步到当前生命周期状态，确切的说，同步到一个不大于当前状态的 targetState 。从源码中的计算方式也有所体现，targetState 是当前状态 mState，mObserverMap 中最后一个观察者的状态，有重入情况下 parentState 的状态这三者中的最小值。

为什么要取这个最小值呢？我是这么理解的，当有新的生命周期事件时，需要将 mObserverMap 中的所有观察者都同步到新的同一状态，这个同步过程可能尚未完成，所以新加入的观察者只能先同步到最小状态。注意在 addObserver 方法的 while 循环中，新的观察者每改变一次生命周期，都会调用 calculateTargetState() 重新计算 targetState 。

有小伙伴可能有疑问，已经有了siblingState状态，为什么还要获取parentState 状态？而且如果你调试过程序会发现，这里的siblingState 值（如果有的话）和parentState 值是一样的。

parentState的存在是为了解决下面这种情况，结合下面这个。

void onStart() {mRegistry.removeObserver(this);mRegistry.add(newObserver);
}

为了方便描述，我们把被删除的LifecycleObserver 称为 A，新添加的称为B

删除LifecycleObserver，也就是从mObserverMap中移除，那么在calculateTargetState 函数中，siblingState 的值就是null

这里是嵌套添加LifecycleObserverB，是在LifecycleObserverA的回调函数中添加的，此时LifecycleObserverA，在源码中执行了pushParentState ，再回调本函数onStart，回调执行结束会执行popParentState。

如果此时添加LifecycleObserverB，在调用calculateTargetState函数中，siblingState 的值就可能为空的（如果mObserverMap 只有一个值，removeObserver后，就为空），parentState值不为空（在popParentState 中设置的，该值也就是LifecycleObserverA的上个生命阶段），最后添加完成后，执行了sync(),再次同步状态

也就说LifecycleObserverA 某一生命周期阶段（这里指onStart）执行完成后，才会执行LifecycleObserverB的同一生命周期阶段。
就前面的分析，onCreate流程应该是这个样子，需要注意的是Observer的状态在onstateChange方法之后才会更新

再看onStart事件的分发，与上一个forwardPass方法不同，这里我们标记了pushParentState,不是上一次没有而是用不上，在FirstObserver的onStart方法里先移除了自己再添加了SecondObserver，所以FirstObserver还没来得及升级到STARTED状态就挂了。

再看calculateTargetState方法，由于前面FirstObserver被移除了，state为null，如果没有使用pushParentState记录FirstObserver状态，那么返回的目标状态就是STARTED,这样SecondObserver就会连续触发onCreate和onStart，但此时FirstObserver的onstateChange还没执行完，状态还没升到STARTED，导致后加的SecondObserver状态越界，使用parentState起到限制作用。在这个addObserver方法中SecondObserver只会被提到CREATED状态，随后的循环才会分发SecondObserver的onStart事件和提升状态。

最终的稳定状态下，没有生命周期切换，没有添加新的观察者，mObserverMap 中的所有观察者应该处于同一个生命周期状态。最终状态如下

LifecycleRegister#handleLifecycleEvent

前面提到了，每当生命周期发生变化，最终都会调用dispatch方法中的handleLifecycleEvent方法
下图是每个生命周期对应的状态，及转换：

这张图来源于Android开发者网站，主要描述了Lifecycle中所定义的事件和状态的流转情况。我们可以看到，整个过程以RESUMED为分界状态，分别有从INITIALIZED到RESUMED的前进流程，和从RESUMED到DESTROYED的回退流程。

正向前进流程

初始状态为INITIALIZED, 当执行了onCreate方法，触发ON_CREATE事件后进入CREATED状态。
执行了onStart方法触发ON_START事件后进入STARTED状态
执行onResume方法触发ON_RESUME状态后进入RESUMED状态

后退反向流程

当处于RESUMED状态时，如果发生onPause方法的执行，就会触发ON_PAUSE事件，进入STARTED状态，什么时候
触发onPause呢，可以参考Activity/Fragment的生命周期
如果继续进入onStop方法触发ON_STOP事件的话继续回退到CREATED状态
最后如果走到onDestroy触发ON_DESTROY事件，那么进入DESTROYED状态

我们可以看到，状态并没有像生命周期方法或事件一样有一一对应的。对应的状态和生命周期关系如下

onStart和onPause处于同一个状态，STARTED
onStop和onCreate后处于同一状态，CREATED
onDestroy处于DESTROYED状态
onResume处于RESUMED状态
初始状态为INITIALIZED状态

下面来看下handleLifecycleEvent方法的代码：

 public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {State next = getStateAfter(event);moveToState(next);}private void moveToState(State next) {if (mState == next) {return;}mState = next;//mHandlingEvent 表示处理事件，所以不需要再次调用//mAddingObserverCounter != 0 表示正在添加observer（在函数addObserver），满足此条件，最后会调用sync()，所以这里不需再次调用if (mHandlingEvent || mAddingObserverCounter != 0) {// 停止正在更新生命周期的操作，因为有新的事件传递进来mNewEventOccurred = true;// we will figure out what to do on upper level.return;}mHandlingEvent = true;sync();mHandlingEvent = false;
}

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<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();if (!mNewEventOccurred && newest != null&& mState.compareTo(newest.getValue().mState) > 0) {forwardPass(lifecycleOwner);}}mNewEventOccurred = false;
}

这里可以看到

如果ObserverWithState的state小于当前state，那么就调用forwardPass方法，
如果大于当前state，那么就调用backwardPass方法。

ObserverWithState默认的State是在addObserver方法里确定的，如果不是DESTROYED状态，就初始为 INITIALIZED

LifecycleRegister#forwardPass

继续看forwardPass方法

    private void forwardPass(LifecycleOwner lifecycleOwner) {Iterator<Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =mObserverMap.iteratorWithAdditions();//如果有新的事件发生，则停止        while (ascendingIterator.hasNext() && !mNewEventOccurred) {Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();ObserverWithState observer = entry.getValue();//如果有新的事件发生，则停止    while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred&& mObserverMap.contains(entry.getKey()))) {//下面这三句，和addObserve 中的操作一样    pushParentState(observer.mState);observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));popParentState();}}}

上面的observer其实是一个ObserverWithState对象,它是一个静态内部类

LifecycleRegister#ObserverWithState

添加Observer的时候会把LifecycleObserver包装成ObserverWithState，主要的目的在于对LifecycleObserver和State进行绑定，并添加dispatchEvent方法处理事件分发逻辑

    static class ObserverWithState {State mState;LifecycleEventObserver mLifecycleObserver;ObserverWithState(LifecycleObserver observer, State initialState) {//这里调用lifecycleEventObserver，生成一个事件观察者mLifecycleObserver，//每个生命周期，要发送给谁，都是通过这个变量来实现的（它是一个接口onStateChanged，有不同的实现）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;}}

调用了Lifecycling.lifecycleEventObserver方法来获得LifecycleEventObserver 的实例，通过这个实例调用onStateChanged

    static LifecycleEventObserver lifecycleEventObserver(Object object) {boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;if (isLifecycleEventObserver && isFullLifecycleObserver) {return new FullLifecycleObserverAdapter((FullLifecycleObserver) object,(LifecycleEventObserver) object);}if (isFullLifecycleObserver) {return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);}if (isLifecycleEventObserver) {return (LifecycleEventObserver) object;}//获取监听者的类型，实际上就有两种，一种是使用Lifecycle-compiler自动生成的，一种是继承或者实现内置Observer类的//通过反射，找到Lifecycle 自动生成的类 XXX_LifecycleAdapterfinal Class<?> klass = object.getClass();int type = getObserverConstructorType(klass);//处理使用lifecycle-compiler进行编译时生成Observer的处理逻辑if (type == GENERATED_CALLBACK) {List<Constructor<? extends GeneratedAdapter>> constructors =sClassToAdapters.get(klass);//如果是只有一个构造函数，构造GeneratedAdapter 实例对象并作为SingleGeneratedAdapterObserver//的构造函数参数传递进来，最终生成一个SingleGeneratedAdapterObserver，这个类实现//LifecycleEventObserver，并在onStateChanged方法中调用GeneratedAdapter 的callMethod方法，最终调用//到我们的Lifecycle Observer类的周期函数if (constructors.size() == 1) {GeneratedAdapter generatedAdapter = createGeneratedAdapter(constructors.get(0), object);//最终使用XXX_LifecycleAdapter，创建SingleGeneratedAdapterObserverreturn new SingleGeneratedAdapterObserver(generatedAdapter);}GeneratedAdapter[] adapters = new GeneratedAdapter[constructors.size()];for (int i = 0; i < constructors.size(); i++) {adapters[i] = createGeneratedAdapter(constructors.get(i), object);}return new CompositeGeneratedAdaptersObserver(adapters);}return new ReflectiveGenericLifecycleObserver(object);}

这个方法大概意思就是,根据传进的LifecycleObserver进行判断,构造一个LifecycleEventObserver对象.

LifecycleEventObserver 是一个接口有一个方法onStateChanged()，有四种实现：

FullLifecycleObserverAdapter
SingleGeneratedAdapterObserver
CompositeGeneratedAdaptersObserver
ReflectiveGenericLifecycleObserver

FullLifecycleObserverAdapter

LifecycleEventObserver，该接口继承自LifecycleObserver，增加了onStateChanged回调函数，实现了不需要通过OnLifecycleEvent注解监听生命周期事件，所有的事件变换都会在onStateChanged中进行监听

/*** 如果一个类实现了这个接口和DefaultLifecycleObserver接口，那么DefaultLifecycleObserver方法会被先调用，紧接着就会* 调用onStateChanged方法* 如果一个类实现了这个接口，同时也实现了了OnLifecycleEvent注解接口，那么注解接口就会被忽略*/
public interface LifecycleEventObserver extends LifecycleObserver {void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event);
}

FullLifecycleObserver，定义了所有完整与宿主生命周期相同的函数,实现类直接可以在对应的函数中处理生命周期事件

interface FullLifecycleObserver extends LifecycleObserver {void onCreate(LifecycleOwner owner);void onStart(LifecycleOwner owner);void onResume(LifecycleOwner owner);void onPause(LifecycleOwner owner);void onStop(LifecycleOwner owner);void onDestroy(LifecycleOwner owner);
}

可以看到组件本身为了提供不同的事件处理方式，提供了非常灵活的接口给调用方，而FullLifecycleObserverAdapter正好是利用适配器模式，通过适配器来实现对FullLifecycleObserver 和LifecycleEventObserver 这两种Observer的事件统一处理逻辑。

 //本身实现了LifecycleEventObserver ，这样可以方便的处理LifecycleEventObserver 的onStageChange回调
class FullLifecycleObserverAdapter implements LifecycleEventObserver {//FullLifecycleObserver private final FullLifecycleObserver mFullLifecycleObserver;//FullLifecycleObserver private final LifecycleEventObserver mLifecycleEventObserver;FullLifecycleObserverAdapter(FullLifecycleObserver fullLifecycleObserver,LifecycleEventObserver lifecycleEventObserver) {mFullLifecycleObserver = fullLifecycleObserver;mLifecycleEventObserver = lifecycleEventObserver;}@Overridepublic void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {//在onStateChanged中做了两件事情//1. 利用回调来处理和调用mFullLifecycleObserver的各个生命周期函数//2. 在这里同样会将事件继续传递给LifecycleEventObserver 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);}}
}

解析和处理lifecycle-compiler

为什么要提供这个组件，本章内容我们有提到过LifecycleObserver这个接口，它是一个标志性接口，需要监听生命周期事件的话需要使用OnLifecycleEvent注解，而这个注解绑定的函数最终是通过反射来调用的，这样一来在性能上会有一些损耗，所以就提供这个组件，在编译期就会生成对应的LifecycleAdapter类，可以直接进行调用，不用反射。
我们先看一下利用Lifecycle-compiler自动生成的类（app/build/generated/source/apt/包名/下生成了一个辅助文件）

//生成一个LifecycleAdapter结尾的类，并实现GeneratedAdapter
public class Task_LifecycleAdapter implements GeneratedAdapter {//这个receiver就是我们定义的实现了LifecycleObserver接口的实例对象final Task mReceiver;Task_LifecycleAdapter(Task receiver) {this.mReceiver = receiver;}@Overridepublic void callMethods(LifecycleOwner owner, Lifecycle.Event event, boolean onAny,MethodCallsLogger logger) {boolean hasLogger = logger != null;if (onAny) {return;}//在这个callMethods中会根据Event的类型调用Observer的对应方法if (event == Lifecycle.Event.ON_RESUME) {if (!hasLogger || logger.approveCall("start", 1)) {mReceiver.start();}return;}if (event == Lifecycle.Event.ON_STOP) {if (!hasLogger || logger.approveCall("stop", 1)) {mReceiver.stop();}return;}...}
}

前文提到在处理编译生成的LifecycleAdapter时会把该LifecycleAdapter类作为SingleGeneratedAdapterObserver（单构造函数情况下，这里只分析单构造函数）的构造函数参数，实例化SingleGeneratedAdapterObserver作为lifecycleEventObserver的返回值。

本例中onStateChanged 函数会调用到下面这个类中

class SingleGeneratedAdapterObserver implements LifecycleEventObserver {//对应的就是编译时生成的P1_LifecycleAdapter类private final GeneratedAdapter mGeneratedAdapter;SingleGeneratedAdapterObserver(GeneratedAdapter generatedAdapter) {mGeneratedAdapter = generatedAdapter;}@Overridepublic void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {//mGeneratedAdapter 也就是Lifecycle 自动生成的类，这里特指P1_LifecycleAdapter//onStateChanged方法中直接调用生成的LifecycleAdapter的callMethods方法，这样就会最终调用//到我们自定义的LifecycleObserver类中相关的注解绑定函数mGeneratedAdapter.callMethods(source, event, false, null);mGeneratedAdapter.callMethods(source, event, true, null);}
}

通过这样的方式，使得调用效率会更高，避免了反射调用的性能损耗。如果没有采用Lifecycle-compiler的话是采用反射的方式来调用目标LifecycleObserver，具体可以参考ReflectiveGenericLifecycleObserver，我们不再进行分析。

下面来看下，自动生成的类P1_LifecycleAdapter，在不同的生命周期事件，调用不同的函数
使用注解，会自动生成。所以需要在依赖中添加kapt “androidx.lifecycle:lifecycle-compiler:2.2.0”
不添加的话也可以运行，但不会生成自动类，运行还是通过注解反射的方式，会损耗性能。

public class P1_LifecycleAdapter implements GeneratedAdapter {final P1 mReceiver;P1_LifecycleAdapter(P1 receiver) {this.mReceiver = receiver;}@Overridepublic void callMethods(LifecycleOwner owner, Lifecycle.Event event, boolean onAny,MethodCallsLogger logger) {boolean hasLogger = logger != null;if (onAny) {return;}if (event == Lifecycle.Event.ON_CREATE) {if (!hasLogger || logger.approveCall("p1Create", 1)) {mReceiver.p1Create();}return;}if (event == Lifecycle.Event.ON_START) {if (!hasLogger || logger.approveCall("p1Start", 1)) {mReceiver.p1Start();}return;}if (event == Lifecycle.Event.ON_RESUME) {if (!hasLogger || logger.approveCall("p1Resume", 1)) {mReceiver.p1Resume();}return;}if (event == Lifecycle.Event.ON_PAUSE) {if (!hasLogger || logger.approveCall("p1Pause", 1)) {mReceiver.p1Pause();}return;}}
}

四、Lifecycle为什么要使用Fragment

Lifecycle为什么要使用Fragment，为什么不直接把这些方法，在Activity中实现呢？

我个人认为有两个原因：

因为不是所有的页面都继承AppCompatActivity，为了兼容非AppCompatActivity
Activity和Fragment都实现Lifecycle，避免代码重复
所以封装一个同样具有生命周期的Fragment来给Lifecycle分发生命周期事件。

五、总结

State是如何与Activity/Fragment的生命周期绑定的？

在Activity中添加一个ReportFragment(如果你的Activity继承AppCompatActivity，会在父类的onCreate()中添加ReportFragment，否则由LifecycleDispatcher添加)，在ReportFragment生命周期函数中调用LifecycleRegistry.handleLifecycleEvent()方法改变State。

Event事件是如何分发到LifecycleObserver的？

LifecycleRegistry在收到handleLifecycleEvent()后，内部调用moveToState()方法，改变State值，每一次State值改变，都会调用LifecycleObserver.onStateChanged()方法将Event分发到LifecycleObserver

最后总结一张图

Lifecycle 使用与源码分析相关推荐

Lifecycle 使用与源码分析——彻底搞懂Lifecycle原理
一.Lifecycle 介绍 Lifecycle是一个生命周期感知组件,一般用来响应Activity.Fragment等组件的生命周期变化,并将变化通知到已注册的观察者.有助于更好地组织代码,让代码逻 ...
spring cloud集成 consul源码分析
1.简介 1.1 Consul is a tool for service discovery and configuration. Consul is distributed, highly ava ...
Tomcat7.0源码分析——Session管理分析（下）
版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/beliefer/article/details/52451061 前言在<Tomcat7.0 ...
Tomcat7.0源码分析——Session管理分析（上）
版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/beliefer/article/details/52450268 前言对于广大java开发者而言, ...
Java并发编程实战（chapter_3）（线程池ThreadPoolExecutor源码分析）
为什么80%的码农都做不了架构师?>>> 这个系列一直没再写,很多原因,中间经历了换工作,熟悉项目,熟悉新团队等等一系列的事情.并发课题对于Java来说是一个又重要又难的一大块 ...
Tomcat源码分析--转
一.架构下面谈谈我对Tomcat架构的理解总体架构: 1.面向组件架构 2.基于JMX 3.事件侦听 1)面向组件架构 tomcat代码看似很庞大,但从结构上看却很清晰和简单,它主要由一堆组件组成 ...
android6.0源码分析之AMS服务源码分析
activitymanagerservice服务源码分析 1.ActivityManagerService概述 ActivityManagerService(以下简称AMS)作为Android中最核心 ...
eureka 之前的服务如何关闭_干货分享 | 服务注册中心Spring Cloud Eureka部分源码分析...
友情提示:全文13000多文字,预计阅读时间10-15分钟 Spring Cloud Eureka作为常用的服务注册中心,我们有必要去了解其内在实现机制,这样出现问题的时候我们可以快速去定位问题.当我 ...
SaltStack源码分析之：master端执行salt模块大致流程
2019独角兽企业重金招聘Python工程师标准>>> ##JOB执行流程先看下官网对于master端的工作流程的介绍: The Salt master works by alwa ...

Lifecycle 使用与源码分析