硬核讲解 Jetpack 之 LifeCycle 源码篇

前一篇 硬核讲解 Jetpack 之 LifeCycle 使用篇 主要介绍了 LifeCycle 存在的意义，基本和进阶的使用方法。今天话不多说，直接开始撸源码。

本文基于我手里的 android_9.0.0_r45 源码，所有相关源码包括注释都上传到了我的 Github ，可以直接 clone 下来对照文章查看。

LifeCycle 三剑客

在正式阅读源码之前，很有必要先介绍几个名词，LifecycleOwner ，LifecycleObserver，Lifecycle 。

LifecycleOwner 是一个接口 , 接口通常用来声明具备某种能力。LifecycleOwner 的能力就是具有生命周期。典型的生命周期组件有 Activity 和 Fragment 。当然，我们也可以自定义生命周期组件。LifecycleOwner 提供了 getLifecycle() 方法来获取其 Lifecycle 对象。

public interface LifecycleOwner {

    @NonNull
    Lifecycle getLifecycle();
}

LifecycleObserver 是生命周期观察者，它是一个空接口。它没有任何方法，依赖 OnLifecycleEvent 注解来接收生命周期回调。

public interface LifecycleObserver {

}

生命周期组件 和 生命周期观察者 都有了，Lifecycle 就是它们之间的桥梁。

Lifecycle 是具体的生命周期对象，每个 LifecycleOwner 都会持有 Lifecycle 。通过 Lifecycle 我们可以获取当前生命周期状态，添加/删除 生命周期观察者等等。

Lifecycle 内部定义了两个枚举类，Event 和 State 。Event 表示生命周期事件，与 LifecycleOwner 的生命周期事件是相对应的。

public enum Event {
    /**
     * Constant for onCreate event of the {@link LifecycleOwner}.
     */
    ON_CREATE,
    /**
     * Constant for onStart event of the {@link LifecycleOwner}.
     */
    ON_START,
    /**
     * Constant for onResume event of the {@link LifecycleOwner}.
     */
    ON_RESUME,
    /**
     * Constant for onPause event of the {@link LifecycleOwner}.
     */
    ON_PAUSE,
    /**
     * Constant for onStop event of the {@link LifecycleOwner}.
     */
    ON_STOP,
    /**
     * Constant for onDestroy event of the {@link LifecycleOwner}.
     */
    ON_DESTROY,
    /**
     * An {@link Event Event} constant that can be used to match all events.
     */
    ON_ANY
}

ON_ANY 比较特殊，它表示任意生命周期事件。为什么要设计 ON_ANY 呢？其实我也不知道，暂时还没发现它的用处。

另一个枚举类 State 表示生命周期状态。

public enum State {
        /**
         * 在此之后，Lifecycle 不会再派发生命周期事件。
         * 此状态在 Activity.onDestroy() 之前
         */
        DESTROYED,

        /**
         * 在 Activity 已经实例化但未 onCreate() 之前
         */
        INITIALIZED,

        /**
         * 在 Activity 的 onCreate() 之后到 onStop() 之前
         */
        CREATED,

        /**
         * 在 Activity 的 onStart() 之后到 onPause() 之前
         */
        STARTED,

        /**
         * 在 Activity 的 onResume() 之后
         */
        RESUMED;

        public boolean isAtLeast(@NonNull State state) {
            return compareTo(state) >= 0;
        }
    }

State 可能相对比较难以理解，特别是其中枚举值的顺序。这里先不详细解读，但是务必记住这几个枚举值的顺序，DESTROYED —— INITIALIZED —— CREATED —— STARTED ——RESUMED，这个对于后面源码的理解特别重要。

简单梳理一下三剑客的关系。生命周期组件 LifecycleOwner 在进入特定的生命周期后，发送特定的生命周期事件 Event ，通知 Lifcycle 进入特定的 State ，进而回调生命周期观察者 LifeCycleObserver 的指定方法。

从 addObserver() 下手

