原文链接：https://juejin.cn/post/689387…
Android35 个内容
Jetpack5 个内容
Lifecycle1 个内容
Android 架构组件 5 个内容
一、Android Jetpack 介绍
1.1 Jetpack 是啥
官网定义如下:
Jetpack 是一个由多个库组成的套件，可帮忙开发者遵循最佳做法，缩小样板代码并编写可在各种 Android 版本和设施中统一运行的代码，让开发者精力集中编写重要的代码。
JetPack 更多是一种概念和态度，它是谷歌开发的非 Android Framework SDK 自带、但同时是 Android 开发必备的 / 举荐的 SDK/ 开发标准合集。相当于 Google 把本人的 Android 生态重新整理了一番，确立了 Android 将来的开发大方向。
应用 Jetpack 有如下益处：
- 遵循最佳做法 ，Android Jetpack 组件采纳最新的设计办法构建，具备向后兼容性，能够缩小解体和内存泄露。
- 打消样板代码 ，Android Jetpack 能够治理各种繁琐的 Activity（如后台任务、导航和生命周期治理），以便您能够专一于打造杰出的利用。
- 缩小不统一 ，这些库可在各种 Android 版本和设施中以统一的形式运作，助您升高复杂性。
Jetpack 原意为 喷气背包，Android 背上 Jetpack 后就直冲云霄，这很形象了~
也就是，Jetpack 是帮忙开发者高效开发利用的工具集。那么这一工具蕴含了哪些内容呢？
1.2 Jetpack 分类
分类如下图（当初官网曾经找不到这个图了）：
Android Jetpack 组件笼罩以下 4 个方面：架构（Architecture）、根底（Foundation）、行为（Behavior）、界面（UI）。
真正的精髓次要是 Architecture，全称是 Android Architecture Component（AAC），即 Android 架构组件 。
其包含比拟胜利的 Lifecycle、LiveData、ViewModel，同时也是咱们应用 MVVM 模式的最好框架工具，能够组合应用，也能够独自应用。
以上根本都是官网的介绍，咱们次要指标就是把握 AAC 的组件，深刻了解进而使用到 MVVM 架构中。
如题，咱们学习 Jetpack 的重点就是 AAC，这篇就从根底的 Lifecycle 讲起。
二、Lifecycle
Lifecycle，顾名思义，是用于帮忙开发者治理 Activity 和 Fragment 的生命周期，它是 LiveData 和 ViewModel 的根底。上面就先介绍为何及如何应用 Lifecycle。
2.1 Lifecycle 之前
官网文档有个例子 来阐明应用 Lifecycle 之前是如何生命周期治理的：
假如咱们有一个在屏幕上显示设施地位的 Activity。常见的实现可能如下所示：
class MyLocationListener {public MyLocationListener(Context context, Callback callback) {// ...}
void start() {// 连贯零碎定位服务}
void stop() {// 断开零碎定位服务}
}
class MyActivity extends AppCompatActivity {
private MyLocationListener myLocationListener;
@Override
public void onCreate(...) {myLocationListener = new MyLocationListener(this, (location) -> {// 更新 UI});
}
@Override
public void onStart() {super.onStart();
myLocationListener.start();
// 治理其余须要响应 activity 生命周期的组件
}
@Override
public void onStop() {super.onStop();
myLocationListener.stop();
// 治理其余须要响应 activity 生命周期的组件
}
} 尽管此示例看起来没问题，但在实在的利用中，最终会有太多治理界面和其余组件的调用，以响应生命周期的以后状态。治理多个组件会在生命周期办法（如 onStart() 和 onStop()）中搁置大量的代码，这使得它们难以保护。
此外，无奈保障组件会在 Activity 或 Fragment 进行之前启动 myLocationListener。在咱们须要执行长时间运行的操作（如 onStart() 中的某种配置查看）时尤其如此。在这种状况下，myLocationListener 的 onStop() 办法会在 onStart() 之前调用，这使得组件留存的工夫比所需的工夫要长，从而导致内次透露。如下：
class MyActivity extends AppCompatActivity {
private MyLocationListener myLocationListener;
public void onCreate(...) {
myLocationListener = new MyLocationListener(this, location -> {// 更新 UI});
}
@Override
public void onStart() {super.onStart();
Util.checkUserStatus(result -> {// 如果 checkUserStatus 耗时较长，在 activity 进行后才回调，那么 myLocationListener 启动后就没方法走 stop() 办法了，// 又因为 myLocationListener 持有 activity，所以会造成内存透露。if (result) {myLocationListener.start();
}
});
}
@Override
public void onStop() {super.onStop();
myLocationListener.stop();}
} 即 2 个问题点：
- activity 的生命周期内有大量治理组件的代码，难以保护。
- 无奈保障组件会在 Activity/Fragment 进行后不执行启动
Lifecycle 库 则能够 以弹性和隔离的形式解决这些问题。
2.2 Lifecycle 的应用
Lifecycle 是一个库，也蕴含 Lifecycle 这样一个类，Lifecycle 类 用于存储无关组件（如 Activity 或 Fragment）的生命周期状态的信息，并容许其余对象察看此状态。
2.2.1 引入依赖
1、 非 androidX 我的项目 引入:
implementation "android.arch.lifecycle:extensions:1.1.1"增加这一句代码就依赖了如下的库:
2、androidX 我的项目 引入:
如果我的项目曾经依赖了 AndroidX:
implementation 'androidx.appcompat:appcompat:1.2.0'那么咱们就能够应用 Lifecycle 库了，因为 appcompat 依赖了 androidx.fragment，而 androidx.fragment 下依赖了 ViewModel 和 LiveData，LiveData 外部又依赖了 Lifecycle。
如果想要独自引入依赖，则如下：
在我的项目根目录的 build.gradle 增加 google() 代码库，而后 app 的 build.gradle 引入依赖，官网给出的依赖如下：
// 根目录的 build.gradle
repositories {google()
...
}
//app 的 build.gradle
dependencies {
def lifecycle_version = "2.2.0"
def arch_version = "2.1.0"
// ViewModel
implementation "androidx.lifecycle:lifecycle-viewmodel:$lifecycle_version"
// LiveData
implementation "androidx.lifecycle:lifecycle-livedata:$lifecycle_version"
// 只有 Lifecycles (不带 ViewModel or LiveData)
implementation "androidx.lifecycle:lifecycle-runtime:$lifecycle_version"
// Saved state module for ViewModel
implementation "androidx.lifecycle:lifecycle-viewmodel-savedstate:$lifecycle_version"
// lifecycle 注解处理器
annotationProcessor "androidx.lifecycle:lifecycle-compiler:$lifecycle_version"
// 替换 - 如果应用 Java8, 就用这个替换下面的 lifecycle-compiler
implementation "androidx.lifecycle:lifecycle-common-java8:$lifecycle_version"
// 以下按需引入
// 可选 - 帮忙实现 Service 的 LifecycleOwner
implementation "androidx.lifecycle:lifecycle-service:$lifecycle_version"
// 可选 - ProcessLifecycleOwner 给整个 app 过程 提供一个 lifecycle
implementation "androidx.lifecycle:lifecycle-process:$lifecycle_version"
// 可选 - ReactiveStreams support for LiveData
implementation "androidx.lifecycle:lifecycle-reactivestreams:$lifecycle_version"
// 可选 - Test helpers for LiveData
testImplementation "androidx.arch.core:core-testing:$arch_version"
} 看着有很多，实际上如果只应用 Lifecycle，只须要引入 lifecycle-runtime 即可。但通常都是和 ViewModel、LiveData 配套应用的，所以 lifecycle-viewmodel、lifecycle-livedata 个别也会引入。
另外，lifecycle-process 是给整个 app 过程提供一个 lifecycle，会面也会提到。
2.2.2 应用办法
Lifecycle 的应用很简略：
- 1、生命周期拥有者 应用 getLifecycle() 获取 Lifecycle 实例，而后代用 addObserve() 增加观察者；
- 2、观察者实现 LifecycleObserver，办法上应用 OnLifecycleEvent 注解关注对应生命周期，生命周期触发时就会执行对应办法；
2.2.2.1 根本应用
在 Activity（或 Fragment）中 个别用法如下：
public class LifecycleTestActivity extends AppCompatActivity {
private String TAG = "Lifecycle_Test";
@Override
protected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);
setContentView(R.layout.activity_lifecycle_test);
//Lifecycle 生命周期
getLifecycle().addObserver(new MyObserver());
Log.i(TAG, "onCreate:");
}
@Override
protected void onResume() {super.onResume();
Log.i(TAG, "onResume:");
}
@Override
protected void onPause() {super.onPause();
Log.i(TAG, "onPause:");
}
}Activity（或 Fragment）是生命周期的拥有者，通过 getLifecycle() 办法获取到生命周期 Lifecycle 对象，Lifecycle 对象应用 addObserver 办法 给本人增加观察者，即 MyObserver 对象。当 Lifecycle 的生命周期发生变化时，MyObserver 就能够感知到。
MyObserver 是如何应用生命周期的呢？看下 MyObserver 的实现：
public class MyObserver implements LifecycleObserver {
private String TAG = "Lifecycle_Test";
@OnLifecycleEvent(value = Lifecycle.Event.ON_RESUME)
public void connect(){Log.i(TAG, "connect:");
}
@OnLifecycleEvent(value = Lifecycle.Event.ON_PAUSE)
public void disConnect(){Log.i(TAG, "disConnect:");
}
}首先 MyObserver 实现了接口 LifecycleObserver，LifecycleObserver 用于标记一个类是生命周期观察者。而后在 connectListener()、disconnectListener() 上 别离都加了 @OnLifecycleEvent 注解，且 value 别离是 Lifecycle.Event.ON_RESUME、Lifecycle.Event.ON_PAUSE，这个成果就是：connectListener() 会在 ON_RESUME 时执行，disconnectListener() 会在 ON_PAUSE 时执行。
咱们关上 LifecycleTestActivity 而后退出，日志打印如下：
2020-11-09 17:25:40.601 4822-4822/com.hfy.androidlearning I/Lifecycle_Test: onCreate:
2020-11-09 17:25:40.605 4822-4822/com.hfy.androidlearning I/Lifecycle_Test: onResume:
2020-11-09 17:25:40.605 4822-4822/com.hfy.androidlearning I/Lifecycle_Test: connect:
2020-11-09 17:25:51.841 4822-4822/com.hfy.androidlearning I/Lifecycle_Test: disConnect:
2020-11-09 17:25:51.841 4822-4822/com.hfy.androidlearning I/Lifecycle_Test: onPause: 可见 MyObserver 的办法 的确是在对应关注的生命周期触发时调用。当然注解中的 value 你也写成其它 你关注的任何一个生命周期，例如 Lifecycle.Event.ON_DESTROY。
2.2.2.2 MVP 架构中的应用
如果是 在 MVP 架构中 ，那么就能够把 presenter 作为观察者：
public class LifecycleTestActivity extends AppCompatActivity implements IView {
private String TAG = "Lifecycle_Test";
@Override
protected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);
setContentView(R.layout.activity_lifecycle_test);
//Lifecycle 生命周期
// getLifecycle().addObserver(new MyObserver());
//MVP 中应用 Lifecycle
getLifecycle().addObserver(new MyPresenter(this));
Log.i(TAG, "onCreate:");
}
@Override protected void onResume() {super.onResume();
Log.i(TAG, "onResume:");
}
@Override
protected void onPause() {super.onPause();
Log.i(TAG, "onPause:");
}
@Override
public void showView() {}
@Override public void hideView() {}
}
//Presenter
class MyPresenter implements LifecycleObserver {
private static final String TAG = "Lifecycle_Test";
private final IView mView;
public MyPresenter(IView view) {mView = view;}
@OnLifecycleEvent(value = Lifecycle.Event.ON_START)
private void getDataOnStart(LifecycleOwner owner){Log.i(TAG, "getDataOnStart:");
Util.checkUserStatus(result -> {
//checkUserStatus 是耗时操作，回调后查看以后生命周期状态
if (owner.getLifecycle().getCurrentState().isAtLeast(STARTED)) {start();
mView.showView();}
});
}
@OnLifecycleEvent(value = Lifecycle.Event.ON_STOP)
private void hideDataOnStop(){Log.i(TAG, "hideDataOnStop:");
stop();
mView.hideView();}
}
//IView
interface IView {void showView();
void hideView();}这里是让 Presenter 实现 LifecycleObserver 接口，同样在办法上注解要触发的生命周期，最初在 Activity 中作为观察者增加到 Lifecycle 中。
这样做益处是啥呢？当 Activity 生命周期发生变化时，MyPresenter 就能够感知并执行办法，不须要在 MainActivity 的多个生命周期办法中调用 MyPresenter 的办法了。
- 所有办法调用操作都由组件自身治理 ：Presenter 类主动感知生命周期，如果须要在其余的 Activity/Fragment 也应用这个 Presenter，只需增加其为观察者即可。
- 让各个组件存储本人的逻辑，加重 Activity/Fragment 中代码，更易于治理 ；
—— 下面提到的第一个问题点就解决了。
另外，留神到 getDataOnStart() 中耗时校验回调后，对以后生命周期状态进行了查看：至多处于 STARTED 状态才会继续执行 start() 办法，也就是保障了 Activity 进行后不会走 start() 办法；
—— 下面提到的第二个问题点也解决了。
2.2.3 自定义 LifecycleOwner
在 Activity 中调用 getLifecycle() 能获取到 Lifecycle 实例，那 getLifecycle() 是哪里定义的办法呢？是接口 LifecycleOwner，顾明来思义，生命周期拥有者：
/**
* 生命周期拥有者
* 生命周期事件可被 自定义的组件 用来 解决生命周期事件的变动，同时不会在 Activity/Fragmen 中写任何代码
*/
public interface LifecycleOwner {
@NonNull
Lifecycle getLifecycle();}Support Library 26.1.0 及以上、AndroidX 的 Fragment 和 Activity 已实现 LifecycleOwner 接口，所以咱们在 Activity 中能够间接应用 getLifecycle()。
如果有一个自定义类并心愿使其成为 LifecycleOwner，能够应用 LifecycleRegistry 类，它是 Lifecycle 的实现类，但须要将事件转发到该类：
public class MyActivity extends Activity implements LifecycleOwner {
private LifecycleRegistry lifecycleRegistry;
@Override
protected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);
lifecycleRegistry = new LifecycleRegistry(this);
lifecycleRegistry.markState(Lifecycle.State.CREATED);
}
@Override
public void onStart() {super.onStart();
lifecycleRegistry.markState(Lifecycle.State.STARTED);
}
@NonNull
@Override
public Lifecycle getLifecycle() {return lifecycleRegistry;}
}MyActivity 实现 LifecycleOwner，getLifecycle() 返回 lifecycleRegistry 实例。lifecycleRegistry 实例则是在 onCreate 创立，并且在各个生命周期内调用 markState() 办法实现生命周期事件的传递。这就实现了 LifecycleOwner 的自定义，也即 MyActivity 变成了 LifecycleOwner，而后就能够和 实现了 LifecycleObserver 的组件配合应用了。
补充一点， 观察者的办法能够承受一个参数 LifecycleOwner，就能够用来获取以后状态、或者持续增加观察者。若注解的是 ON_ANY 还能够接管 Event，用于辨别是哪个事件。如下：
class TestObserver implements LifecycleObserver {@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
void onCreated(LifecycleOwner owner) {// owner.getLifecycle().addObserver(anotherObserver);
// owner.getLifecycle().getCurrentState();
}
@OnLifecycleEvent(Lifecycle.Event.ON_ANY)
void onAny(LifecycleOwner owner, Lifecycle.Event event) {// event.name()
}
}2.3 Application 生命周期 ProcessLifecycleOwner
之前对 App 进入前后台的判断是通过 registerActivityLifecycleCallbacks(callback) 办法，而后在 callback 中利用一个全局变量做计数，在 onActivityStarted() 中计数加 1，在 onActivityStopped 办法中计数减 1，从而判断前后台切换。
而应用 ProcessLifecycleOwner 能够间接获取利用前后台切换状态。（记得先引入 lifecycle-process 依赖）
应用形式和 Activity 中相似，只不过要应用 ProcessLifecycleOwner.get() 获取 ProcessLifecycleOwner，代码如下：
public class MyApplication extends Application {
@Override
public void onCreate() {super.onCreate();
// 注册 App 生命周期观察者
ProcessLifecycleOwner.get().getLifecycle().addObserver(new ApplicationLifecycleObserver()); }
/**
* Application 生命周期察看，提供整个利用过程的生命周期
*
* Lifecycle.Event.ON_CREATE 只会散发一次，Lifecycle.Event.ON_DESTROY 不会被散发。*
* 第一个 Activity 进入时，ProcessLifecycleOwner 将分派 Lifecycle.Event.ON_START, Lifecycle.Event.ON_RESUME。* 而 Lifecycle.Event.ON_PAUSE, Lifecycle.Event.ON_STOP，将在最初一个 Activit 退出后后提早散发。如果因为配置更改而销毁并从新创建活动，则此提早足以保障 ProcessLifecycleOwner 不会发送任何事件。*
* 作用：监听应用程序进入前台或后盾
*/
private static class ApplicationLifecycleObserver implements LifecycleObserver {@OnLifecycleEvent(Lifecycle.Event.ON_START)
private void onAppForeground() {Log.w(TAG, "ApplicationObserver: app moved to foreground");
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
private void onAppBackground() {Log.w(TAG, "ApplicationObserver: app moved to background");
}
}
}看到的确很简略，和后面 Activity 的 Lifecycle 用法简直一样，而咱们应用 ProcessLifecycleOwner 就显得很优雅了。生命周期散发逻辑已在正文里阐明。
三、源码剖析
Lifecycle 的应用很简略，接下来就是对 Lifecycle 原理和源码的解析了。
咱们能够先猜下原理：LifecycleOwner（如 Activity）在生命周期状态扭转时（也就是生命周期办法执行时），遍历观察者，获取每个观察者的办法上的注解，如果注解是 @OnLifecycleEvent 且 value 是和生命周期状态统一，那么就执行这个办法。这个猜想正当吧？上面你来看看。
3.1 Lifecycle 类
先来瞅瞅 Lifecycle：
public abstract class Lifecycle {
// 增加观察者
@MainThread public abstract void addObserver(@NonNull LifecycleObserver observer);
// 移除观察者
@MainThread public abstract void removeObserver(@NonNull LifecycleObserver observer);
// 获取以后状态
public abstract State getCurrentState();
// 生命周期事件，对应 Activity 生命周期办法
public enum Event {
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY // 能够响应任意一个事件
}
// 生命周期状态.（Event 是进入这种状态的事件）public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
// 判断至多是某一状态
public boolean isAtLeast(@NonNull State state) {return compareTo(state) >= 0;
}
}Lifecycle 应用两种次要枚举跟踪其关联组件的生命周期状态：
- Event，生命周期事件，这些事件对应 Activity/Fragment 生命周期办法。
- State，生命周期状态，而 Event 是指进入一种状态的事件。Event 触发的机会：
- ON_CREATE、ON_START、ON_RESUME 事件，是在 LifecycleOwner 对应的办法执行 之后 散发。
- ON_PAUSE、ON_STOP、ON_DESTROY 事件，是在 LifecycleOwner 对应的办法调用 之前 散发。这保障了 LifecycleOwner 是在这个状态内。
官网有个图很清晰：
3.2 Activity 对 LifecycleOwner 的实现
后面提到 Activity 实现了 LifecycleOwner，所以能力间接应用 getLifecycle()，具体是在 androidx.activity.ComponentActivity 中:
//androidx.activity.ComponentActivity，这里疏忽了一些其余代码，咱们只看 Lifecycle 相干 public class ComponentActivity extends androidx.core.app.ComponentActivity implements LifecycleOwner{ ...
private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
...
@Override protected void onCreate(@Nullable Bundle savedInstanceState) {super.onCreate(savedInstanceState);
mSavedStateRegistryController.performRestore(savedInstanceState);
ReportFragment.injectIfNeededIn(this); // 应用 ReportFragment 散发生命周期事件
if (mContentLayoutId != 0) {setContentView(mContentLayoutId);
}
}
@CallSuper
@Override
protected void onSaveInstanceState(@NonNull Bundle outState) {Lifecycle lifecycle = getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {((LifecycleRegistry) lifecycle).setCurrentState(Lifecycle.State.CREATED);
}
super.onSaveInstanceState(outState);
mSavedStateRegistryController.performSave(outState);
}
@NonNull
@Override
public Lifecycle getLifecycle() {return mLifecycleRegistry;}
}这里疏忽了一些其余代码，咱们只看 Lifecycle 相干。
看到 ComponentActivity 实现了接口 LifecycleOwner，并在 getLifecycle() 返回了 LifecycleRegistry 实例。后面提到 LifecycleRegistry 是 Lifecycle 具体实现。
而后在 onSaveInstanceState() 中设置 mLifecycleRegistry 的状态为 State.CREATED，而后怎么没有了？其余生命周期办法内咋没解决？what？和猜想的不一样啊。别急，在 onCreate() 中有这么一行：ReportFragment.injectIfNeededIn(this);, 这个就是关键所在。
3.3 生命周期事件散发——ReportFragment
// 专门用于散发生命周期事件的 Fragment
public class ReportFragment extends Fragment {public static void injectIfNeededIn(Activity activity) {if (Build.VERSION.SDK_INT >= 29) {
// 在 API 29 及以上，能够间接注册回调 获取生命周期
activity.registerActivityLifecycleCallbacks(new LifecycleCallbacks());
}
//API29 以前，应用 fragment 获取生命周期
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit(); manager.executePendingTransactions();
}
}
@SuppressWarnings("deprecation")
static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) {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);// 应用 LifecycleRegistry 的 handleLifecycleEvent 办法处理事件
}
}
}
@Override
public void onActivityCreated(Bundle savedInstanceState) {super.onActivityCreated(savedInstanceState);
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);
}
... 省略 onStop、onDestroy
private void dispatch(@NonNull Lifecycle.Event event) {if (Build.VERSION.SDK_INT < 29) {dispatch(getActivity(), event);
}
}
// 在 API 29 及以上，应用的生命周期回调
static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks {
...
@Override
public void onActivityPostCreated(@NonNull Activity activity,@Nullable Bundle savedInstanceState) {dispatch(activity, Lifecycle.Event.ON_CREATE);
}
@Override
public void onActivityPostStarted(@NonNull Activity activity) {dispatch(activity, Lifecycle.Event.ON_START);
}
@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);
}
... 省略 onStop、onDestroy
}
}首先 injectIfNeededIn() 内进行了版本辨别：在 API 29 及以上 间接应用 activity 的 registerActivityLifecycleCallbacks 间接注册了生命周期回调，而后给以后 activity 增加了 ReportFragment，留神这个 fragment 是没有布局的。
而后，无论 LifecycleCallbacks、还是 fragment 的生命周期办法 最初都走到了 dispatch(Activity activity, Lifecycle.Event event) 办法，其外部应用 LifecycleRegistry 的 handleLifecycleEvent 办法处理事件。
而 ReportFragment 的作用就是获取生命周期而已，因为 fragment 生命周期是附丽 Activity 的。益处就是把这部分逻辑抽离进去，实现 activity 的无侵入。如果你对图片加载库 Glide 比拟熟，就会晓得它也是应用通明 Fragment 获取生命周期的。
3.4 生命周期事件处理——LifecycleRegistry
到这里，生命中周期事件的解决有转移到了 LifecycleRegistry 中：
//LifecycleRegistry.java
// 零碎自定义的保留 Observer 的 map，可在遍历中增删
private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap = new FastSafeIterableMap<>();
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {State next = getStateAfter(event);// 获取 event 产生之后的将要处于的状态
moveToState(next);// 挪动到这个状态
}
private void moveToState(State next) {if (mState == next) {return;// 如果和以后状态统一，不解决}
mState = next; // 赋值新状态
if (mHandlingEvent || mAddingObserverCounter != 0) {
mNewEventOccurred = true;
return;
}
mHandlingEvent = true;
sync(); // 把生命周期状态同步给所有观察者
mHandlingEvent = false;
}
private void sync() {LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {throw new IllegalStateException("LifecycleOwner of this LifecycleRegistry is already" + "garbage collected. It is too late to change lifecycle state.");
}
while (!isSynced()) {//isSynced() 意思是 所有观察者都同步完了
mNewEventOccurred = false;
//mObserverMap 就是 在 activity 中增加 observer 后 用于寄存 observer 的 map
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;
}
...
static State getStateAfter(Event event) {switch (event) {
case ON_CREATE:
case ON_STOP:
return CREATED;
case ON_START:
case ON_PAUSE:
return STARTED;
case ON_RESUME:
return RESUMED;
case ON_DESTROY:
return DESTROYED;
case ON_ANY:
break;
}
throw new IllegalArgumentException("Unexpected event value" + event);
}逻辑很清晰：应用 getStateAfter() 获取 event 产生之后的将要处于的状态（看后面那张图很好了解），moveToState() 是挪动到新状态，最初应用 sync() 把生命周期状态同步给所有观察者。
留神到 sync() 中有个 while 循环，很显然是在遍历观察者。并且很显然观察者是寄存在 mObserverMap 中的，而 mObserverMap 对观察者的增加 很显然 就是 Activity 中应用 getLifecycle().addObserver() 这里：
//LifecycleRegistry.java
@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);
//observer 作为 key，ObserverWithState 作为 value，存到 mObserverMap
if (previous != null) {return;// 曾经增加过，不解决}
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {return;//lifecycleOwner 退出了，不解决}
// 上面代码的逻辑：通过 while 循环，把新的观察者的状态 间断地 同步到最新状态 mState。// 意思就是：尽管可能增加的晚，但把之前的事件一个个分发给你 (upEvent 办法)，即粘性
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
State targetState = calculateTargetState(observer);// 计算指标状态
mAddingObserverCounter++;
while ((statefulObserver.mState.compareTo(targetState) < 0
&& mObserverMap.contains(observer))) {pushParentState(statefulObserver.mState);
statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
popParentState();
// mState / subling may have been changed recalculate
targetState = calculateTargetState(observer);
}
if (!isReentrance) {sync();
}
mAddingObserverCounter--;
}用 observer 创立带状态的观察者 ObserverWithState，observer 作为 key、ObserverWithState 作为 value，存到 mObserverMap。接着做了平安判断，最初把新的观察者的状态 间断地 同步到最新状态 mState，意思就是：尽管可能增加的晚，但会把之前的事件一个个分发给你，即粘性。
回到刚刚 sync() 的 while 循环，看看如何解决散发事件：
private void sync() {LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {Log.w(LOG_TAG, "LifecycleOwner is garbage collected, you shouldn't try dispatch "+"new events from it.");
return;
}
while (!isSynced()) {
mNewEventOccurred = false;
// no need to check eldest for nullability, because isSynced does it for us.
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;
}
private boolean isSynced() {if (mObserverMap.size() == 0) {return true;}// 最老的和最新的观察者的状态统一，都是 ower 的以后状态，阐明曾经同步完了
State eldestObserverState = mObserverMap.eldest().getValue().mState;
State newestObserverState = mObserverMap.newest().getValue().mState;
return eldestObserverState == newestObserverState && mState == newestObserverState;
}
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));//observer 获取事件
popParentState();}
}
}
private void backwardPass(LifecycleOwner lifecycleOwner) {Iterator<Entry<LifecycleObserver, ObserverWithState>> descendingIterator = mObserverMap.descendingIterator();
while (descendingIterator.hasNext() && !mNewEventOccurred) {// 反向遍历，从新到老
Entry<LifecycleObserver, ObserverWithState> entry = descendingIterator.next();
ObserverWithState observer = entry.getValue();
while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred && mObserverMap.contains(entry.getKey()))) {Event event = downEvent(observer.mState);
pushParentState(getStateAfter(event));
observer.dispatchEvent(lifecycleOwner, event);//observer 获取事件
popParentState();}
}
}循环条件是!isSynced()，若最老的和最新的观察者的状态统一，且都是 ower 的以后状态，阐明曾经同步完了。
没有同步完就进入循环体：
- mState 比最老观察者状态小，走 backwardPass(lifecycleOwner)：从新到老散发，循环应用 downEvent() 和 observer.dispatchEvent()，间断散发事件；
- mState 比最新观察者状态大，走 forwardPass(lifecycleOwner)：从老到新散发，循环应用 upEvent() 和 observer.dispatchEvent()，间断散发事件。
接着 ObserverWithState 类型的 observer 就获取到了事件，即 observer.dispatchEvent(lifecycleOwner, event)，上面来看看它是如何让加了对应注解的办法执行的。
3.5 事件回调后 办法执行
咱们持续看下 ObserverWithState:
static class ObserverWithState {
State mState;
GenericLifecycleObserver mLifecycleObserver;
ObserverWithState(LifecycleObserver observer, State initialState) {mLifecycleObserver = Lifecycling.getCallback(observer);
mState = initialState;
}
void dispatchEvent(LifecycleOwner owner, Event event) {State newState = getStateAfter(event);
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}mState 的作用是：新的事件触发后 遍历告诉所有观察者时，判断是否曾经告诉这个观察者了，即避免反复告诉。
mLifecycleObserver 是应用 Lifecycling.getCallback(observer) 获取的 GenericLifecycleObserver 实例。GenericLifecycleObserver 是接口，继承自 LifecycleObserver：
// 承受生命周期扭转并分发给真正的观察者 public interface LifecycleEventObserver extends LifecycleObserver {
// 生命周期状态变动
void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event);}也就说，LifecycleEventObserver 给 LifecycleObserver 减少了感知生命周期状态变动的能力。
看看 Lifecycling.getCallback(observer)：
@NonNull
static LifecycleEventObserver lifecycleEventObserver(Object object) {
... 省略很多类型判断的代码
return new ReflectiveGenericLifecycleObserver(object);
}办法内有很多对 observer 进行类型判断的代码，咱们这里关注的是 ComponentActivity，所以 LifecycleEventObserver 的实现类就是 ReflectiveGenericLifecycleObserver 了：
class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
private final Object mWrapped;
private final CallbackInfo mInfo;
ReflectiveGenericLifecycleObserver(Object wrapped) {
mWrapped = wrapped;
mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());// 寄存了 event 与加了注解办法的信息
}
@Override
public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Event event) {mInfo.invokeCallbacks(source, event, mWrapped);// 执行对应 event 的观察者的办法
}
}它的 onStateChanged() 办法外部应用 CallbackInfo 的 invokeCallbacks 办法，这里应该就是执行观察者的办法了。
ClassesInfoCache 外部用 Map 存了 所有观察者的回调信息，CallbackInfo 是以后观察者的回调信息。
先看下 CallbackInfo 实例的创立，ClassesInfoCache.sInstance.getInfo(mWrapped.getClass())：
//ClassesInfoCache.java
private final Map<Class, CallbackInfo> mCallbackMap = new HashMap<>();// 所有观察者的回调信息
private final Map<Class, Boolean> mHasLifecycleMethods = new HashMap<>();// 观察者是否有注解了生命周期的办法
CallbackInfo getInfo(Class<?> klass) {CallbackInfo existing = mCallbackMap.get(klass);// 如果曾经存在以后观察者回调信息 间接取
if (existing != null) {return existing;}
existing = createInfo(klass, null);// 没有就去收集信息并创立
return existing;
}
private CallbackInfo createInfo(Class<?> klass, @Nullable Method[] declaredMethods) {Class<?> superclass = klass.getSuperclass();
Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();// 生命周期事件到来 对应的办法
...
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; // 没有注解 OnLifecycleEvent 就 return}
hasLifecycleMethods = true;// 有注解 OnLifecycleEvent
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(// 第一个参数必须是 LifecycleOwner
"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(// 第二个参数必须是 Event
"invalid parameter type. second arg must be an event");
}
if (event != Lifecycle.Event.ON_ANY) {
throw new IllegalArgumentException(// 有两个参数 注解值只能是 ON_ANY
"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);// 校验办法并退出到 map handlerToEvent 中
}
CallbackInfo info = new CallbackInfo(handlerToEvent);// 获取的 所有注解生命周期的办法 handlerToEvent，结构回调信息实例
mCallbackMap.put(klass, info);// 把以后观察者的回调信息存到 ClassesInfoCache 中
mHasLifecycleMethods.put(klass, hasLifecycleMethods);// 记录 观察者是否有注解了生命周期的办法
return info;
}- 如果不存在以后观察者回调信息，就应用 createInfo() 办法收集创立
- 先反射获取观察者的办法，遍历办法 找到注解了 OnLifecycleEvent 的办法，先对办法的参数进行了校验。
- 第一个参数必须是 LifecycleOwner；第二个参数必须是 Event；有两个参数 注解值只能是 ON_ANY；参数不能超过两个
- 校验办法并退出到 map，key 是办法，value 是 Event。map handlerToEvent 是所有的注解了生命周期的办法。
- 遍历完，而后用 handlerToEvent 来结构 以后观察者回调信息 CallbackInfo，存到 ClassesInfoCache 的 mCallbackMap 中，并记录 观察者是否有注解了生命周期的办法。
整体思路还是很清晰的，持续看 CallbackInfo 的 invokeCallbacks 办法：
static class CallbackInfo {
final Map<Lifecycle.Event, List<MethodReference>> mEventToHandlers;//Event 对应的多个办法
final Map<MethodReference, Lifecycle.Event> mHandlerToEvent;// 要回调的办法
CallbackInfo(Map<MethodReference, Lifecycle.Event> handlerToEvent) {
mHandlerToEvent = handlerToEvent;
mEventToHandlers = new HashMap<>();
// 这里遍历 mHandlerToEvent 来获取 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());
}
}
@SuppressWarnings("ConstantConditions")
void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) {invokeMethodsForEvent(mEventToHandlers.get(event), source, event, target);// 执行对应 event 的办法
invokeMethodsForEvent(mEventToHandlers.get(Lifecycle.Event.ON_ANY), source, event,target);// 执行注解了 ON_ANY 的办法
}
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--) {// 执行 Event 对应的多个办法
handlers.get(i).invokeCallback(source, event, mWrapped);
}
}
}
}很好了解，执行对应 event 的办法、执行注解了 ON_ANY 的办法。其中 mEventToHandlers 是在创立 CallbackInfo 时由遍历 mHandlerToEvent 来获取，寄存了每个 Event 对应的多个办法。
最初看看 handlers.get(i).invokeCallback，即 MethodReference 中：
static class MethodReference {
...
void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) {
try {switch (mCallType) {
case CALL_TYPE_NO_ARG:
mMethod.invoke(target);// 没有参数的
break;
case CALL_TYPE_PROVIDER:
mMethod.invoke(target, source);// 一个参数的：LifecycleOwner
break;
case CALL_TYPE_PROVIDER_WITH_EVENT:
mMethod.invoke(target, source, event);// 两个参数的：LifecycleOwner，Event
break;
}
}
...
}
...
}依据不同参数类型，执行对应办法。
到这里，整个流程就残缺了。理论看了这么一大圈，基本思路和咱们的猜测是统一的。
这里借 Android Jetpack 架构组件（三）一文带你理解 Lifecycle（原理篇）的图总结下：
四、总结
本文先介绍了 Jetpack 和 AAC 的概念，这是 Android 官网举荐的通用开发工具集。其中 AAC 是架构组件，是本系列文章的介绍内容。接着介绍了 AAC 的根底组件 Lifecycle，它能让开发者更好的治理 Activity/Fragment 生命周期。最初详细分析了 Lifecycle 源码及原理。
Jetpack 的 AAC 是咱们后续开发 Android 必备常识，也是实现 MVVM 架构的根底。Lifecycle 更是 AAC 中的根底，所以残缺把握本篇内容十分必要。
文末
您的点赞珍藏就是对我最大的激励！
欢送关注我，分享 Android 干货，交换 Android 技术。
对文章有何见解，或者有何技术问题，欢送在评论区一起留言探讨！