Jetpack之Lifecycle

android Jetpack Lifecycle

基于android.arch.lifecycle的1.1.1版本

WHAT（使用，什么作用？）

简介

Lifecycle 是一个类，用于存储有关组件（如 Activity 或 Fragment）的生命周期状态的信息，并允许其他对象观察此状态。
Lifecycle 使用两种主要枚举跟踪其关联组件的生命周期状态：

• 事件
  从框架和 Lifecycle 类分派的生命周期事件。这些事件映射到 Activity 和 Fragment 中的回调事件。
• 状态
  由 Lifecycle 对象跟踪的组件的当前状态。

从左向右我们称之为上升，或者前进，反之称为降低或者后退。从数值上看，右侧比左侧大。（DESTROYED值最小）

注意：Support Library 26.1.0 及更高版本中的 Fragment 和 Activity 已实现 LifecycleOwner 接口。

Lifecycle 的应用场景非常广泛，我们可以利用 Lifecycle 的机制来帮助我们将一切跟生命周期有关的业务逻辑全都剥离出去，进行完全解耦。比如说：

• 视频的暂停与播放，
• Handler 的消息移除，
• 网络请求的取消操作，
• Presenter 的 attach&detach View
• 暂停和恢复动画绘制

使用

package com.example.lifecycledemo1;
import android.arch.lifecycle.Lifecycle;
import android.arch.lifecycle.LifecycleObserver;
import android.arch.lifecycle.OnLifecycleEvent;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.util.Log;
public class MainActivity extends AppCompatActivity {
    private static final String TAG = "MainActivity";
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        getLifecycle().addObserver(new MyObserver());//2
    }
    //1
    public class MyObserver implements LifecycleObserver{
        @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
        void onResume(){
            Log.d(TAG, "Lifecycle call onResume");
        }
        @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
        void onPause(){
            Log.d(TAG, "Lifecycle call onPause");
        }
    }
    @Override
    protected void onResume() {
        super.onResume();
        Log.d(TAG, "onResume");
    }
    @Override
    protected void onPause() {
        super.onPause();
        Log.d(TAG, "onPause");
    }
}

• 注释1，MyObserver实现了LifecycleObserver，通过注解的方式，对ON_CREATE和ON_RESUME事件进行监听。

• 注释2，直接使用getLifecycle方法获取Lifecycle对象，getLifecycle()是LifecycleOwner接口的方法
  因为在Android Support Library 26.1.0 及其之后的版本，Activity和Fragment已经默认实现了LifecycleOwner接口

• MyObserver是观察者，可以观察MainActivity的生命周期变化

• LifecycleOwner可以理解为被观察者，MainActivity默认实现了LifecycleOwner接口，也就是说MainActivity是被观察者。

运行程序，打印的log如下所示：

D/MainActivity: onResume
D/MainActivity: Lifecycle call onResume
D/MainActivity: Lifecycle call onPause
D/MainActivity: onPause

只要在MainActivity的onCreate方法中添加MyObserver，那么MyObserver就可以观察到MainActivity的各个生命周期的变化。

注意：在新版本，比如说2.2.0版本，提供了DefaultLifecycleObserver，这种通过接口的方式来回调生命周期，注解的方式在以后会被逐步废弃，Google 官方也建议开发者尽量使用接口回调的形式。

• 如果您使用Java 8 语言 ，然后使用DefaultLifecycleObserver 观察事件。 需要将"androidx.lifecycle:common-java8:" 增加到你的 build.gradle 文件中。
• 如果你使用的Java 7 语言 ，使用的注解观察生命周期事件。

自定义LifecycleOwner

如果你的 Support 库版本号低于 26.1.0，或者你的自定义类想要实现 LifecycleOwner，你需要使用到 LifecycleRegistry，并且自己处理每个生命周期，它是Lifecycle的实现类。

public class MyActivity extends Activity implements LifecycleOwner {
    private LifecycleRegistry lifecycleRegistry;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        lifecycleRegistry = new LifecycleRegistry(this);
        lifecycleRegistry.markState(Lifecycle.State.CREATED);
    }
    @Override
    public void onStart() {
        super.onStart();
        lifecycleRegistry.markState(Lifecycle.State.STARTED);
    }
    @NonNull
    @Override
    public Lifecycle getLifecycle() {
        return lifecycleRegistry;
    }
}

小结

• support包中的AppCompatActivity或者Fragment
  
  • Support Library 26.1.0 及更高版本
    直接使用即可
  • Support Library 26.1.0以下版本
    同下
• 普通Activity
  
  1. 依赖了android.arch.lifecycle:extensions，Activity只需要实现LifecycleOwner即可（为什么，下面会说明）
  2. 没有依赖，实现LifecycleOwner，并且需要自己处理生命周期，调用LifecycleRegistry相关方法
• 普通Fragment
  
  1. 实现LifecycleOwner，并且需要自己处理生命周期，调用LifecycleRegistry相关方法

HOW（原理，怎么实现的？）

基于1.1.0版本

Support Library 26.1.0 及更高版本

通过使用方式，我们可以很清楚的看出来，Lifecycle组件使用的是观察者模式，注册一个观察者，当Activity/Fragment生命周期改变的时候，通知观察者。

被观察者

LifecycleOwner

public interface LifecycleOwner {
    @NonNull
    Lifecycle getLifecycle();
}

LifecycleOwner接口非常简单，就提供了一个方法：返回Lifecycle。
所有实现了LifecycleOwner的类，都将会作为被观察者。

Lifecycle

Lifecycle只是一个抽象类，如下：

public abstract class Lifecycle {
    @MainThread
    public abstract void addObserver(@NonNull LifecycleObserver observer);
    @MainThread
    public abstract void removeObserver(@NonNull LifecycleObserver observer);
    @MainThread
    @NonNull
    public abstract State getCurrentState();
    @SuppressWarnings("WeakerAccess")
    public enum Event {
        ON_CREATE,
        ON_START,
        ON_RESUME,
        ON_PAUSE,
        ON_STOP,
        ON_DESTROY,
        ON_ANY
    }
    @SuppressWarnings("WeakerAccess")
    public enum State {
        DESTROYED,
        INITIALIZED,
        CREATED,
        STARTED,
        RESUMED;
        public boolean isAtLeast(@NonNull State state) {
            return compareTo(state) >= 0;
        }
    }
}

