【Jetpack】学穿:Lifecycle → 生命周期 (原理篇)

0x1、Lifecycle核心思想

本质上是围绕着这两个设计模式进行的:

  • 模板模式 → 定义算法骨架,对外开放扩展点,基于 继承 关系实现,子类重写父类抽象方法;
  • 观察者模式 → 对象间定义一对多的依赖,当一个对象状态发生改变,依赖对象都会自动收到通知;

对这两种模式不了解的强烈建议看下笔者之前写的专栏:《把书读薄 | 设计模式之美》。

本节先肝下Lifecycle组件的两个库 lifecycle-commonlifecycle-runtime 的源码,了解实现原理,在肝Activity、Fragment中Lifecycle是如何发挥作用的。希望通过这节,能让你在实际开中能够有的放矢,放心大胆地用上Lifecycle。


0x2、lifecycle-common 源码解读

lifecycle-common 包中包含下述文件,挑着看:

① Lifecycle抽象类

类中定义了生命周期事件和状态,先看 Event,枚举了7种生命周期事件:

ON_CREATEON_STARTON_RESUMEON_PAUSEON_STOPON_DESTROYON_ANY

定义了状态升级、降级的四个方法:

downFrom()downTo()upFrom()upTo()

这里的升降级,读者看了可能会有点懵,可以把之前那个图竖着看:

以downFrom()为例,从传入状态降级,返回对应State:

从CREATED往下走,调用OnDestory,从STARTED往下走,调用onStop(),从RESUME往下走,调用onPause()

嘿嘿,是不是一下子就看懂了,再看下downTo():

往下走到DESTORYED,调用onDestory(),往下走到CREATED,调用onStop(),剩下两个也是类似~

然后还有个 getTargetState()

这个就更好理解了,调用onCreate()、onStop()会处于CREATED状态,其他同理。

说完Event说State,更简单,定义了定义了5个状态的枚举值:

DESTROYEDINITIALIZEDCREATEDSTARTEDRESUMED

以及一个判断状态是否相等的方法:

最后定义了三个抽象方法:

addObserver()、removeObserver()、getCurrentState()

可以把Lifecycle看作 抽象被观察者,抽取出生命周期事件与状态,统一状态流转过程,并提供了增删观察者的抽象方法供 具体被观察者 实现。


② LifecycleObserver接口

空接口,类型标记,可看作 抽象观察者


③ FullLifecycleObserver、LifecycleEventObserver接口

都继承LifecycleObserver接口,提供了两类不同的回调:

一种是详细的生命周期回调,一种是有状态变化就回调,前者优先级大于后者。


④ DefaultLifecycleObserver接口

继承 FullLifecycleObserver,这里用到了Java 8后才有的特性:接口声明默认方法,默认重写了回调方法,具体观察者 按需实现关注的回调方法即可。

public interface DefaultLifecycleObserver extends FullLifecycleObserver {
    @Override default void onCreate(@NonNull LifecycleOwner owner) { }
    @Override default void onStart(@NonNull LifecycleOwner owner) { }
    @Override default void onResume(@NonNull LifecycleOwner owner) { }
    @Override default void onPause(@NonNull LifecycleOwner owner) { }
    @Override default void onStop(@NonNull LifecycleOwner owner) { }
    @Override default void onDestroy(@NonNull LifecycleOwner owner) { }
}
复制代码

⑤ LifecycleOwner接口

提供一个获取 Lifecycle 的方法:


⑥ Lifecycling类

将传入的 LifecycleObserver 进行类型包装,生成一个新的 LifecycleEventObserver 实例,使得Event分发过程可以统一入口。直接关注 lifecycleEventObserver()

看下 FullLifecycleObserverAdapter

就是套了一层,保证先执行FullLifecycleObserver的回调,再执行LifecycleEventObserver的回调。

注解反射相关的暂且不看,基于OnLifecycleEvent注解方式进行回调,是面向基于Java 7作为编译版本的平台,现在基本都Java 8了,甚至有些玩Compose的都已经用上Java 11了。注释也有说,只是为了兼容保留,后续会逐步废弃。

