Lifecycle存在的意义
可以使得的一个非Activity类去感知Activity的生命周期，同时不需要在Activity中编写太多额外的逻辑
Lifecycle的基本使用
使用一：（推荐使用）
- 但是在使用之前需要注意的是：
必须添加对Java8 的依赖
implementation ‘androidx.lifecycle:lifecycle-common-java8:2.2.0’
- 基于接口（DefaultLifecycleObserver）来进行事件回调的，每当 Activity 的生命周期函数被触发时，该接口的相应同名函数就会在之前或者之后被调用，以此来获得相应生命周期事件变化的通知
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
lifecycle.addObserver(object : DefaultLifecycleObserver {
override fun onCreate(owner: LifecycleOwner) {
}
override fun onResume(owner: LifecycleOwner) {
}
override fun onDestroy(owner: LifecycleOwner) {
}
})
}
使用二：
- 实现LifecycleObserver接口
- 通过添加注解@OnLifeycleEvent(Lifecycle.Event.XXX)
可以通过ON_CREATE、ON_START、ON_RESUME、ON_PAUSE、ON_STOP、ON_DESTROY、ON_ANY（可以匹配到Activity的任何生命周期回调） - 可以通过以下代码进行配置
lifecycleOwner.lifecycle.addObserver(MyObserver()).参数为实现的LifecycleObserver()的类
- 在Activity或者Fragment中，由于它们本身就是一个LifecycleOwner实例，androidX库已经帮我们完成，就可以直接在相对应的Activity或者Fragment中使用 lifecycle.addObserver(MyLifeCycle()) 来进行配置
以下用简单实例展示Lifecycles的简单使用
（1）
class MyLifeCycle :LifecycleObserver{
@OnLifecycleEvent(Lifecycle.Event.ON_START)
fun activityStart() {
Log.e("lifecycleObserver","start")
}
@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
fun activityPause() {
Log.e("lifecycleObserver","pause")
}
}
（2）
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
lifecycle.addObserver(MyLifeCycle()) //只需要这一行代码，其他事情，androdX已经帮我们做好了
}
}
通过以上的方式，可以使得LifecycleObserver感知到生命周期的变化，但是不能主动获知activity的生命周期的状态，我们可以通过一下方式，得到activity的生命周期的状态
class MyLifeCycle(val lifecycle: Lifecycle) :LifecycleObserver{
}
传入的参数中有lifecycle对象，可以通过调用lifecycle.currentState来获取当前的生命周期状态，它的返回值为initialized、destroyed、created、started、resumed五种状态。
他们和Activity的生命周期的关系如下：
常见问题
（1）在一个非Activity的类中去感知Activity的生命周期有哪几种方式？
- 在Activity中嵌入一个隐藏的Fragment来进行感知
- 通过手写监听器的方式来进行感知
Lifecycle的源码分析
首先对几个特别重要的类进行简单的认识，也可以在阅读源码的过程中，遇到时，再来进行翻阅：
（1）Lifecycle
（2）LifecycleOwner
（3）LifecycleObserver
（4）LifecycleEventObserver
（5）FullLifecycleObserver
（6）DefaultLifecycleObserver
（7）FullLifecycleObserverAdapter
（8）Lifecycling
Lifecycle
在Lifecycle的使用中最先就是获取activity或者Fragment的lifecycle
- 首先介绍Lifecycle类：有两个枚举类，还有三个方法：分别用于添加观察者、移除观察者以及获取当前的生命周期的状态。
LifecycleOwner
public interface LifecycleOwner {
/**
* Returns the Lifecycle of the provider.
*
* @return The lifecycle of the provider.
*/
@NonNull
Lifecycle getLifecycle();
}
LifecycleOwner的实现类具有Lifecycle对象，在Activity和Fragment中都实现了这个接口
public class ComponentActivity extends androidx.core.app.ComponentActivity implements
LifecycleOwner,
ViewModelStoreOwner,
HasDefaultViewModelProviderFactory,
SavedStateRegistryOwner,
OnBackPressedDispatcherOwner {
···
}
----
public class Fragment implements ComponentCallbacks, OnCreateContextMenuListener, LifecycleOwner,
ViewModelStoreOwner, HasDefaultViewModelProviderFactory, SavedStateRegistryOwner {
···
}
LifecycleObserver
LifecycleObserver 是一个空接口，大部分情况下真正具有使用意义的是它的子接口 ，LifecycleObserver 可以说仅是用于类型标记。
public interface LifecycleObserver {
}
LifecycleEventObserver
他就是上面说的LifecycleObserver的子类，LifecycleEventObserver 用于监听 Lifecycle 的生命周期变化，可以获取到生命周期事件发生的具体变化。
public interface LifecycleEventObserver extends LifecycleObserver {
void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event);
}
FullLifecycleObserver
FullLifecycleObserver 根据 「Activity/Fragment」 这两个类的生命周期回调函数扩展了几个同名的抽象方法，可以看成是对 LifecycleEventObserver 进行更加具体的事件拆分，他也是LifecycleObserver的子类。
interface FullLifecycleObserver extends LifecycleObserver {
void onCreate(LifecycleOwner owner);
void onStart(LifecycleOwner owner);
void onResume(LifecycleOwner owner);
void onPause(LifecycleOwner owner);
void onStop(LifecycleOwner owner);
void onDestroy(LifecycleOwner owner);
}
DefaultLifecycleObserver
DefaultLifecycleObserver 是 FullLifecycleObserver的子类，androidx.lifecycle:lifecycle-common-java8:xxx 整个依赖库仅包含了该接口，从依赖库的命名上来看，可以看出它是用于 Java 8 平台的。
DefaultLifecycleObserver 将 FullLifecycleObserver 的所有方法都进行了默认实现，让开发者可以只处理自己关心的生命周期事件。因为大多数时候我们仅需要使用一部分生命周期状态函数，如果使用 FullLifecycleObserver 的话我们就必须实现所有抽象方法，而大部分方法可能都是空实现。
所以，为了简化代码，Jetpack 也提供了 DefaultLifecycleObserver 接口，而「接口可以声明默认方法」这一特性也是 Java 8 开始才有的，所以只有当你的项目是以 Java 8 作为目标编译版本时，才可以使用 DefaultLifecycleObserver。
public interface DefaultLifecycleObserver extends FullLifecycleObserver {
@Override
default void onCreate(@NonNull LifecycleOwner owner) {
}
@Override
default void onStart(@NonNull LifecycleOwner owner) {
}
@Override
default void onResume(@NonNull LifecycleOwner owner) {
}
@Override
default void onPause(@NonNull LifecycleOwner owner) {
}
@Override
default void onStop(@NonNull LifecycleOwner owner) {
}
@Override
default void onDestroy(@NonNull LifecycleOwner owner) {
}
}
FullLifecycleObserverAdapter
他是LifecycleEventObserver的子类，用于在收到 Lifecycle 生命周期事件状态变化时，对其两个构造函数参数（ 「FullLifecycleObserver、LifecycleEventObserver」）进行事件转发。也就是说当Activity或者Fragment的生命周期发生变化的时候调用FullLifecycleObserverAdapter的onStateChanged方法就可以实现当生命周期变化的时候回调LifecycleObserver的同名方法。
class FullLifecycleObserverAdapter implements LifecycleEventObserver {
private final FullLifecycleObserver mFullLifecycleObserver;
private final LifecycleEventObserver mLifecycleEventObserver;
FullLifecycleObserverAdapter(FullLifecycleObserver fullLifecycleObserver,
LifecycleEventObserver lifecycleEventObserver) {
mFullLifecycleObserver = fullLifecycleObserver;
mLifecycleEventObserver = lifecycleEventObserver;
}
@Override
public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {
switch (event) {
case ON_CREATE:
mFullLifecycleObserver.onCreate(source);
break;
case ON_START:
mFullLifecycleObserver.onStart(source);
break;
case ON_RESUME:
mFullLifecycleObserver.onResume(source);
break;
case ON_PAUSE:
mFullLifecycleObserver.onPause(source);
break;
case ON_STOP:
mFullLifecycleObserver.onStop(source);
break;
case ON_DESTROY:
mFullLifecycleObserver.onDestroy(source);
break;
case ON_ANY:
throw new IllegalArgumentException("ON_ANY must not been send by anybody");
}
if (mLifecycleEventObserver != null) {
mLifecycleEventObserver.onStateChanged(source, event);
}
}
}
源码分析
在ComponentActivity的onCreate方法中，ReportFragment.injectIfNeededIn(this);在Activity中注入了让一个Fragment，下面看一下这个注入的方法具体的实现
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mSavedStateRegistryController.performRestore(savedInstanceState);
ReportFragment.injectIfNeededIn(this);
if (mContentLayoutId != 0) {
setContentView(mContentLayoutId);
}
}
public static void injectIfNeededIn(Activity activity) {
if (Build.VERSION.SDK_INT >= 29) {
//当 API 等级为 29+ 时，我们可以直接向 android.app.Activity 注册生命周期回调
activity.registerActivityLifecycleCallbacks(
new LifecycleCallbacks());
}
/*在 API 29 之前，为了保持与旧版本的 ProcessLifecycleOwner 的兼容性
（因为有可能更新了 lifecycle-runtime 库而目标设备并非 29+，
并且需要支持 support 包中没有继承于 FragmentActivity 的 Activity），
此处向 activity 添加一个不可见的 framework 中的 fragment，以此来取得 Activity 生命周期事件的正确回调
*/
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
manager.executePendingTransactions();
}
}
ReportFragment 的 injectIfNeededIn() 函数会根据两种情况来进行事件分发
运行设备的系统版本号小于 29。此情况会通过向 Activity 添加一个无 UI 界面的 Fragment（即 ReportFragment），间接获得 Activity 的各个生命周期事件的回调通知
运行设备的系统版本号大于或等于29。此情况会向 Activity 注册一个 LifecycleCallbacks ，以此来直接获得各个生命周期事件的回调通知。此时也会同时执行第一种情况的操作
之所以会进行这两种情况区分，是因为 registerActivityLifecycleCallbacks 是 SDK 29 时 android.app.Activity 新添加的方法，从这个版本开始支持直接在 LifecycleCallbacks 中取得事件通知。当用户的设备 SDK 版本小于 29 时，就还是需要通过 ReportFragment 来间接取得事件通知。且为了保证 support 包的兼容性，即使 SDK 版本号大于 29，也依然会添加 ReportFragment
当SDK >= 29时
先来看下 LifecycleCallbacks 类。其逻辑就是会在 Activity 的 「onCreate、onStart、onResume」 等方法「被调用后」通过 dispatch(activity, Lifecycle.Event.ON_XXX) 方法发送相应的 Event 值，并在 「onPause、onStop、onDestroy」 等方法「被调用前」发送相应的 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);
}
@Override
public void onActivityStarted(@NonNull Activity activity) {
}
@Override
public void onActivityPostStarted(@NonNull Activity activity) {
dispatch(activity, Lifecycle.Event.ON_START);
}
@Override
public void onActivityResumed(@NonNull Activity activity) {
}
@Override
public void onActivityPostResumed(@NonNull Activity activity) {
dispatch(activity, Lifecycle.Event.ON_RESUME);
}
@Override
public void onActivityPrePaused(@NonNull Activity activity) {
dispatch(activity, Lifecycle.Event.ON_PAUSE);
}
@Override
public void onActivityPaused(@NonNull Activity activity) {
}
@Override
public void onActivityPreStopped(@NonNull Activity activity) {
dispatch(activity, Lifecycle.Event.ON_STOP);
}
@Override
public void onActivityStopped(@NonNull Activity activity) {
}
@Override
public void onActivitySaveInstanceState(@NonNull Activity activity,
@NonNull Bundle bundle) {
}
@Override
public void onActivityPreDestroyed(@NonNull Activity activity) {
dispatch(activity, Lifecycle.Event.ON_DESTROY);
}
@Override
public void onActivityDestroyed(@NonNull Activity activity) {
}
}
最终通过调用dispatch方法发送Event值
ReportFragment
当SDK < 29 时，添加了一个ReportFragment，再来看下向 Activity 添加的 ReportFragment 是如何生效的。由于 ReportFragment 是挂载在 Activity 身上的，ReportFragment 本身的生命周期函数和所在的 Activity 是相关联的，通过在 ReportFragment 相应的生命周期函数里调用 「dispatch(Lifecycle.Event.ON_XXXX)」 函数发送相应的 Event 值，以此来间接获得 Activity 的各个生命周期事件的回调通知。
@Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
dispatchCreate(mProcessListener);
dispatch(Lifecycle.Event.ON_CREATE);
}
@Override
public void onStart() {
super.onStart();
dispatchStart(mProcessListener);
dispatch(Lifecycle.Event.ON_START);
}
@Override
public void onResume() {
super.onResume();
dispatchResume(mProcessListener);
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);
// just want to be sure that we won't leak reference to an activity
mProcessListener = null;
}
还是调用了dispatch（）方法来发送Event 值，看一下diapatch方法
private void dispatch(@NonNull Lifecycle.Event event) {
if (Build.VERSION.SDK_INT < 29) {
//判断了版本号<29才发送Event值，避免重复发送，前面说了在版本29前后都添加了Report Fragment，所以为了避免重复发送
//需要先判读一下版本号
dispatch(getActivity(), event);
}
}
接下来调用的dispatch方法就和前面的LifecycleCallbacks生命周期中调用的dispatch方法一样了。
看一下这个dispatch方法
static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) {
//LifecycleRegistryOwner 已被废弃，主要看 LifecycleOwner
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的lifecycle对象通过类型判断，调用了LifecycleRegister的handleLifecycleEvent方法
LifecycleRegister
在介绍handle LifecycleEvent方法之前先对LifecycleRegister做一个简单的了解：
不单单是 Activity 和 Fragment 可以实现 LifecycleOwner 接口，像 Service、Dialog 等具有生命周期的类一样可以实现 LifecycleOwner 接口，而不管 LifecycleOwner 的实现类是什么，其本身所需要实现的「功能/逻辑」都是一样的：「addObserver、removeObserver、getCurrentState、遍历循环 observers 进行 Event 通知」等。所以 Google 官方势必需要提供一个通用的 Lifecycle 实现类，以此来简化开发者实现 LifecycleOwner 接口的成本，最终的实现类即 LifecycleRegistry
外部可以通过 addObserver() 方法来向 LifecycleRegistry 添加 Observer，Observer 内部可能会被用于执行一些耗时操作，而在耗时操作完成之前 Activity 可能已经走向 DESTORY 状态了，所以 LifecycleRegistry 也需要做好避免内存泄漏的准备，不能直接强引用 Activity。
假设当 Activity 处于 State.STARTED 状态时向其添加了一个 LifecycleEventObserver ，此时就必须向 LifecycleEventObserver 同步当前的最新状态值，所以 LifecycleEventObserver 就会先后收到 Lifecycle.Event.ON_CREATE、Lifecycle.Event.ON_START 两个 Event。
外部可能先后向 LifecycleRegistry 添加多个 Observer 或者是移除 Observer，且可能是在不同线程上进行调用，所以在管理 Observer 时需要做好同步处理。LifecycleRegistry 向 Observer 发布 Event 值的触发条件有两种：
新添加了一个 Observer，需要向其同步 Activity 当前的 State 值。在同步的过程中新的 Event 值可能刚好又来了，此时需要考虑如何向所有 Observer 同步最新的 Event 值
Activity 的生命周期状态发生了变化，需要向 Observer 同步最新的 State 值。在同步的过程中可能又添加了新的 Observer 或者移除了 Observer ，此时一样需要考虑如何向所有 Observer 同步最新的 Event 值
public class LifecycleRegistry extends Lifecycle {
//一般一个 LifecycleRegistry 对应一个 LifecycleOwner 对象（Activity/Fragment等）
//mState 就用来标记 LifecycleOwner 对象所处的当前生命周期状态
private State mState;
//持有对 LifecycleOwner 的弱引用，避免内存泄露
private final WeakReference<LifecycleOwner> mLifecycleOwner;
public LifecycleRegistry(@NonNull LifecycleOwner provider) {
mLifecycleOwner = new WeakReference<>(provider);
mState = INITIALIZED;
}
接下来看一下在使用过程中常用到的add Observer方法：
addObserver() 函数的主要逻辑是：将传入的 observer 对象包装为 ObserverWithState 类型，方便将 注解形式的LifecycleObserver（Java 7）「和」接口实现的 LifecycleObserver（Java 8） 进行状态回调时的入口统一为 「dispatchEvent()」 方法。此外，由于当添加 LifecycleObserver 时 Lifecycle 可能已经处于非 INITIALIZED 状态了，所以需要通过循环检查的方式来向 ObserverWithState 逐步下发 Event 值。
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
if (previous != null) {
//如果 observer 已经已经传进来过了，则不重复添加，直接返回
return;
}
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
// it is null we should be destroyed. Fallback quickly
//如果 LifecycleOwner 对象已经被回收了，则直接返回
return;
}
//如果 isReentrance 为 true，则说明此时存在多线程同时 addObserver 的情况或者
//是正处于向外回调 Lifecycle.Event 的状态
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
State targetState = calculateTargetState(observer);
//递增加一，标记当前正处于向新添加的 LifecycleObserver 回调 Event 值的过程
mAddingObserverCounter++;
//statefulObserver.mState.compareTo(targetState) < 0 成立的话说明 State 值还没遍历到目标状态
//mObserverMap.contains(observer) 成立的话说明 observer 还没有并移除，因为有可能
//在遍历过程中 observer 就被移除了，所以这里每次循环都检查下
while ((statefulObserver.mState.compareTo(targetState) < 0
&& mObserverMap.contains(observer))) {
//将 observer 已经遍历到的当前的状态值 mState 保存下来
pushParentState(statefulObserver.mState);
//向 observer 回调进入“statefulObserver.mState”前需要收到的 Event 值
statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
//移除 mState
popParentState();
// mState / subling may have been changed recalculate
targetState = calculateTargetState(observer);
}
if (!isReentrance) {
// we do sync only on the top level.
sync();
}
mAddingObserverCounter--;
}
ObserverWithState 将外界传入的 LifecycleObserver 对象传给 Lifecycling 进行类型包装，将反射逻辑和接口回调逻辑都给汇总综合成一个新的 LifecycleEventObserver 对象，从而使得 Event 分发过程都统一为一个入口。
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);
//在这里调用了LifecycleObserver的onStateChanged方法
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}
而在上文提到的，ReportFragment 最终在向外传出 Lifecycle.Event 值时，调用的都是 LifecycleRegistry 对象的 handleLifecycleEvent(Lifecycle.Event) 方法，该方法会根据接收到的 Event 值换算出对应的 State 值，然后更新本地的 mState，再向所有 Observer 进行事件通知，最终还是会调用到 ObserverWithState 的 dispatchEvent 方法，所以后边我们再来重点关注 dispatchEvent 方法即可。
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
//根据Lifecycle.Event的情况执行完后判断Lifecycle.state的情况
State next = getStateAfter(event);
moveToState(next);
}
private void moveToState(State next) {
......
sync();
......
}
private void sync() {
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
//循环 遍历所有观察者
while (...) {
....
//分发事件
forwardPass(lifecycleOwner);
}
}
private void forwardPass(LifecycleOwner lifecycleOwner) {
Iterator<Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
mObserverMap.iteratorWithAdditions();
while (ascendingIterator.hasNext() && !mNewEventOccurred) {
Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
ObserverWithState observer = entry.getValue();
while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey()))) {
pushParentState(observer.mState);
//分发事件
observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));
popParentState();
}
}
}
Lifecycling
上面说到了，LifecycleRegistry 会将外部传入的所有 LifecycleObserver 根据 Lifecycling 包装成 LifecycleEventObserver 对象，这里先来解释下为什么需要进行这层包装
LifecycleEventObserver 和 FullLifecycleObserver 都是继承于 LifecycleObserver 的接口，如果开发者自己实现的自定义 Observer 同时实现了这两个接口，那按道理来说 LifecycleRegistry 就必须在有事件触发的情况下同时回调这两个接口的所有方法
如果开发者自己实现的自定义 Observer 仅实现了 LifecycleEventObserver 和 FullLifecycleObserver 这两个接口当中的一个，那么也需要在有事件触发的情况下调用相应接口的对应方法
实现了通过以上两个接口来实现回调外，Google 也提供了通过注解的方法来声明生命周期回调函数，此时就只能通过反射来进行回调
基于以上三点现状，如果在 LifecycleRegistry 中直接对外部传入的 Observer 来进行类型判断、接口回调、反射调用等一系列操作的话，那势必会使得 LifecycleRegistry 整个类非常的臃肿，所以 Lifecycling 的作用就是来将这一系列的逻辑给封装起来，仅仅开放一个 onStateChanged 方法即可让 LifecycleRegistry 完成整个事件分发，从而使得整个流程会更加清晰明了且职责分明。
在前面的代码中调用了lifecycleEventObserver，看一下这个方法的处理：
@NonNull
@NonNull
static LifecycleEventObserver lifecycleEventObserver(Object object) {
//以下对应于上述的第一点和第二点
boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
if (isLifecycleEventObserver && isFullLifecycleObserver) {
//如果 object 对象同时继承了 LifecycleEventObserver 和 FullLifecycleObserver 接口
//则将其包装为 FullLifecycleObserverAdapter 对象来进行事件转发
return new FullLifecycleObserverAdapter((FullLifecycleObserver) object,
(LifecycleEventObserver) object);
}
if (isFullLifecycleObserver) {
//同上
return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);
}
if (isLifecycleEventObserver) {
//object 已经是需要的目标类型了（LifecycleEventObserver），直接原样返回即可
return (LifecycleEventObserver) object;
}
//以下对应于上述所说的第三点，即反射操作
final Class<?> klass = object.getClass();
int type = getObserverConstructorType(klass);
if (type == GENERATED_CALLBACK) {
List<Constructor<? extends GeneratedAdapter>> constructors =
sClassToAdapters.get(klass);
if (constructors.size() == 1) {
GeneratedAdapter generatedAdapter = createGeneratedAdapter(
constructors.get(0), object);
return new SingleGeneratedAdapterObserver(generatedAdapter);
}
GeneratedAdapter[] adapters = new GeneratedAdapter[constructors.size()];
for (int i = 0; i < constructors.size(); i++) {
adapters[i] = createGeneratedAdapter(constructors.get(i), object);
}
return new CompositeGeneratedAdaptersObserver(adapters);
}
return new ReflectiveGenericLifecycleObserver(object);
}
这里前两种情况再展开讨论，看一下第三种情况：
对于第三种情况的反射操作，其逻辑相对来说会比较复杂，需要进行一系列的类型判断、类型缓存、反射调用等操作，这里主要来看下 ClassesInfoCache 对于使用 OnLifecycleEvent进行注解的函数是如何进行限制的。
开发者应该都知道，Java 平台的反射操作是一个比较低效和耗费性能的行为，为了避免每次有需要进行事件回调时都再来对包含 OnLifecycleEvent 注解的 class 对象进行反射解析，所以 Lifecycling 内部对 Class、Method 等进行了缓存，以便后续复用。而 Lifecycling 就将这些缓存信息都封装存放在了 ClassesInfoCache 内部。
此外，被注解的函数的入参类型、入参顺序、入参个数都有着严格的限制，毕竟如果开发者为回调函数声明了一个 String 类型的入参参数的话，Lifecycle 也不知道该向其传递什么属性值。
ClassesInfoCache 内部会判断指定的 class 对象是否包含使用了 OnLifecycleEvent 进行注解的函数，并将判断结果缓存在 mHasLifecycleMethods 内，缓存信息会根据 createInfo(klass, methods) 来进行获取。
//判断指定的 class 对象是否包含使用了 OnLifecycleEvent 进行注解的函数
boolean hasLifecycleMethods(Class<?> klass) {
Boolean hasLifecycleMethods = mHasLifecycleMethods.get(klass);
if (hasLifecycleMethods != null) {
//如果本地有缓存的话则直接返回缓存值
return hasLifecycleMethods;
}
//本地还没有缓存值，以下逻辑就是来通过反射判断 klass 是否包含使用 OnLifecycleEvent 进行注解的函数
//获取 klass 包含的所有函数
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;
}
而正是在 createInfo函数内部对被注解函数的入参类型、入参顺序、入参个数等进行了限制，当不符合规定时则会在运行时直接抛出异常。
//以下三个整数值用于标记被注解的函数的入参参数的个数
//不包含入参参数
private static final int CALL_TYPE_NO_ARG = 0;
//包含一个入参参数
private static final int CALL_TYPE_PROVIDER = 1;
//包含两个入参参数
private static final int CALL_TYPE_PROVIDER_WITH_EVENT = 2;
private CallbackInfo createInfo(Class<?> klass, @Nullable Method[] declaredMethods) {
Class<?> superclass = klass.getSuperclass();
Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();
if (superclass != null) {
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;
//以下的所有逻辑是这样的：
//1. 获取 method 所对应的函数的参数个数和参数类型，即 params
//2. 如果参数个数为 0，则 callType = CALL_TYPE_NO_ARG，method 不包含入参参数
//3. 如果参数个数大于 0，则第一个参数必须是 LifecycleOwner 类型的对象，否则抛出异常
//3.1、如果参数个数为 1，则 callType = CALL_TYPE_PROVIDER
//3.2、如果参数个数为 2，则注解值 annotation 必须是 Lifecycle.Event.ON_ANY
// 且第二个参数必须是 Lifecycle.Event 类型的对象，否则抛出异常
// 如果一切都符合条件，则 callType = CALL_TYPE_PROVIDER_WITH_EVENT
//3.3、如果参数个数大于 2，则抛出异常，即要求 method 最多包含两个参数，且对参数类型和参数顺序进行了限制
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");
}
}
Lifecycle.Event event = annotation.value();
if (params.length > 1) {
callType = CALL_TYPE_PROVIDER_WITH_EVENT;
if (!params[1].isAssignableFrom(Lifecycle.Event.class)) {
throw new IllegalArgumentException(
"invalid parameter type. second arg must be an event");
}
if (event != Lifecycle.Event.ON_ANY) {
throw new IllegalArgumentException(
"Second arg is supported only for ON_ANY value");
}
}
if (params.length > 2) {
throw new IllegalArgumentException("cannot have more than 2 params");
}
MethodReference methodReference = new MethodReference(callType, method);
verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
}
CallbackInfo info = new CallbackInfo(handlerToEvent);
mCallbackMap.put(klass, info);
mHasLifecycleMethods.put(klass, hasLifecycleMethods);
return info;
}
然后最终在 MethodReference 类内部的 invokeCallback() 函数完成最终的反射调用 MethodReference 用于缓存具有 OnLifecycleEvent 注解的函数（Method）以及该函数所具有的入参个数（知道了入参个数就知道了该如何进行反射调用），通过 invokeCallback() 函数来进行 Lifecycle.Event 事件通知。
static class MethodReference {
final int mCallType;
final Method mMethod;
MethodReference(int callType, Method method) {
mCallType = callType;
mMethod = method;
mMethod.setAccessible(true);
}
void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) {
//noinspection TryWithIdenticalCatches
//根据入参个数来传递特定的参数并进行反射回调
//因此用 OnLifecycleEvent 进行注解的函数，其入参个数、入参类型、入参声明顺序都有固定的要求
//当不符合要求时会导致反射失败从而抛出异常
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);
}
}
//省略无关函数
····
}
总结
Lifecycle 的整个事件流程都在上文大致讲述完毕了，这里再来做下总结：
我们日常使用的 androidx.appcompat.app.AppCompatActivity 和 androidx.fragment.app.Fragment 都实现了 LifecycleOwner 接口，其 getLifecycle() 方法返回的 Lifecycle 对象均为 LifecycleRegistry
AppCompatActivity 默认挂载了一个无 UI 界面的 ReportFragment，ReportFragment 会根据用户手机的系统版本号高低，用不同的方式获取到 AppCompatActivity 的事件变化通知，最终调用 LifecycleRegistry 的 handleLifecycleEvent(Lifecycle.Event) 方法将 Lifecycle.Event 传递出去。此时，LifecycleRegistry 就拿到了 Lifecycle.Event
androidx.fragment.app.Fragment 会在内部直接调用 LifecycleRegistry 的 handleLifecycleEvent(Lifecycle.Event) 方法完成事件通知，此时，LifecycleRegistry 也拿到了 Lifecycle.Event
LifecycleRegistry 会将外部 addObserver 传进来的 LifecycleObserver 对象都给包装成 ObserverWithState 类内部的 LifecycleEventObserver 对象，屏蔽了外部传进来的 LifecycleObserver 的差异性（可能是接口，也可能是注解）
LifecycleRegistry 通过直接调用 ObserverWithState 类内部的 LifecycleEventObserver 对象的 onStateChanged 方法来完成最终的事件回调。至此整个流程就完成了