Lifecycle内部不仅包括了添加和移除观察者的方法，还包括了此前说到的Event和State枚举。可以看到Event中的事件和Activity的生命周期几乎是对应的，除了ON_ANY，它可用于匹配所有事件。

Lifecycle使用两个枚举来跟踪其关联组件的生命周期状态，这两个枚举分别是Event和State。

• State指的是Lifecycle的生命周期所处的状态。
• Event代表Lifecycle生命周期对应的事件，这些事件会映射到Activity和Fragment中的回调事件中。

ComponentActivity/SupportActivity

Support Library 26.1.0 及更高版本，我们的Activity/Fragment都是直接实现了LifecycleOwner，所以我们看一下它们里面是怎么处理的。

• 在Android 8.0时，FragmentActivity继承自SupportActivity
• 在Android 9.0，FragmentActivity继承自ComponentActivity 。

SupportActivity和ComponentActivity的代码区别不大，这里以ComponentActivity举例，如下所示：

public class ComponentActivity extends Activity implements LifecycleOwner {
    private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);//1
    ...
    @Override
    @SuppressWarnings("RestrictedApi")
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ReportFragment.injectIfNeededIn(this);//2
    }
    ...
    @Override
    public Lifecycle getLifecycle() {
        return mLifecycleRegistry;//3
    }
    ...
}

我们发现，Activity里面并没有直接通过生命周期接口进行各种通知处理，与Lifecycle相关的有三个地方：
1. new LifecycleRegistry(LifecycleOwner)
2. ReportFragment.injectIfNeededIn(this)
3. getLifecycle()

关于3，比较好理解，因为实现了LifecycleOwner，所以需要实现LifecycleOwner的唯一接口getLifecycle，返回的是LifecycleRegistry。

目前有两个问题：

• ReportFragment是干嘛的？
  因为Activity里面并没有直接通过生命周期接口进行各种通知处理，所以我们猜测这个应该就是具体的处理各个生命周期的类，类似于Glide
• LifecycleRegistry应该是继承了Lifecycle，那么它里面做了什么处理呢？

ReportFragment

我们先来看在Activity里面调用的静态方法injectIfNeededIn():

public static void injectIfNeededIn(Activity activity) {
    // ProcessLifecycleOwner should always correctly work and some activities may not extend
    // FragmentActivity from support lib, so we use framework fragments for activities
    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();
    }
}

首先，通过tag去找对应的Fragment，如果不存在，就新建一个ReportFragment，并立即添加到Activity中去。
另外还提供了一个静态方法：

static ReportFragment get(Activity activity) {
        return (ReportFragment) activity.getFragmentManager().findFragmentByTag(
                REPORT_FRAGMENT_TAG);
    }

用来返回ReportFragment，有可能为 null。
我们继续来看它在生命周期回调都做了什么：

@Override
public void onActivityCreated(Bundle savedInstanceState) {
    super.onActivityCreated(savedInstanceState);
    dispatch(Lifecycle.Event.ON_CREATE);
}
@Override
public void onStart() {
    super.onStart();
    dispatch(Lifecycle.Event.ON_START);
}
@Override
public void onResume() {
    super.onResume();
    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);
}

ReportFragment在它的生命周期里面都调用来dispatch()，并且传入了Lifecycle.Event，我们来看下dispatch()：

private void dispatch(Lifecycle.Event event) {
    Activity activity = getActivity();
    // 已经废弃，忽略
    if (activity instanceof LifecycleRegistryOwner) {
        ((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
        return;
    }
    // 1
    if (activity instanceof LifecycleOwner) {
        Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
        if (lifecycle instanceof LifecycleRegistry) {
            ((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
            }
        }
    }

我们主要看注释1这里，很简单：

• 判断Activity是否为LifecycleOwner
• 调用LifecycleOwner#getLifecycle()，得到Lifecycle
• 判断Lifecycle是否为LifecycleRegistry
• 调用LifecycleRegistry#handleLifecycleEvent()来分发Lifecycle.Event

LifecycleRegistry

https://android.googlesource.com/platform/frameworks/support/+/a9ac247af2afd4115c3eb6d16c05bc92737d6305/lifecycle/runtime/src/main/java/androidx/lifecycle/LifecycleRegistry.java

public class LifecycleRegistry extends Lifecycle {
    //一般一个 LifecycleRegistry 对应一个 LifecycleOwner 对象（Activity/Fragment等）
    //mState 就用来标记 LifecycleOwner 对象所处的当前生命周期状态
    private State mState;
    //持有对 LifecycleOwner 的弱引用，避免内存泄露
    private final WeakReference<LifecycleOwner> mLifecycleOwner;
    public LifecycleRegistry(@NonNull LifecycleOwner provider) {
        mLifecycleOwner = new WeakReference<>(provider);
        mState = INITIALIZED;
    }
}

LifecycleRegistry，继承了Lifecycle抽象类，是整个 Lifecycle 家族内一个很重要的类，其屏蔽了生命周期持有类（Activity / Fragment 等）的具体类型，使得外部（Activity / Fragment 等）可以只负责转发生命周期事件，由 LifecycleRegistry 来实现具体的事件回调和状态管理。

我们先来看下LifecycleRegistry是如何实现Lifecycle抽象类的。

getCurrentState()

/**
 * Current state
 */
private State mState;
public LifecycleRegistry(@NonNull LifecycleOwner provider) {
    mLifecycleOwner = new WeakReference<>(provider);
    mState = INITIALIZED;
}
@Override
public State getCurrentState() {
    return mState;
}

返回当前的State，会在moveToState(State)进行更新

removeObserver(LifecycleObserver)

@Override
public void removeObserver(@NonNull LifecycleObserver observer) {
    mObserverMap.remove(observer);
}

删除监听，删除观察者

addObserver(LifecycleObserver)

//Lifecycle 类中对 addObserver 方法添加了 @MainThread 注解，意思是该方法只能用于主线程调用
//所以此处不需要考虑多线程的情况
@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) {
        //如果 observer 之前已经传进来过了，则不重复添加，直接返回
        return;
    }
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        // it is null we should be destroyed. Fallback quickly
        //如果 LifecycleOwner 对象已经被回收了，则直接返回
        return;
    }
    //如果 isReentrance 为 true，则说明此时以下两种情况至少有一个成立：
    //1. mAddingObserverCounter != 0。会出现这种情况，是由于开发者先添加了一个 LifecycleObserver ，当还在向其回调事件的过程中，在回调函数里又再次调用了 addObserver 方法添加了一个新的 LifecycleObserver
    //2.mHandlingEvent 为 true。即此时正处于向外回调 Lifecycle.Event 的状态
    boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
    State targetState = calculateTargetState(observer);
    //递增加一，标记当前正处于向新添加的 LifecycleObserver 回调 Event 值的过程
    mAddingObserverCounter++;
    //statefulObserver.mState.compareTo(targetState) < 0 成立的话说明 当前观察者的State 小于 目标State
    //mObserverMap.contains(observer) 成立的话说明 observer 还没有并移除
    //因为有可能在遍历过程中开发者主动在回调函数里将 observer 给移除掉了，所以这里每次循环都检查下
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        //将 observer 已经遍历到的当前的状态值 mState 保存下来
        pushParentState(statefulObserver.mState);
        //向 observer 回调进入“statefulObserver.mState”前需要收到的 Event 值
        statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
        //移除 mState
        popParentState();
        // mState / subling may have been changed recalculate
        targetState = calculateTargetState(observer);
    }
    if (!isReentrance) {
        // we do sync only on the top level.
        sync();
    }
    mAddingObserverCounter--;
}