lifecycle-common包看得差不多了,接下来看另一个~


0x3、lifecycle-runtime 源码解读

lifecycle-runtime 包含下述四个文件:

① LifecycleRegistry类

整个包里最重要的一个类,可看作 具体被观察者,常规玩法都是:

定义一个集合,存所有观察者,事件产生时,迭代集合,调用观察者对应的回调方法。

但在这里,逻辑变得更复杂了,因为还涉及到了 状态管理,还得考虑这些问题:

  • ① 有事件产生迭代观察者集合时,可能增删集合中的观察者 → 集合需要支持迭代时增删元素 → 你像ArrayList就不行,for迭代时移除元素会报ConcurrentModificationException;
  • ② 处理事件回调时,新加入的观察者该如何处理?该设置为什么状态?要不要也进行回调?
  • ③ 如果移除观察者呢?状态要更新吗?还是直接忽略?等等...

心中埋下这些问题的种子,然后开始跟源码,先是这个支持迭代时增删元素的集合:

一眼就看到这个 FastSafeIterableMap,点开类,注释说到:

简陋版的LinkedHashMap,支持遍历时的元素删除,比SafeIterableMap占用更多内存,非线程安全

他继承 SafeIterableMap(链表实现) 类,并重写了这四个方法

空间换时间,就是套了一层HashMap,使得 查找起来会更快 而已,接着看 SafeIterableMap

定义了头、尾Entry,存迭代器的WeakHashMap,节点计数器,看下 Entry

就是每个独立的 节点,里面除了key,value外,还有前后节点的引用,继续看get()、和put():

单链表的常规操作了,而 putIfAbsent() 更简单,就是调get(),拿到元素直接返回,拿不到put()插入元素。

回到关注点:遍历时删除元素,跟下 remove()

跟下 supportRemove()

关于迭代器具体的添加和删除,提供三个具体实现类:

  • AscendingIterator(升序)
  • DescendingIterator(降序)
  • IteratorWithAdditions(还支持添加元素)

就不去抠了,在调用 iterator() 获得迭代器时,都会把迭代器添加到集合中:

移除的话就不牢费心了,因为是弱引用,GC会自动回收,关于这个迭代时可增删元素的集合就了解到这。看回LifecycleRegistry:

key是LifecycleObserver,Value是 ObserverWithState,看看定义:

就是状态与观察者进行关联,并提供统一的事件分发入口,接着看下啥时候加集合里了,搜下 putIfAbsent 定位到了 addObserver()

大体了解流程,有疑惑的应该是这个 可重入标记sync()同步,看看都同步的啥吧:

看下降级、升级同步对应的两个方法:

所以sync()做的事情就是:让所有观察者完成状态迁移,并完成相应的事件分发,而同步完成的判断依据就是:首尾节点是否相等

除了addObserver()添加新Observer时会同步外,在生命周期事件迁移时也会同步,定位到:

看到这里应该能feel到为什么需要 可重入 的标记了,如果没有的话,可能产生sync()嵌套:

moveToState(state1)
→ sync()
→ moveToState(state1)
  → sync()

addObserver()
→ addObserver()
  → sync()
→ sync()

addObserver()
→ moveToState()
  → sync()
→ sync()
复制代码

最后都会走 最外层(顶层)的sync(),中间发生的sync() 完全没必要执行,减少不必要的迭代或错误,通过这三个字段配合来完成:mHandlingEventmNewEventOccurredmAddingObserverCounter

然后还有个属性还没弄清楚是干嘛的:

解释下:它为了解决 事件嵌套增加新观察者对观察者队列有序性的破坏。怎么说,看代码:

假如没有mParentStates,好像还正常,然后注释给了一个反例:

  • Observer1 在 onStart() 回调中把自己从集合中移除,然后添加了新的Observer2;
  • 假如集合中只有Observer1这个观察者,移除后集合就是空的,会导致Observer2直接更新到LifecycleRegister的STARTED状态;
  • 但,此时Observer1的 onStart() 回调还未执行完,而 Observer2 的 ON_START就回调执行完了,显然就违背了LifecycleRegistry的设计 → 观察者的同步是按照顺序执行的

