原文链接：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() {}}//Presenterclass 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();    }}//IViewinterface 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

//专门用于散发生命周期事件的Fragmentpublic 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技术。
对文章有何见解，或者有何技术问题，欢送在评论区一起留言探讨！