前言

在阅读之前先看看这些问题：

1. LifecycleRegistry 里存放观察者的Map是什么结构？
2. 这个Map有一个性质你知道吗？为什么要维护这个性质？
3. 你是否了解“重入”这种情况？

如果你对这些问题有疑问，那本文也许有一点帮助。

在上一篇 Lifecycle 源码解析（一）：预备知识 中已经讲了解读 Lifecycle 源码需要的预备知识，本篇正式开始对 Lifecycle 的流程进行源码分析。

首先确定我们要研究的流程，Lifecycle 的整个流程可以分为：生命周期组件添加观察者，生命周期组件发送事件，Lifecycle分发事件。

为方便理解，本文使用 Activity 作为生命周期组件的代表进行分析。

LifecycleRegistry

LifecycleRegistry 是整个库的核心，它也是 Lifecycle 的唯一实现类。在开始流程分析前，先了解一下它的几个重要的成员变量。

public class LifecycleRegistry extends Lifecycle {
    /**
     * Custom list that keeps observers and can handle removals / additions during traversal.
     *
     * Invariant: at any moment of time for observer1 & observer2:
     * if addition_order(observer1) < addition_order(observer2), then
     * state(observer1) >= state(observer2),
     */
    private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap =
            new FastSafeIterableMap<>();
    /**
     * Current state
     */
    private State mState;
    /**
     * The provider that owns this Lifecycle.
     * Only WeakReference on LifecycleOwner is kept, so if somebody leaks Lifecycle, they won't leak
     * the whole Fragment / Activity. However, to leak Lifecycle object isn't great idea neither,
     * because it keeps strong references on all other listeners, so you'll leak all of them as
     * well.
     */
    private final WeakReference<LifecycleOwner> mLifecycleOwner;

    private int mAddingObserverCounter = 0;

    private boolean mHandlingEvent = false;
    private boolean mNewEventOccurred = false;

    // we have to keep it for cases:
    // void onStart() {
    //     mRegistry.removeObserver(this);
    //     mRegistry.add(newObserver);
    // }
    // newObserver should be brought only to CREATED state during the execution of
    // this onStart method. our invariant with mObserverMap doesn't help, because parent observer
    // is no longer in the map.
    private ArrayList<State> mParentStates = new ArrayList<>();
    private final boolean mEnforceMainThread;
    ...
}

源码中对各个变量的注释对我们理解源码有很大的帮助，大致意思如下：

• mObserverMap ：保存观察者并且能在遍历的时候进行添加或者移除操作，同时它还有一个“不变性”：任何时刻，新观察者的状态 <= 旧观察者的状态。
• mState : （Activity的）当前的状态
• mLifecycleOwner ： Activity 的弱引用
• mAddingObserverCounter ： 正在添加的观察者的个数
• mHandlingEvent ： 是否正在处理生命周期事件
• mNewEventOccurred ： 由 mAddingObserverCounter 和 mHandlingEvent 得到，后面会讲到
• mParentStates ： 与是否重入有关，后面会讲到
• mEnforceMainThread ： 是否强制在主线程中执行代码

Activity 添加观察者

使用方法很简单，调用 Lifecycle 的 addObserver() 就可以了。但是这个方法是 Lifecycle 的抽象方法，那我们就找到 Lifecycle 的唯一子类 LifecycleRegistry ，Lifecycle 的具体实现都在这个类中。

addObserver()

public void addObserver(@NonNull LifecycleObserver observer) {
    enforceMainThreadIfNeeded("addObserver");
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);

    if (previous != null) {
        return;
    }
    
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        // it is null we should be destroyed. Fallback quickly
        return;
    }

    boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
    State targetState = calculateTargetState(observer);
    mAddingObserverCounter++;
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        pushParentState(statefulObserver.mState);
        final Event event = Event.upFrom(statefulObserver.mState);
        if (event == null) {
            throw new IllegalStateException("no event up from " + statefulObserver.mState);
        }
        statefulObserver.dispatchEvent(lifecycleOwner, event);
        popParentState();
        // mState / subling may have been changed recalculate
        targetState = calculateTargetState(observer);
    }

    if (!isReentrance) {
        // we do sync only on the top level.
        sync();
    }
    mAddingObserverCounter--;
}

我们分成几段分析：

State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);

• 这里给观察者加上一个初始状态封装起来，之所以要加状态是因为 LifecycleObserver 中没有表示状态的东西，而将 Activity 的生命周期同步给观察者的实现显然需要知道观察者的状态。
• 初始状态有 mState 决定，也就是 Activity 的当前状态。
• 如果 Activity 已经被销毁了，那么观察者的初始状态也应该是 DESTROYED , 这样做的好处时后面的分发事件，同步前的判断使用的 compareTo() 的返回值都为0，也就不会进行分发事件，同步，符合观察者不在感应已销毁 Activity 的生命周期的逻辑。
• 只要 Activity 没有被销毁，那么观察者的初始状态都应该是 INITIALIZED , 这样做是为了实现后面的“黏性”事件，后面会讲到。