添加了这个属性,在执行观察者回调前 pushParentState() 暂存当前观察者,回调完后 popParentState() 移除观察者,然后执行 calculateTargetState() 时判断是否为空,不为空取出最后一个缓存的观察者,然后取:LifecycleRegister当前状态、previous当前状态、缓存观察者状态中的最小值,作为当前观察者的状态。

关于 LifecycleRegistry 关键代码的的解析就这些,它还对外暴露了几个改变状态的方法:

Activiyt和Fragment中就有用到,等下会碰到,先继续往下走~


② ReportFragment类

一个专门用于分发生命周期事件的无UI界面的Fragment,入口方法 injectIfNeededIn()

很清晰明了,API版本大于等于29,直接使用 activity.registerActivityLifecycleCallbacks(),重写生命周期回调方法进行事件分发:

API版本小于29,直接开启一个事务,新建一个ReportFragment实例,添加到activity上,在ReportFragment中已对生命周期回调方法进行了重写,完成事件分发:

然后 dispatch() 就是调下 LifecycleRegistry.handleLifecycleEvent() 而已。

还定义了一个 ActivityInitializationListener 接口:

支持外部通过 setProcessListener() 传入自定义实现,在 lifecycle-process 源码中看到过:

留了个后门,让ProcessLifecycleOwner的onStart()和onResume(),先于第一个Activity执行。

③ ViewTreeLifecycleOwner类

看着有点蒙?看下 set() 调用处的代码就知道了:

ComponentActivity实现了LifecycleOwner接口,所以这里传入了 根视图 + ComponentActivity这个LifecycleOwner

而在调用 get() 传入view时,通过getParent()一层层往上拿,直到获取到这个LifecycleOwner为止(也可能没有返回空)。

那这有什么用呢?简化代码

View内部需要基于lifecycle进行某些操作时,可以避免Lifecycle的层层传递,比如LiveData订阅。


0x4、Activity中的Lifecycle相关

实现了Lifecycle接口,没干啥活,毕竟生命周期事件分发的活都交给ReportFragment了,直接贴相关代码~

// 定义一个LifecycleRegistry
private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
    ...
    ReportFragment.injectIfNeededIn(this);  // 使用Report分发生命周期事件
    ...
}

@Override
protected void onSaveInstanceState(@NonNull Bundle outState) {
    Lifecycle lifecycle = getLifecycle();
    if (lifecycle instanceof LifecycleRegistry) {
        // 设置mLifecycleRegistry当前状态为CREATED
        ((LifecycleRegistry) lifecycle).setCurrentState(Lifecycle.State.CREATED);
    }
    ...
}

@Override
public Lifecycle getLifecycle() {
    return mLifecycleRegistry;
}
复制代码

0x5、Fragment中的Lifecycle相关

同样实现了LifecycleOwner接口,实例化了一个LifecycleRegistry用于生命周期事件转发。

有一点要注意,在大多数情况下Fragment与其管理的View(视图)的生命周期是一致的,但存在特例:

Fragment被replace()时 → FragmentTransaction.detach() → 回调onDestroyView()销毁视图 → 不走onDestory() → 使得Fragment状态得以保留,当前内存空间得以释放,下次加载直接onCreateView(),速度更快。

这样的操作也导致了Fragment的生命周期比View长,所以Fragment还定义了一个 FragmentViewLifecycleOwner 来单独处理View的生命周期,官方文档有给出 《Fragment lifecycle》 给出了这样一张图:

源码注释中也有给出Fragment中管理的View:生命周期与Fragment自身回调间的对应关系

直接抠出来,方便看:

  • onViewStateRestored()后ON_CREATE
  • onStart()后ON_START
  • onResume()后ON_RESUME
  • onPause()前ON_PAUSE
  • onStop()前ON_STOP
  • onDestroyView()前ON_DESTROY

可调用 getViewLifecycleOwner() 获得View的LifecycleOwner哈~

Fragment中涉及到状态流转的核心代码如下:

