Jetpack——Lifecycle源码解析

一、Lifecycle是什么？

官网文档是学习最好的资料，传送门：

• Lifecycle
• 使用生命周期感知型组件处理生命周期

Lifecycle 属于Jetpack的一个组件，是构建生命周期感知型组件，这些组件可以根据 Activity 或 Fragment 的当前生命周期状态调整行为。生命周期感知型组件可执行操作来响应另一个组件的生命周期状态的变化。这些组件有助于我们写出更有条理且往往更精简的代码，这样的代码更易于维护。

Jetpack是一个庞大且强大的工具集，这是第一篇分析Jetpack 的文章，在此列出部分组件供参考，后续可能会出一个系列分析其中稳定、成熟的组件。

1.1 Lifecycle的作用

Lifecycle 的出现是为了解耦系统组件的生命周期与自定义组件之间耦合。以前如果自定义的组件需要在 Activity 对应的生命周期做相应的处理的话，就要重写 Activity 的生命周期，然后在生命周期方法里做相应的处理，而现在可以通过 Lifecycle 去省略掉重写生命周期方法这个步骤。可以有效避免内存泄漏，解决 Android 生命周期常见难题。

1.2 Lifecycle的原理

Lifecycle 架构设计使用了观察者模式，通过 Owner 和 Observer 的配合，使用观察者模式监听被观察者的生命周期的变化，来实现生命周期的解耦。Activity 虽然实现了 LifecycleOwner 接口，但是并没有实现相关处理，而是通过添加一个 Fragment 来代理 Lifecycle 的分发。这种通过 Fragment 代理 Activity 行为的设计在其他一些库也经常出现，相对来说更加无侵和优雅。

1.3 Lifecycle 框架涉及到几个关键类

• Lifecycle 是一个持有组件生命周期状态信息的核心抽象类，能够监听Activity / Fragment生命周期行为的各种变化。包含一个全局变量、三个抽象方法和两个枚举内部类，三个方法分别用于添加 LifecycleObserver 、移除 LifecycleObserver、获取当前 Lifecycle 所处的状态值和表示状态和事件的两个枚举。一个常量mInternalScopeRef 用于在引入了 lifecycle-common-ktx 包的情况，即只有在使用 Kotlin 协程库的时候才有用。
• LifecycleOwner 是一个核心接口，生命周期的事件分发者，接口通常用来声明具备某种能力，该接口的实现类表示能够为外部提供 Lifecycle 实例用于连接生命周期对象，如Activity / Fragment ，当然，也可以自定义生命周期组件。LifecycleOwner 提供了 getLifecycle() 方法来获取其 Lifecycle 对象，大部分情况下真正具有使用意义的是它的子接口 ，可以说仅是用于类型标记，系统框架实现中 Lifecycle 的唯一子类LifecycleRegistry，在 Activity/Fragment 他们的生命周期发生变化的时发出相应的 Event 给 LifecycleRegistry。
• LifecycleObserver 该接口的实现类表示为关注生命周期事件的观察者，用于观察 LifecycleOwner，它是没有任何方法是一个空接口，实际的工作一般根据需求使用其子类接口或者使用注解实现，一般包括：
  • LifecycleObserver 该接口本身采用注解方式，@OnLifecycleEvent标记自定义的方法以实现回调。
    注解的工作方式有两种：反射和预编译适配类，默认的工作方式为反射。
    反射方式：通过包装和处理后，最终通过invoke调用被注解的方法。
    预编译方式：需要引入注解编译器：androidx.lifecycle:lifecycle-compiler:$lifecycle_version。
    对被注解标记 且 继承/实现 LifecycleObserver 接口的 类/接口，自动编译生成对应的继承 GeneratedAdapter 的 _LifecycleAdapter.class 适配类，以减少反射消耗，典型的空间换时间，通过注解将处理函数与希望监听的 Event 绑定,当相应的 Event 发生时，LifecycleRegistry 会通知相应的函数进行处理。
  • FullLifecycleObserver 为所有的生命周期事件都定义了对应的回调方法。实现该接口就需要把不需要观察的方法回调都做一个空实现。在没有 Java 8 的 default 关键字时，如果仅需要1-2个回调方法，那么最终实现类中的空方法会相当碍眼，这种情况下推选使用 @OnLifecycleEvent注解方式替代。(当然也可以自己实现一个空实现的BaseLifecycleObserver)。
  • DefaultLifecycleObserver 使用 Java 8 的 default 关键字空实现了 FullLifecycleObserver 的所有方法。如果项目中使用了 Java8 或者开启 Java 8 特性，那么官方强烈推选DefaultLifecycleObserver替代的 @OnLifecycleEvent 注解实现 (注解后续可能被弃用)，包括预编译。引入 DefaultLifecycleObserver 后，就需要把注解实现相关逻辑移除。即使保留注解，由于 Lifecycling 的处理逻辑（系统架构逻辑中所有传入的观察者都会经过 Lifecycling 处理），任何 FullLifecycleObserver 的实现类 (即包括 DefaultLifecycleObserver) 内部所有的 @OnLifecycleEvent 注解都会失效。
  • LifecycleEventObserver 只有一个 onStateChanged() 方法，以 Lifecycle.Event 入参提供事件区分的形式，进行统一方法回调。与 FullLifecycleObserver 不冲突，但是也会无效化@OnLifecycleEvent注解。同时实现 LifecycleEventObserver 和 FullLifecycleObserver，可以得到2次相同的生命周期回调，后者的具体方法回调优先于前者的统一方法回调。
  • ReflectiveGenericLifecycleObserver 是 LifecycleEventObserver 子类。适应于注解方式的反射工作方式。通过该类对观察者进行包装，处理观察者关注的回调的反射调用，由Lifecycling处理包装过程。
  • SingleGeneratedAdapterObserver 是 LifecycleEventObserver 子类。适应于注解方式的预编译工作方式。通过该类对观察者的 GeneratedAdapter 进行包装，处理 GeneratedAdapter 的方法调用，由 Lifecycling 处理包装过程。
  • CompositeGeneratedAdaptersObserver 是 SingleGeneratedAdapterObserver 的复数版，内部逻辑基本与其一致，只是提供"复数" GeneratedAdapter 的支持。