添加观察者，步骤如下：

• 传入的LifecycleObserver，包装成ObserverWithState
• 将ObserverWithState保存到Map中，Key为LifecycleObserver，Value为ObserverWithState
  
  • 如果Map中已经存在，就不保存新的，并返回旧的Value
  • 如果不存在，就保存新的，并返回null
• Map返回不为null，也就是Map中已经存在，就直接return
• Map返回为null，需要同步新Observer的State和targetState一致，并且回调之前的生命周期方法，举例来说吧：
  
  • 假设当前 LifecycleRegistry 的 mState 处于 RESUMED 状态，此时通过 addObserver 方法新添加的 LifecycleObserver 会被包装为 ObserverWithState，且初始化状态为 INITIALIZED。由于 RESUMED 大于INITIALIZED，ObserverWithState 就会按照 INITIALIZED -> CREATED -> STARTED -> RESUMED 这样的顺序先后收到事件通知

addObserver()这里面有几个需要说的地方：

calculateTargetState(LifecycleObserver)
这个方法是用来计算targetState，怎么计算呢？

当前状态 mState、mObserverMap 中最后一个观察者的状态 、有重入情况下 parentState 的状态 这三者中的最小值就是targetState

/**
 * 计算出的 targetState 一定是 <= mState 的
 */
private State calculateTargetState(LifecycleObserver observer) {
  // 获取当前 Observer 的前一个 Observer
  Entry<LifecycleObserver, ObserverWithState> previous = mObserverMap.ceil(observer);
  State siblingState = previous != null ? previous.getValue().mState : null;
  // 无重入情况下可不考虑 parentState ，为 null
  State parentState = !mParentStates.isEmpty() ? mParentStates.get(mParentStates.size() - 1)
          : null;
  return min(min(mState, siblingState), parentState);
}

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

ObserverWithState
addObserver的时候，会把传进来的LifecycleObserver包装成ObserverWithState

static class ObserverWithState {
    State mState;
    GenericLifecycleObserver mLifecycleObserver;
    ObserverWithState(LifecycleObserver observer, State initialState) {
        mLifecycleObserver = Lifecycling.getCallback(observer);
        mState = initialState;
    }
    void dispatchEvent(LifecycleOwner owner, Event event) {
        State newState = getStateAfter(event);
        mState = min(mState, newState);
        mLifecycleObserver.onStateChanged(owner, event);
        mState = newState;
    }
}

可以看出来，通过LifecycleObserver，得到了一个GenericLifecycleObserver，这个类是LifecycleObserver的子类，比LifecycleObserver多了一个onStateChanged(LifecycleOwner, Lifecycle.Event)。

handleLifecycleEvent(Lifecycle.Event)

上面我们看到了，ReportFragment 最终在向外传出 Lifecycle.Event 值时，调用的都是 LifecycleRegistry 对象的。 handleLifecycleEvent(Lifecycle.Event) 方法，既然需要的 Event 值已经拿到了，那再来看下 LifecycleRegistry 是如何将 Event 值转发给 LifecycleObserver 的。

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;
}
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;
}

LifecycleRegistry利用FastSafeIterableMap有序的特性，保证添加的Observer按照插入顺序，State从大到小的顺序排列。所以判断同步完成，只需要看第一个Observer和最后一个Observer的状态相等，并且等于LifecycleRegistry的状态。

• backwardPass：生命周期倒退。分发onPause，onStop，onDestroy事件
  
  • mState >= 最旧的Observer
    所有的Observer都小于mState，不需要backwardPass
  • mState < 最旧的Observer
    需要backwardPass
  • descendingIterator():倒序迭代器，确保按照顺序生命周期依次相等或更小
• forwardPass：生命周期前进。分发onCreate，onStart，onResume
  
  • mState > 最新的Observer
    需要forwardPass
  • mState <= 最新的Observer
    所有的Observer都大于mState，不需要forwardPass
  • iteratorWithAdditions():正序迭代器，且包含后面新添加的元素