---

ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver); 
if (previous != null) { return; }

• putIfAbsend() 这个方法只有之前没有存放过这个 key 才会把 value 存进去，并不会覆盖。如果之前存过，那就返回之前的值；没存过就返回 null 。
• 而在这个方法中的逻辑就是：如果之前添加过这个观察者就直接返回，不重复添加同一个观察者

---

LifecycleOwner lifecycleOwner = mLifecycleOwner.get(); 
if (lifecycleOwner == null) {  return; }

• 调用弱引用的 get() 返回 null ，说明 Activity 已经被回收了，没必要执行后面的操作了，直接返回。

---

boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;

• mAddingObserverCounter 这个变量只在紧接着这一句之后+1，在这个方法结束前-1，所以能表示正在添加的观察者个数。
• 一般情况下，Activity 一个一个地添加观察者，mAddingObserverCounter 一开始都是 0 ,然后+1，再-1变回0。isReentrance 为 false ,表示没有“重入”。
• 但是在之后的 while 循环中会将生命周期事件分发给观察者，如果这个观察者的回调方法又调用了这个 LifecycleRegistry 实例的 addObserver()，那么一开始 mAddingObserverCounter 就是1，而不是0。isReentrance 为true,这就是“重入”的由来。
• mHandlingEvent 涉及的方法是 moveToState() ，一般为 false ,后面会讲到。

---

State targetState = calculateTargetState(observer);

• 计算新添加的观察者在添加完成后应该到达的状态。一般情况下就是 mState,后面会讲到。

---

 while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        pushParentState(statefulObserver.mState);
        final Event event = Event.upFrom(statefulObserver.mState);
        if (event == null) {
            throw new IllegalStateException("no event up from " + statefulObserver.mState);
        }
        statefulObserver.dispatchEvent(lifecycleOwner, event);
        popParentState();
        // mState / subling may have been changed recalculate
        targetState = calculateTargetState(observer);
    }

• 观察者的初始状态为 DESTROYED 时进入不了循环，前面说过了。
• pushParentState(),popParentState()与“重入”有关，对一般情况没有影响，后面会讲到。
• Event.upFrom() ，从参数类型和返回类型来看，这个方法根据状态得到生命周期事件，那中间逻辑是什么呢？

public static Event upFrom(@NonNull State state) {
    switch (state) {
        case INITIALIZED:
            return ON_CREATE;
        case CREATED:
            return ON_START;
        case STARTED:
            return ON_RESUME;
        default:
            return null;
    }
}

up 表示上升的意思，再结合第一篇中的状态与事件的图片

从 INITIALIZED 到 RESUMED 就是“上升”，从 RESUMED 到 DESTROYED 就是“下降” 能看出这个方法其实就是这张图片的具体实现，只不过只有“上升”这一部分。“下降”的部分就有 Event 中的downFrom() 实现。Event 中其他的方法 upTo(),downTo() 也是这个图的实现。

• statefulObserver.dispatchEvent(lifecycleOwner, event); 这一句向观察者发送生命周期事件，后面会讲到。
• 整个 while 循环的逻辑就是从 INITIALIZED 状态一步一步跳到 targetState 这个状态，每一步都调用观察者对应的回调方法，更新观察者的状态。

---

if (!isReentrance) { 
    // we do sync only on the top level. 
    sync(); 
}

• sync() ，看这方法名，很显然是同步的意思，具体就是将观察者队列的状态同步成 Activity 的一样的状态。只有在没有“重入”的时候调用。一般情况下，上面的 while 循环中statefulObserver.dispatchEvent(lifecycleOwner, event)已经完成了同步工作，这里调用 sync() 也不过是做一些检查

---

到这里，添加观察者的逻辑已经完成。

Activity 发送生命周期事件

寻找起点

下面是我寻找 Activity 发送生命周期事件的起点的思路，没有贴上代码，可以直接跳过，后面会直接下结论，感兴趣的读者可以一边看源码一边跟着这个思路走验证一下。

