Header
终于到了最后的关头,Android Architecture Component 系列的最后一节内容。今天给大家带来的就是 Lifecycle 的解析。
至于 Lifecycle 的作用就不过多介绍,简单的来说就是让你自己定义的东西可以感知生命周期。比如你想设计了一个 GPS 位置监听器,打算在 Activity 可交互状态下发送地址位置,那么就可以利用 Lifecycle 来做这件事,这样和 Activity 的耦合性就减少了很多。
废话不多说了,就来看看 Lifecycle 内部的实现原理吧。
Lifecycle
Part 1
LifecycleOwner
先来看 LifecycleOwner 接口,这个接口定义就说明了某样东西是具有生命周期的。getLifecycle() 方法返回生命周期。
1 | public interface LifecycleOwner { |
官方建议除了 Activity 和 Fragment 之外,其他的代码都不应该实现 LifecycleOwner 这个接口。
目前 SupportActivity 和 Fragment 都实现了该接口。
Lifecycle
在上面我们看到 LifecycleOwner 接口的 getLifecycle() 方法返回了 Lifecycle 。Lifecycle 代表着生命周期,那么来看看 Lifecycle 是怎么定义的。
1 | public abstract class Lifecycle { |
Lifecycle 是个抽象类,其中定义了:
- addObserver :增加观察者,观察者可以观察到该生命周期的变化,具体的观察者就是 LifecycleObserver ;
- removeObserver :移除观察者 LifecycleObserver ;
- getCurrentState :返回当前生命周期的状态;
- Event :生命周期事件;
- State :生命周期状态;
至于 Event 和 State 的关系我们等到了下面再讲。
到这,我们来看看 SupportActivity 和 Fragment 在 getLifecycle 方法中返回了什么:
1 | @Override |
发现返回的是 LifecycleRegistry 的一个对象,而 LifecycleRegistry 就是 Lifecycle 的实现类。
我们先把对 LifecycleRegistry 的解析放一放,先来看看生命周期观察者 LifecycleObserver 。
LifecycleObserver
1 | @SuppressWarnings("WeakerAccess") |
LifecycleObserver 是个空接口,里面什么都没有。那我们自己定义一个类 MyLifecycleObserver 来实现 LifecycleObserver 接口,以达到观察生命周期的目的。
1 | public class MyLifecycleObserver implements LifecycleObserver { |
然后在 MainActivity 里面添加我们的 MyLifecycleObserver 观察者。
1 | @Override |
通过之前分析的代码我们可以观察到,getLifecycle() 返回的就是 LifecycleRegistry 对象。所以其实调用的就是 LifecycleRegistry 的 addObserver 方法来添加观察者的。
LifecycleRegistry
1 | @Override |
一开始,针对每个 LifecycleObserver 对象设置了一个初始状态 initialState ,然后结合初始状态 initialState 和 observer ,把它俩包装成一个 ObserverWithState 对象。并保存到 mObserverMap 中。 mObserverMap 缓存了所有的生命周期观察者。
我们来看看 ObserverWithState 里面的操作。
ObserverWithState
ObserverWithState 是 LifecycleRegistry 的静态内部类。
1 | static class ObserverWithState { |
在 ObserverWithState 中,我们有点蹊跷,mLifecycleObserver 的类型是 GenericLifecycleObserver ,但是我们传入的是 LifecycleObserver 类型。所以在 Lifecycling.getCallback(observer) 这句代码中做的事情就是把 LifecycleObserver 转化成 GenericLifecycleObserver ,我们深入了解下。
Lifecycling
1 | @NonNull |
根据代码可以大概知道,在 getCallback 中主要做的事情就是利用适配器 Adapter 把 LifeObserver 转化成 GenericLifecycleObserver 。
之前我们定义的 MyLifecycleObserver 是直接实现 LifecycleObserver 接口的,所以它不属于 FullLifecycleObserver 或者 FullLifecycleObserver ,因此它会去执行 getObserverConstructorType(klass) 方法。
1 | private static int getObserverConstructorType(Class<?> klass) { |
在 getObserverConstructorType 中,主要还是要看 resolveObserverCallbackType 方法。
1 | private static int resolveObserverCallbackType(Class<?> klass) { |
resolveObserverCallbackType 方法中调用 generatedConstructor 来生成 MyLifecycleObserver 的 GeneratedAdapter 构造器。看到这里可能很多人会懵逼,什么是 GeneratedAdapter ?
GeneratedAdapter
其实 GeneratedAdapter 可以理解为系统为我们的 MyLifecycleObserver 而设计适配器。
比如,我们在 MyLifecycleObserver 里设计了 onCreate 方法在生命周期的创建状态来回调,但是系统并不知道这个 onCreate 方法。所以需要设计出一套适配器来适配我们的 MyLifecycleObserver 。
那么这个适配器的代码也需要我们来写吗?不需要,在编译期时 apt 自动帮我们生成好了。我们可以在 build/generated/source/apt 目录下找到自动生成的 GeneratedAdapter 。
1 | public class MyLifecycleObserver_LifecycleAdapter implements GeneratedAdapter { |
到这里就真相大白了吧,所以在 generatedConstructor 方法中生成的就是 MyLifecycleObserver_LifecycleAdapter 的构造器。
具体代码:
1 | @Nullable |
我们再回到 resolveObserverCallbackType 方法,获取到 MyLifecycleObserver_LifecycleAdapter 构造器后,直接返回了 GENERATED_CALLBACK 。
1 | Constructor<? extends GeneratedAdapter> constructor = generatedConstructor(klass); |
然后在 getCallback 方法中会执行:
1 | if (type == GENERATED_CALLBACK) { |
因为 MyLifecycleObserver_LifecycleAdapter 的构造器就只有一个,所以 LifecycleObserver 转化成了 SingleGeneratedAdapterObserver 。
SingleGeneratedAdapterObserver
1 | @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP) |
SingleGeneratedAdapterObserver 是实现了 GenericLifecycleObserver 这个接口的。经过上面的一系列操作,我们的 MyLifecycleObserver 就被适配成了 SingleGeneratedAdapterObserver 。
ObserverWithState
其实在 ObserverWithState 还有一个方法 : dispatchEvent 。
1 | void dispatchEvent(LifecycleOwner owner, Event event) { |
dispatchEvent 会在生命周期发生改变时,然后通知观察者的时候调用。
所以我们可以理一理调用链:
生命周期发生改变 -> ObserverWithState.dispatchEvent -> SingleGeneratedAdapterObserver.onStateChanged -> MyLifecycleObserver_LifecycleAdapter.callMethods -> MyLifecycleObserver.onCreate/onAny/onDestroy
看完有没有一种原来如此、恍然大悟的感觉?
Part 2
那么什么时候会去调用 ObserverWithState.dispatchEvent 的方法呢?
答案就是在 LifecycleRegistry.handleLifecycleEvent 。 handleLifecycleEvent 方法就是被设计为设置生命周期状态并通知观察者的。
LifecycleRegistry
1 | public void handleLifecycleEvent(@NonNull Lifecycle.Event event) { |
在这里正好把 event 和 state 的关系捋一捋,这是官方给出的参考图,简明扼要。
下面就来看看 moveToState 方法。
1 | private void moveToState(State next) { |
如果当前生命周期的状态已经同步完成了,就直接 return 掉。否则就会同步并调用 sync 方法。
1 | private void sync() { |
主要做的事情就是比较当前生命周期的状态和我们存放在 mObserverMap 中最早或最新放入的观察者的状态,通过上面的分析,我们知道是 ObserverWithState 里面一开始有我们添加观察者时的初始状态。
假如生命周期当前状态 mState 是 STARTED ,而观察者的状态是 CREATED,那么我们需要通过 forwardPass() 通知所有的观察者当前生命周期的状态改变到了 STARTED ,请同步。
1 | private void forwardPass(LifecycleOwner lifecycleOwner) { |
首先循坏遍历存储了所有观察者的 mObserverMap ,第二个 while 是要分发处理各个状态经过的 event 。
比如当前状态 mState 是 RESUMED ,而 ObserverWithState 中的 state 是 INITIALIZED 。那么调用 ObserverWithState 的 dispatchEvent 方法就要分发 ON_CREATE ,ON_START ,ON_RESUME 了。
Part 3
问题又来了,到底是谁调用了 handleLifecycleEvent 呢?
我们可以在最终 merge 好的 AndroidManifest 中去寻找答案。
我们发现了这货 :
1 | <provider |
进 ProcessLifecycleOwnerInitializer 里看看。
1 | @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP) |
里面有个 LifecycleDispatcher ,一听名字上就猜到它做的是生命周期分发的工作。
1 | class LifecycleDispatcher { |
发现有一个 ReportFragment.injectIfNeededIn(activity); 进这里面看看。
1 | @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP) |
把 ReportFragment 加入到 Activity 中,然后在其各个生命周期中都会调用 dispatch() 方法。而 dispatch 方法最后调用了 LifecycleRegistry.RehandleLifecycleEvent 。
至此,Lifecycle 的整个流程都梳理完成了。
Footer
我们终于完成了对 Android Architecture Component 的整体源码解析,其中涉及到了 LiveData 、 ViewModel 和 Lifecycle 。当然出此之外还有 Room 和 Paging Library 等也是不错的选择,暂时就告一段落了。至于 Room 等有兴趣的同学可以下去自己研究下,拜拜!
bye ~~