private void backwardPass(LifecycleOwner lifecycleOwner) {
    // 反向遍历的迭代器
    Iterator<Entry<LifecycleObserver, ObserverWithState>> descendingIterator =
            mObserverMap.descendingIterator();
    // 如果在分发过程中有新的事件，就终止分发
    while (descendingIterator.hasNext() && !mNewEventOccurred) {
        Entry<LifecycleObserver, ObserverWithState> entry = descendingIterator.next();
        // 内部对Observer的封装，记录Observer的状态
        ObserverWithState observer = entry.getValue();
        // 如果Observer的state比当前state大，调整state（通过分发事件）
        // 这里判断是否contains可能是为了兼容在分发过程中Observer被移除的情况，避免不必要的处理。比如Observer的state比当前state大两个级别，那么下面的循环将执行两次，第一次分发事件的处理中，有可能就把Observer移除了；第二次在进入循环，mObserverMap中就不会存在这个entry了。
        while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
                && mObserverMap.contains(entry.getKey()))) {
            // 获取下一个事件
            Event event = downEvent(observer.mState);
            // 兼容重入场景，入栈。这里记录的是observer的目标状态，也就是执行完event后的状态。
            pushParentState(getStateAfter(event));
            // 分发事件
            observer.dispatchEvent(lifecycleOwner, event);
            // 兼容重入场景，出栈。
            popParentState();
        }
    }
}

不管是前进还是后退，最后都是调用了observer.dispatchEvent()，也就是ObserverWithState#dispatchEvent(LifecycleOwner owner, Event event)

pushParentState()

主要是为了解决嵌套使用的问题。
例如在观察者A的回调里面，又再次add了一个观察者B，观察者A当前的状态就是观察者B的ParentState，看名字是不是有点理解了。并且需要确保执行顺序

private ArrayList<State> mParentStates = new ArrayList<>();
private void popParentState() {
    mParentStates.remove(mParentStates.size() - 1);
}
private void pushParentState(State state) {
    mParentStates.add(state);
}

我们来举例说明：

假设，onStart监听了Event的ON_START，先添加的ObserverA的onStart方法，一定比后添加的ObserverB的onStart方法先执行完成。即便是B在A的onStart方法中添加的情况下（A.onStart执行完成后，B.onStart方法才会执行）。

ObserverA {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    void onStart(){
        ....
        mRegistry.removeObserver(this);
        mRegistry.addObserver(ObserverB);
    }
}

整个方法调用流程大致如下：

Activity#onStart()
LifecycleRegistry#handleLifecycleEvent()
LifecycleRegistry#moveToState()
LifecycleRegistry#sync()
LifecycleRegistry#forwardPass()
    LifecycleRegistry#pushParentState()// push A，此时为CREATED
    A-ObserverWithState#dispatchEvent()
    A-ObserverWithState#mState// 此时取的是min(mState, newState)
    A-GenericLifecycleObserver#onStateChanged()
    A#onStart()
        LifecycleRegistry#removeObserver()// 删除A
        LifecycleRegistry#addObserver() // 添加B
            LifecycleRegistry#calculateTargetState() // 此时LifecycleRegistry#mState是STARTED，previousObserver为null（A被删除了），mParentState为CREATED，所以最后targetState为CREATED
            LifecycleRegistry#pushParentState()// push B
            B-ObserverWithStateB#dispatchEvent()
            LifecycleRegistry#popParentState()// pop B
            LifecycleRegistry#calculateTargetState()// B add完成
    A-ObserverWithState#mState// 此时取的是newState，A更新完毕为STARTED
    LifecycleRegistry#popParentState()// pop A
    // 继续对B进行通知，更新B为STARTED

这个比较难理解，咱们理一下，说一下关键点：

• 修改LifecycleRegistry#mState = STARTED
• 遍历所有的ObserverWithState
• 回调A生命周期方法，ON_START
• 删除A
• 添加B
  
  • 获取targetState，此时，mState为STARTED，previousObserver为null，mParentState为CREATED，所以最后targetState为CREATED
  • 所以B只会更新到CREATED
• 修改A，ObserverWithState#mState = STARTED
• 回调B生命周期方法，ON_START
• 修改B，ObserverWithState#mState = STARTED

所以你看，如果没有mParentState，也就是没有调用pushParentState()，那么B就会先于A更新到STARTED状态

ObserverWithState

static class ObserverWithState {
        State mState;
        GenericLifecycleObserver mLifecycleObserver;
        ObserverWithState(LifecycleObserver observer, State initialState) {
            mLifecycleObserver = Lifecycling.getCallback(observer);
            mState = initialState;
        }
        void dispatchEvent(LifecycleOwner owner, Event event) {
            State newState = getStateAfter(event);
            mState = min(mState, newState);
            mLifecycleObserver.onStateChanged(owner, event);
            mState = newState;
        }
    }

ObserverWithState很简单，主要是需要关注两个点：

• 创建的时候，调用了Lifecycling.getCallback(observer)
• dispatchEvent的时候，调用了GenericLifecycleObserver#onStateChanged（）

小结

• 对于Activity来说，生命周期的分发并不是在Activity里面，而是在起内部插入了一个无UI的ReportFragment，通过监听ReportFragment的生命周期来分发Activity的生命周期
  
  • 在Lifecycle的新版本里面，如果设备版本 >= 29，会直接使用Activity.registerActivityLifecycleCallbacks，< 29的时候继续使用ReportFragment的方式
• LifecycleRegistry
  当Activity/Fragment的生命周期改变的时候，会调用LifecycleRegistry#handleLifecycleEvent(@NonNull Lifecycle.Event event)
  
  • addObserver()的时候，假设当前 LifecycleRegistry 的 mState 处于 RESUMED 状态，此时通过 addObserver 方法新添加的 LifecycleObserver 会被包装为 ObserverWithState，且初始化状态为 INITIALIZED。由于 RESUMED 大于INITIALIZED，ObserverWithState 就会按照 INITIALIZED -> CREATED -> STARTED -> RESUMED 这样的顺序先后收到事件通知
  • 假设onStart监听了Event的ON_START，先添加的ObserverA的onStart方法，一定比后添加的ObserverB的onStart方法先执行完成。即便是B在A的onStart方法中添加的情况下（A.onStart执行完成后，B.onStart方法才会执行）

观察者

LifecycleObserver（观察者）

这是一个空方法，实现该接口的类，通过注解的方式，并通过Lifecycle#addObserver()注册后，LifecycleObserver便可以观察到LifecycleOwner的生命周期事件。

GenericLifecycleObserver

https://android.googlesource.com/platform/frameworks/support/+/a9ac247af2afd4115c3eb6d16c05bc92737d6305/lifecycle/common/src/main/java/androidx/lifecycle/GenericLifecycleObserver.java