• 要看Activity是怎么发送生命周期事件的，先来看看 LifecycleRegistry 是怎么接收生命周期事件的，因为这个是“必经之路”。在 LifecycleRegistry 中找到给 mState 赋值的代码，发现只有 LifecycleRegistry 的构造方法和 moveToState() ，构造方法显然不用考虑，那么这个“必经之路”就确实是 moveToState() 了。
• 再来看看调用 moveToState() 的地方，发现只有两个地方，handleLifecycleEvent() 和 setCurrentState() 。
• 先看调用 setCurrentState() 的地方，一直追溯到其他类，有 ComponentActivity 的 onSaveInstanceState(), FragmentActivity 的 init() 和 onStop() ，可以看到这些方法是直接让 LifecycleRegistry 改变状态，没有“事件”的概念，也没有全部的生命周期，所以排除 setCurrentState() 。
• 再来看看 handleLifecycleEvent() ,这个方法的名字就是处理生命周期事件的意思，我们来看看调用它的其他类，有 Fragment,FragmentActivity,ReportFragment。我们要研究的是 Activity ，所以 Fragment 就不用考虑了。
• 先看 FragmentActivity ，它是 AppCompatActivity 的父类，可以看到它调用 handleLifecycleEvent() 的地方都是生命周期方法，而且全部生命周期事件的齐全了，看上去就是我们要找的 Activity 发送生命周期事件的地方，实则不然，FragmentActivity 内部的 LifecycleRegistry 实例并没有用 public 修饰，那我们平常写的 MainActivity 这类的就不能访问这个实例，同时 FragmentActivity 没有重写 getLifecycle() 这个方法，所以这里也不是我们要找的地方。
• 再来看 ReportFragment ，它调用 handleLifecycleEvent() 的地方只有 dispatch(Activity activity, @NonNull Lifecycle.Event event), 再一直追溯到就只剩2个地方了，ReportFragment本身的生命周期方法 和 内部类 LifecycleCallbacks 。到这里就比较难再往上追溯了，但也并不是前功尽弃了，至少我们知道 Activity 分发生命周期事件很有可能与 ReportFragment 有关系。
• 前面都是逆向分析的过程，现在我们来正向分析一下代码。我们在 MainActivity 中调用 getLifecycle() 获得一个 LifecycleRegistry 实例，实际上是调用 ComponentActivity 的 getLifecycle() 。之前我们也说过这个类实现了 LifecycleOwner 这个接口，按说最简单的分发生命周期事件的实现就是在 onCreate(),onStart()等这些生命周期方法中直接调用 LifecycleRegistry 的 handleLifecycleEvent() 就好了。但是 ComponentActivity 除了重写 onCreate() 外，其他生命周期方法都没重写，显然不是我们想的那样。那它是怎么实现的呢？前面说到这可能跟 ReportFragment 有关系，那我们就找找 ComponentActivity 中有没有 ReportFragment 的身影。这一找，还真有，而且只有一个地方，那就是 onCreate() 里的 ReportFragment.injectIfNeededIn(this)

到这里，Activity 发送生命周期事件的起点就找到了：ComponentActivity 的 onCreate() 中调用的 ReportFragment.injectIfNeededIn(this) 。现在我们开始正向分析吧。

ReportFragment.injectIfNeedIn()

public static void injectIfNeededIn(Activity activity) {
    if (Build.VERSION.SDK_INT >= 29) {
        // On API 29+, we can register for the correct Lifecycle callbacks directly
        LifecycleCallbacks.registerIn(activity);
    }
    // Prior to API 29 and to maintain compatibility with older versions of
    // ProcessLifecycleOwner (which may not be updated when lifecycle-runtime is updated and
    // need to support activities that don't extend from FragmentActivity from support lib),
    // use a framework fragment to get the correct timing of Lifecycle events
    if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
        manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
        // Hopefully, we are the first to make a transaction.
        manager.executePendingTransactions();
    }
}

可以看到这个方法跟运行设备的系统版本号有关系，分为>=29和<29两种情况。下面分别对这两种情况进行分析

SDK>=29

@RequiresApi(29)
static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks {

    static void registerIn(Activity activity) {
        activity.registerActivityLifecycleCallbacks(new LifecycleCallbacks());
    }

   ...
}

接着看 Activity 的 registerActivityLifecycleCallbacks() :

private final ArrayList<Application.ActivityLifecycleCallbacks> mActivityLifecycleCallbacks =
            new ArrayList<Application.ActivityLifecycleCallbacks>();

public void registerActivityLifecycleCallbacks(
        @NonNull Application.ActivityLifecycleCallbacks callback) {
    synchronized (mActivityLifecycleCallbacks) {
        mActivityLifecycleCallbacks.add(callback);
    }
}

可以看到这个方法就是把一个回调（LifecycleCallbacks）添加到了一个集合中。那我就去找这个集合在哪些地方被用到。

private Object[] collectActivityLifecycleCallbacks() {
    Object[] callbacks = null;
    synchronized (mActivityLifecycleCallbacks) {
        if (mActivityLifecycleCallbacks.size() > 0) {
            callbacks = mActivityLifecycleCallbacks.toArray();
        }
    }
    return callbacks;
}

这个方法把回调集合转换成对象数组再返回，看看调用这个方法的地方，调用这个方法的都是 Activity 里的 dispatchActivityXXXXXXXX()，这些方法都调用了回调方法，在这里就是 LifecycleCallbacks ：