• LifecycleRegistry 控制中心，它负责控制 state 的转换、接受分发 event 事件。
• Lifecycling 核心工具类。系统框架实现中，对所有 LifecycleObserver 的包装适配器选择和相关处理都由本类完成。

怎么理解“复数”呢？
首先要知道，在程序运行过程，Lifecycling 会查找传入观察者自身的对应的 GeneratedAdapter，假如不存在，则会查找其所有父类/接口对应的 GeneratedAdapter。
假如存在自身的对应的 GeneratedAdapter，那么此时 GeneratedAdapter 数量等于1，则会实例化这个 GeneratedAdapter 并使用 SingleGeneratedAdapterObserver 保存（所以叫做 Single）。
假如目标观察者类自身不包含注解方法，而是继承或实现包含注解方法的 LifecycleObserver 类/接口。根据前面的预编译规则，由于目标类不包含注解方法，注解编译器不会为其生成 GeneratedAdapter。
根据查找逻辑，自身对应的 GeneratedAdapter 不存在，Lifecycling将会查找其所有父类/接口对应的 GeneratedAdapter。
如果结果 GeneratedAdapter 数量等于1，则走 SingleGeneratedAdapterObserver 流程。
如果结果 GeneratedAdapter 数量大于1 （继承+实现，或多实现等等，都可能发生），Lifecycling 将会结果 GeneratedAdapter 实例化并打包成数组，并使用 CompositeGeneratedAdaptersObserver 保存（所以叫做 Composite）。
——深入理解AAC架构 - Lifecycle整体机制源码

Lifecycle组件原理——图源：ShymanZhu

二、Lifecycle的使用

2.1 声明依赖

（1）完整引入

// lifecycle-extensions 中的 API 已弃用。您可以为特定 Lifecycle 工件添加所需的依赖项。
dependencies {
    def lifecycle_version = "2.4.0"// 文档用的是val lifecycle_version = "2.4.0"
    def arch_version = "2.1.0"

    // ViewModel
    implementation("androidx.lifecycle:lifecycle-viewmodel-ktx:$lifecycle_version")
    // ViewModel utilities for Compose
    implementation("androidx.lifecycle:lifecycle-viewmodel-compose:$lifecycle_version")
    // LiveData
    implementation("androidx.lifecycle:lifecycle-livedata-ktx:$lifecycle_version")
    // Lifecycles only (without ViewModel or LiveData)
    implementation("androidx.lifecycle:lifecycle-runtime-ktx:$lifecycle_version")

    // Saved state module for ViewModel
    implementation("androidx.lifecycle:lifecycle-viewmodel-savedstate:$lifecycle_version")

    // Annotation processor
    kapt("androidx.lifecycle:lifecycle-compiler:$lifecycle_version")
    // 替换 - 如果使用Java8,就用这个替换上面的lifecycle-compiler
    // alternately - if using Java8, use the following instead of lifecycle-compiler
    implementation("androidx.lifecycle:lifecycle-common-java8:$lifecycle_version")

	//以下按需引入
    // optional - helpers for implementing LifecycleOwner in a Service
    implementation("androidx.lifecycle:lifecycle-service:$lifecycle_version")
    // optional - ProcessLifecycleOwner provides a lifecycle for the whole application process
    implementation("androidx.lifecycle:lifecycle-process:$lifecycle_version")
    // optional - ReactiveStreams support for LiveData
    implementation("androidx.lifecycle:lifecycle-reactivestreams-ktx:$lifecycle_version")
    // optional - Test helpers for LiveData
    testImplementation("androidx.arch.core:core-testing:$arch_version")
}

（2）精简版本

dependencies {
    implementation "androidx.lifecycle:lifecycle-runtime:2.0.0"
    implementation "androidx.lifecycle:lifecycle-extensions:2.0.0"
    implementation "androidx.lifecycle:lifecycle-common-java8:2.0.0"
    annotationProcessor "androidx.lifecycle:lifecycle-runtime:2.0.0"
}

如果只使用Lifecycle，只需要引入lifecycle-runtime即可。

2.2 使用

（1）自定义监听器

如果不使用 Lifecycle 的话实现一个观察者，需要自定义监听器

/**
 * 自定义监听器
 */
class MyListener {
    private val TAG = "MyListener"

    // 能监听到所有需要的方法
    fun start():Int = Log.d(TAG, "start run ...")
    fun stop():Int = Log.d(TAG, "stop run ...")
}

在界面初始化的位置实例化，并在被观察者需要监听的位置调用监听器对应的方法实现效果

class MainActivity : AppCompatActivity() {
    private var myListener: MyListener? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        myListener = MyListener()// 初始化订阅关系
    }

    override fun onStart() {
        super.onStart()
        myListener?.start()// 调用监听器对应方法
    }

    override fun onStop() {
        super.onStop()
        myListener?.stop()
    }
}

（2）MVP中使用

一般这种编程思路通常在P层监听 Activity 生命周期，忽略已消亡的页面逻辑、数据处理

/**
 * 一般用于MVP中P层监听Activity生命周期
 */
class MyPresenter {
    private val TAG = "MyPresenter"

    // 能监听到所有需要的方法
    fun resume():Int = Log.d(TAG, "resume run ...")
    fun pause():Int = Log.d(TAG, "pause run ...")
}

Activity中使用，和上面相同的方式

class MainActivity : AppCompatActivity() {
    private var mPresenter: MyPresenter? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        mPresenter = MyPresenter()
    }

    override fun onResume() {
        super.onResume()
        mPresenter?.resume()
    }

    override fun onPause() {
        super.onPause()
        mPresenter?.pause()
    }
}

