敞开成长之旅！这是我参加「日新方案 12 月更文应战」的第3天，点击检查活动概况
前语
Lifecycle 到现在咱们应该都很了解了，是 Jetpack 中管理生命周期的一个东西。除了 Activity、Fragment 中能够供给给咱们生命周期回调，任何自界说 View 相同能够完成相似的回调功用。在没有 Lifecycle 之前咱们都需求界说接口，手动在生命周期办法中调用接口的完成。而 Lifecycle 只是需求一行代码即可完成！关于咱们来说不仅应该学会运用 Lifecycle 更应该了解其原理，学习其优异的规划。那么本文就来浅析一下 Lifecycle 的原理，看看 Google 官方是如何对生命周期回调这个需求进行规划。
源码版别
// lifecycle 的扩展许多 这儿用 * 替代了
implementation androidx.lifecycle:lifecycle-*:2.4.0
2.4 相关于 2.3 版别将 @OnLifecycleEvent 注解符号了废弃，由于其运用了反射功能欠安，这块咱们下面再说。
简略运用
Lifecycle 运用起来十分简略，以给 Activity 增加生命周期回调为例，新建回调类 ActivityLifecycleObserver：
ActivityLifecycleObserver.kt
class ActivityLifecycleObserver: DefaultLifecycleObserver {
private val TAG = "LifecycleObserver"
override fun onCreate(owner: LifecycleOwner) {
super.onCreate(owner)
Log.d(TAG, "onCreate")
}
override fun onStart(owner: LifecycleOwner) {
super.onStart(owner)
Log.d(TAG, "onStart")
}
override fun onResume(owner: LifecycleOwner) {
super.onResume(owner)
Log.d(TAG, "onResume")
}
override fun onPause(owner: LifecycleOwner) {
super.onPause(owner)
Log.d(TAG, "onPause")
}
override fun onStop(owner: LifecycleOwner) {
super.onStop(owner)
Log.d(TAG, "onStop")
}
override fun onDestroy(owner: LifecycleOwner) {
super.onDestroy(owner)
Log.d(TAG, "onDestroy")
}
}
在 Activity 中增加一行代码：
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
// ...
// 一行代码搞定
lifecycle.addObserver(ActivityLifecycleObserver())
}
}
作用：
源码剖析
原理探求
Lifecycle 不是魔法，只是一种优异的规划，已然能够在对应的生命周期中触发回调那么其生命周期办法中肯定有相关代码调用，顺着这个主意翻一下 Activity 的源码，果不其然，在 ComponentActivity 的 onCreate 中就找到了头绪：
ComponentActivity.java
// 承继关系只贴出了关键信息
// ComponentActivity 完成了 LifecycleOwner 接口
public class ComponentActivity implements LifecycleOwner{
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
// ...
ReportFragment.injectIfNeededIn(this);
// ...
}
}
ReportFragment.injectIfNeededIn 点进去检查其源码：
public class ReportFragment extends android.app.Fragment {
// ...
public static void injectIfNeededIn(Activity activity) {
// sdk >= 29 则运用 Application.ActivityLifecycleCallbacks 来处理 activity 的生命周期回调
if (Build.VERSION.SDK_INT >= 29) {
LifecycleCallbacks.registerIn(activity);
}
// sdk 小于 29 的兼容处理
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
// 给 activity 增加一个空白的 Fragment 并且设置 TAG
manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
manager.executePendingTransactions();
}
}
// 经过固定 TAG 获取当时 activity 中的空白 Fragment
static ReportFragment get(Activity activity) {
return (ReportFragment) activity.getFragmentManager().findFragmentByTag(
REPORT_FRAGMENT_TAG);
}
@Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
// 一切的生命周期办法中都调用了 dispatch
dispatch(Lifecycle.Event.ON_CREATE);
}
@Override
public void onStart() {
super.onStart();
dispatch(Lifecycle.Event.ON_START);
}
@Override
public void onResume() {
super.onResume();
dispatch(Lifecycle.Event.ON_RESUME);
}
@Override
public void onPause() {
super.onPause();
dispatch(Lifecycle.Event.ON_PAUSE);
}
@Override
public void onStop() {
super.onStop();
dispatch(Lifecycle.Event.ON_STOP);
}
@Override
public void onDestroy() {
super.onDestroy();
dispatch(Lifecycle.Event.ON_DESTROY);
}
// 内部调用了 双参数 dispatch 办法
private void dispatch(@NonNull Lifecycle.Event event) {
// sdk >= 29 时运用 LifecycleCallbacks 中的回调直接调用双参数 dispatch 办法
if (Build.VERSION.SDK_INT < 29) {
dispatch(getActivity(), event);
}
}
static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) {
// ...
// activity 一定要先完成 LifecycleOwner
if (activity instanceof LifecycleOwner) {
Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
// 调用 handleLifecycleEvent
((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
}
}
}
static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks {
static void registerIn(Activity activity) {
activity.registerActivityLifecycleCallbacks(new LifecycleCallbacks());
}
@Override
public void onActivityCreated(@NonNull Activity activity,
@Nullable Bundle bundle) {
}
@Override
public void onActivityPostCreated(@NonNull Activity activity,
@Nullable Bundle savedInstanceState) {
dispatch(activity, Lifecycle.Event.ON_CREATE);
}
// 其他的生命周期回谐和 onCreate 是相同的都是调用 dispatch 就不全贴了...
}
// ...
}
ReportFragment 的源码很简略，能够看出经过调用 injectIfNeededIn 会给 Activity 增加一个空白的 Fragment，当 Activity 生命周期发生变化时 Fragment 中会触发对应的生命周期，在 Fragment 的生命周期办法中调用 dispatch 传递生命周期阶段。这个办法和图片加载库 Glide 中的规划有异曲同工之妙，关于 Glide 系列的博客后续会随缘写写。
Google 对代码兼容处理也十分不错，sdk >=29 时直接运用了更为方便的 Application 的ActivityLifecycleCallbacks 在其对应办法中调用 dispatch，这个 dispatch 中主要调用了 LifecycleRegistry 的 handleLifecycleEvent 办法。关于这部分咱们先按下不表。
到这儿能够看出 Lifecycle 关于 Activity 来说是经过增加 Fragment 来处理生命周期回调的。
初始化工作
我在学习 Lifecycle 到这部分时产生了一个主意，ReportFragment 已然是在 ComponentActivity 中增加的，我偏不按照官方的来，我不承继 ComponentActivity 这种状况是不是就无法触发回调了？先说答案：Google 官方给你治的明明白白的，依然会给你的 Activity 增加 ReportFragment。
修改 MainActivity 如下：
class MainActivity : Activity(), LifecycleOwner {
val mLifecycle = LifecycleRegistry(this)
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
getLifecycle().addObserver(ActivityLifecycleObserver())
}
override fun getLifecycle(): Lifecycle = mLifecycle
}
这么写会发现 log 仍旧正常输出，这儿就不卖关子了直接给出定论，不过不能按照 2.4.0 版别来讲了这部分的代码改动比较大 2.4.0 版别的这部分内容牵扯到了另一个库 starup。所以这一末节的内容以 Lifecycle 2.2.0 版别来讲，原理肯定是差不多的，重在了解原理。
在 lifecycle-process:2.2.0 源码中有一个 ContentProvider 源码如下：
public class ProcessLifecycleOwnerInitializer extends ContentProvider {
@Override
public boolean onCreate() {
// 留意这一行
LifecycleDispatcher.init(getContext());
// ...
}
}
持续检查其源码：
class LifecycleDispatcher {
private static AtomicBoolean sInitialized = new AtomicBoolean(false);
static void init(Context context) {
if (sInitialized.getAndSet(true)) {
return;
}
// 又看到了了解的 registerActivityLifecycleCallbacks
((Application) context.getApplicationContext())
.registerActivityLifecycleCallbacks(new DispatcherActivityCallback());
}
// DispatcherActivityCallback 源码也十分简略
static class DispatcherActivityCallback extends EmptyActivityLifecycleCallbacks {
@Override
public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
// 这儿借助 Application.ActivityLifecycleCallbacks 又对 Activity 增加了 ReportFragment
ReportFragment.injectIfNeededIn(activity);
}
@Override
public void onActivityStopped(Activity activity) {
}
@Override
public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
}
}
private LifecycleDispatcher() {
}
}
Google 官方一个 ContentProvider 已然看穿我的小九九，专门避免有些开发者不承继 ComponentActivity 特意在 ContentProvider 中又进行了一次注入空白 Fragment 操作，当然这个操作也不会重复，由于在增加 Fragment 前就先经过 TAG 获取了一次，为 null 时才会进行增加。
两个重要枚举类
先贴一张网图：
Event 和 State 是两个枚举类，其间的枚举类型是对应状况，如图所示 Event 的 ON_CREATE 对应的 State 即为 CREATED，以此类推。
在下面了解两个类的源码时一定要结合这张图。
Lifecycle.Event
public enum Event {
// ON_XXX 是 Event 界说的几种生命周期，能够参阅 Activity 的生命周期来了解
// Lifecycle 不只是是给 Activity 用，能够让任何类都有生命周期，并且触发回调
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY;
// downFrom downTo upFrom upTo 分别是四个依据 State 获取 Evnent 的办法
public static Event downFrom(@NonNull State state) {
switch (state) {
case CREATED:
return ON_DESTROY;
case STARTED:
return ON_STOP;
case RESUMED:
return ON_PAUSE;
default:
return null;
}
}
public static Event downTo(@NonNull State state) {
switch (state) {
case DESTROYED:
return ON_DESTROY;
case CREATED:
return ON_STOP;
case STARTED:
return ON_PAUSE;
default:
return null;
}
}
public static Event upFrom(@NonNull State state) {
switch (state) {
case INITIALIZED:
return ON_CREATE;
case CREATED:
return ON_START;
case STARTED:
return ON_RESUME;
default:
return null;
}
}
public static Event upTo(@NonNull State state) {
switch (state) {
case CREATED:
return ON_CREATE;
case STARTED:
return ON_START;
case RESUMED:
return ON_RESUME;
default:
return null;
}
}
// 依据当时 Event 获取当时对应的 State
public State getTargetState() {
switch (this) {
case ON_CREATE:
case ON_STOP:
return State.CREATED;
case ON_START:
case ON_PAUSE:
return State.STARTED;
case ON_RESUME:
return State.RESUMED;
case ON_DESTROY:
return State.DESTROYED;
case ON_ANY:
break;
}
throw new IllegalArgumentException(this + " has no target state");
}
}
Lifecycle.State
public enum State {
// State 便是状况的意思，表明当时目标的生命周期处于什么样的状况
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
// 比较 声明的次序进行比较
public boolean isAtLeast(@NonNull State state) {
return compareTo(state) >= 0;
}
}
枚举类的代码比较简略，结合图片去了解 Event 中的升降操作办法也很简略，就不赘述了。
LifecycleRegistry
在上述 RepoFragment 中 dispatch 办法可谓是中心代码，dispatch 办法中调用了 LifecycleRegistry 的 handleLifecycleEvent，先来看看 LifecycleRegistry 是什么，LifecycleRegistry 承继自 Lifecycle 源码如下：
LifecycleRegistry.java
public class LifecycleRegistry extends Lifecycle {
// 咱们调用 addObserver 时就将目标增加到了这个 map 中
private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap =
new FastSafeIterableMap<>();
// 当时状况
private State mState;
// 弱引用保存当时要监听的目标
private final WeakReference<LifecycleOwner> mLifecycleOwner;
//...
public LifecycleRegistry(@NonNull LifecycleOwner provider) {
this(provider, true);
}
// 结构函数
private LifecycleRegistry(@NonNull LifecycleOwner provider, boolean enforceMainThread) {
// 保存当时被调查的目标
mLifecycleOwner = new WeakReference<>(provider);
// 状况初始为 INITIALIZED
mState = INITIALIZED;
// 默认为 true，执行在主线程
mEnforceMainThread = enforceMainThread;
}
// 增加调查者
public void addObserver(@NonNull LifecycleObserver observer) {
// mEnforceMainThread 为ture时 判别是否为主线程
// 内部经过 Handler 判别的
enforceMainThreadIfNeeded("addObserver");
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
// 传入的 Observer 包装为 ObserverWithState
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
// 增加到 map 中，第一次增加回来 null，后续增加回来 map 中的 value
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
// 第一次增加 为null 不进入 if
if (previous != null) {
return;
}
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
return;
}
// 是否重复进入
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
State targetState = calculateTargetState(observer);
// ++ 操作进行符号 操作完成后进行 --
mAddingObserverCounter++;
while ((statefulObserver.mState.compareTo(targetState) < 0
&& mObserverMap.contains(observer))) {
pushParentState(statefulObserver.mState);
final Event event = Event.upFrom(statefulObserver.mState);
if (event == null) {
throw new IllegalStateException("no event up from " + statefulObserver.mState);
}
statefulObserver.dispatchEvent(lifecycleOwner, event);
popParentState();
targetState = calculateTargetState(observer);
}
if (!isReentrance) {
// 进行同步 将一切的 observer state event 保持一致
sync();
}
mAddingObserverCounter--;
}
// 在 RepoFragment 生命周期中调用的办法
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
enforceMainThreadIfNeeded("handleLifecycleEvent");
// 内部调用了 moveToState
moveToState(event.getTargetState());
}
private void moveToState(State next) {
if (mState == next) {
return;
}
mState = next;
if (mHandlingEvent || mAddingObserverCounter != 0) {
mNewEventOccurred = true;
// we will figure out what to do on upper level.
return;
}
mHandlingEvent = true;
// 和 addObserver 时相同进行同步
// 这儿是外部调用 handleLifecycleEvent 导致 event 发生变化进行同步
sync();
mHandlingEvent = false;
}
private void sync() {
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
// isSynced 判别 map （链表结构） 第一个元素和终究一个元素的 state 以及当时的 state 是否相同
while (!isSynced()) {
mNewEventOccurred = false;
// 不同的话 则依据巨细不同调用 backwardPass、forwardPass 进行同步
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
// 要点
backwardPass(lifecycleOwner);
}
Map.Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
if (!mNewEventOccurred && newest != null
&& mState.compareTo(newest.getValue().mState) > 0) {
// 要点
forwardPass(lifecycleOwner);
}
}
mNewEventOccurred = false;
}
private void forwardPass(LifecycleOwner lifecycleOwner) {
// ...
// 循环调用每一个 observer 的 dispatchEvent
// 也便是 ObserverWithState
while (descendingIterator.hasNext() && !mNewEventOccurred) {
//...
observer.dispatchEvent(lifecycleOwner, event);
//...
}
}
}
private void backwardPass(LifecycleOwner lifecycleOwner) {
// ...
// 循环调用每一个 observer 的 dispatchEvent
// 也便是 ObserverWithState
while (descendingIterator.hasNext() && !mNewEventOccurred) {
//...
observer.dispatchEvent(lifecycleOwner, event);
//...
}
}
}
// ...
}
能够看出 LifecycleRegistry 内部保护了一个 <LifecycleObserver, ObserverWithState> 类型的 map，并且将 map 搞成了一个链表结构来寄存咱们传入的 observer；ObserverWithState 是对咱们传入的 observer 的包装类，当外部调用 handleLifecycleEvent 传入的 Event 和当时对应的 State 不一起，就会进行同步，遍历链表触发 ObserverWithState 的 dispatchEvent 办法。
LifecycleRegistry 并没有直接触发生命周期回调的操作，具体操作就在 ObserverWithState 类中。
ObserverWithState
ObserverWithState 是 LifecycleRegistry 的内部类，其源码如下：
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 = event.getTargetState();
mState = min(mState, newState);
// 这儿便是触发回调的具体办法了
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}
ObserverWithState 的源码很少，要点就在于其间的 mLifecycleObserver 的初始化。检查 Lifecycling.lifecycleEventObserver 办法源码：
static LifecycleEventObserver lifecycleEventObserver(Object object) {
// 前面这部分对应了文章开始所说的 废弃了 @OnLifecycleEvent 注解
// 引荐咱们的 observer 都承继 FullLifecycleObserver
boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
if (isLifecycleEventObserver && isFullLifecycleObserver) {
// 假如承继自 FullLifecycleObserver 那么直接回来 FullLifecycleObserverAdapter
// FullLifecycleObserverAdapter 内部的 onStateChange 办法直接依据当时 Event 触发了对应的生命周期回调办法
// 咱们承继 FullLifecycleObserver 接口完成其办法即可
// 这儿主要是避免了反射调用 提高功能 源码很简略 点进去一看便知 就不贴了
return new FullLifecycleObserverAdapter((FullLifecycleObserver) object,
(LifecycleEventObserver) object);
}
if (isFullLifecycleObserver) {
return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);
}
if (isLifecycleEventObserver) {
return (LifecycleEventObserver) object;
}
// 没有承继 FullLifecycleObserver 的处理 也便是 2.4.0 版别之前的注解处理
final Class<?> klass = object.getClass();
// 要点代码 下面再剖析
int type = getObserverConstructorType(klass);
if (type == GENERATED_CALLBACK) {
// 这个 if 表明存在和上述 FullLifecycleObserverAdapter 相似的 adapter
// 只是运用结构函数反射创立 adapter
// ...
return new CompositeGeneratedAdaptersObserver(adapters);
}
// 表明依据 @OnLifecycleEvent 注解反射对应办法进行调用
return new ReflectiveGenericLifecycleObserver(object);
}
能够看出 lifecycleEventObserver 办法主要依据传入的 observer 进行了不同的处理，运用 adapter 适配器触发回调的代码比较简略，咱们自行检查不难了解。经过 @OnLifecycleEvent 注解反射办法调用的状况应该目前运用的比较多，这儿就着重剖析下这种状况。
@OnLifecycleEvent 注解回调原理
getObserverConstructorType
从上面说到的一处要点办法开端剖析，getObserverConstructorType 源码如下：
private static int getObserverConstructorType(Class<?> klass) {
// 这儿用 map 做了一层缓存 提高功能
Integer callbackCache = sCallbackCache.get(klass);
if (callbackCache != null) {
return callbackCache;
}
// 要点在于 resolveObserverCallbackType
int type = resolveObserverCallbackType(klass);
sCallbackCache.put(klass, type);
return type;
}
resolveObserverCallbackType 源码如下：
private static int resolveObserverCallbackType(Class<?> klass) {
// 依据命名也不难看出
// REFLECTIVE_CALLBACK 表明需求反射调用
// GENERATED_CALLBACK 表明生成 也便是生成 adapter
if (klass.getCanonicalName() == null) {
return REFLECTIVE_CALLBACK;
}
// 这儿的 generatedConstructor 内部有生成 adapter 结构的逻辑 这儿就不具体剖析了
Constructor<? extends GeneratedAdapter> constructor = generatedConstructor(klass);
if (constructor != null) {
sClassToAdapters.put(klass, Collections
.<Constructor<? extends GeneratedAdapter>>singletonList(constructor));
return GENERATED_CALLBACK;
}
// 要点看注解反射 这种状况
boolean hasLifecycleMethods = ClassesInfoCache.sInstance.hasLifecycleMethods(klass);
if (hasLifecycleMethods) {
return REFLECTIVE_CALLBACK;
}
// ...
}
经过 hasLifecycleMethods 办法获取是否存在 LifecycleMethods ，其源码如下：
boolean hasLifecycleMethods(Class<?> klass) {
// 相同做了一层 map 缓存
Boolean hasLifecycleMethods = mHasLifecycleMethods.get(klass);
if (hasLifecycleMethods != null) {
return hasLifecycleMethods;
}
// 获取类中的 办法
Method[] methods = getDeclaredMethods(klass);
// 遍历
for (Method method : methods) {
// 测验获取 @OnLifecycleEvent 注解
OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
if (annotation != null) {
// 存在注解 则阐明是生命周期回调办法
createInfo(klass, methods);
return true;
}
}
mHasLifecycleMethods.put(klass, false);
return false;
}
private CallbackInfo createInfo(Class<?> klass, @Nullable Method[] declaredMethods) {
Class<?> superclass = klass.getSuperclass();
Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();
if (superclass != null) {
// 这儿相同又是 map 缓存
CallbackInfo superInfo = getInfo(superclass);
if (superInfo != null) {
handlerToEvent.putAll(superInfo.mHandlerToEvent);
}
}
Class<?>[] interfaces = klass.getInterfaces();
for (Class<?> intrfc : interfaces) {
for (Map.Entry<MethodReference, Lifecycle.Event> entry : getInfo(
intrfc).mHandlerToEvent.entrySet()) {
verifyAndPutHandler(handlerToEvent, entry.getKey(), entry.getValue(), klass);
}
}
// 再次获取类中的 办法
Method[] methods = declaredMethods != null ? declaredMethods : getDeclaredMethods(klass);
boolean hasLifecycleMethods = false;
for (Method method : methods) {
// 遍历测验获取 @OnLifecycleEvent 注解
OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
if (annotation == null) {
continue;
}
hasLifecycleMethods = true;
Class<?>[] params = method.getParameterTypes();
int callType = CALL_TYPE_NO_ARG;
if (params.length > 0) {
callType = CALL_TYPE_PROVIDER;
if (!params[0].isAssignableFrom(LifecycleOwner.class)) {
throw new IllegalArgumentException(
"invalid parameter type. Must be one and instanceof LifecycleOwner");
}
}
// 获取 @OnLifecycleEvent 注解中的 value
Lifecycle.Event event = annotation.value();
// ...
// 生成 method 包装类 callType 表明参数个数
MethodReference methodReference = new MethodReference(callType, method);
// 放入到 handlerToEvent map 容器中
verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
}
// 对 handlerToEvent 进行包装
CallbackInfo info = new CallbackInfo(handlerToEvent);
// 放入 map 缓存
mCallbackMap.put(klass, info);
// class 是否存在生命周期回调办法 map 缓存
mHasLifecycleMethods.put(klass, hasLifecycleMethods);
return info;
}
能够看出经过 getObserverConstructorType 获取 observer 回调类型时还额定对 observer 进行了解析，将标有 @OnLifecycleEvent 注解的办法进行了包装，存入了 map 中；
ReflectiveGenericLifecycleObserver
经过上述的剖析，假如运用 @OnLifecycleEvent 注解处理生命周期回调，则 ObserverWithState 中的 mLifecycleObserver 终究生成的为 ReflectiveGenericLifecycleObserver；
咱们再看一下其 onStateChanged 办法如何完成的：
class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
// mWrapped 即为咱们传入的 observer
private final Object mWrapped;
// mInfo 即为上一末节中 createInfo 创立的
private final androidx.lifecycle.ClassesInfoCache.CallbackInfo mInfo;
ReflectiveGenericLifecycleObserver(Object wrapped) {
mWrapped = wrapped;
// 经过 map 获取 mInfo
// 假如不存在 会再走一次 createInfo 流程
mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
}
@Override
public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Event event) {
mInfo.invokeCallbacks(source, event, mWrapped);
}
}
终究又调回到了 CallbackInfo 中的 invokeCallbacks，检查其源码：
static class CallbackInfo {
final Map<Lifecycle.Event, List<MethodReference>> mEventToHandlers;
final Map<MethodReference, Lifecycle.Event> mHandlerToEvent;
CallbackInfo(Map<MethodReference, Lifecycle.Event> handlerToEvent) {
mHandlerToEvent = handlerToEvent;
mEventToHandlers = new HashMap<>();
// 对 mEventToHandlers 初始化
for (Map.Entry<MethodReference, Lifecycle.Event> entry : handlerToEvent.entrySet()) {
Lifecycle.Event event = entry.getValue();
List<MethodReference> methodReferences = mEventToHandlers.get(event);
if (methodReferences == null) {
methodReferences = new ArrayList<>();
mEventToHandlers.put(event, methodReferences);
}
methodReferences.add(entry.getKey());
}
}
void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) {
// 终究调用到 invokeMethodsForEvent 中
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--) {
// 又调用到了 MethodReference 的 invokeCallback
handlers.get(i).invokeCallback(source, event, mWrapped);
}
}
}
}
持续跟着源码往里跳，检查 MethodReference 的 invokeCallback 的源码：
// mMethod 即为 observer 中的回调办法
final Method mMethod;
void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) {
try {
// 依据参数不同对 mMethod 进行反射调用
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;
}
}
// ...
}
到此位置，就成功触发了 observer 中对应注解中的回调办法。
总结
开始版别的 Lifecycle 都运用 @OnLifecycleEvent 注解对 observer 中的办法进行符号，到达生命周期回调的意图，2.4.0 供给了 FullLifecycleObserver 依据 Event 不同直接调用对应的办法，省去了反射办法、进行缓存的过程，提高了全体功能。其间用到了适配器规划模式来完成，十分值得咱们开发中学习。
在项目中能够能会有大量的 observer 需求解析，Lifecycle 中多处用到了 map 缓存，足可见其重要性，对重复大量的操作做缓存也是十分值得咱们开发中学习。
Lifecycle 并不只是限于运用在 Activity 上，任何类完成 LifecycleOwner 都能够被 LifecycleObserver 调查其生命周期，不过 Activity 是 Google 官方帮我增加了 RepoFragment 自动触发了生命周期回调，而关于咱们自己写的类而言需求在合适的时机自动触发 onStateChanged 办法。
换个思路来想咱们不只是能够让任何类完成 LifecycleOwner 也能够让任何类成为 LifecycleObserver，举个比如，你有一个 WebView 想让它跟随 Activity 的生命周期进行自动销毁，那么 Activity 作为 LifecycleOwner，WebView 能够作为 LifecycleObserver。这个比如就不在这儿赘述了，欢迎检查我之前的博客关于 WebView 优化的两篇博客中对这部分的完成有具体的代码。
终究
假如我的博客分享对你有点协助，不妨点个赞支持下！