public interface GenericLifecycleObserver extends LifecycleObserver {
    /**
     * Called when a state transition event happens.
     *
     * @param source The source of the event
     * @param event The event
     */
    void onStateChanged(LifecycleOwner source, Lifecycle.Event event);
}

增加了一个onStateChanged()，在addObserver的时候，把LifecycleObserver通过Lifecycling转换为了GenericLifecycleObserver，并保存了起来，后续通知时使用。

Lifecycling

https://android.googlesource.com/platform/frameworks/support/+/a9ac247af2afd4115c3eb6d16c05bc92737d6305/lifecycle/common/src/main/java/androidx/lifecycle/Lifecycling.java

https://leavesc.gitbook.io/androidguide/jetpack-yuan-ma-bi-ji/lifecycle-yuan-ma-jie-xi#3-2-sdk-less-than-29

Lifecycling被上面提到了很多次，getCallback主要以下几种情况：

• Observer为FullLifecycleObserver时，直接返回FullLifecycleObserverAdapter，FullLifecycleObserverAdapter实现了GenericLifecycleObserver。
  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);
}
class FullLifecycleObserverAdapter implements GenericLifecycleObserver {
    private final FullLifecycleObserver mObserver;
    FullLifecycleObserverAdapter(FullLifecycleObserver observer) {
        mObserver = observer;
    }
    @Override
    public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
        switch (event) {
            case ON_CREATE:
                mObserver.onCreate(source);
                break;
            case ON_START:
                mObserver.onStart(source);
                break;
            case ON_RESUME:
                mObserver.onResume(source);
                break;
            case ON_PAUSE:
                mObserver.onPause(source);
                break;
            case ON_STOP:
                mObserver.onStop(source);
                break;
            case ON_DESTROY:
                mObserver.onDestroy(source);
                break;
            case ON_ANY:
                throw new IllegalArgumentException("ON_ANY must not been send by anybody");
        }
    }
}

• Observer为GenericLifecycleObserver，那么就直接返回该Observer
• Observer为LifecycleObserver接口，通过@LifecycleEvent注解声明回调方法的类。这个又分成两种情况
  
  • 如果是依赖了lifecycle-compiler包，编译时生成了实现GeneratedAdapter接口的实现类。Lifecycling通过类型反射获取构造方法，通过构造方法创建CompositeGeneratedAdaptersObserver类的对象，适配GeneratedAdapter。
  • 如果没有依赖lifecycle-compiler包，或者生成的类被混淆，Lifecycling将利用反射，查找注解并解析方法声明，将其缓存起来。最终创建ReflectiveGenericLifecycleObserver对象，作为GenericLifecycleObserver接口的实现类。具体解析的逻辑在ClassesInfoCache类中。

ClassesInfoCache

https://leavesc.gitbook.io/androidguide/jetpack-yuan-ma-bi-ji/lifecycle-yuan-ma-jie-xi#wu-lifecycling

Java 平台的反射操作是一个比较低效和耗费性能的行为，为了避免每次有需要进行事件回调时都再来对包含 OnLifecycleEvent 注解的 class 对象进行反射解析，所以 Lifecycling 内部对 Class、Method 等进行了缓存，以便后续复用。而 Lifecycling 就将这些缓存信息都封装存放在了 ClassesInfoCache 内部

需要注意的是：被注解的函数的入参类型、入参顺序、入参个数都有着严格的限制。
毕竟如果开发者为回调函数声明了一个 String 类型的入参参数的话，Lifecycle 也不知道该向其传递什么属性值

ClassesInfoCache 内部会判断指定的 class 对象是否包含使用了 OnLifecycleEvent 进行注解的函数，并将判断结果缓存在 mHasLifecycleMethods 内，缓存信息会根据 createInfo(klass, methods) 来进行获取

 //判断指定的 class 对象是否包含使用了 OnLifecycleEvent 进行注解的函数
boolean hasLifecycleMethods(Class<?> klass) {
    Boolean hasLifecycleMethods = mHasLifecycleMethods.get(klass);
    if (hasLifecycleMethods != null) {
        //如果本地有缓存的话则直接返回缓存值
        return hasLifecycleMethods;
    }
    //本地还没有缓存值，以下逻辑就是来通过反射判断 klass 是否包含使用 OnLifecycleEvent 进行注解的函数
    //获取 klass 包含的所有函数
    Method[] methods = getDeclaredMethods(klass);
    for (Method method : methods) {
        OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
        if (annotation != null) {
            // Optimization for reflection, we know that this method is called
            // when there is no generated adapter. But there are methods with @OnLifecycleEvent
            // so we know that will use ReflectiveGenericLifecycleObserver,
            // so we createInfo in advance.
            // CreateInfo always initialize mHasLifecycleMethods for a class, so we don't do it
            // here.
            createInfo(klass, methods);
            return true;
        }
    }
    mHasLifecycleMethods.put(klass, false);
    return false;
}

而正是在 createInfo函数内部对被注解函数的入参类型、入参顺序、入参个数等进行了限制，当不符合规定时则会在运行时直接抛出异常