（3）使用 Lifecycle 方式

只要项目支持 Androidx，系统已经实现了 Lifecycle 接口，不需要自己写监听器。

我们看一下系统是如何帮我们实现 Lifecycle 接口的？

一般我们页面都是 AppCompatActivity 的实现类：

class MainActivity : AppCompatActivity() {

AppCompatActivity 继承自 FragmentActivity：

public class AppCompatActivity extends FragmentActivity implements AppCompatCallback,
        TaskStackBuilder.SupportParentable, ActionBarDrawerToggle.DelegateProvider {

FragmentActivity 继承自 ComponentActivity ：

public class FragmentActivity extends ComponentActivity implements
        ActivityCompat.OnRequestPermissionsResultCallback,
        ActivityCompat.RequestPermissionsRequestCodeValidator {

ComponentActivity 中实现了 LifecycleOwner 接口，这就是关键所在：

public class ComponentActivity extends androidx.core.app.ComponentActivity implements
        LifecycleOwner, // Lifecycle持有者
        ViewModelStoreOwner,
        SavedStateRegistryOwner,
        OnBackPressedDispatcherOwner {

只需要写一个观察者实现类，并实现 LifecycleObserver 接口，为方法添加注解即可。
缺点：这种方式拿不到页面环境。

/**
 * 观察者
 * 开发环境是 Java 1.7 ，可以使用注解的方式来监听生命周期变化
 * 但在以后会被逐步废弃，Google 官方也建议开发者尽量使用接口回调的形式
 */
class MyObserver : LifecycleObserver {
    private val TAG = "MyObsever"

    // 画面可见，连接
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun connectListener(): Int = Log.d(TAG, "connectListener run ...")

    // 画面不可见，断开连接
    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun disConnectListener(): Int = Log.d(TAG, "disConnectListener run ...")
}

在页面初始化添加监听，不需要手动调用方法（如果大量页面中出现人为失误，会造成处理不一致性功能问题）

/**
 * 宿主（Activity/Fragment）
 * 依靠LifecycleOwner来维护
 */
class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 一般放在BaseActivity中关联注册
        // 观察者与被观察者关联的环节
        lifecycle.addObserver(MyObserver())
        lifecycle.addObserver(MyObserver2())
    }
}

可以增加多个观察者，多次观察，一般放在 BaseActivity 中关联注册。

另一种写法，不需要注解：

/**
 * 推荐写法
 * 开发环境是 Java 8 ，推荐使用以实现 DefaultLifecycleObserver 接口的方式来监听生命周期的变化
 * DefaultLifecycleObserver是对LifecycleObserver的二次封装，需要引入支持：
 * implementation "android.arch.lifecycle:common-java8:1.1.1"
 */
class MyObserver2 : DefaultLifecycleObserver {
    private val TAG = "MyObserver2"

    override fun onCreate(owner: LifecycleOwner) {
        super.onCreate(owner)
        Log.d(TAG, "onCreate run ...")
    }

    override fun onResume(owner: LifecycleOwner) {
        super.onResume(owner)
        Log.d(TAG, "onResume run ...")
    }

    override fun onPause(owner: LifecycleOwner) {
        super.onPause(owner)
        Log.d(TAG, "onPause run ...")
    }
}

DefaultLifecycleObserver 是对 LifecycleObserver 的二次封装，使用更加简单，不需要注解。
优点：可以拿到页面环境，进行 Dialog、Toast…等为所欲为。

public interface DefaultLifecycleObserver extends FullLifecycleObserver {}
interface FullLifecycleObserver extends LifecycleObserver {}	

（4）内部类实现Lifecycle，可以实现结构分层

/**
 * 内部类监听，不常见
 * 好处，实现简单的结构分层，不需要写onStart()、onStop()...
 */
class MainActivity : AppCompatActivity() {
    private val TAG = "MainActivity"

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 一般放在BaseActivity中关联注册
        lifecycle.addObserver(MyObserver())
    }

    inner class MyObserver : LifecycleObserver {

        @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
        fun onResume() {
            Log.d(TAG, "lifecycle call onResume")
            // 优点：逻辑处理，结构分层
        }

        @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
        fun onPause() {
            Log.d(TAG, "lifecycle call onPause")
        }
    }

    /*override fun onResume() {
        super.onResume()
        // ...
    }*/
}

（5）接口监听法

接口监听法，设计模式的设计环节会见到这种写法。间接添加一个中间层。

class MyPresenter : IPresenter {}
class MyPresenter2 : IPresenter {}
class MyPresenter3 : IPresenter {}
...

先定义一个接口：

/**
 * 间接添加一个中间层
 */
interface IPresenter : LifecycleObserver {// :表示继承关系

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun onResume()

    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun onPause()
}

再对这个接口进行实现：

class MyPresenter : IPresenter {// :表示实现关系
    private val TAG = "MyPresenter"

    override fun onResume() {
        Log.d(TAG, "lifecycle call onResume")
    }

    override fun onPause() {
        Log.d(TAG, "lifecycle call onPause")
    }
}

最后在页面使用：

/**
 * 接口监听法，设计模式的设计环节会见到这种写法
 */
class MainActivity : AppCompatActivity() {
    private val TAG = "MainActivity"
    private var mPresenter: IPresenter? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 可以用工厂设计模式来实现要实现的具体类，动态变化
        mPresenter = MyPresenter()

        lifecycle.addObserver(mPresenter!!)
    }
}

总结： 用户端面向接口编程，可以用工厂设计模式来实现要实现的具体类，实现复杂的动态变化

（6）App 进入前后台的判断

使用 ProcessLifecycleOwner 可以简单的直接获取应用前后台切换状态

