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

0x1、Lifecycle核心思想

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

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

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

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

0x2、lifecycle-common 源码解读

lifecycle-common 包中包含下述文件，挑着看：

① Lifecycle抽象类

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

ON_CREATE、ON_START、ON_RESUME、ON_PAUSE、ON_STOP、ON_DESTROY、ON_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个状态的枚举值：

DESTROYED、INITIALIZED、CREATED、STARTED、RESUMED

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

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

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() 完全没必要执行，减少不必要的迭代或错误，通过这三个字段配合来完成：mHandlingEvent、mNewEventOccurred、mAddingObserverCounter。

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

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

假如没有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抽象类：抽象被观察者，定义了两个生命周期相关的枚举 Event 和 State，统一了State升降级对应触发的Event(关联关系)，提供了添加、移除观察者，获取当前State的三个抽象方法；
③ LifecycleObserver：空接口，类型标记，抽象观察者；
④ FullLifecycleObserver、LifecycleEventObserver：继承LifecycleObserver接口，提供两种不同的回调方式；
⑤ DefaultLifecycleObserver：继承FullLifecycleObserver，利用Java 8特性【接口声明默认方法】，默认重写了回调方法，具体观察者；
⑥ LifecycleOwner：提供一个获取Lifecycle的方法；
⑦ Lifecycling → 对传入LifecycleOwner进行统一的类型包装，使得Event分发过程得以统一入口；
⑧ LifecycleRegistry → 具体观察者，组件状态维护，使用自定义支持迭代时增删元素的 FastSafeIterableMap (HashMap套链表) 保存观察者。键为LifecycleObserver，值为 ObserverWithState，其中包含观察者与状态关联，并提供事件分发方法dispatchEvent()；
⑨ 通过三个变量：mHandlingEvent、mNewEventOccurred、mAddingObserverCounter 的配合来解决 事件嵌套 引起的sync()多次执行；
⑩ 额外定义了一个 mParentStates 来解决 事件嵌套 中 增加新观察者对观察者队列有序性的破坏。

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

Tips：关于Lifecycle库的改动可以参见：Lifecycle，其他库亦是如此~

参考文献：