//以下三个整数值用于标记被注解的函数的入参参数的个数
//不包含入参参数
private static final int CALL_TYPE_NO_ARG = 0;
//包含一个入参参数    
private static final int CALL_TYPE_PROVIDER = 1;
//包含两个入参参数        
private static final int CALL_TYPE_PROVIDER_WITH_EVENT = 2;
private CallbackInfo createInfo(Class<?> klass, @Nullable Method[] declaredMethods) {
    Class<?> superclass = klass.getSuperclass();
    Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();
    if (superclass != null) {
        CallbackInfo superInfo = getInfo(superclass);
        if (superInfo != null) {
            handlerToEvent.putAll(superInfo.mHandlerToEvent);
        }
    }
    Class<?>[] interfaces = klass.getInterfaces();
    for (Class<?> intrfc : interfaces) {
        for (Map.Entry<MethodReference, Lifecycle.Event> entry : getInfo(
                intrfc).mHandlerToEvent.entrySet()) {
            verifyAndPutHandler(handlerToEvent, entry.getKey(), entry.getValue(), klass);
        }
    }
    Method[] methods = declaredMethods != null ? declaredMethods : getDeclaredMethods(klass);
    boolean hasLifecycleMethods = false;
    for (Method method : methods) {
        //找到包含 OnLifecycleEvent 注解的函数
        OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
        if (annotation == null) {
            continue;
        }
        hasLifecycleMethods = true;
        //以下的所有逻辑是这样的：
        //1. 获取 method 所对应的函数的参数个数和参数类型，即 params
        //2. 如果参数个数为 0，则 callType = CALL_TYPE_NO_ARG，method 不包含入参参数
        //3. 如果参数个数大于 0，则第一个参数必须是 LifecycleOwner 类型的对象，否则抛出异常
        //3.1、如果参数个数为 1，则 callType = CALL_TYPE_PROVIDER
        //3.2、如果参数个数为 2，则注解值 annotation 必须是 Lifecycle.Event.ON_ANY
        //     且第二个参数必须是 Lifecycle.Event 类型的对象，否则抛出异常
        //     如果一切都符合条件，则 callType = CALL_TYPE_PROVIDER_WITH_EVENT
        //3.3、如果参数个数大于 2，则抛出异常，即要求 method 最多包含两个参数，且对参数类型和参数顺序进行了限制
        Class<?>[] params = method.getParameterTypes();
        int callType = CALL_TYPE_NO_ARG;
        if (params.length > 0) {
            callType = CALL_TYPE_PROVIDER;
            if (!params[0].isAssignableFrom(LifecycleOwner.class)) {
                throw new IllegalArgumentException(
                        "invalid parameter type. Must be one and instanceof LifecycleOwner");
            }
        }
        Lifecycle.Event event = annotation.value();
        if (params.length > 1) {
            callType = CALL_TYPE_PROVIDER_WITH_EVENT;
            if (!params[1].isAssignableFrom(Lifecycle.Event.class)) {
                throw new IllegalArgumentException(
                        "invalid parameter type. second arg must be an event");
            }
            if (event != Lifecycle.Event.ON_ANY) {
                throw new IllegalArgumentException(
                        "Second arg is supported only for ON_ANY value");
            }
        }
        if (params.length > 2) {
            throw new IllegalArgumentException("cannot have more than 2 params");
        }
        MethodReference methodReference = new MethodReference(callType, method);
        verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
    }
    CallbackInfo info = new CallbackInfo(handlerToEvent);
    mCallbackMap.put(klass, info);
    mHasLifecycleMethods.put(klass, hasLifecycleMethods);
    return info;
}

然后最终在 MethodReference 类内部的 invokeCallback() 函数完成最终的反射调用
MethodReference 用于缓存具有 OnLifecycleEvent 注解的函数（Method）以及该函数所具有的入参个数（知道了入参个数就知道了该如何进行反射调用），通过 invokeCallback() 函数来进行 Lifecycle.Event 事件通知

static class MethodReference {
    final int mCallType;
    final Method mMethod;
    MethodReference(int callType, Method method) {
        mCallType = callType;
        mMethod = method;
        mMethod.setAccessible(true);
    }
    void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) {
        //noinspection TryWithIdenticalCatches
        //根据入参个数来传递特定的参数并进行反射回调
        //因此用 OnLifecycleEvent 进行注解的函数，其入参个数、入参类型、入参声明顺序都有固定的要求
        //当不符合要求时会导致反射失败从而抛出异常
        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);
        }
    }
    //省略无关函数
    ····
}

总结

Lifecycle 的整个事件流程都在上文大致讲述完毕了，这里再来做下总结：

• 我们日常使用的 androidx.appcompat.app.AppCompatActivity 和 androidx.fragment.app.Fragment 都实现了 LifecycleOwner 接口，其 getLifecycle() 方法返回的 Lifecycle 对象均为 LifecycleRegistry

• AppCompatActivity 默认挂载了一个无 UI 界面的 ReportFragment，ReportFragment 会根据用户手机的系统版本号高低，用不同的方式获取到 AppCompatActivity 的事件变化通知，最终调用 LifecycleRegistry 的 handleLifecycleEvent(Lifecycle.Event) 方法将 Lifecycle.Event 传递出去。此时，LifecycleRegistry 就拿到了 Lifecycle.Event

• androidx.fragment.app.Fragment 会在内部直接调用 LifecycleRegistry 的 handleLifecycleEvent(Lifecycle.Event) 方法完成事件通知，此时，LifecycleRegistry 也拿到了 Lifecycle.Event

• LifecycleRegistry 会将外部 addObserver 传进来的 LifecycleObserver 对象都给包装成 ObserverWithState 类内部的 LifecycleEventObserver 对象，屏蔽了外部传进来的 LifecycleObserver 的差异性（可能是接口，也可能是注解）

• LifecycleRegistry 通过直接调用 ObserverWithState 类内部的 LifecycleEventObserver 对象的 onStateChanged 方法来完成最终的事件回调。至此整个流程就完成了

普通Activity

https://github.com/leavesC/AndroidGuide/blob/gitbook/jetpack/Lifecycle%E8%A1%8D%E7%94%9F.md

普通Activity
1. 依赖了android.arch.lifecycle:extensions，Activity只需要实现LifecycleOwner即可（为什么，下面会说明）

使用的时候，我们说过，普通Activity，依赖了android.arch.lifecycle:extensions，只需要实现LifecycleOwner，我们就可以监听生命周期变化呢？

LifecycleDispatcher

LifecycleDispatcher 的主要逻辑是用于向应用内所有 Activity 注入一个 ReportFragment，通过 ReportFragment 来辅助获取 Activity 的生命周期事件。
并由外部通过调用 init(Context) 方法来进行初始化

使用 registerActivityLifecycleCallbacks来监听 Activity 的最大优势就是它的涉及范围可以囊括应用的所有自定义 Activity 和使用到的依赖库中的所有第三方 Activity，大多数情况下我们是无法也不会去直接修改第三方依赖库中的代码，通过系统提供的方法我们才可以比较简单地向其注入一些自定义逻辑