class ApplicationLifecycleObserver : LifecycleObserver {
    private val TAG = "AppLifecycleObserver"

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onAppForeground(owner: LifecycleOwner) {
        Log.d(TAG, "${owner.javaClass.simpleName}:app moved to foreground")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    fun onAppBackground(owner: LifecycleOwner) {
        Log.d(TAG, "${owner.javaClass.simpleName}:app moved to background")
    }
}

自定义 Application 中初始化，拿到状态我们可以为所欲为了。

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        ProcessLifecycleOwner.get().lifecycle.addObserver(ApplicationLifecycleObserver())
    }
}

（7）观察者的解注册

// 观察者解注册的逻辑比较简单
fun removeObserver() {
    lifecycle.removeObserver(mObserver)
}

三、Lifecycle源码原理的理解【※重点】

源码分析一定要关注主线流程，忽略支线、细节，否则会淹死在源码里，神仙看了也摇头~

定义监听器 MyLocationListener 模拟定位功能：

/**
 * 源码分析——观察者
 * 模拟地图定位动能
 */
class MyLocationListener : LifecycleObserver {
    private val TAG = "MyLocationListener"

    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    fun create() = Log.d(TAG, "create 正在启动系统定位服务中...")

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun start() = Log.d(TAG, "start 连接系统定位服务中...")

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun resume() = Log.d(TAG, "resume 系统定界面展示...")

    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun pause() = Log.d(TAG, "pause 系统定位界面关闭...")

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    fun stop() = Log.d(TAG, "stop 断开系统定位服务...")

    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    fun destroy() = Log.d(TAG, "destroy 正在停止系统定位服务...")
}

将监听器注册到界面进行分析

/**
 * 源码分析——被观察者
 * 接口监听法，设计模式的设计环节会见到这种写法
 */
class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 绑定观察者与被观察者
        lifecycle.addObserver(MyLocationListener())
    }
}

3.1 观察者与被观察者如何关联起来的？

MainActivity 只留给我们一句话可以进行分析，那么 addObserver() 就可以作为源码分析的入口：

lifecycle.addObserver(MyLocationListener())

lifecycle 即 getLifecycle() ，只是在 Kotlin 中被简写了，获取到是 Lifecycle 的具体实现类 LifecycleRegistry 对象，getLifecycle() 是接口 LifecycleOwner 的方法。然后使用 addObserver() 添加 LifecycleObserver 对象，也就是添加要通知的观察者，之后才能够在 Activity 或 Fragment 生命周期发生变化时观察者才会被通知，那么 Activity 的生命周期是如何被感知呢？

Lifecycle.java是个抽象类，再进去看其内部的 addObserver() 方法：