面对源码无从下手的话，我们就从 Lifecycle 的基本使用入手。

lifecycle.addObserver(LocationUtil( ))

lifecycle 其实就是 getLifecycle()方法，只是在 Kotlin中被 简写了。getLifecycle() 是接口 LifecycleOwner 的方法。而 AppCompatActivity 并没有直接实现 LifecycleOwner，它的父类 FragmentActivity 也没有，在它的爷爷类 ComponentActivity 中才找到 LifecycleOwner 的踪影，看一下接口的实现。

@Override
public Lifecycle getLifecycle() {
    return mLifecycleRegistry;
}

mLifecycleRegistry 是 LifecycleRegistry 对象，LifecycleRegistry 是 LifeCycle 的实现类。那么这里的 LifecycleRegistry 就是我们的生命周期对象了。来看一下它的 addObserver() 方法。

> LifecycleRegistry.java

......

// 保存 LifecycleObserver 及其对应的 State
private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap =
        new FastSafeIterableMap<>();

 // 当前生命周期状态
private State mState;

/**
 * 添加生命周期观察者 LifecycleObserver
 * 另外要注意生命周期事件的 “倒灌”，如果在 onResume() 中调用 addObserver()，
 * 那么，观察者依然可以接收到 onCreate 和 onStart 事件。
 * 这么做的目的是保证 mObserverMap 中的 LifecycleObserver 始终保持在同一状态
 */
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
    // ObserverWithState 是一个静态内部类
    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 || mHandlinengEvent;
    State targetState = calculateTargetState(observer);
    mAddingObserverCounter++;

    // 如果观察者的初始状态小于 targetState ，则同步到 targetState
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        pushParentState(statefulObserver.mState);
        statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
        popParentState();
        // mState / subling may have been changed recalculate
        targetState = calculateTargetState(observer);
    }

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

这里面要注意两个问题。第一个问题是生命周期的 “倒灌问题” ，这是我从 LiveData 那里借来的一次词。具体是什么问题呢？来举一个例子，即使你在 onResume( ) 中调用 addObserver( ) 方法来添加观察者，观察者依然可以依次接收到 onCreate 和 onStart 事件 ，最终同步到 targetState 。这个 targetState 是通过 calculateTargetState(observer) 方法计算出来的。