@RequiresApi(29)
static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks {

    static void registerIn(Activity activity) {
        activity.registerActivityLifecycleCallbacks(new LifecycleCallbacks());
    }

    @Override
    public void onActivityCreated(@NonNull Activity activity,
            @Nullable Bundle bundle) {
    }

    @Override
    public void onActivityPostCreated(@NonNull Activity activity,
            @Nullable Bundle savedInstanceState) {
        dispatch(activity, Lifecycle.Event.ON_CREATE);
    }

    @Override
    public void onActivityStarted(@NonNull Activity activity) {
    }

    @Override
    public void onActivityPostStarted(@NonNull Activity activity) {
        dispatch(activity, Lifecycle.Event.ON_START);
    }

    @Override
    public void onActivityResumed(@NonNull Activity activity) {
    }

    @Override
    public void onActivityPostResumed(@NonNull Activity activity) {
        dispatch(activity, Lifecycle.Event.ON_RESUME);
    }

    @Override
    public void onActivityPrePaused(@NonNull Activity activity) {
        dispatch(activity, Lifecycle.Event.ON_PAUSE);
    }

    @Override
    public void onActivityPaused(@NonNull Activity activity) {
    }

    @Override
    public void onActivityPreStopped(@NonNull Activity activity) {
        dispatch(activity, Lifecycle.Event.ON_STOP);
    }

    @Override
    public void onActivityStopped(@NonNull Activity activity) {
    }

    @Override
    public void onActivitySaveInstanceState(@NonNull Activity activity,
            @NonNull Bundle bundle) {
    }

    @Override
    public void onActivityPreDestroyed(@NonNull Activity activity) {
        dispatch(activity, Lifecycle.Event.ON_DESTROY);
    }

    @Override
    public void onActivityDestroyed(@NonNull Activity activity) {
    }
}

在这些回调方法里，只有部分方法是有实现的，看这些方法的名字就知道这应该更生命周期事件发送的时机有关，我们看看它的父类 Application.ActivityLifecycleCallbacks ，里面的注释就说得很清楚，以 onCreate() 为例：

public interface ActivityLifecycleCallbacks {

    /**
     * Called as the first step of the Activity being created. This is always called before
     * {@link Activity#onCreate}.
     * 创建Activity的第一步，这个方法总是在onCreate()之前调用
     */
    default void onActivityPreCreated(@NonNull Activity activity,
            @Nullable Bundle savedInstanceState) {
    }

    /**
     * Called when the Activity calls {@link Activity#onCreate super.onCreate()}.
     * 调用onCreate()时调用这个方法
     */
    void onActivityCreated(@NonNull Activity activity, @Nullable Bundle savedInstanceState);

    /**
     * Called as the last step of the Activity being created. This is always called after
     * {@link Activity#onCreate}.
     * 创建Activity的最后一步，这个方法总是在onCreate()之后调用
     */
    default void onActivityPostCreated(@NonNull Activity activity,
            @Nullable Bundle savedInstanceState) {
    }
    ......
}    

所以总结一下：ON_CREATE,ON_START,ON_RESUME 这些事件都是在 onCreate(),onStart(),onResume()执行完之后才发送，而 ON_PAUSE,ON_STOP,ON_DESTROYED 这些事件则是在 onPause(),onStop(),onDestroyed() 执行完之后才发送。

回到 ReportFragment 的 dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event 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);
        }
    }
}

可以看到调用了 LifecycleRegistry 的 handleLifecycleEvent() ，生命周期事件发送到了 LifecycleRegistry。

SDK<29

• 当系统运行设备的版本号小于29时，会把没有 UI 的 Fragment（ReportFragment）添加到当前 Activity 的 FragmentManager 中，这样就把 Activity 的生命周期方法和这个 Fragment 实例的生命周期联系起来了，比如调用了 Activity 的 onCreate() 就会这个 Fragment 实例的 onCreate() ，从而实现对 Activity 的生命周期的感知。
• 我在阅读到这里的时候有一个问题：为什么 SDK>=29 的时候，注册了回调，又要用一个 Fragment 去感知？不会重复发送事件吗？
• 第一个问题我也不是很清楚，不过看源码在这个地方的注释，似乎是为了兼容老版本的 ProcessLifecycleOwner ，有了解的读者还望在评论中指点指点。
• 第二个问题：不会重复发送事件，因为后面具体分发事件前会对版本号进行判断。后面会讲到。

再来看看 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);
}

......

都是调用了 dispatch(Lifecycle.Event event)

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.injectIfNeededIn
        dispatch(getActivity(), event);
    }
}

先判断版本号是不是小于29，之后的再调用的 dispatch(getActivity(), event) 就更 SDK>=29 的实现是一样的了，也是调用了 LifecycleRegistry 的 handleLifecycleEvent()

到这里，Activity 把生命周期事件发送给 LifecycleRegistry 就分析完毕了

Lifecycle 分发事件

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一般为false,
    //mAddingObserverCounter在“重入”的时候大于0，后面会讲到
    if (mHandlingEvent || mAddingObserverCounter != 0) {
        mNewEventOccurred = true;
        // we will figure out what to do on upper level.
        return;
    }
    mHandlingEvent = true;
    sync(); //同步观察者的状态
    mHandlingEvent = false;
}