public abstract class Lifecycle {
	// 观察者 LifecycleObserver，这里又是个抽象方法
	@MainThread
	public abstract void addObserver(@NonNull LifecycleObserver observer);

那么 addObserver() 实际上是调用了 LifecycleRegistry 的 addObserver() 方法，点进去看其实现类 LifecycleRegistry.java 是如何处理的：

public class LifecycleRegistry extends Lifecycle {
	...
	@Override
    public void addObserver(@NonNull LifecycleObserver observer) {
		// 忽略枝节，看主要代码，ObserverWithState 是一个静态内部类
		// 将传进来的监听者observer封装成一个ObserverWithState
	    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
	    // 将封装好的ObserverWithState存入集合中
	    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
	...

关于注册流程，上面我们重点关注封装了 Observer 的内部静态类 ObserverWithState，我们看其 ObserverWithState() 构造方法：

ObserverWithState(LifecycleObserver observer, State initialState) {
    mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
    mState = initialState;
}

继续看 lifecycleEventObserver() 方法，在 Lifecycling.java 类里面

static LifecycleEventObserver lifecycleEventObserver(Object object) {
	...
	return new ReflectiveGenericLifecycleObserver(object);
}

进去看一下这个 ReflectiveGenericLifecycleObserver 构造器：

ReflectiveGenericLifecycleObserver(Object wrapped) {
    mWrapped = wrapped;
    // 使用反射拿class（就是我们的MyLocationListener）所有回调回来
    mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
}

着重记住这个类，我们后面会找回来：

class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {

构造器里有 getInfo() 这个方法，到 ClassInfoCache.java 类进去看：

final class ClassesInfoCache {
	...
	CallbackInfo getInfo(Class<?> klass) {
		// （只要涉及到反射）大部分系统源码都会设计Map缓存，提升一点点性能
		// 第一次创建、之后直接从缓存里面取
	    CallbackInfo existing = mCallbackMap.get(klass);
	    if (existing != null) {
	        return existing;
	    }
	    existing = createInfo(klass, null);
	    return existing;
	}
	...
}

看一下 createInfo() 方法：

private CallbackInfo createInfo(Class<?> klass, @Nullable Method[] declaredMethods) {

	// 到这里代码基本上已经结束了，停了
	
	// 将klass保存到Map，决定观察者class的走向
	// 【埋下伏笔】将观察者所有的信息存储在Map方便后续宿主反射来激活
	CallbackInfo info = new CallbackInfo(handlerToEvent);
	mCallbackMap.put(klass, info);
	mHasLifecycleMethods.put(klass, hasLifecycleMethods);
}

走到这里走不通了，观察者已经添加完成了，我们再换个方向继续分析。那么如何将生命周期的变化通知观察者呢？

3.2 宿主的生命周期又是如何激活的？

Activity 没有接调用 HandleLifecycleEvent 进行生命周期的分发，而是通过 ReportFragment 实现。从 MainActivity 着手来看继承关系：

MainActivity : AppCompatActivity {
AppCompatActivity extends FragmentActivity {
FragmentActivity extends ComponentActivity {
ComponentActivity implements LifecycleOwner {

LifecycleOwner 接口就是持有，作用就是返回 Lifecycle 对象

public interface LifecycleOwner {

    @NonNull
    Lifecycle getLifecycle();
}

ComponentActivity 中一定会执行 onCreate() 函数，在 ComponentActivity 中添加了一个无界面的 Fragment （即 ReportFragment）用来感知 Activity 的生命周期。ReportFragment 的 injectIfNeededIn() 函数会通过向 Activity 添加这个无 UI 界面的 Fragment，间接获得 Activity 的各个生命周期事件的回调通知：

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    mSavedStateRegistryController.performRestore(savedInstanceState);
    // 在 Activity 中添加一个 Fragment，这里的 ReportFragment 就是问题的答案
    ReportFragment.injectIfNeededIn(this);// 传参this
    if (mContentLayoutId != 0) {
        setContentView(mContentLayoutId);
    }
}

虽然 ComponentActivity 实现了 LifecycleOwner 接口并持有 LifecycleRegistry 实例，但是操作 LifecycleRegistry 生命周期变化的逻辑却是在 ReportFragment 中。ReportFragment 作为 Lifecycle 的实际操作者，在 ComponentActivity 中通过 injectIfNeededIn() 注入，追进到 ReportFragment.java 中看一下 injectIfNeededIn() 方法：

public class ReportFragment extends Fragment {
	// 创建Fragment
	public static void injectIfNeededIn(Activity activity) {
		// 高版本切面切出去处理兼容
	    if (Build.VERSION.SDK_INT >= 29) {
	        LifecycleCallbacks.registerIn(activity);
	    }
	    // 低版本处理，太熟悉了，模仿Glide的写法，无UI/空白的Fragment（ReportFragment）监听状态
	    android.app.FragmentManager manager = activity.getFragmentManager();
	    // 保证添加一次
	    if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
	        manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
	        manager.executePendingTransactions();
	    }
	}
}

injectIfNeededIn() 方法会创建一个名称为 ReportFragment 的 Fragment，每创建一个 Activity 时该 Fragment 就会被添加到对应的 Activity 中，不出意外，ReportFragment 才是真正分发生命周期的地方。

• 无UI/空白的 Fragment（即 ReportFragment）：为什么不在 Activity 里面搞？
  不直接在 ComponentActivity 对 LifecycleRegistry 进行操作，原因是出于适配考虑，开发者有可能直接继承 Activity，对这种情况不能直接把 Lifecycle 生命周期变化的逻辑直接写到 ComponentActivity。继承 Activity 可以，继承SupportActivity可以，继承 AppCompatActivity 可以，继承 XXXActivity（Android 升级新的 Activity）也可以，通过 LifecycleDispatcher 实现 ReportFragment 的注入，为了方便以后升级版本扩充兼容。ReportFragment 的注入和过程全程无侵，值得我们借鉴和学习！
• 为什么对版本做不同的处理？
  之所以会进行这两种情况区分，是因为 registerActivityLifecycleCallbacks() 中的 onActivityPostXXX() 和 onActivityPreXXX() 等方法是 SDK 29 时新添加的方法。当版本小于 29 时，就还是需要通过 ReportFragment 来间接取得事件通知。
  （1）运行设备的系统版本号小于 29。此情况会通过向 Activity 添加一个无 UI 界面的 Fragment（即 ReportFragment），间接获得 Activity 的各个生命周期事件的回调通知
  （2）运行设备的系统版本号大于等于29。此情况会向 Activity 注册一个 LifecycleCallbacks ，以此来直接获得各个生命周期事件的回调通知。这里应该还牵扯到对旧版本 ProcessLifecycleOwner 和 support 库的兼容，所以此时也会同时执行第一种情况的操作

继续看 ReportFragment.java 这个类：

public class ReportFragment extends android.app.Fragment {
	// Activity 初始化监听器，监听Activity的生命周期状态
    private ActivityInitializationListener mProcessListener;
	...
	@Override
	public void onActivityCreated(Bundle savedInstanceState) {
	    super.onActivityCreated(savedInstanceState);
	    // 分发对应的生命周期状态
	    dispatchCreate(mProcessListener);
	    // 事件分发，继续看
	    dispatch(Lifecycle.Event.ON_CREATE);
	}
	...
	// 分发生命周期状态，2.1.0 及之前版本调用的方法
	private void dispatch(@NonNull Lifecycle.Event event) {
	    if (Build.VERSION.SDK_INT < 29) {
	        dispatch(getActivity(), event);// 继续看
	    }
	}
	...
	// 2.2.0 新增的 dispatch 重载，尝试获取 Activity 中的 LifecycleRegistry 并调用 handleLifecycleEvent
	static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) {
		if (activity instanceof LifecycleRegistryOwner) {
	        ((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
	        return;
	    }
	
		// 获取Activity中的Lifecycle
	    if (activity instanceof LifecycleOwner) {
	        Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
	        if (lifecycle instanceof LifecycleRegistry) {
	        	// 主干逻辑看这里，分发Activity生命周期状态，继续
	            ((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
	        }
	    }
	}
	...

至此，生命周期组件对 LifecycleRegistry 的调用已分析完成，可见在 ReportFragment 对应的生命周期方法里面进行对应生命周期状态的分发，分发过程对应 dispatch() 方法，里面调用了 handleLifecycleEvent() 方法，dispatch()方法则会判断 Activity 是否实现了 LifecycleOwner 接口，如果实现了该接口就调用 LifecycleRegister 的 handleLifecycleEvent() 这样生命周期的状态就会借由 LifecycleRegistry 通知给各个 LifecycleObserver 从而调用其中对应 Lifecycle.Event 的方法。这种通过 Fragment 来感知 Activity 生命周期的方法其实在 Glide 的中也是有体现的。接下来就是分析 LifecycleRegistry 如何管理自身的生命周期状态，及如何回调到开发者注册的观察者，切换到LificycleRegistry.java 中的 handleLifecycleEvent()方法：

public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
    enforceMainThreadIfNeeded("handleLifecycleEvent");
    // 设置当前状态并通知观察者
    moveToState(event.getTargetState());// 核心代码，源码分析的重要入口
}

先查看 getTargetState() 方法：

 // 状态机：主要是google考虑到Lifecycle要给ViewModel、LiveData...任何框架用
 // 通过事件拿状态，就是说状态自身不会变化，需要依靠事件（onCreate()、onStart()...）的驱动而变化
 // 事件有前进（① ② ③）和倒退（④ ⑤ ⑥）两个方向，最终会返回一个枚举类型的状态值
@NonNull
public State getTargetState() {
    switch (this) {
        case ON_CREATE:// ①执行onCreate()事件，初始化状态->创建状态
        case ON_STOP:// ⑤执行onStop()事件，启动状态->创建状态
            return State.CREATED;// 创建状态
        case ON_START:// ②执行onStart()事件，创建状态->启动状态
        case ON_PAUSE:// ④执行onPause()事件，界面显示状态->启动状态
            return State.STARTED;// 启动状态
        case ON_RESUME:// ③执行onResume()事件，启动状态->界面显示状态
            return State.RESUMED;// 界面显示状态，没有后退的情况
        case ON_DESTROY:// ⑤执行onDestroy()事件，创建状态->销毁状态
            return State.DESTROYED;// 销毁状态
        case ON_ANY:
            break;
    }
    throw new IllegalArgumentException(this + " has no target state");
}
...
// 枚举状态等价于生命周期六个函数
public enum State {
	DESTROYED,
	INITIALIZED,
	CREATED,
	STARTED,
	RESUMED;
	// 判断至少是某一状态
	public boolean isAtLeast(@NonNull State state) {
	    return compareTo(state) >= 0;
	}
}

getTargetState() 的作用是根据 Event 获取事件之后处于的状态 ，并通知观察者同步到此生命周期状态。

状态的管理：关于 State 和 Event 的关系，官网给出了一张图，向 LifecycleObserver 回调事件的过程可以用以下这张官方提供的图来展示，理解这幅图很重要，可以说搞不清 Event 和 State 的关系，就看不懂 Lifecycle 的源码：

图：构成 Android Activity 生命周期的状态和事件

假设当前 LifecycleRegistry 的 mState 处于 RESUMED 状态，此时通过 addObserver ()方法新添加的 LifecycleObserver 会被包装为 ObserverWithState，且初始化状态为 INITIALIZED。由于 RESUMED 大于INITIALIZED，ObserverWithState 就会按照 INITIALIZED -> CREATED -> STARTED -> RESUMED 这样的顺序先后收到事件通知。假设当前 LifecycleRegistry 的 mState 处于 STARTED 状态。如果 LifecycleRegistry 收到 ON_RESUME 事件，mState 就需要变更为 RESUMED；如果 LifecycleRegistry 收到 ON_STOP 事件，mState 就需要变更为 CREATED；所以说，LifecycleRegistry 的 mState 会先后向不同方向迁移。同一个 Activity，其 LifecycleOwner 与 Fragment 的生命周期回调实际并不一致，需要特别注意！

LiveData 靠这个变量控制，会用一个 mActive 做记录，STARTED 和 RESUMED 是 true，其他状态为 false，当状态为 true 时显示画面，处理数据。

public abstract class LiveData<T> {
    class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {

		// LiveData能够直接拿到Lifecycle的状态来处理逻辑
        @Override
        public void onStateChanged(@NonNull LifecycleOwner source,
                @NonNull Lifecycle.Event event) {
            Lifecycle.State currentState = mOwner.getLifecycle().getCurrentState();
            // 如果销毁则解绑，不会内存泄漏
            if (currentState == DESTROYED) {
                removeObserver(mObserver);
                return;
            }
            Lifecycle.State prevState = null;
            while (prevState != currentState) {
                prevState = currentState;
                activeStateChanged(shouldBeActive());
                currentState = mOwner.getLifecycle().getCurrentState();
            }
        }

看完状态值，接着就是最最最关键的 moveToState() 状态平移/同步方法：

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;
}
...
/**
 * 状态对齐，比大小
*/
private void sync() {
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    // 同步时，假如生命周期组件已回收，抛出异常
    if (lifecycleOwner == null) {
        throw new IllegalStateException("LifecycleOwner of this LifecycleRegistry is already"
                + "garbage collected. It is too late to change lifecycle state.");
    }
    // 假如没有同步成功就进行同步，否则跳出循环，直到isSynced判断同步完成
    while (!isSynced()) {
        mNewEventOccurred = false;// 移除新事件标记
        // 枚举比大小，判断倒退或前进
        // 头节点状态大于当前状态，降级同步，例：RESUMED->STARTED
        // 不用对头结点做非空判断，因为头结点不存在时，isSynced返回true
        if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
            backwardPass(lifecycleOwner);
        }
        // 尾节点状态小于当前状态，升级同步例：STARTED->RESUMED
        // 需要检测mNewEventOccurred，降级同步时有可能发生事件嵌套
        // 需要对尾节点作出空判断，降级同步时有可能将节点移除
        Map.Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
        if (!mNewEventOccurred && newest != null
                && mState.compareTo(newest.getValue().mState) > 0) {
            forwardPass(lifecycleOwner);
        }
    }
    mNewEventOccurred = false;// 移除新事件标记
}
...
// 判断是否已经完成同步
private boolean isSynced() {
    // 假如不存在观察者，则不需要同步，返回已同步
    if (mObserverMap.size() == 0) {
        return true;
    }
    // 尾节点状态和头节点状态相同，且等于当前状态，则已同步
    State eldestObserverState = mObserverMap.eldest().getValue().mState;
    State newestObserverState = mObserverMap.newest().getValue().mState;
    // 当mObserverMap首尾节点状态相同，且尾节点状态等于当前状态时，认为同步完成
    return eldestObserverState == newestObserverState && mState == newestObserverState;
}
...
// 倒退，降级同步，同步过程优先进行降级同步
private void backwardPass(LifecycleOwner lifecycleOwner) {
	// 逆向迭代器，源码比较简单，此处不贴出
    Iterator<Map.Entry<LifecycleObserver, ObserverWithState>> descendingIterator =
            mObserverMap.descendingIterator();
    // 通过迭代器遍历，遇到新事件标识时中断
    while (descendingIterator.hasNext() && !mNewEventOccurred) {
        Map.Entry<LifecycleObserver, ObserverWithState> entry = descendingIterator.next();
        ObserverWithState observer = entry.getValue();
        // 严谨性，多次检测。循环对比单个观察者的状态，直到单个观察者同步到目标状态
        while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
                && mObserverMap.contains(entry.getKey()))) {
            // 通过状态获取事件
            Event event = Event.downFrom(observer.mState);
            if (event == null) {
                throw new IllegalStateException("no event down from " + observer.mState);
            }
            pushParentState(event.getTargetState());
            // 事件分发
            observer.dispatchEvent(lifecycleOwner, event);
            // 移除observer状态缓存
            popParentState();
        }
    }
}

// 计算传入状态降级所对应的事件
@Nullable
public static Event downFrom(@NonNull State state) {
    switch (state) {
        case CREATED:
            return ON_DESTROY;
        case STARTED:
            return ON_STOP;
        case RESUMED:
            return ON_PAUSE;
        default:
            return null;
    }
}

// 前进与后退流程类似，只是迭代器正向遍历，链表头部优先升级，以确保不变式成立。
private void forwardPass(LifecycleOwner lifecycleOwner) {
	...
}	
// 计算传入状态升级所对应的事件
public static Event upFrom(@NonNull State state) {
	...
}
...
// 封装的事件派分逻辑，分发生命周期事件最终依赖 ObserverWithState 的 dispatchEvent() 方法
void dispatchEvent(LifecycleOwner owner, Event event) {
    State newState = event.getTargetState();
    mState = min(mState, newState);
    mLifecycleObserver.onStateChanged(owner, event);// 回调生命周期状态，继续看
    mState = newState;
}

//内部类
public interface LifecycleEventObserver extends LifecycleObserver {
    void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event);
}

至此可以了解到，LifecycleRegistry 如何在生命周期改变时，外部通过 setCurrentState() 和handleLifecycleEvent()，最终调用 moveToState() 执行新状态设置和 Observe 同步。基于不变式，升级时 Observe 先进先同步，降级时 Observe 后进先同步。

由于 Lifecycle 用枚举的形式定义了所有 State，并且各个状态是按照固定的顺序来变化的，所以 State 具备了大小和顺序的概念。LifecycleRegistry 将事件通知给所有观察者之前，存在一个同步的过程。这个同步的过程中，前面的观察者已经通知到了，后面的观察者还没被通知，于是所有观察者之间的状态就不一致了，各观察者状态之间便产生了大小关系，只有第一个观察者的状态等于最后一个观察者的状态，并且等于 LifecycleRegistry 中的当前状态 mState，才说明状态同步整个完成了。

紧跟着 onStateChanged() 方法看其实现类，最终回到了前文埋下的伏笔：

@Deprecated
class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
    private final Object mWrapped;
    private final androidx.lifecycle.ClassesInfoCache.CallbackInfo mInfo;

    @SuppressWarnings("deprecation")
    ReflectiveGenericLifecycleObserver(Object wrapped) {
        mWrapped = wrapped;
        mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
    }

    @Override
    public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Event event) {
    	// invoke反射执行通过注解找到函数
        mInfo.invokeCallbacks(source, event, mWrapped);
    }
}

又回到了ClassInfoCache.java类

@SuppressWarnings("ConstantConditions")
void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) {
    invokeMethodsForEvent(mEventToHandlers.get(event), source, event, target);
    invokeMethodsForEvent(mEventToHandlers.get(Lifecycle.Event.ON_ANY), source, event, target);
}

private static void invokeMethodsForEvent(List<MethodReference> handlers,
        LifecycleOwner source, Lifecycle.Event event, Object mWrapped) {
    if (handlers != null) {
        for (int i = handlers.size() - 1; i >= 0; i--) {
            handlers.get(i).invokeCallback(source, event, mWrapped);
        }
    }
}
...
void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) {
    //noinspection TryWithIdenticalCatches
    try {
        switch (mCallType) {
            case CALL_TYPE_NO_ARG:
                mMethod.invoke(target);
                break;
            case CALL_TYPE_PROVIDER:
                mMethod.invoke(target, source);
                break;
            case CALL_TYPE_PROVIDER_WITH_EVENT:
                mMethod.invoke(target, source, event);
                break;
        }
    } catch (InvocationTargetException e) {
        throw new RuntimeException("Failed to call observer method", e.getCause());
    } catch (IllegalAccessException e) {
        throw new RuntimeException(e);
    }
}

到此为止，拨云见日，所有流程都清晰了，结束。

PS：如果宿主从 onResume() 注册，乱搞、抬杠、手误…会怎样？

继续分析addObserver()方法：

override fun onResume(){
	super.onResume()

	// while循环，一步接一步的修改，不会跳过
	// CREATED-->STARTED-->RESUMED
	lifecycle.addObserver(MyLocationListener())
}
...
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
	enforceMainThreadIfNeeded("addObserver");
	// 获取的observer需要设置的初始状态，如果不是DESTROYED就是INITIALIZED
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
    // 通过ObserverWithState对observer进行包装，并绑定初始的生命周期状态
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
    // 将包装的observer添加到mObserverMap，以observer自身作为Key值
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);

