AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

硬核讲解 Jetpack 之 LifeCycle 源码篇

2022-05-11 185
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 硬核讲解 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 的关系，官网给出了一张图，如下所所示：

image.png

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

image.png

状态之间的事件，事件之后的状态，状态之间的大小 ，是不是有种一目了然的感觉？理解这幅图很重要，可以说搞不清 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 的协程使用相关源码，可是文章篇幅有点过长了，就留到下一篇吧，敬请期待！



文章标签：
索引
Kotlin
关键词：
jetpack源码
jetpack lifecycle
游客2c23dhwiokfua
目录
相关文章
程序员徐师兄
|
程序员 开发工具 Android开发
Android JetPack App Startup 使用及源码浅析（二）
Android JetPack App Startup 使用及源码浅析
程序员徐师兄
121 0
程序员徐师兄
|
开发工具 Android开发
Android JetPack App Startup 使用及源码浅析（一）
Android JetPack App Startup 使用及源码浅析
程序员徐师兄
118 0
林栩link
|
监控 Java 定位技术
Android Jetpack 应用指南（四） - Lifecycle
林栩link
365 0
Android Jetpack 应用指南（四） - Lifecycle
陈有余Tech
|
Java API Android开发
Jetpack 之 LifeCycle 组件原理解析
1. LifeCycle 是如何监听到 Activity/Fragment 生命周期变化的？ 2. LifeCycle 如何将生命周期变化的事件分发给观察者的？
陈有余Tech
136 0
Jetpack 之 LifeCycle 组件原理解析
陈有余Tech
|
Java API 开发工具
Jetpack 之 LifeCycle 组件使用详解
LifeCycle 是一个可以感知宿主生命周期变化的组件。常见的宿主包括 Activity/Fragment、Service 和 Application。LifeCycle 会持有宿主的生命周期状态的信息，当宿主生命周期发生变化时，会通知监听宿主的观察者。
陈有余Tech
130 0
Jetpack 之 LifeCycle 组件使用详解
_小马快跑_
|
安全 Android开发
Android Jetpack系列之Lifecycle
`Lifecycle`可以让某一个类变成`Activity`、`Fragment`的生命周期观察者类，监听其生命周期的变化并可以做出响应。`Lifecycle`使得代码更有条理性、精简、易于维护。
_小马快跑_
111 0
彭旭锐
|
安全 API 调度
Jetpack 系列（1）—— Lifecycle：生命周期感知型组件的基础
Jetpack 系列（1）—— Lifecycle：生命周期感知型组件的基础
彭旭锐
286 0
Jetpack 系列（1）—— Lifecycle：生命周期感知型组件的基础
编程的平行世界
|
缓存 前端开发 Java
2022 · 让我带你Jetpack架构组件从入门到精通 — Lifecycle
不是标题党！作者会尽力把文章写的更容易理解也更充满深度，本文也随作者的持续学习，持续更新，有问题欢迎在评论区提出~
编程的平行世界
304 0
全能杰哥
|
设计模式 缓存 算法
【Jetpack】学穿：Lifecycle → 生命周期 (原理篇)（下）
本质上是围绕着这两个设计模式进行的： 模板模式 → 定义算法骨架，对外开放扩展点，基于 继承 关系实现，子类重写父类抽象方法； 观察者模式 → 对象间定义一对多的依赖，当一个对象状态发生改变，依赖对象都会自动收到通知；
全能杰哥
262 0
全能杰哥
|
设计模式 算法 安全
【Jetpack】学穿：Lifecycle → 生命周期 (原理篇)（中）
本质上是围绕着这两个设计模式进行的： 模板模式 → 定义算法骨架，对外开放扩展点，基于 继承 关系实现，子类重写父类抽象方法； 观察者模式 → 对象间定义一对多的依赖，当一个对象状态发生改变，依赖对象都会自动收到通知；
全能杰哥
174 0

热门文章

最新文章

  • 1
    android Jetpack组件Navigation导航组件--组件间跳转、组件间传值功能实现
  • 2
    android Jetpack—ViewModel使用方法和详细原理解析
  • 3
    Jetpack 系列（4）—— 有小伙伴说看不懂 LiveData、Flow、Channel，跟我走
  • 4
    Android Jetpack组件 DataStore的使用和简单封装
  • 5
    Android Jetpack系列之Lifecycle
  • 6
    android Jetpack Navigation组件—— 之嵌套导航图
  • 7
    Android Jetpack系列之MVVM使用及封装
  • 8
    Android Jetpack系列之 ViewModel
  • 9
    Jetpack Compose助我快速打造电影App
  • 10
    Jetpack Compose导航动画
  • 1
    Jetpack Compose for Desktop实现复杂的自动布局网格，熬夜整理蚂蚁金服Python高级笔试题
    62
  • 2
    Android架构组件JetPack之DataBinding玩转MVVM开发实战（四）
    71
  • 3
    Android Jetpack架构开发组件化应用实战，字节跳动+阿里+华为+腾讯等大厂Android面试题
    66
  • 4
    构建高效Android应用：采用Kotlin与Jetpack的实践指南
    74
  • 5
    构建高效Android应用：采用Kotlin与Jetpack的实践指南
    81
  • 6
    构建高效Android应用：采用Kotlin与Jetpack的实践指南
    54
  • 7
    构建高效Android应用：使用Jetpack架构组件实现MVVM模式
    103
  • 8
    构建高效的安卓应用：探究Android Jetpack架构组件
    84
  • 9
    什么是Android Jetpack，它包括哪些组件？
    97
  • 10
    使用Android Jetpack组件加速开发流程
    46

    • 相关课程

    更多
  • 前端自动化构建工具 Webpack

    • 相关电子书

    更多
  • JSPatch成长之路
  • JSPatch 成长之路
  • 深入浅出Dart
    • 下一篇
    【案例实战】SpringBoot整合阿里云文件上传OSS