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);
}
}
这个代码就很简单了,就是利用反射去执行。