	// 不等于null表示我们携带状态的被观察者已经存在于类中（addObserver可以被调用多次）:这个方法对我们日常项目有很强的学习作用
    if (previous != null) {
        return;// 如果 observer 之前已经传进来过了，则不重复添加，直接返回
    }
    //这里持有的是LifecycleOwner的弱引用，通常是Activity
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        return;// 如果 LifecycleOwner 对象已经被回收了，则直接返回
    }

	// 表示是重新进入的，如果 isReentrance 为 true，则说明此时以下两种情况至少有一个成立：
    // 1. mAddingObserverCounter != 0。表示正在执行生命周期迁移导致的sync()同步，会出现这种情况，是由于开发者先添加了一个 LifecycleObserver ，当还在向其回调事件的过程中，在回调函数里又再次调用了 addObserver 方法添加了一个新的 LifecycleObserver
    // 2.mHandlingEvent 为 true。表示addObserver()导致的单个Observer同步，即此时正处于向外回调 Lifecycle.Event 的状态
    boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
    // 为啥用calculateTargetState：为了兼顾前面的，以及前面的前面的等等状态，合而为一取最小
    State targetState = calculateTargetState(observer);
    // 递增加一，标记当前正处于向新添加的 LifecycleObserver 回调 Event 值的过程，这里的++是为了完成以后的--，
    mAddingObserverCounter++;
        
	// 使Observer迁移到目标状态，会依次循环到正常状态为止
	// statefulObserver.mState.compareTo(targetState) < 0 成立的话说明 State 值还没遍历到目标状态
    // mObserverMap.contains(observer) 成立的话说明 observer 还没有并移除
    // 因为有可能在遍历过程中开发者主动在回调函数里将 observer 给移除掉了，所以这里每次循环都检查下
    // 当Observer的状态小于目标状态时，升级到目标状态
    // Observer的初始状态时DESTROYED或INITIALIZED，且当初始状态为DESTROYED时，目标状态也应为DESTROYED，所以新添加的Observer在初始化同步的时候只需要考虑升级同步。
    // 这里同时做了mObserverMap.contains(observer)的判断，之所以要这么处理，是因为有时候用户会在observer的生命周期回调中removeObserver移除自身，当发生这种情况时，立即结束迁移操作
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
            // 循环执行，targetState逐渐移动，直到持平于statefulObserver的mState，即DESTROYED 或INITIALIZED，目标是纠正与之前的状态
        //将 observer 已经遍历到的当前的状态值 mState 保存下来添加到父容器中
        pushParentState(statefulObserver.mState);
        final Event event = Event.upFrom(statefulObserver.mState);
        if (event == null) {
            throw new IllegalStateException("no event up from " + statefulObserver.mState);
        }
        // 将state转换event，状态转事件，然后调用dispatchEvent
        statefulObserver.dispatchEvent(lifecycleOwner, event);
        popParentState();// 以上操作完成在移除父容器中
        // 由于可能存在的变更，重新调用calculateTargetState获取当前目标需要迁移的目标状态
        // 我们 dispatch 了一个事件给观察者，在回调观察者代码的时候，观察者可能会修改我们的状态
        targetState = calculateTargetState(observer);
    }

	// 非重入状态执行sync同步
    if (!isReentrance) {
        sync();
    }
    // 与上面的++对应
    mAddingObserverCounter--;
}