void performCreate(Bundle savedInstanceState) {
    if (Build.VERSION.SDK_INT >= 19) {
        mLifecycleRegistry.addObserver(new LifecycleEventObserver() {
            @Override
            public void onStateChanged(@NonNull LifecycleOwner source,
                    @NonNull Lifecycle.Event event) {
                if (event == Lifecycle.Event.ON_STOP) {
                    if (mView != null) {
                        mView.cancelPendingInputEvents();
                    }
                }
            }
        });
    }
    mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
}

void performStart() {
    mState = STARTED;
    mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START);
    if (mView != null) {
        mViewLifecycleOwner.handleLifecycleEvent(Lifecycle.Event.ON_START);
    }
}

void performResume() {
    mState = RESUMED;
    mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_RESUME);
    if (mView != null) {
        mViewLifecycleOwner.handleLifecycleEvent(Lifecycle.Event.ON_RESUME);
    }
}

void performPause() {
    if (mView != null) {
        mViewLifecycleOwner.handleLifecycleEvent(Lifecycle.Event.ON_PAUSE);
    }
    mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_PAUSE);
    mState = AWAITING_ENTER_EFFECTS;
}

void performStop() {
    if (mView != null) {
        mViewLifecycleOwner.handleLifecycleEvent(Lifecycle.Event.ON_STOP);
    }
    mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);
    mState = ACTIVITY_CREATED;
}

void performDestroy() {
    mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_DESTROY);
    mState = ATTACHED;
}
复制代码

既有Fragment Lifecycle的State,又有ViewLifecycleOwner的State,还有Fragment自身的State,这个要区分哈:

另外,相比以前的源码,Fragment发生了较大的改动,比如状态管理相关的剥离到 FragmentStateManager 中了,笔者目前还不太了解,就不先不往下挖了,后续专门研究Fragment再说吧~


0x6、小结

关于源码的解析暂且到这里吧,Lifecycle的路数基本摸清了,小结下要点方便回顾:

  • ① Lifecycle的核心思想是:模板模式 + 观察者模式
  • Lifecycle抽象类抽象被观察者,定义了两个生命周期相关的枚举 EventState,统一了State升降级对应触发的Event(关联关系),提供了添加、移除观察者,获取当前State的三个抽象方法;
  • LifecycleObserver:空接口,类型标记,抽象观察者
  • FullLifecycleObserverLifecycleEventObserver:继承LifecycleObserver接口,提供两种不同的回调方式;
  • DefaultLifecycleObserver:继承FullLifecycleObserver,利用Java 8特性【接口声明默认方法】,默认重写了回调方法,具体观察者
  • LifecycleOwner:提供一个获取Lifecycle的方法;
  • Lifecycling → 对传入LifecycleOwner进行统一的类型包装,使得Event分发过程得以统一入口;
  • LifecycleRegistry具体观察者,组件状态维护,使用自定义支持迭代时增删元素的 FastSafeIterableMap (HashMap套链表) 保存观察者。键为LifecycleObserver,值为 ObserverWithState,其中包含观察者与状态关联,并提供事件分发方法dispatchEvent();
  • ⑨ 通过三个变量:mHandlingEventmNewEventOccurredmAddingObserverCounter 的配合来解决 事件嵌套 引起的sync()多次执行;
  • ⑩ 额外定义了一个 mParentStates 来解决 事件嵌套增加新观察者对观察者队列有序性的破坏

以上就是本节的全部内容,后续肝多几个组件,再来个实战篇吧,谢谢~


参考文献

  • 官方文档:使用生命周期感知型组件处理生命周期

  • 官方文档:Fragment lifecycle

  • 重学安卓:为你还原一个真实的 Jetpack Lifecycle

  • Lifecycle之SafeIterableMap

  • 带你理解Jetpack——Lifecycle篇

  • 【Android】使用ViewTreeLifecycleOwner获取Lifecycle

  • “终于懂了“系列:Jetpack AAC完整解析(一)Lifecycle 完全掌握!

  • 从源码看 Jetpack(1)- Lifecycle 源码详解

你可能感兴趣的:(【Jetpack】学穿:Lifecycle → 生命周期 (原理篇))