前一篇 硬核讲解 Jetpack 之 LifeCycle 使用篇 主要介绍了 LifeCycle 存在的意义, 基本和进阶的使用方法. 今天话不多说, 直接开始撸源码.
本文基于我手里的 https://github.com/lulululbj/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 , 流程如下.
ReportFragment 调用 dispatch(Lifecycle.Event.ON_PAUSE) , 分发 ON_PAUSE 事
调用 LifecycleRegistry.handleLifecycleEvent() 方法, 参数是 ON_PAUSE
getStateAfter() 得到要同步到的状态是 STARTED , 并赋给 mState, 接着调用 moveToState()
moveToState(Lifecycle.State.STARTED) 中调用 sync() 方法同步
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 的关系, 官网给出了一张图, 如下所所示:
但我不得不说, 画的的确有点抽象, 其实应该换个画法. 再来一张我在 这里 https://www.jianshu.com/p/1d2d566e5690 看到的一张图:
状态之间的事件, 事件之后的状态, 状态之间的大小 , 是不是有种一目了然的感觉? 理解这幅图很重要, 可以说搞不清 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(三) https://www.jianshu.com/p/1d2d566e5690
Android-Lifecycle 超能解析 - 生命周期的那些事儿 https://www.jianshu.com/p/2c9bcbf092bc
文章首发微信公众号: 秉心说 , 专注 Java , Android 原创知识分享, LeetCode 题解.
来源: https://www.cnblogs.com/bingxinshuo/p/12089035.html