再来看 sync()

private void sync() {
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        Log.w(LOG_TAG, "LifecycleOwner is garbage collected, you shouldn't try dispatch "
                + "new events from it.");
        // Activity 已经被回收，直接返回        
        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;
}

private boolean isSynced() {
    if (mObserverMap.size() == 0) {
        return true;
    }
    State eldestObserverState = mObserverMap.eldest().getValue().mState;
    State newestObserverState = mObserverMap.newest().getValue().mState;
    //最老的观察者和最新的观察者的状态是否相同
    //若相同，这些观察者的状态与 Activity 的状态是否相同
    return eldestObserverState == newestObserverState && mState == newestObserverState;
}

单独拿出 while 循环里的这段：

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

要理解好这段代码需要了解 mObserverMap 的结构才行，下面我们来分析一下：

FastSafeIterableMap

/**
 * Custom list that keeps observers and can handle removals / additions during traversal.
 *
 * Invariant: at any moment of time for observer1 & observer2:
 * if addition_order(observer1) < addition_order(observer2), then
 * state(observer1) >= state(observer2),
 */
private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap =
        new FastSafeIterableMap<>();

注意这个成员变量的注释，非常重要！在 LifecycleRegistry 中维护一个“不变性”：任意时刻，旧的观察者的状态 >= 新的观察者的状态。注意这个性质 FastSafeIterableMap 本身是没有的，只是在 LifecycleRegistry 的中实现了这个性质。

不知道你是否会有这个问题：为什么一定要保存这个性质呢？我不确定作者的全部用意，但有一点可以确定的是：isSyned()就是靠这个性质才能只用第一个观察者和最后一个观察者来判断是否同步完成，而不需要考虑中间的观察者。

继续看 FastSafeIterableMap 这个类：

先看它的父类 SafeIterableMap 本来想贴代码的，但是篇幅有点长，这里直接下结论：SafeIterableMap 是一个双向链表的结构，它实现的是 Iterable 接口而不是 Map 接口，新元素添加到链表尾部，支持2种遍历顺序：从头到尾 和 从尾到头，还支持遍历时添加元素。

FaseSafeIterableMap 比它的父类多了一个 Fast ，来看看这个 Fast 是什么意思

public class FastSafeIterableMap<K, V> extends SafeIterableMap<K, V> {

    private HashMap<K, Entry<K, V>> mHashMap = new HashMap<>();

    @Override
    protected Entry<K, V> get(K k) {
        return mHashMap.get(k);
    }

    @Override
    public V putIfAbsent(@NonNull K key, @NonNull V v) {
        Entry<K, V> current = get(key);
        if (current != null) {
            return current.mValue;
        }
        //双向链表里放一份，HashMap里也放一份
        mHashMap.put(key, put(key, v));
        return null;
    }

    @Override
    public V remove(@NonNull K key) {
        V removed = super.remove(key);
        mHashMap.remove(key);
        return removed;
    }

    /**
     * Returns {@code true} if this map contains a mapping for the specified
     * key.
     */
    public boolean contains(K key) {
        //通过HashMap来判断有没有，如果用双向链表来判断，就需要遍历
        return mHashMap.containsKey(key);
    }

    /**
     * Return an entry added to prior to an entry associated with the given key.
     *
     * @param k the key
     */
    public Map.Entry<K, V> ceil(K k) {
        if (contains(k)) {
            return mHashMap.get(k).mPrevious;
        }
        return null;
    }
}

可以看到这个 Fast 体现在“取”上，多用一个 HashMap ,双链表保存的东西 HashMap 里也有，从而达到快速取出元素，快速判断有没有这个元素。

同步

知道了 mObserverMap 的性质和结构，这段代码就很好理解了：

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

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()))) {
            pushParentState(observer.mState);
            observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));
            popParentState();
        }
    }
}

private void backwardPass(LifecycleOwner lifecycleOwner) {
    Iterator<Entry<LifecycleObserver, ObserverWithState>> descendingIterator =
            mObserverMap.descendingIterator();
    while (descendingIterator.hasNext() && !mNewEventOccurred) {
        Entry<LifecycleObserver, ObserverWithState> entry = descendingIterator.next();
        ObserverWithState observer = entry.getValue();
        while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
                && mObserverMap.contains(entry.getKey()))) {
            Event event = downEvent(observer.mState);
            pushParentState(getStateAfter(event));
            observer.dispatchEvent(lifecycleOwner, event);
            popParentState();
        }
    }
}