private State calculateTargetState(LifecycleObserver observer) {
	// 当前对象的前一个对象
    Map.Entry<LifecycleObserver, ObserverWithState> previous = mObserverMap.ceil(observer);
	// 当前对象前一个对象的状态属性
    State siblingState = previous != null ? previous.getValue().mState : null;
    // 如果父容器不为空，去最后一个
    State parentState = !mParentStates.isEmpty() ? mParentStates.get(mParentStates.size() - 1)
            : null;
    return min(min(mState, siblingState), parentState);// 取以上三者中最小的一个
}

backwardPass() / forwardPass() 会同步 mObserverMap 中的所有观察者到指定生命周期状态，如果跨度比较大，会依次分发中间状态。

执行流程大致可以分为三步：

• 第一步，重新包装观察者生成一个 ObserverWithState。LifecycleObserver 的关键的生命周期接口实现既可以像上面例子一样通过 @OnLifecycleEvent(XXX) 注解实现，也可以继承相应的接口实现。所以这个类的主要作用是统一接口回调，并且保存了观察者的状态。
• 第二步，将封装后的 statefulObserver 保存进以原始参数 observer 为 key 的 map 中去，同时判断是否这个 observer 之前已经添加过了，如果 previous 不为 null，表示之前已经添加过了，就直接退出流程；如果 lifecycleOwner 为 null，说明 lifecycleOwner 已经死亡了，那么也可以直接退出。顺便提一句，LifecycleOwner 是作为弱引用传递进来的。
• 第三步，将新的观察者加进列表之后，通过while循环将它的状态同步到最新的状态 mState。upEvent 的返回值是传入 state 的下一个事件，这说明新的观察者仍然会连续收到从 INITIALIZED 到当前状态之间的所有状态，这里可以理解为是粘性的。

总结

其实 Lifecycle 使用的设计模式就是：观察者模式，具体的技术：注解 + 反射。

一共分两步实现

step 1：将观察者所有函数的class保存到ReflectiveGenericLifecycleObserver的ClassInfoCache中；
step 2：进行激活，创建空白的Fragment监听事件分发，通过事件寻找对应的状态，对状态比较确定前进或者后退同步状态，通过这个状态来反射到被观察者Class的所有函数，再得到被观察者的对应的事件。

具体执行流如图所示：

推荐阅读

• Jetpack 之 Lifecycle源码解析
• Jetpack —— Lifecycle源码解析
• 硬核讲解 Jetpack 之 Lifecycle 源码篇
• 深入理解AAC架构 - Lifecycle整体机制源码
• 从源码看 Jetpack（1）-Lifecycle 源码详解
• 从源码看 Jetpack（2）-Lifecycle 衍生物源码详解
• “终于懂了“系列：Jetpack AAC完整解析（一）Lifecycle 完全掌握！
• Retrofit 结合 Lifecycle，将 Http 生命周期管理到极致