/**
 * 计算出的 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);
  }

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

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

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

谁来分发生命周期事件？

观察者已经添加完成了，那么如何将生命周期的变化通知观察者呢？

再回到 ComponentActivity ，你会发现里面并没有重写所有的生命周期函数。唯一让人可疑的就只有 onCreate() 当中的一行代码。

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    mSavedStateRegistryController.performRestore(savedInstanceState);
    ReportFragment.injectIfNeededIn(this);
    if (mContentLayoutId != 0) {
        setContentView(mContentLayoutId);
    }
}

这里的 ReportFragment 就是问题的答案。追进 injectIfNeededIn() 方法。

public static void injectIfNeededIn(Activity activity) {
    // 使用 android.app.FragmentManager 保持兼容
    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();
    }
}

这里向 Activity 注入了一个没有页面的 Fragment 。这就让我想到了一些动态权限库也是这个套路，通过注入 Fragment 来代理权限请求。不出意外，ReportFragment 才是真正分发生命周期的地方。

@Override
 public void onActivityCreated(Bundle savedInstanceState) {
     super.onActivityCreated(savedInstanceState);
     dispatchCreate(mProcessListener);
     dispatch(Lifecycle.Event.ON_CREATE);
 }

 @Override
 public void onStart() {
     super.onStart();
     dispatchStart(mProcessListener);
     dispatch(Lifecycle.Event.ON_START);
 }

 @Override
 public void onResume() {
     super.onResume();
     dispatchResume(mProcessListener);
     dispatch(Lifecycle.Event.ON_RESUME);
 }

 @Override
 public void onPause() {
     super.onPause();
     dispatch(Lifecycle.Event.ON_PAUSE);
 }

 @Override
 public void onStop() {
     super.onStop();
     dispatch(Lifecycle.Event.ON_STOP);
 }

 @Override
 public void onDestroy() {
     super.onDestroy();
     dispatch(Lifecycle.Event.ON_DESTROY);
     // just want to be sure that we won't leak reference to an activity
     mProcessListener = null;
 }

mProcessListener 是处理应用进程生命周期的，暂时不去管它。

先看一下 dispatch() 方法。

private void dispatch(Lifecycle.Event event) {
    Activity activity = getActivity();
    if (activity instanceof LifecycleRegistryOwner) {
        ((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
        return;
    }

    if (activity instanceof LifecycleOwner) {
        Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
        if (lifecycle instanceof LifecycleRegistry) {
            // 调用 LifecycleRegistry.handleLifecycleEvent() 方法
            ((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
        }
    }
}

在ReportFragment 的各个生命周期函数中通过 dispatch() 方法来分发生命周期事件， 然后调用 LifecycleRegistry 的 handleLifecycleEvent() 方法来处理 。为了方便后面的代码理解，这里假定 现在要经历从 onStart() 同步到 onResume() 的过程，即handleLifecycleEvent() 方法中的参数是 ON_RESUME 。

// 设置当前状态并通知观察者
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
    State next = getStateAfter(event);
    moveToState(next);
}

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

static State getStateAfter(Event event) {
    switch (event) {
        case ON_CREATE:
        case ON_STOP:
            return CREATED;
        case ON_START:
        case ON_PAUSE:
            return STARTED;
        case ON_RESUME:
            return RESUMED;
        case ON_DESTROY:
            return DESTROYED;
        case ON_ANY:
            break;
    }
    throw new IllegalArgumentException("Unexpected event value " + event);
}

参数是 ON_RESUME ，所以需要同步到的状态是 RESUMED 。接下来看看 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;
}

首先将要同步到的生命周期状态赋给当前生命周期状态 mState ，此时 mState 的值就是 RESUMED 。然后调用 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.");
        return;
    }
    while (!isSynced()) {
        mNewEventOccurred = false;
        // mState 是当前状态，如果 mState 小于 mObserverMap 中的状态值，调用 backwardPass()
        if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
            backwardPass(lifecycleOwner);
        }
        Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
        // 如果 mState 大于 mObserverMap 中的状态值，调用 forwardPass()
        if (!mNewEventOccurred && newest != null
                && mState.compareTo(newest.getValue().mState) > 0) {
            forwardPass(lifecycleOwner);
        }
    }
    mNewEventOccurred = false;
}

这里会比较 mState 和 mObserverMap 中观察者的 State 值，判断是需要向前还是向后同步状态。现在 mState 的值是 RESUMED , 而观察者还停留在上一状态 STARTED ，所以观察者的状态都得往前挪一步，这里调用的是 forwardPass() 方法。

private void forwardPass(LifecycleOwner lifecycleOwner) {
    Iterator<Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
            mObserverMap.iteratorWithAdditions();
    while (ascendingIterator.hasNext() && !mNewEventOccurred) {
        Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
        ObserverWithState observer = entry.getValue();
        // 向上传递事件，直到 observer 的状态值等于当前状态值
        while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
                && mObserverMap.contains(entry.getKey()))) {
            pushParentState(observer.mState);
            // 分发生命周期事件
            observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));
            popParentState();
        }
    }
}

forwardPass() 会同步 mObserverMap 中的所有观察者到指定生命周期状态，如果跨度比较大，会依次分发中间状态。分发生命周期事件最终依赖 ObserverWithState 的 dispatchEvent() 方法。

这里先暂停存档一下，不继续往下追源码。上面假定的场景是 ON_START 到 ON_RESUME 的过程。现在假定另一个场景，我直接按下 Home 键返回桌面，当前 Activity 的生命周期从onResumed 到 onPaused ，流程如下。

1. ReportFragment 调用 dispatch(Lifecycle.Event.ON_PAUSE) ，分发 ON_PAUSE 事

2. 调用 LifecycleRegistry.handleLifecycleEvent() 方法，参数是 ON_PAUSE

3. getStateAfter() 得到要同步到的状态是 STARTED ，并赋给 mState，接着调用 moveToState()

4. moveToState(Lifecycle.State.STARTED) 中调用 sync() 方法同步

5. sync() 方法中，mState 的值是 STARTED ，而 mObserverMap 中观察者的状态都是 RESUMED 。所以观察者们都需要往后挪一步，这调用的就是 backwardPass() 方法。

backwardPass() 方法其实和 forwardPass() 差不多。

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();
        // 向下传递事件，直到 observer 的状态值等于当前状态值
        while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
                && mObserverMap.contains(entry.getKey()))) {
            Event event = downEvent(observer.mState);
            pushParentState(getStateAfter(event));
            // 分发生命周期事件
            observer.dispatchEvent(lifecycleOwner, event);
            popParentState();
        }
    }
}

二者唯一的区别就是获取要分发的事件，一个是 upEvent() ，一个是 downEvent() 。

upEvent() 是获取 state 升级所需要经历的事件，downEvent() 是获取 state 降级所需要经历的事件。

private static Event upEvent(State state) {
    switch (state) {
        case INITIALIZED:
        case DESTROYED:
            return ON_CREATE;
        case CREATED:
            return ON_START;
        case STARTED:
            return ON_RESUME;
        case RESUMED:
            throw new IllegalArgumentException();
    }
    throw new IllegalArgumentException("Unexpected state value " + state);
}

private static Event downEvent(State state) {
    switch (state) {
        case INITIALIZED:
            throw new IllegalArgumentException();
        case CREATED:
            return ON_DESTROY;
        case STARTED:
            return ON_STOP;
        case RESUMED:
            return ON_PAUSE;
        case DESTROYED:
            throw new IllegalArgumentException();
    }
    throw new IllegalArgumentException("Unexpected state value " + state);
}

从 STARTED 到 RESUMED 需要升级，upEvent(STARTED) 的返回值是 ON_RESUME 。
从 RESUMED 到 STARTED 需要降级，downEvent(RESUMED)的返回值是 ON_PAUSE 。

看到这不知道你有没有一点懵，State 和 Event 的关系我也摸索了很长一段时间才理清楚。首先还记得 State 的枚举值顺序吗？

DESTROYED —— INITIALIZED —— CREATED —— STARTED —— RESUMED

DESTROYED 最小，RESUMED 最大 。onResume 进入到 onPause 阶段最后分发的生命周期事件的确是 ON_PAUSE ，但是将观察者的状态置为了 STARTED 。这是为什么呢？

关于 State 和 Event 的关系，官网给出了一张图，如下所所示：

但我不得不说，画的的确有点抽象，其实应该换个画法。再来一张我在 这里 看到的一张图：

状态之间的事件，事件之后的状态，状态之间的大小 ，是不是有种一目了然的感觉？理解这幅图很重要，可以说搞不清 Event 和 State 的关系，就看不懂 Lifecycle 的源码。

谁来回调你的注解方法 ？

再读取刚才的暂停存档，同步 Observer 生命周期的 sync() 方法最终会调用 ObserverWithState 的 dispatchEvent() 方法。

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);
        // ReflectiveGenericLifecycleObserver.onStateChanged()
        mLifecycleObserver.onStateChanged(owner, event);
        mState = newState;
    }
}

mLifecycleObserver 通过 Lifecycling.getCallback() 方法赋值。

@NonNull
static GenericLifecycleObserver getCallback(Object object) {
    if (object instanceof FullLifecycleObserver) {
        return new FullLifecycleObserverAdapter((FullLifecycleObserver) object);
    }

    if (object instanceof GenericLifecycleObserver) {
        return (GenericLifecycleObserver) object;
    }

    final Class<?> klass = object.getClass();
    int type = getObserverConstructorType(klass);
    // 获取 type
    // GENERATED_CALLBACK 表示注解生成的代码
    // 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);
}

如果使用的是 DefaultLifecycleObserver ，而 DefaultLifecycleObserver 又是继承 FullLifecycleObserver 的，所以这里会返回 FullLifecycleObserverAdapter 。

如果只是普通的 LifecycleObserver ，那么就需要通过 getObserverConstructorType() 方法判断使用的是注解还是反射。

private static int getObserverConstructorType(Class<?> klass) {
    if (sCallbackCache.containsKey(klass)) {
        return sCallbackCache.get(klass);
    }
    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;
    }

    // 寻找注解生成的 GeneratedAdapter 类
    Constructor<? extends GeneratedAdapter> constructor = generatedConstructor(klass);
    if (constructor != null) {
        sClassToAdapters.put(klass, Collections
                .<Constructor<? extends GeneratedAdapter>>singletonList(constructor));
        return GENERATED_CALLBACK;
    }

    // 寻找被 OnLifecycleEvent 注解的方法
    boolean hasLifecycleMethods = ClassesInfoCache.sInstance.hasLifecycleMethods(klass);
    if (hasLifecycleMethods) {
        return REFLECTIVE_CALLBACK;
    }

    // 没有找到注解生成的 GeneratedAdapter 类，也没有找到 OnLifecycleEvent 注解，
    // 则向上寻找父类
    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;
}

注意其中的 hasLifecycleMethods() 方法。

boolean hasLifecycleMethods(Class klass) {
    if (mHasLifecycleMethods.containsKey(klass)) {
        return mHasLifecycleMethods.get(klass);
    }

    Method[] methods = getDeclaredMethods(klass);
    for (Method method : methods) {
        OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
        if (annotation != null) {
            createInfo(klass, methods);
            return true;
        }
    }
    mHasLifecycleMethods.put(klass, false);
    return false;
}

这里会去寻找 OnLifecycleEvent 注解。所以我们通过 OnLifecycleEvent 注解实现的 MyObserver 的类型是 REFLECTIVE_CALLBACK ，表示使用反射调用。注意另一个类型 GENERATED_CALLBACK 表示使用注解生成的代码，而不是反射。

所以，所以，**Lifecycle 可以选择使用 apt 编译期生成代码来避免使用运行时反射，以优化性能？**好像还真是这么一回事。这就让我想到了 EventBus 的索引加速 默认也是关闭的。看吧，这就是阅读源码的好处，总能发现自己的知识盲区。添加下列依赖，来提速 LifeCycle 吧 ！

kapt "androidx.lifecycle:lifecycle-compiler:$lifecycle_version"

为了方便解析，还是回到反射调用上来。

我们自己定义的在普通的观察者调用的是 ReflectiveGenericLifecycleObserver.onStateChanged() 。

class ReflectiveGenericLifecycleObserver implements GenericLifecycleObserver {
    private final Object mWrapped; // Observer 对象
    private final CallbackInfo mInfo; // 反射获取注解信息

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

    @Override
    public void onStateChanged(LifecycleOwner source, Event event) {
        // 调用 ClassesInfoCache.CallbackInfo.invokeCallbacks()
        mInfo.invokeCallbacks(source, event, mWrapped);
    }
}

再追进 ClassesInfoCache.CallbackInfo.invokeCallbacks() 方法。

void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) {
    // 不仅分发了当前生命周期事件，还分发了 ON_ANY
    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);
    }
}

其实就很简单了，反射调用 OnLifecycleEvent 注解标记的生命周期回调方法。

Wait For More

本想再接着分析进程生命周期 ProcessLifecycleOwner 和 Lifecycle 的协程使用相关源码，可是文章篇幅有点过长了，就留到下一篇吧，敬请期待！

参考和推荐

下面几篇文章同样优秀，直接仔细研读，推荐给大家。

• Android架构之美-Lifecycle
• Jetpack和LifeCycle（三）
• Android-Lifecycle超能解析-生命周期的那些事儿