class LifecycleDispatcher {
    private static AtomicBoolean sInitialized = new AtomicBoolean(false);
    static void init(Context context) {
        //避免重复初始化
        if (sInitialized.getAndSet(true)) {
            return;
        }
        ((Application) context.getApplicationContext())
                .registerActivityLifecycleCallbacks(new DispatcherActivityCallback());
    }
    @SuppressWarnings("WeakerAccess")
    @VisibleForTesting
    static class DispatcherActivityCallback extends EmptyActivityLifecycleCallbacks {
        @Override
        public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
            //当 Activity 被创建时，向其注入一个 ReportFragment（如果需要的话）
            ReportFragment.injectIfNeededIn(activity);
        }
        @Override
        public void onActivityStopped(Activity activity) {
        }
        @Override
        public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
        }
    }
    private LifecycleDispatcher() {
    }
}

ProcessLifecycleOwner

ProcessLifecycleOwner 是 LifecycleOwner的一个 实现类，可用于监听整个应用的前后台变化，内部维护resume和start的数量来判断Application的状态。
在一些场景下（比如消息推送时的跳转、数据埋点）是比较有用的

使用

ProcessLifecycleOwner 是单例模式，获取到其唯一实例后向其添加 Observer 即可。需要注意的是，ProcessLifecycleOwner 是依靠于应用内所有 Activity 的生命周期的变化来定义生命周期事件的，所以对于那些完全无 UI 界面的应用来说使用 ProcessLifecycleOwner 是没有意义的

ProcessLifecycleOwner.get().lifecycle.addObserver(object : DefaultLifecycleObserver {
            override fun onCreate(owner: LifecycleOwner) {
                Log.e("TAG", "应用被启动")
            }
            override fun onResume(owner: LifecycleOwner) {
                Log.e("TAG", "应用进入前台")
            }
            override fun onStop(owner: LifecycleOwner) {
                Log.e("TAG", "应用进入后台")
            }
        })

源码

ProcessLifecycleOwner 实现了 LifecycleOwner 接口，也用到了 LifecycleRegistry 作为其生命周期实现。其构造函数是私有的，通过静态变量来实现单例模式

public class ProcessLifecycleOwner implements LifecycleOwner {
    private final LifecycleRegistry mRegistry = new LifecycleRegistry(this);
    private static final ProcessLifecycleOwner sInstance = new ProcessLifecycleOwner();
    /**
     * The LifecycleOwner for the whole application process. Note that if your application
     * has multiple processes, this provider does not know about other processes.
     *
     * @return {@link LifecycleOwner} for the whole application.
     */
    @NonNull
    public static LifecycleOwner get() {
        return sInstance;
    }
    @NonNull
    @Override
    public Lifecycle getLifecycle() {
        return mRegistry;
    }
}

开放了 init(Context)函数来由外部进行变量初始化，该方法的主要逻辑是这样的：

• 通过外部传入的 context 对象获取到 Application 对象
• 向 Application 注册 registerActivityLifecycleCallbacks，通过 EmptyActivityLifecycleCallbacks 和 ReportFragment 来实现对所有系统版本下的 Activity 进行全局的生命周期事件监听

static void init(Context context) {
    sInstance.attach(context);
}
void attach(Context context) {
    mHandler = new Handler();
    //因为 ProcessLifecycleOwner 是针对于对整个应用的生命周期的监听
    //会执行到这一步的话说明应用肯定被启动了，此时就到了 Lifecycle.Event.ON_CREATE
    //且由于 attach 方法只会被调用一次，所以外部也只会收到一次 Lifecycle.Event.ON_CREATE 事件
    mRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
    Application app = (Application) context.getApplicationContext();
    app.registerActivityLifecycleCallbacks(new EmptyActivityLifecycleCallbacks() {
        @Override
        public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
        //在 LifecycleDispatcher 中已经为每个 Activity 注入了 ReportFragment
        //所以此处都可以成功获取到 ReportFragment 对象并设置回调事件
        ReportFragment.get(activity).setProcessListener(mInitializationListener);
        }
        @Override
        public void onActivityPaused(Activity activity) {
            activityPaused();
        }
        @Override
        public void onActivityStopped(Activity activity) {
            activityStopped();
        }
    });
}

在onActivityCreated的时候，设置了一个mInitializationListener，而这个mInitializationListener在ReportFragment的生命周期改变的时候，都是会回调的。

void activityStarted() {
    mStartedCounter++;
    if (mStartedCounter == 1 && mStopSent) {
        mRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START);
        mStopSent = false;
    }
}
void activityResumed() {
    mResumedCounter++;
    if (mResumedCounter == 1) {
        if (mPauseSent) {
            mRegistry.handleLifecycleEvent(Lifecycle.Event.ON_RESUME);
            mPauseSent = false;
        } else {
            mHandler.removeCallbacks(mDelayedPauseRunnable);
        }
    }
}
void activityPaused() {
    mResumedCounter--;
    if (mResumedCounter == 0) {
        mHandler.postDelayed(mDelayedPauseRunnable, TIMEOUT_MS);
    }
}
void activityStopped() {
    mStartedCounter--;
    dispatchStopIfNeeded();
}
private void dispatchPauseIfNeeded() {
    if (mResumedCounter == 0) {
        mPauseSent = true;
        mRegistry.handleLifecycleEvent(Lifecycle.Event.ON_PAUSE);
    }
}
private void dispatchStopIfNeeded() {
    if (mStartedCounter == 0 && mPauseSent) {
        mRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);
        mStopSent = true;
    }
}

这里需要注意的是，activityPaused的时候是有一个700ms的延迟的，主要为了解决：
应用还保持在前台，但由于用户旋转了屏幕导致 Activity 处于重建中。所以为了避免由于第一种情况导致误判，此处会通过 Handler 来发送一个延迟消息，在 700 毫秒后（等待 Activity 重建完成）再来进行检查是否真的需要发布 ON_PAUSE 事件

ProcessLifecycleOwnerInitializer

LifecycleDispatcher 和 ProcessLifecycleOwner 两个类都需要外部传入 Context 对象以便进行初始化，但我们在使用时其实是不需要手动初始化的，这是为什么呢？

