private final WeakReference mLifecycleOwner;
private int mAddingObserverCounter = 0;
private boolean mHandlingEvent = false;
}
-
FastSafeIterableMap LifecycleRegistry 中存储observer的集合类型,这个集合的功能是通过代理 HashMap 来进行拓展的。类似于 LinkedHashMap ,集合元素有序,通过链表将每一个Entry连起来。支持迭代操作和添加删除操作同时进行
-
mLifecycleOwner 这里使用了弱引用。如果在 Fragmnet 或者 Activity 中 lifecycle 的引用被其他组件持有,弱引用保护了不会泄漏整个 Framgnet 、 Activity (但是我们在开发中最好不要让 lifecycle 的引用暴露出来)
-
mAddingObserverCounter 、mHandlingEvent 两个bool值,与同步操作相关。
-
mState 表示LifecycleOwner的当前状态。当lifecycle监测到Activity/Framgnet 的生命周期发生变化时,会首先更新mState的值,然后调用sync()这个方法将其他lifecycle的数据和observers的数据进行同步,并根据mState的变化分发mState对应Event。
我们接着分析注册流程
addObserver(LifecycleObserver observer) 方法就是注册流程的入口。
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
// observer的转化流程在这里,这一步走完就已经将LifecycleObserver转换为LifecycleEventObserver了,
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
// 重复添加,直接返回
if (previous != null) {
return;
}
// 判空
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
return;
}
// 是否重入
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
State targetState = calculateTargetState(observer);
mAddingObserverCounter++;
// 重要
// 此时statefulObserver.mState 的初始值为
// INITIALIZED ,通过与计算出的 targetState 比较,
// 小于的话,就进入循环。
// (DESTROYED是最小的,INITIALIZED比DESTROYED大,CREATED比INITIALIZED,以此类推)
while ((statefulObserver.mState.compareTo(targetState) < 0
&& mObserverMap.contains(observer))) {
// 将自身状态存起来
pushParentState(statefulObserver.mState);
// 分发Event
statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
// 将自身状态删掉
popParentState();
// 重新计算状态,用于循环退出条件:直到observer的状态从INITIALIZED的状态递进到当前LifecyleOwner的状态
targetState = calculateTargetState(observer);
}
//如果重入的话没有必要每次都同步,浪费资源,只需要在最后一次处理完所有任务之后同步一次即可
if (!isReentrance) {
//更新一些属性,并分发event
sync();
}
mAddingObserverCounter–;
}
这个方法首先进来前几行代码:将 state与observer 包装成ObserverWithState类型,state 的初始值为 INITIALIZED ,然后存入集合,如果observer之前已经存在的话,就认定重复添加,直接返回。当添加的observer为新的时候,走下面流程。
接着判断了一下isReentrance这个boolean值,从字面意思来看,代表着:是否重入,可以理解为:
同时执行添加addObserver()的流程或者同时有其他Event事件正在分发。
如果重入的话,在方法末尾的同步方法sync()就不会执行,因为重入时对每一次状态改变都进行同步是多余的操作,只需要在最后一次进行同步操作即可。
还记得上一篇文章的末尾我举了一个例子吗?在 observer 中观察 Activity 的ONSTART 事件和 ONCREATE 事件,而在 Activity 的 onResume() 中才调用 addObserver() 。结果 observer 还是能受到 nCreate 和 onStart 生命周期的事件通知
Lifecycle能实现这种神奇的操作,逻辑就在这一段while循环中。
为了方便,while循环的分析写在了代码的注释里。
看一下这段循环中涉及到的两个方法dispatchEvent() 和 upEvent()
static class ObserverWithState {
State mState;
LifecycleEventObserver mLifecycleObserver;
ObserverWithState(LifecycleObserver observer, State initialState) {
mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
mState = initialState;
}
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
mState = min(mState, newState);
// observer的回调函数
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}
可以看到 dispatchEvent() 真正调用了 observer的回调方法,自己写的逻辑会在这里被执行,然后会更新mState,这里的 mState 是 observer 的 State。然后再配合 upEvent() 方法
private static Event upEvent(State state) {
switch (state) {
case INITIALIZED:
case DESTROYED:
return ON_CREATE;
case CREATED:
return ON_START;
case STARTED:
return ON_RESUME;
case RESUMED:
throw new IllegalArgumentException();
}
throw new IllegalArgumentException("Unexpected state value " + state);
}
和上面的代码注释,大家应该能很容易理解:observer的 mState 初始状态为INITIALIZED ,然后通过upEvent不断向前分发事件,更新状态,直到 observer 的mState达到当前 LifecycleOwner 的 mState
一个完整的addObserver()流程就走完了
LifecycleRegistry这个类整体的功能基本符合之前的猜测,这里再回顾一下
-
添加观察者observer,将observer解析之后,存在集合中,并在适当的时候移除observer
-
获取当前LifecycleOwner的状态,并负责状态与事件的转换
在注册流程的最后,我其实漏了一个点,Lifecycle是如何将多种不同的LifecycleObserver实现类 转化成统一的LifecycleEventObserver实现类。
因为对主线影响不大,这里就不展开说了,读者有兴趣可以自己去阅读源码,入口在addObserver()方法里,我已经用注释标出
通知流程
====
注册流程走完,Lifecycle 已经持有了所有 observer 的引用,只要在Activity \Fragment 生命周期改变的时候,通过Lifecycle 去通知所有observers,即可实现lifecycle的功能,而Lifecycle是如何感知Activity \Fragment生命周期的变化呢?
其实之前看ComponentActivity类的时候有一个奇怪的东西:
public class ComponentActivity extends androidx.core.app.ComponentActivity implements
LifecycleOwner,
ViewModelStoreOwner,
… {
…
private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
…
// 这里
ReportFragment.injectIfNeededIn(this);
if (mContentLayoutId != 0) {
setContentView(mContentLayoutId);
}
}
…
}
跟进去看一下ReportFragment这个类有什么功能:
public class ReportFragment extends Fragment {
public static void injectIfNeededIn(Activity activity) {
//为 @param activity 创建一个没有UI的Fragment
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
manager.executePendingTransactions();
}
}
…
@Override
public void onActivityCreated(Bundle savedInstanceState) {
dispatch(Lifecycle.Event.ON_CREATE);
}
@Override
public void onStart() {
dispatch(Lifecycle.Event.ON_START);
}
@Override
public void onResume() {
dispatch(Lifecycle.Event.ON_RESUME);
}
@Over
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享
ride
public void onPause() {
dispatch(Lifecycle.Event.ON_PAUSE);
}
@Override
public void onStop() {
dispatch(Lifecycle.Event.ON_STOP);
}
@Override
public void onDestroy() {
dispatch(Lifecycle.Event.ON_DESTROY);
}
private void dispatch(Lifecycle.Event event) {
Activity activity = getActivity();
if (activity instanceof LifecycleRegistryOwner) {
((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
return;
}
if (activity instanceof LifecycleOwner) {
Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
}
}
}
看完这里,豁然开朗。通过向 Activity 注入没有UI的一个 ReportFragment ,然后在** ReportFragment 的每一个与 Activity 对应的生命周期回调中写了dispathch() 方法** 分发生命周期状态的改变.因为Fragment依赖于创建它的Activity,Fragment的生命周期和Activity生命周期同步,这样就间接实现了 Lifecycle 监听Activity生命周期的功能。然后看一下是dispatch()如何分发Event的:
private void dispatch(Lifecycle.Event event) {
Activity activity = getActivity();
if (activity instanceof LifecycleRegistryOwner) {
((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
return;
}
if (activity instanceof LifecycleOwner) {
Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
}
}
}
调用getActivity()后向上强制转换为LifecycleOwner,然后调用了LifecycleRegistry类的handleLifecycleEvent(),逻辑又回到了LifecycleRegistry类中,从这里将事件Event分发回LifecycleRegistry之中
看一下handleLifecycleEvent(event)的具体实现:
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
State next = getStateAfter(event);
moveToState(next);
}
将分发来的事件Event转换为State,然后调用 moveToState() :
private void moveToState(State next) {
// 将 mState 更新为当前的 State
mState = next;
…
mHandlingEvent = true;
sync();
mHandlingEvent = false;
}
更新了mState的值之后,就调用sync()。这个方法算是 LifecycleRegistry 类中的一个很重要的方法。
大家可以发现event事件分发过来之后只是更新了一下mSate的值,并没有去调用observers的 onStateChanged() 回调方法。
所有的操作都是交给sync()方法根据 mState 的改变做出同步操作,并分发事件。
private void sync() {
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
…
// 判断是否需要同步,没有同步则一直进行
while (!isSynced()) {
mNewEventOccurred = false;
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
// 同步并分发事件
backwardPass(lifecycleOwner);
}
Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
if (!mNewEventOccurred && newest != null
&& mState.compareTo(newest.getValue().mState) > 0) {
//同步并分发事件
forwardPass(lifecycleOwner);
}
}
mNewEventOccurred = false;
}
首先通过调用isSynced() 来判断是否需要同步,这个方法的实现非常简单。
private boolean isSynced() {
if (mObserverMap.size() == 0) {
return true;
}
State eldestObserverState = mObserverMap.eldest().getValue().mState;
State newestObserverState = mObserverMap.newest().getValue().mState;
return eldestObserverState == newestObserverState && mState == newestObserverState;
}
通过之前的介绍我们知道存储observer的这种数据结构一种有序的Map。