• forwardPass() 和 backwardPass() 的逻辑差不多，外层循环是对观察者的遍历，内层循环是单个观察者状态的同步，发送事件（这个过程是一步一步的，不会出现从CREATED直接跳到RESUMED这种情况）。区别是forwardPass()是从老到新遍历，backwardPass()是从新到老遍历。
• 当 mState (Activity的状态) 比最老的观察者的状态小时，结合 mObserverMap 的性质，至少这个最老的观察者的状态需要同步，比它新的观察者可能状态和mState是一样的。那为什么要从最新的观察者开始遍历呢？还是为了维护 mObserverMap 的性质。举个例子：共有4个观察者，它们的状态都是2，也就是 2-2-2-2 这样的形式，此时 mState 为1，如果从最老的观察者开始同步，就会出现 1-2-2-2 这样的情况，破坏了 mObserverMap 的性质，而从最新的观察者开始遍历就不会，比如：2-2-1-1，维护了 mObserverMap 的性质。
• 当 mState (Activity的状态) 比最新的观察者的状态大时，道理同上。

Lifcycling

上面讲到调用 ObserverWithState 的 dispatchEvent() ，我们继续分析：

static class ObserverWithState {
    State mState;
    LifecycleEventObserver mLifecycleObserver;

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

    void dispatchEvent(LifecycleOwner owner, Event event) {
        State newState = event.getTargetState();
        mState = min(mState, newState);
        mLifecycleObserver.onStateChanged(owner, event);
        mState = newState;
    }
}

这里要先搞清楚 mLifecycleObserver 是怎么来的，在 ObserverWithState 的构造方法中，调用了 Lifecycling.lifecycleEventObserver(observer) 并把结果赋值给了 mLifecycleObserver 。

static LifecycleEventObserver lifecycleEventObserver(Object object) {
    //LifecycleEventObserver 和 FullLifecycleObserver 都直接继承了 LifecycleObserver
    boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
    boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
    //两个接口都实现了用FullLifecycleObserverAdapter封装
    if (isLifecycleEventObserver && isFullLifecycleObserver) {
        return new FullLifecycleObserverAdapter((FullLifecycleObserver) object,
                (LifecycleEventObserver) object);
    }
    //只实现了FullLifecycleObserver还是用FullLifecycleObserverAdapter封装
    if (isFullLifecycleObserver) {
        return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);
    }
    //只实现了LifecycleEventObserver就返回自己
    if (isLifecycleEventObserver) {
        return (LifecycleEventObserver) object;
    }

    //下面是两种接口都没实现的情况，一般是直接继承 LifecycleObserver 
    final Class<?> klass = object.getClass();
    int type = getObserverConstructorType(klass);
    // type 有两种，GENERATED_CALLBACK 表示使用了APT
    // REFLECTIVE_CALLBACK 表示使用反射
    if (type == GENERATED_CALLBACK) {
        List<Constructor<? extends GeneratedAdapter>> constructors =
                sClassToAdapters.get(klass);
        if (constructors.size() == 1) {
            GeneratedAdapter generatedAdapter = createGeneratedAdapter(
                    constructors.get(0), object);
            return 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);
}

接着看 getObserverConstructorType()

private static int getObserverConstructorType(Class<?> klass) {
    Integer callbackCache = sCallbackCache.get(klass);
    if (callbackCache != null) {
        //有缓存就返回
        return callbackCache;
    }
    //没缓存就解析，并保存到缓存中
    int type = resolveObserverCallbackType(klass);
    sCallbackCache.put(klass, type);
    return type;
}

//解析
private static int resolveObserverCallbackType(Class<?> klass) {
    // anonymous class bug:35073837
    // 匿名类
    if (klass.getCanonicalName() == null) {
        return REFLECTIVE_CALLBACK;
    }

    // 使用APT
    Constructor<? extends GeneratedAdapter> constructor = generatedConstructor(klass);
    if (constructor != null) {
        sClassToAdapters.put(klass, Collections
                .<Constructor<? extends GeneratedAdapter>>singletonList(constructor));
        return GENERATED_CALLBACK;
    }

    //使用反射
    @SuppressWarnings("deprecation")
    boolean hasLifecycleMethods = ClassesInfoCache.sInstance.hasLifecycleMethods(klass);
    if (hasLifecycleMethods) {
        return REFLECTIVE_CALLBACK;
    }

    //上面的代码都没找到结果，就在父类中找
    Class<?> superclass = klass.getSuperclass();
    List<Constructor<? extends GeneratedAdapter>> adapterConstructors = null;
    if (isLifecycleParent(superclass)) {
        if (getObserverConstructorType(superclass) == REFLECTIVE_CALLBACK) {
            return REFLECTIVE_CALLBACK;
        }
        adapterConstructors = new ArrayList<>(sClassToAdapters.get(superclass));
    }

    //在实现的接口中找
    for (Class<?> intrface : klass.getInterfaces()) {
        if (!isLifecycleParent(intrface)) {
            continue;
        }
        if (getObserverConstructorType(intrface) == REFLECTIVE_CALLBACK) {
            return REFLECTIVE_CALLBACK;
        }
        if (adapterConstructors == null) {
            adapterConstructors = new ArrayList<>();
        }
        adapterConstructors.addAll(sClassToAdapters.get(intrface));
    }
    if (adapterConstructors != null) {
        sClassToAdapters.put(klass, adapterConstructors);
        return GENERATED_CALLBACK;
    }

    return REFLECTIVE_CALLBACK;
}

