Jetpack源码 之 Lifecycle
0. 前言
0.1 用法
Lifecycle可以说是Jetpack中最基础的一个库,他的主要作用就是帮我们实现的生命周期监听。
对于他的用法也很简单,由于我们的Activity(间接通过ComponentActivity
实现)、Fragment(直接实现)都已经实现了LifecycleOwner
接口,所以我们可以直接在他们中调用getLifecycle()
获得到Lifecycle
对象,然后调用他的addObserver()
将我们自定义的LifecycleObserver
传入进入即可。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33/* 以Activity为例 */
// MainActivity
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_lifecycle_test)
lifecycle.addObserver(LifecycleObserverTest)
}
//...
}
// LifecycleObserverTest
object LifecycleObserverTest : LifecycleObserver {
private const val TAG = "LifecycleTest"
fun prepare() {
// todo 播放器准备工作
Log.d(TAG, "prepare: Create时播放器准备工作")
}
fun release() {
// todo 释放资源
Log.d(TAG, "release: Destroy时释放资源")
}
fun play(context: Context) {
// todo 开始播放
Log.d(TAG, "play")
}
}
这样当MainActivity执行onCreate()
时会自动执行prepare()
方法,执行onDestroy()
时会自动执行release()
方法,就不需要我们手动的去调用了。
但是这块需要注意的是,这些添加了生命周期的方法,一定不要传入任何参数,因为都已经是自动调用的了,也就我们手动干预不了,那么系统怎么知道你要传入的参数是谁呢。没有添加生命周期的方法不受影响。
另外一个注意的点是,我们调用addObserver()
并不是一定得在onCreate()
方法中调用,我们在任何地方任何生命周期时调用即可,比方说我们上面在onCreate()
中调用了,这样打印出来的log就如下所示:
但是如果我们把addObserver()
放在onResume()
中调用,结果就变成了这样:
我们就会发现,原本应该在onCreate()
时执行的方法却到了onResume()
才执行。
所以这点我们一定要注意,我们调用addObserver()
一定得在我们监听的生命周期里面或者之前。
0.2 真 · 前言
看完刚刚的用法,我们能得到的第一个要素就是Lifecycle一定是通过观察者模式实现的,这个从addObserver()
就能看出来。
所以我们可以大胆猜想下Lifecycle的实现原理:
当调动addObserver()
之后,Lifecycle就通过一种数据接口将这个LifecycleObserver的对象保存了起来,当Activity生命周期变化时,他就会遍历这个数据结构,然后调用每一个的对应的生命周期的回调代码。
对应的也就分为两部分:
- 注册
- 分发
- 执行回调
(PS:突然感觉好像EventBus😂)
接下来我们就可以开始看源码,来验证我们的猜想到底正不正确。
1. 注册
注册肯定是从getLifecycle().addObserver(LifecycleObserver observer)
开始嘛。
首先,getLifecycle()
是谁的方法?
直接通过AndroidStudio的跳转功能就能看到,我们调用的getLifecycle()
其实是ComponentActivity的一个方法,进一步跳转就能看到其实是LifecycleOwner这个接口的一个抽象方法。
所以也就是说,Activity继承自ComponentActivity,而ComponentActivity实现了LifecycleOwner接口,这个接口中只有一个方法,那就是getLifecycle()
。(Fragment同理)
而这个方法返回的是Lifecycle,那么Lifecycle里面有些啥东西?
1.1 Lifecycle抽象类
进入Lifecycle的源码就能看到它是一个抽象类,代码也很少:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33public abstract class Lifecycle {
AtomicReference<Object> mInternalScopeRef = new AtomicReference<>();
public abstract void addObserver(; LifecycleObserver observer)
public abstract void removeObserver(; LifecycleObserver observer)
public abstract State getCurrentState();
public enum Event {
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY
}
public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
public boolean isAtLeast( { State state)
return compareTo(state) >= 0;
}
}
}
Lifecycle中有三个方法和两个枚举:
- 三个方法
addObserver()
:Adds a LifecycleObserver that will be notified when the LifecycleOwner changes.
(添加一个LifecycleObserver,这个LifecycleObserver在LifecycleOwner变化时能得到通知)removeObserver()
:Removes the given observer from the observers list.
(从observers的集合中移除这个observer)getCurrentState()
:Returns the current state of the Lifecycle.
(返回当前的生命周期状态(State))
- 两个枚举
Event
:这个不用多说,对应着Activity、Fragment的基本生命周期State
:这个是返回的当前Activity、Fragment的状态,具体转换看下图:
从上可得知,Lifecycle这个抽象类主要的作用就是
- 添加和移除Observer
- 获取当前LifecycleOwner的状态,并负责对应的状态和事件的转换
那么我们回过头来,getLifecycle()
要求返回一个Lifecycle对象,但是Lifecycle是一个抽象类,没办法直接构造对象,那么这个方法返回的是谁?
我们直接看ComponentActivity的getLifecycle()
方法:1
2
3public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
而这个mLifecycleRegistry
是LifecycleRegistry的对象,所以可以得知,Lifecycle其中一个(实际上是唯一)实现类是LifecycleRegistry。
1.2 LifecycleRegistry
Lifecycle只有唯一一个实现类,那就是LifecycleRegistry。
刚刚说到,注册肯定是有一个Observer的集合,刚刚Lifecycle源码中的注释也说明了这一点,所以我们先从这个类的属性开始看起:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16public class LifecycleRegistry extends Lifecycle {
private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap =
new FastSafeIterableMap<>();
private State mState;
private final WeakReference<LifecycleOwner> mLifecycleOwner;
private int mAddingObserverCounter = 0;
private boolean mHandlingEvent = false;
private boolean mNewEventOccurred = false;
// ...
}
mObserverMap
:用于保存Observer的集合,是一个FastSafeIterableMap集合,而这个FastSafeIterableMap根据源码注释,是类似于LinkedHashMap的,并且它是线程不安全,允许使用迭代器时修改集合的。mState
:当前的状态(State)。就是Lifecycle中的那个State枚举类。mLifecycleOwner
:就是这个LifecycleRegistry的持有者,这块使用了弱引用,是为了避免对Fragment、Activity直接引用而造成内存泄漏。mAddingObserverCounter
:正在添加到mObserverMap中的Observer的数量。mHandlingEvent
:是否正在分发事件的标记。mNewEventOccurred
:是否有新的事件发生的标记。
接着就来分析addObserver方法:
1.2.1 addObserver(@NonNull LifecycleObserver observer)
1 |
|
所以这个方法主要执行了下面几件事
- 先构造一个默认状态,要么是
DESTROYED
要么是INITIALIZED
- 然后根据这个
observer
和这个状态构建出一个statefulObserver
- 就去计算
targetState
,并对于这个statefulObserver
,如果他的state
小于targetState
,就进行分发时间,并重新计算targetState
- 如果是不可重入状态,则执行
sync()
方法
1.2.2 calculateTargetState(LifecycleObserver observer)
1 | private State calculateTargetState(LifecycleObserver observer) { |
所以这个方法的主要作用就是计算targetState
,这个targetState
一定小于等于当前mState
。
也就是说,我们可以添加多个Observer,但是每次添加新的Observer的时候,初始状态都是INITIALIZED
,这个时候就需要把它同步到当前的生命周期状态。
并且在更新状态的时候,每次更新之后都会调用这个方法再重新计算targetState
。
上面就完成了事件的添加了,那我们现在再来看下它是怎么分发事件的。
2. 分发
我们再次回到ComponentActivity,他在onCreate()
方法中执行了一行代码:1
2
3
4
5
6
7
8
9
protected void onCreate( { Bundle savedInstanceState)
super.onCreate(savedInstanceState);
mSavedStateRegistryController.performRestore(savedInstanceState);
ReportFragment.injectIfNeededIn(this); // !!!
if (mContentLayoutId != 0) {
setContentView(mContentLayoutId);
}
}
那我们看一下这个ReportFragment到底是啥:
2.1 ReportFragment
2.1.1 ReportFragment # injectIfNeededIn()
1 | public static void injectIfNeededIn(Activity activity) { |
看到这块是不是感觉很眼熟,Android中最常用的监听生命周期的方法就是往Activity中添加一个没有界面的Fragment,这块正是这个操作,所以我们具体看一下ReportFragment的实现。
2.1.2 ReportFragment # 生命周期监听
1 |
|
这是ReportFragment中对生命周期监听的所有方法,我们可以看到这些方法都有两个共性:
- 他们都调用了
dispatch()
方法去分发生命周期 - 他们都通知了
mProcessListener
对于mProcessListener
,这个是处理应用程序进程的生命周期的,这个我们先不去管它,我们需要重视的是这个dispatch()
方法
2.1.3 ReportFragment # dispatch()
1 | private void dispatch(Lifecycle.Event event) { |
由于我们探究的是ComponentActivity,所以肯定是走的第8行的if,然后他就会通过getLifecycle()
拿到mLifecycleRegistry
,然后调用了他的handleLifecycleEvent(event)
2.2 LifecycleRegistry
2.2.1 LifecycleRegistry # handleLifecycleEvent()
1 | public void handleLifecycleEvent( { Lifecycle.Event event) |
他首先调用了getSateAfter()
方法,获取到了当前event
对应的State(这个对应关系见上面那个State和Event的对应关系图)。
然后调用moveToSate()
去分发事件以及移动状态。
2.2.2 LifecycleRegistry # getStateAfter()
1 | static State getStateAfter(Event event) { |
这个也就是我们上面说的Event和State对照图的来源。
2.2.3 LifecycleRegistry # moveToState()
1 | private void moveToState(State next) { |
这个方法就是将next
同步到mState
,并进行对应的状态的分发。
2.2.4 LifecycleRegistry # sync()
1 | private void sync() { |
由于这是mState
已经更新,但是Observers的状态还没更新过,所以肯定是进入第23行的if,也就执行forwardPass()
方法
2.2.5 LifecycleRegistry # forwardPass()
1 | private void forwardPass(LifecycleOwner lifecycleOwner) { |
到这块我们就差不多能理解他的一个流程了,假设我们上面的流程是从ON_CREATE
到ON_RESUME
,那么这个流程就是:
- ReportFragment通过监听生命周期变化,调用了
dispatch(Lifecycle.Event.ON_RESUME)
; - 在
dispatch()
中则执行了LifecycleRegistry的handleLifecycleEvent()
方法,参数是ON_RESUME
; - 通过
getStateAfter()
返回RESUMED
,在调用moveToState()
跳转到RESUMED
; - 这时将
mSate
更新为RESUMED
,然后调用sync()
方法 - 在
sync()
方法中,由于mSate
是RESUMED
状态,而mObserverMap
中的状态都是STARTED
,那么mState
大于mObserverMap
,就执行forwardPass()
方法 - 最后就会调用
observer.dispatchEvent()
去分发事件
2.2.6 LifecycleRegistry # backwardPass()
刚刚看完了上面的代码和流程,那么既然有forwardPass()
,对应的backwardPass()
有啥作用呢?
我们还是假设一下流程,我们刚刚说到了ON_RESUME
,那么我们假设从ON_RESUME
到ON_PAUSE
,再来看一下刚刚的流程,和刚刚的流程一样的:
- ReportFragment通过监听生命周期变化,调用了
dispatch(Lifecycle.Event.ON_PAUSE)
; - 在
dispatch()
中则执行了LifecycleRegistry的handleLifecycleEvent()
方法,参数是ON_PAUSE
; - 通过
getStateAfter()
返回STARTED
,在调用moveToState()
跳转到STARTED
; - 这时将
mSate
更新为STARTED
,然后调用sync()
方法 - 在
sync()
方法中,由于mSate
是STARTED
状态,而mObserverMap
中的状态都是RESUMED
,那么mState
小于mObserverMap
,就执行backwardPass()
方法 - 最后就会调用
observer.dispatchEvent()
去分发事件
1 | // 和 forwardPass() 差不多 |
上面就是事件分发的过程。
那么剩下最后一个问题,怎么执行回调方法?
3. 执行回调
其实这块我们刚刚已经提到过了,那就是在sync()
方法中会调用forwardPass()
和backwardPass()
方法,这两个方法中都会调用observer.dispatchEvent(lifecycleOwner, event)
方法,所以我们就从这个入手。
首先我们回顾下,我们添加进去的observer
到底是谁?
回到addObserver()
方法,在这个方法内部的第二行和第三行:1
2ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
可以看到我们取出来的observer
其实就是这块的这个statefulObserver
,他是调用了ObserverWithState的构造方法构造出来的,并且我们后面也是调用的他的dispatchEvent()
方法,那我们就直接来看一下这个类:
3.1 ObserverWithState
1 | static class ObserverWithState { |
通过这个源码可以看到,它里面有两个参数,一个是mSate
,这个就是这个Observer当前的状态,另一个就是mLifecycleObserver
,这个也就是我们传入的Observer,但是他并不是直接拿着我们传入的observer
使用,而是调用Lifecycling.lifecycleEventObserver()
返回了一个值,那我们看一下这个方法到底是啥:
3.1.1 Lifecycling
3.1.1.1 Lifecycling # lifecycleEventObserver()
1 |
|
其中我们需要注意的是hasLifecycleMethods
:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23boolean hasLifecycleMethods(Class klass) {
Boolean hasLifecycleMethods = mHasLifecycleMethods.get(klass);
if (hasLifecycleMethods != null) {
return hasLifecycleMethods;
}
Method[] methods = getDeclaredMethods(klass);
for (Method method : methods) {
OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
if (annotation != null) {
// Optimization for reflection, we know that this method is called
// when there is no generated adapter. But there are methods with @OnLifecycleEvent
// so we know that will use ReflectiveGenericLifecycleObserver,
// so we createInfo in advance.
// CreateInfo always initialize mHasLifecycleMethods for a class, so we don't do it
// here.
createInfo(klass, methods);
return true;
}
}
mHasLifecycleMethods.put(klass, false);
return false;
}
这个代码就没啥好说的,单纯通过反射去找OnLifecycleEvent注解,所以综上所述,我们通过OnLifecycleEvent注解实现的Observer则返回的是REFLECTIVE_CALLBACK
类型,对应的lifecycleEventObserver()
方法返回的也是new ReflectiveGenericLifecycleObserver(observer)
。
3.1.2 ReflectiveGenericLifecycleObserver
1 | class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver { |
而我们之前的observer.dispatchEvent()
方法中实际上调用的是mLifecycleObserver.onStateChanged(owner, event)
,所以最后会交给ReflectiveGenericLifecycleObserver的onStateChanged()
方法来执行,而这个方法中又调用了mInfo.invokeCallbacks()
:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) {
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);
}
}
这个代码就很简单了,就是利用反射去执行。