• Lifecycle使用ProcessLifecycleOwnerInitializer来初始化ProcessLifecycleOwner，ProcessLifecycleOwnerInitializer继承自ContentProvider，利用ContentProvider会在Application初始时同时初始化的特点，在ProcessLifecycleOwnerInitializer的onCreate方法中，将Application对象绑定到ProcessLifecycleOwner中
• 并且在android.arch.lifecycle:extensions的AndroidManifest.xml文件也包含了对 ProcessLifecycleOwnerInitializer 的声明，在打包时会自动将声明语句合并到主项目工程中的 AndroidManifest.xml 文件中

这样就实现了，在不修改Application的情况下进行绑定

public class ProcessLifecycleOwnerInitializer extends ContentProvider {
    @Override
    public boolean onCreate() {
        LifecycleDispatcher.init(getContext());
        ProcessLifecycleOwner.init(getContext());
        return true;
    }
    @Nullable
    @Override
    public Cursor query(@NonNull Uri uri, String[] strings, String s, String[] strings1,
            String s1) {
        return null;
    }
    @Nullable
    @Override
    public String getType(@NonNull Uri uri) {
        return null;
    }
    @Nullable
    @Override
    public Uri insert(@NonNull Uri uri, ContentValues contentValues) {
        return null;
    }
    @Override
    public int delete(@NonNull Uri uri, String s, String[] strings) {
        return 0;
    }
    @Override
    public int update(@NonNull Uri uri, ContentValues contentValues, String s, String[] strings) {
        return 0;
    }
}

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="androidx.lifecycle.process" >
    <uses-sdk
        android:minSdkVersion="14"
        android:targetSdkVersion="28" />
    <application>
        <provider
            android:name="androidx.lifecycle.ProcessLifecycleOwnerInitializer"
            android:authorities="${applicationId}.lifecycle-process"
            android:exported="false"
            android:multiprocess="true" />
    </application>
</manifest>

总结

• ProcessLifecycleOwner 是对整个应用的生命周期进行监听，但由于 ProcessLifecycleOwner 是依靠于应用内所有 Activity 的生命周期的变化来定义生命周期事件的，所以对于那些完全无 UI 界面的应用来说使用 ProcessLifecycleOwner 是没有意义的
• ON_CREATE 事件只会在 ProcessLifecycleOwner 初始化的时候被触发
• 当应用刚被打开，或者是从后台切换到前台时，会依次触发 ON_START、ON_RESUME 事件
• 当应用从前台退到后台时，会依次触发 ON_PAUSE、ON_STOP 事件
• 由于存在用户旋转了屏幕导致 Activity 被重建的情况，所以 ProcessLifecycleOwner 内部有延时判断的逻辑，因此 ON_PAUSE、ON_STOP 这两个事件会有 700 毫秒的延迟
• ON_DESTROY 事件永远不会被触发
• ProcessLifecycleOwner 的初始化过程由 ProcessLifecycleOwnerInitializer 隐式完成

WHY（扩展，为什么这么实现？有没有更好的方式？）

为什么不直接在SupportActivity的生命周期函数中给Lifecycle分发生命周期事件，而是要加一个Fragment呢？

public static void injectIfNeededIn(Activity activity) {
        // ProcessLifecycleOwner should always correctly work and some activities may not extend
        // FragmentActivity from support lib, so we use framework fragments for activities
        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();
        }
    }

看注释可知：

• 为了能让 ProcessLifecycleOwner 正确地工作；
• 并非所有的 Activity 都是继承SupportActivity
  这个可以详细说下，如果有一个Activity并不是继承的SupportActivity，那么它怎么监听生命周期呢？就是之前说过的，实现LifecycleOwner即可，然后LifecycleDispatcher会给该Activity注入一个ReportFragment，再这个Fragment里面来监听Activity的生命周期变化

为什么用ReportFragment分发生命周期而不直接使用Activity#ActivityLifecycleCallbacks的回调来处理Lifecycle生命周期的变化？

新版本已经使用Activity#ActivityLifecycleCallbacks，区分Android版本，如下：

public class ReportFragment extends Fragment {
   public static void injectIfNeededIn(Activity activity) {
       // 如果是 Android 10 版本或者以上
       // 则通过 registerActivityLifecycleCallbacks 的方式来实现生命周期的回调
       if (Build.VERSION.SDK_INT >= 29) {
           // On API 29+, we can register for the correct Lifecycle callbacks directly
           activity.registerActivityLifecycleCallbacks(
                   new LifecycleCallbacks());
       }
       // 往页面添加一个空的 Fragment，在 Fragment 的生命周期方法中分发事件
       android.app.FragmentManager manager = activity.getFragmentManager();
       if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
           manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
           manager.executePendingTransactions();
       }
   }
}

对于 Lifecycle.Event 为啥不直接分发，而是通过 Lifecycle.State 中转？

Event-->State-->Event
Activity/Fragment-->LifecycleRegistry-->Obserever

保证一致性，需要根据Event来判断State的走向

每一个Activity都会被注入一个ReportFragment？

这个需要区分系统版本了来看：

• Android 10 版本或者以上
  不会，会使用Activity#ActivityLifecycleCallbacks，没有用ReportFragment
• 反之
  当依赖了ProcessLifecycleOwnerInitializer，那么每一个Activity都会被写入一个ReportFragment，包含第三方的Acitivity

Event和State到底什么区别？

FastSafeIterableMap

https://juejin.cn/post/6844904061519544334

• Map，K-V结构存储。
• 有序，插入顺序决定保存顺序。支持正向、反向遍历。
• 支持在遍历过程中添加、移除元素。（影响LifecycleRegistry的可重入性）

保证添加的Observer按照插入顺序，State从大到小的顺序排列。
例如，o1，o2，o3顺序插入，则o1.state >= o2.state >= o3.state

参考

http://liuwangshu.cn/application/jetpack/2-lifecycle-use.html
https://juejin.cn/post/6844903977788801032
https://blog.kyleduo.com/2019/01/17/lifecycle-source-code/
https://zhich.github.io/2018/11/06/Android-Jetpack-%E4%B9%8B-LifeCycle/
https://github.com/leavesC/AndroidGuide/blob/gitbook/jetpack/Lifecycle%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90.md
https://juejin.cn/post/6844904061519544334