接着看解析是否用反射的方法，代码主要在 ClassInfoCache 中：

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

    //下面就是根据参数个数和类型确定 callType 了
    Method[] methods = declaredMethods != null ? declaredMethods : getDeclaredMethods(klass);
    boolean hasLifecycleMethods = false;
    for (Method method : methods) {
        OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
        if (annotation == null) {
            continue;
        }
        hasLifecycleMethods = true;
        Class<?>[] params = method.getParameterTypes();
        //先默认没参数
        int callType = CALL_TYPE_NO_ARG;
        if (params.length > 0) {
            //参数个数>0 ，先默认只有一个
            callType = CALL_TYPE_PROVIDER;
            if (!params[0].isAssignableFrom(LifecycleOwner.class)) {
            //第一个参数的类型必须是 LifecyclerOwner 
                throw new IllegalArgumentException(
                        "invalid parameter type. Must be one and instanceof LifecycleOwner");
            }
        }
        //event是注解里参数的值
        Lifecycle.Event event = annotation.value();

        if (params.length > 1) {
            //参数个数>1 ，先默认只有2个
            callType = CALL_TYPE_PROVIDER_WITH_EVENT;
            if (!params[1].isAssignableFrom(Lifecycle.Event.class)) {
                //第二个参数类型必须是Event
                throw new IllegalArgumentException(
                        "invalid parameter type. second arg must be an event");
            }
            if (event != Lifecycle.Event.ON_ANY) {
                //两个参数，接收事件的类型只能是 ON_ANY。
                throw new IllegalArgumentException(
                        "Second arg is supported only for ON_ANY value");
            }
        }
        if (params.length > 2) {
            //最多只能有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;
}

回到 ObserverWithState ,Lifcycling 把各种写法的 LifecycleObserver 统一为 LifecycleEventObserver ，这样就能统一接口了。FullLifecycleObserverAdapter CompositeGeneratedAdaptersObserver，ReflectiveGenericLifecycleObserver 各自重写了 onStateChange()

这里只讲一下 ReflectiveGenericLifecycleObserver ，其他的读者自己去探索吧。

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

    @SuppressWarnings("deprecation")
    ReflectiveGenericLifecycleObserver(Object wrapped) {
        mWrapped = wrapped;
        // 之前解析的时候就把有@OnLifecycleEvent注解的合规的方法存放在ClassesInfoCache 中了。
        mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
    }

    @Override
    public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Event event) {
        mInfo.invokeCallbacks(source, event, mWrapped);
    }
}

final class ClassesInfoCache {
    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);
            }
        }
    }
    
    static final 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
            try {
                //根据callType进行反射调用
                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);
            }
        }

        ......
    }
    
}

到这里，流程分析就差不多了，接下来是一些细节的分析

其他细节

并发？

LifecycleRegistry 的 markState(),setCurrentState(),handleLifecycleEvent() ,addObserver() 等方法第一句就是enforceMainThreadIfNeeded()

private void enforceMainThreadIfNeeded(String methodName) {
    if (mEnforceMainThread) {
        if (!ArchTaskExecutor.getInstance().isMainThread()) {
            throw new IllegalStateException("Method " + methodName + " must be called on the "
                    + "main thread");
        }
    }
}

可以看到，如果 mEnforceMainThread 为 true 且当前线程不是主线程，就会抛出异常。mEnforceMainThread 是在构造函数中设置的，而 ComponentActivity 和 Fragment 中的 LifecycleRegistry 的 mEnforceMainThread 就是 true，所以我认为一般情况下不存在并发的问题，mHandlingEvent 为 false。

“重入”

在 addObserver() 中，调用了 calculateTargetState() 获取新添加的观察者应该同步到的状态，我在前面说到它的返回值一般情况下就是 mState ，当具体看它的实现，实际上跟其他因素有关：

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

siblingState 是新观察者的前一个观察者的状态

parentState 是 mParentStates 中保存的最后一个状态

mState 是 Activity 当前的状态

这3个状态的最小值才是这个方法的返回值，这里就有个问题，为什么还要和 siblingState, parentState 比较,而不是直接返回 mState ？

先来看看 mParentStates ：

// we have to keep it for cases:
// void onStart() {
//     mRegistry.removeObserver(this);
//     mRegistry.add(newObserver);
// }
// newObserver should be brought only to CREATED state during the execution of
// this onStart method. our invariant with mObserverMap doesn't help, because parent observer
// is no longer in the map.
private ArrayList<State> mParentStates = new ArrayList<>();

可以看到 mParentStates 就是一个 ArrayList ，作者的这段注释很重要，当不好理解，后面再讲。先看看它是怎么维护的

private void popParentState() {
    mParentStates.remove(mParentStates.size() - 1);
}

private void pushParentState(State state) {
    mParentStates.add(state);
}

用着两个方法来维护，让 mParentStates 像一个栈一样。再看看调用它们的地方：

public void addObserver(@NonNull LifecycleObserver observer) {
    enforceMainThreadIfNeeded("addObserver");
    ...
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        pushParentState(statefulObserver.mState); //这里
        final Event event = Event.upFrom(statefulObserver.mState);
        if (event == null) {
            throw new IllegalStateException("no event up from " + statefulObserver.mState);
        }
        statefulObserver.dispatchEvent(lifecycleOwner, event);
        popParentState(); //这里
        // mState / subling may have been changed recalculate
        targetState = calculateTargetState(observer);
    }
    ...
}

private void forwardPass(LifecycleOwner lifecycleOwner) {
    Iterator<Map.Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
            mObserverMap.iteratorWithAdditions();
    while (ascendingIterator.hasNext() && !mNewEventOccurred) {
        Map.Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
        ObserverWithState observer = entry.getValue();
        while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
                && mObserverMap.contains(entry.getKey()))) {
            pushParentState(observer.mState); //这里
            final Event event = Event.upFrom(observer.mState);
            if (event == null) {
                throw new IllegalStateException("no event up from " + observer.mState);
            }
            observer.dispatchEvent(lifecycleOwner, event);
            popParentState(); //这里
        }
    }
}

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);
            popParentState(); //这里
        }
    }
}

可以看到这两个方法都是成对出现的，而且都是先push,然后同步观察者（发送事件），再pop。

回到 calculateTargetState() 方法

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

一般情况下，mParentStates 就是空的栈，新添加的观察者的前一个观察者可能存在也可能不存在，如果存在，他的状态也应该跟 mState 一样（之前就同步过了），所以这个方法的返回值一般都是 mState 。

如果不比较 siblingState, parentState ，会出现什么问题？

举个例子, 重写 MainActivity 的onResume():

@Override
protected void onResume() {
    super.onResume();
    LifecycleObserver observerB = new LifecycleEventObserver() {
        @Override
        public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {

        }
    };
    LifecycleObserver observerA = new DefaultLifecycleObserver() {
        @Override
        public void onStart(@NonNull LifecycleOwner owner) {
            owner.getLifecycle().addObserver(observerB);
        }
    };
    getLifecycle().addObserver(observerA);
}

定义了两个观察者 observerB 和 observerA。 在 onResumed() 中，此时的 mState 就是 RESUMED 。先添加 observerA ，observerA 接收黏性事件 ON_START，调用 onStart() 时，添加了 observerB , 这时就出现“重入”了。如果只有 mStates ，那calculateTargetState()的返回值就是 mState。这就出现问题了，observerA 是先添加的，它现在的状态的 STARTED ，而 observerB 的状态是 mState,也就是 RESUMED ,出现新观察者的状态比旧观察者的状态大的情况，这破坏了 mObserverMap 的性质。

你可能会问：那只需要一个 siblingState（前一个观察者的状态） 不就好了吗。取它和 mState 的较小值，就能维护 mObserverMap 的性质。但是也有不存在前一个观察者的时候，什么时候会出现这种状况呢？看看 mObserverMap 的注释：

// we have to keep it for cases:
// void onStart() {
//     mRegistry.removeObserver(this);
//     mRegistry.add(newObserver);
// }
// newObserver should be brought only to CREATED state during the execution of
// this onStart method. our invariant with mObserverMap doesn't help, because parent observer
// is no longer in the map.

注释里的例子不好理解，还是上面那个例子，只不过多了一句

@Override
protected void onResume() {
    super.onResume();
    LifecycleObserver observerB = new LifecycleEventObserver() {
        @Override
        public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {

        }
    };
    LifecycleObserver observerA = new DefaultLifecycleObserver() {
        @Override
        public void onStart(@NonNull LifecycleOwner owner) {
            owner.getLifecycle().removeObserver(this);
            owner.getLifecycle().addObserver(observerB);
        }
    };
    getLifecycle().addObserver(observerA);
}

在 observerA 的回调方法里，先把自己移除了，再添加 observerB 。如果只有 sbilingState 和 mStete 比较，在同步 observerB 时，因为前一个观察者已经移除了，siblingState 为 null ，只身下 mState ，返回结果就是 mState ，而 mState 为 RESUMED。这时的情况就是：observerA的状态是 STARTED ，observerB 的状态是 RESUMED ，这也算是一种逻辑错误吧（虽然observerA已经被移除了）。

到这里所有分析就结束了，感谢观看！

感谢与参考：

【JetPack系列】——Lifecycle源码分析

从源码看 Jetpack（1）- Lifecycle 源码详解

“终于懂了“系列：Jetpack AAC完整解析（一）Lifecycle 完全掌握！