Android架构灵魂组件Lifecycle的生命周期机制详解

前言：写作就跟生活相同，是一趟发现之旅。

前言

在前期 Andorid 架构中，生命周期的事情监听和状况查询，咱们需求自界说一套供给侦测功用的 Activity/Fragment 基类及回调接口，在 Activity/Fragment 的生命周期办法中完结依靠组件的操作，在外部进行事情监听和状况查询。这种办法会导致代码条理性很差而且会分散过错。

在 Lifecycle 引入后，可以防止在 Activity/Fragment 生命周期办法内写太多的业务逻辑处理代码，这样可以使咱们的业务逻辑更加解耦。有助于您编写出更有条理且往往更精简的代码，此类代码更易于维护。

什么是Lifecycle

Lifecycle 是一个具有宿主生命周期感知才能的组件。它持有组件（Activity/Fragment）生命周期状况信息，而且答应其调查者监听宿主生命周期状况改动。

一、Lifecycle的运用

在 build.gradle 文件中增加依靠：

implementation "androidx.lifecycle:lifecycle-runtime-ktx:2.5.1"
implementation "androidx.lifecycle:lifecycle-common:2.5.1"

运用 Lifecycle 调查宿主状况有三种完结办法。

1.承继LifecycleObserver

第一种是完结 LifecycleObserver 接口，选用注解办法，运用 @OnLifecycleEvent 符号自界说的办法以完结回调。

//1.自界说LifecycleObserver调查者，用注解声明每个办法调查宿主的状况
public class MyLifecycleObserver implements LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    void onStart(@NotNull LifecycleOwner owner) {
    }
    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    void onStop(@NotNull LifecycleOwner owner) {
    }
}
//2.宿主中注册调查者，调查宿主生命周期状况改动
class MyFragment extends Fragment {
    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        MyLifecycleObserver observer = new MyLifecycleObserver();
        getLifecycle().addObserver(observer);
    }
}

完结 LifecycleObserver 接口，只需求在指定办法上面符号注解，来调查宿主的生命周期，注解里边符号着生命周期事情类型就可以了。然后在宿主注册这个 LifecycleObserver，它不需求销毁的时分进行反注册。

2.完结DefaultLifecycleObserver接口

第二种办法：界说一个类，完结 DefaultLifecycleObserver 接口，里边供给了完好的生命周期事情，为一切的生命周期事情都界说了对应的回调办法。它完结了 FullLifecycleObserver 接口，运用了 default 关键字空完结了各个办法。

class MyFullLifeObserver : DefaultLifecycleObserver {
    override fun onCreate(owner: LifecycleOwner) {}
    override fun onStart(owner: LifecycleOwner) {}
    override fun onResume(owner: LifecycleOwner) {}
    override fun onPause(owner: LifecycleOwner) {}
    override fun onStop(owner: LifecycleOwner) {}
    override fun onDestroy(owner: LifecycleOwner) {}
}

运用 DefaultLifecycleObserver 后，就需求把注解完结相关逻辑移除。即便保留注解，由于 Lifecycling 的处理逻辑（体系架构逻辑中一切传入的调查者都会经过 Lifecycling 处理，下面会解说到），任何 FullLifecycleObserver 的完结类 (即包含DefaultLifecycleObserver) 内部一切的 @OnLifecycleEvent 注解都会失效。

3.完结LifecycleEventObserver

第三种办法：完结 LifecycleEventObserver，它是 LifecycleObserver 的子接口。只有一个 onStateChanged 办法，以 Lifecycle.Event 入参供给事情区别的办法，进行统一办法回调。

interface LifecycleEventObserver : LifecycleObserver {
    // 宿主生命周期改动的事情都会通知到这个办法
    fun onStateChanged(owner: LifecycleOwner?, event: Lifecycle.Event?)
}
//承继自LifecycleEventObserver，复写onStateChanged办法
class MyLifecycleEventObserver : LifecycleEventObserver {
    override fun onStateChanged(owner: LifecycleOwner?, event: Lifecycle.Event?) {
        //需求自行判别Event是onStart仍是onStop
    }
}

不管哪一种办法都需求在宿主中注册调查者。引荐运用第二种和第三种办法，第一种不引荐运用。

二、Lifecycle 组件架构

为下面更好深化了解原理，咱们先来简略了解下 Lifecycle 组件中几个重要的类：

Lifecycle(生命周期) ：一个中心笼统类，用于存储有关组件（如 activity/fragment 的生命周期状况的信息，并答应其他方针调查此状况。承继该类的子类，表明自身是一个具有Android生命周期特性的方针。
LifecycleOwner：中心接口，Lifecycle 持有者，该接口的完结类表明可以为外部供给Lifecycle实例。具有 Android 生命周期的类。这些事情可以被自界说组件用来处理生命周期的改动，而不需求在 Activity/Fragment 中完结任何代码。
LifecycleRegistry：中心类，Lifecycle 的完结类，可以处理多个调查者。完结 Lifecycle 界说生命周期调查订阅，生命周期查询的办法。还完结了架构中，生命周期改动时触发的自身状况处理和相关对调查者的订阅回调的逻辑。
LifecycleObserver：调查者，将一个类符号为生命周期调查者。完结该接口的类，经过注解的办法，可以经过被 LifecycleOwner 类的 addObserver() 办法注册，LifecycleObserver 便可以调查到 LifecycleOwner 的生命周期事情。
State ：当时生命周期所在的状况。
Event ：当时生命周期改动对应的事情。从结构和Lifecycle 类分配的生命周期事情。这些事情对应到 activity/fragment 中的回调事情。

LifecyclerOwner、Lifecycle、LifecyleRegistry 和 Observer 的联系如下图：

一般来说宿主代表着 Activity/Fragment，都完结了 LifecyclerOwner 接口；那么每个宿主有必要复写 getLifecycle()，而且回来一个 Lifecycle 方针，这个 Lifecycle 方针实践上是LifecycleRegistry，只不过它选用的是面向接口的编程办法，咱们对 LifecycleRegistry 注册 Observer 的时分，可以是 LifecycleObserver，FullLifecyclerOberver，LifecyclerEventObserver。

三、Lifecycle 原理剖析

体系结构中，LifecycleOwner 接口的完结类为 ComponentActivity 和 Fragment，两者供给的 Lifecycle 方针，是体系结构完结中 Lifecycle 的唯一子类 LifecycleRegistry。

1.Fragment是怎么完结Lifecycle的

public class Fragment implements LifecycleOwner {
    // 创立LifecycleRegistry 而且把this传递进去
    LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
    @Override
    public Lifecycle getLifecycle() {
        //2.复写自LifecycleOwner,所以有必要new LifecycleRegistry方针回来
        return mLifecycleRegistry;
    }
    //
}

Fragment 内 Lifecycle 中心代码片段，完结了 LifecycleOwner 接口，它表明生命周期宿主，持有生命周期(Lifecycle方针)，该接口的生命周期的改动会被其注册的调查者 LifecycleObserver 调查到并触发其对应的事情。

有必要复写 getLifecycle() 这个办法，回来的实践是 mLifecycleRegistry，阐明 Lifecycle 是 LifecycleRegistry 的父类，这是一种面向接口的编程思维。

public class Fragment implements LifecycleOwner {
    //
    void performCreate(Bundle savedInstanceState) {
        //
        onCreate(savedInstanceState);
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
    }
    void performStart() {
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START);
    }
    void performResume() {
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_RESUME);
    }
    void performPause() {
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_PAUSE);
    }
    void performStop() {
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);
    }
    void performDestroy() {
        mChildFragmentManager.dispatchDestroy();
        mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_DESTROY);
        //
     }
}

咱们注册 Lifecycle 的时分，实践上都注册到 LifecycleRegistry 里边去了。经过 handleLifecycleEvent() 分发自己的状况到每个调查者，然后完结调查生命周期完结改动的才能。看起来简略实践上 Lifecycle 在分产生命周期的时分并不简略，一切逻辑重点都在 LifecycleRegistry。

Fragment 是怎么派产生命周期的？也便是它会在自己生命周期里边，让 LifecycleRegistry 去分产生命周期事情，给每一个调查者。可是 Activity 中并不是这么做的。

2.Activity是怎么是完结Lifecycle的

Activity 完结 Lifecycle 的中心源码，需求来到 ComponentActivity 里边，同样也是完结了 LifecycleOwner 接口：

public class ComponentActivity extends Activity implements LifecycleOwner {
    private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
    //复写getLifecycle()，回来LifecycleRegistry方针
    @Override
    public Lifecycle getLifecycle() {
        return mLifecycleRegistry;
    }
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        //往Activity上增加一个fragment，用以陈述生命周期的改动
        //目的是为了统筹不是承继自AppCompactActivity的场景
        ReportFragment.injectIfNeededIn(this);
    }
}

与上面 Fragment 的完结类似，它完结了 LifecycleOwner，表明一个生命周期的宿主，有必要完结 getLifecycle() 办法，回来一个 Lifecycle，也便是 LifecycleRegistry。

可是在 ComponentActivity 里边并没有在它的每个生命周期办法里边把它的状况分发给一个调查者，可是在 onCreate() 办法里边调用 ReportFragment.injectIfNeededIn(this) 这种做法实践上是往自己里边增加了一个不可见的 Fragment，专门用于陈述分发给每个调查者。

public class ReportFragment extends Fragment {
    public static void injectIfNeededIn (Activity activity) {
        if (Build.VERSION.SDK_INT >= 29) {
            // API 29 以上可以直接注册正确的生命周期回调
            activity.registerActivityLifecycleCallbacks(
                new LifecycleCallbacks ()
            );
        }
        // 兼容API 29之前的，需求支撑直接承继Activity的，运用Fragment来正确取得生命周期事情
        android.app.FragmentManager manager = activity . getFragmentManager ();
        if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
            manager.beginTransaction().add(new ReportFragment (), REPORT_FRAGMENT_TAG).commit();
            manager.executePendingTransactions();
        }
    }
}

所以 Activity 事情的分发是依靠 ReportFragment 来完结的。

API 29 以下: 首要是经过 ReportFragment 将自身增加到 Activity 中完结。
API 29 及以上：Activity 中增加一组 ActivityLifecycleCallbacks 的相关办法，可以直接经过注册 ActivityLifecycleCallbacks 调查生命周期。

ComponentActivity 为什么这么做而不直接在 Activity 内部直接分发呢？首要是为了统筹不是承继自 AppCompatActivity 的场景。有可能是直接承继自 Activity，然后自己完结了 Lifecycle 接口。

public class ReportFragment extends Fragment {
    // 增加dispatch重载，测验获取Activity中的LifecycleRegistry并调用 handleLifecycleEvent
    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);
            }
        }
    }
    // 2.各个生命周期办法里边都调用了dispatch()办法
    @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);
    }
    //
    // 3.拿到Activity的Lifecycle方针，把当时的事情分发给每个调查者
    private void dispatch(@NonNull Lifecycle.Event event) {
        if (Build.VERSION.SDK_INT < 29) {
            // 在API 29之前从ReportFragment分配事情。
            // 在API 29+上，由reportfragment.injectifneededdin中增加的activitylifecyecallbacks处理
            dispatch(getActivity(), event);
        }
    }
}

为了前向兼容，ReportFragment 仍然会被增加到 Activity，并在 dispatch() 中增加过滤防止呈现二次调用。

ReportFragment 会在侦测到 Activity 生命周期改动的时分调用 LifecycleRegistry.handleLifecycleEvent() 传入对应的状况。这时分会有一个类 LifecycleDispatcher:

//挂钩到Activity的回调并进行调查
class LifecycleDispatcher {
    private static AtomicBoolean sInitialized = new AtomicBoolean(false);
    static void init(Context context) {
        ((Application) context.getApplicationContext())
                .registerActivityLifecycleCallbacks(new DispatcherActivityCallback());
    }
    static class DispatcherActivityCallback extends EmptyActivityLifecycleCallbacks {
        @Override
        public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
            // 监听到每个Activity翻开的事情
            ReportFragment.injectIfNeededIn(activity);
        }
    }
}

在它的 init() 办法里边调用了 registerActivityLifecycleCallbacks()，这儿就能督查到每个 Activity 翻开的事情，会再次利用 ReportFragment.injectIfNeededIn(activity)，也便是说往每个 Activity 里边注册一个 ReportFragment，用于分发和陈述当时宿主的生命周期到每个调查者，它这儿是以一个切面编程的办法注入了一个 Fragment 方针，尽管咱们是承继子 Activity，只需你完结了 LifecycleOwner 的接口，也能具有生命周期分发的才能。所以 Activity 生命周期分发的功用提取到 ReportFragment 里边，首要是为了不是承继自 AppCompatActivity 的场景。

到这儿 Activity/Fragment 各自是怎么完结 Lifecycle 才能的现已剖析完结。可是不管怎么生命周期才能都是依靠 LifecycleRegistry 来完结的。

3.LifecycleRegistry 源码剖析

它是 Lifecycle 的完结，可以处理多个调查者。生命周期事情分发都是依靠 LifecycleRegistry 来完结的。先从增加调查者办法开端：

@Override
public void addObserver(@NonNull LifecycleObserver observer) {
    enforceMainThreadIfNeeded("addObserver");
    // 1.初始化状况，当时宿主的状况
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
    // 2.将observer封装成 ObserverWithState，是一个具有宿主状况的调查者
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
    // 增加到Map调集中
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
    boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
    // 3.核算出它应该抵达的状况，也便是当时宿主的状况
    State targetState = calculateTargetState(observer);
    mAddingObserverCounter++;
    // 4.在while()循环中，会让当时的调查者的状况从init状况行进到当时宿主的状况
    //Observer的状况与targetState比较，假如小于0阐明调查者的状况还没有抵达targetState的状况
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        pushParentState(statefulObserver.mState);
        // 5.让Observer的状况行进到targetState
        final Event event = Event.upFrom(statefulObserver.mState);
        // 6. 分发事情
        statefulObserver.dispatchEvent(lifecycleOwner, event);
        popParentState();
        // 重新核算mState
        targetState = calculateTargetState(observer);
    }
    if (!isReentrance) {
        //同步状况
        sync();
    }
}

在 addObserver(observer) 里边，初始化状况，而且把observer封装成一个ObserverWithState，一个具有宿主状况的调查者，然后增加到Map调集傍边。

这儿首要做了四件事：

初始化状况，将 observer 封装成 ObserverWithState，是一个具有初始状况的调查者；
核算出它应该抵达的状况，也便是当时宿主的状况；
while 循环会让当时的调查者的状况从 INITIALIZED 状况行进到当时宿主的状况，Observer 的状况小于 targetState 阐明调查者的状况还没有抵达 targetState 的状况，那么就会让 Observer 的状况行进到 targetState；
Observe 调用 dispatchEvent() 分发事情。

每个进程都很重要，咱们来逐个剖析：

4.状况与事情

State 是一个枚举，表明宿主的状况，可是宿主的状况和宿主的生命周期不是同一个概念。

public enum State {
    // 宿主的销毁状况，onDestory()之后
    DESTROYED,
    // 宿主的初始状况，onCreate()之前
    INITIALIZED,
    // 宿主的创立状况，onCreate()之后，onStop()之前
    CREATED,
    // 宿主的启动状况，onStart()之后，onPasue()之前
    STARTED,
    // 恢复状况，onResume()之后
    RESUMED;
}

比方宿主切换到后台，会履行 onPause() 办法，那么宿主的状况是什么状况？再从后台切回前台会履行 onStart() 再履行 onResum()，所以切换到后台的时分，履行了 onPause 这个事情，它的状况会变成 STARTED 的状况。可以看到它是没有 PAUSE 状况的。

这儿还界说了 Event 事情，一个枚举，表明生命周期事情。它与宿主的生命周期逐个对应。

public enum Event {
     //LifecycleOwner的onCreate事情的常量
    ON_CREATE,
     //LifecycleOwner的onStart事情的常量
    ON_START,
     //LifecycleOwner的onResume事情的常量
    ON_RESUME,
     //LifecycleOwner的onPause事情的常量
    ON_PAUSE,
     //LifecycleOwner的onStop事情的常量
    ON_STOP,
     //LifecycleOwner的onDestroy事情的常量
    ON_DESTROY,
     //可以匹配一切事情的常量
    ON_ANY
}

宿主生命周期与宿主状况联系图：

宿主在创立之初肯定是处于 INITIALIZED 状况，履行了 onCreate() 办法之后就会进入 CREATED 状况，接着履行了 onStart() 办法之后就会进入 STARTED 状况，履行了 onResume() 就会进入 RESUMED 状况，这是生命周期行进的进程，生命周期后退进程同理。这儿便是宿主的生命周期状况和事情完好的流程。

5.状况比较和升降级

回到 addObserver() 办法中：

@Override
public void addObserver(@NonNull LifecycleObserver observer) {
    enforceMainThreadIfNeeded("addObserver");
    // 1.获取observer需求设置的初始状况
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
    // 2.将observer封装成 ObserverWithState，并绑定初始的生命周期状况
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
    // 增加到Map调集中
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
    boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
    // 3.核算出它应该抵达的方针状况
    State targetState = calculateTargetState(observer);
    mAddingObserverCounter++;
    // 4.在while()循环中，会让当时的调查者的状况从init状况行进到方针状况
    //Observer的状况与targetState比较，假如小于0阐明调查者的状况还没有抵达targetState的状况
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        pushParentState(statefulObserver.mState);
        // 5.让Observer的状况晋级到targetState
        final Event event = Event.upFrom(statefulObserver.mState);
        // 6. 分发事情，同步状况
        statefulObserver.dispatchEvent(lifecycleOwner, event);
        popParentState();
        // 重新核算mState
        targetState = calculateTargetState(observer);
    }
    if (!isReentrance) {
        //同步状况
        sync();
    }
}

在初始状况中，只需不是在 onDestory 注册的 Observer，每个调查者的初始状况都是 INITIALIZED 状况。在 while 循环中，会让当时的调查者的状况从 INITIALIZED 状况晋级到方针状况，假如调查者的状况小于方针状况，就会经过 Event.upFrom() 办法让生命周期晋级。

比方咱们在 onResme() 办法中注册一个调查者，那么它会接收到哪几种状况呢？INITIALIZED、ONSTART、ONRESUME 它都会有，这个逻辑就在 while 循环里边，先经过 calculateTargetState(observer) 核算出它应该抵达的方针状况，也便是当时宿主的状况，然后会拿 Observer 的状况比较，假如小于0阐明调查者的状况还没有抵达 targetState 的状况，那么就会让 Observer 的状况晋级到 targetState。那么是怎么进行晋级的呢？

// 核算传入状况晋级所对应的事情
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;
    }
}

脱离当时的状况抵达更高的状况，事情的状况从较低向上晋级。在 INITIALIZED 状况中接收的是 on_Create 事情，然后来到 dispatchEvent() 办法里边：

static class ObserverWithState {
    // 当时状况
    State mState;
    // Observer封装
    LifecycleEventObserver mLifecycleObserver;
    ObserverWithState(LifecycleObserver observer, State initialState) {
        mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
        mState = initialState;
    }
    //事情分发逻辑
    void dispatchEvent(LifecycleOwner owner, Event event) {
        //依据Event获取方针状况
        State newState = event.getTargetState();
        // 获取最小状况
        mState = min(mState, newState);
        // 状况改动回调
        mLifecycleObserver.onStateChanged(owner, event);
        // 更新当时状况
        mState = newState;
    }
}

会依据 Event 反推出方针状况，在 event.getTargetState() 里边，假如 Event 事情是 ON_CREATE 那么就会抵达 State.CREATED 的状况，在调用 mLifecycleObserver.onStateChanged(owner, event) 之后，mState = newState状况就变成新的状况，行进了一步，从 INITIALIZED 状况变成了 CREATED 状况。

// 获取事情方针状况
public State getTargetState() {
    switch (this) {
        // 假如事情是 ON_CREATE或许ON_STOP，那么状况会抵达State.CREATED
        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;
    }
}

它在分发事情的时分是依据调查者的状况推导出分发的事情，然后再依据分发的事情推导出调查者的状况，在这个办法履行完后，会再次回到While()循环中，再次进行调查者状况与方针状况比较，当时状况 mState 现已变成 CREATE, 假如 targetState 是 INITIALIZED，那么就完结了状况的晋级。

可是假如 targetState 是 RESUME，while循环比较仍是小于0的，则会再次调用 Event.upFrom(mState) 和 dispatchEvent() 办法，将状况晋级到 STATED，持续循环晋级到 RESUME，依此类推，mState = newState状况就变成新的状况 RESUME。直到调查者的状况和宿主的状况抵达共同，然后退出While()循环，如下图

增加Observer时，完好的生命周期事情分发

ObserverWithState 被创立之初状况为 INITIALIZED，假如在宿主的 onResume() 生命周期注册一个 Observer，会把宿主的 onCreate，onStart，onResume 都分发给 Observer：

直到 Observer 的状况和宿主的状况对齐为止，而不是直接从 INITIALIZED 状况直接分发一个 RESUME 直接抵达 RESUME，目的由于咱们可以在任何地方注册，而且可以接收到完好的接收事情，然后完结初始化，暂停，开释的作业。

这是增加调查者时的事情分发流程。

6.Lifecycle是怎么分发宿主状况的

那么宿主的生命周期改动之后是怎么分发给每一个调查者的？

依据上面 Activity/Fragment 源码剖析，它会在每个生命周期办法里边履行handleLifecycleEvent(event)，event.getTargetState()依据当时的事情推导出每个调查者方针的生命周期状况。

public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
    enforceMainThreadIfNeeded("handleLifecycleEvent");
    moveToState(event.getTargetState());
}
private void moveToState(State next) {
    if (mState == next) {
        return;
    }
    mState = next;
    mHandlingEvent = true;
    // 同步新状况事情
    sync();
    mHandlingEvent = false;
}

moveToState(next) 里边首要是做一些条件的判别，真正的状况同步是在 sync() 办法里边：

private void sync() {
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    //循环，直到isSynced()同步完结，一切调查者的状况都分发完，状况都与宿主的状况共同
    while (!isSynced()) {
        mNewEventOccurred = false;
        // 1.宿主的状况小于调查者状况，调查者状况进行降级
        if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
            //状况降级
            backwardPass(lifecycleOwner);
        }
        Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
        // 2. 宿主的状况大于调查者状况，调查者状况进行晋级
        if (!mNewEventOccurred && newest != null
                && mState.compareTo(newest.getValue().mState) > 0) {
            // 状况晋级
            forwardPass(lifecycleOwner);
        }
    }
    mNewEventOccurred = false;
}

isSynced() 判别这个接口里边注册的 Observer 是否一切调查者的状况都分发完结，都现已同步到跟宿主共同的状况。假如不是则进入状况判别：

宿主的状况小于调查者状况，调查者状况进行降级；
宿主的状况大于调查者状况，调查者状况进行晋级。

假如宿主的状况小于调查者状况，这种产生在生命周期后退的阶段，比方前台切换到后台，履行 onPause() 办法，宿主进入 STARED 状况，调查者还处于 RESUME 状况，backwardPass() 是让一切的调查者都后退，和宿主相同的状况，而且分发相应的事情给他们，

private void backwardPass(LifecycleOwner lifecycleOwner) {
    Iterator<Map.Entry<LifecycleObserver, ObserverWithState>> descendingIterator =
            mObserverMap.descendingIterator();
    // 循环遍历一切调查者
    while (descendingIterator.hasNext() && !mNewEventOccurred) {
        Map.Entry<LifecycleObserver, ObserverWithState> entry = descendingIterator.next();
        ObserverWithState observer = entry.getValue();
        // 循环比照单个调查者的状况，直到单个调查者同步到方针状况，调查者状况大于宿主状况，则将调查者状况降级处理
        while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
                && mObserverMap.contains(entry.getKey()))) {
            // 依据observer.mState 的状况降级，获取对应的Event事情
            Event event = Event.downFrom(observer.mState);
            pushParentState(event.getTargetState());
            // 分发相应的事情Event
            observer.dispatchEvent(lifecycleOwner, event);
            popParentState();
        }
    }
}

这儿的中心逻辑便是遍历一切调查者，依据当时调查者的状况，核算出它应该分发哪一种事情，由所以生命周期的后退，这儿履行的是 Event.downFrom(observer.mState)，也便是生命周期的降级：

// 核算传入状况降级所对应的事情
public static Event downFrom(@NonNull State state) {
    switch (state) {
        // 假如当时的状况是 CREATED，产生生命周期后退便是履行了ON_DESTROY，回来ON_DESTROY事情
        case CREATED:
            return ON_DESTROY;
        case STARTED:
            return ON_STOP;
        case RESUMED:
            return ON_PAUSE;
        default:
            return null;
    }
}

假如调查者是 RESUME 状况，产生生命周期后退，就会回来一个 ON_PAUSE 事情，假如是 STARTED 状况产生生命周期的后退也便是回来 ON_STOP 事情。

然后依据回来的事情，调用 observer.dispatchEvent() 分发给它，依据上面的剖析，还会当时的事情推导出方针的状况，然后赋值给 mState。

static class ObserverWithState {
    void dispatchEvent(LifecycleOwner owner, Event event) {
        //依据Event获取方针状况
        State newState = event.getTargetState();
        // 获取最小状况
        mState = min(mState, newState);
        // 状况改动回调
        mLifecycleObserver.onStateChanged(owner, event);
        // 更新当时状况
        mState = newState;
    }
}

backwardPass() 履行完之后，调查者的状况就会降级到和宿主相同的状况，直到调集里边的一切调查者的状况和宿主的相同为止。

private void sync() {
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    //一切调查者的状况都分发完，状况都与宿主的状况共同
    while (!isSynced()) {
        // 
        Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
        // 2. 宿主的状况和Observe状况比较，宿主的状况大于调查者状况，调查者状况进行晋级
        if (!mNewEventOccurred && newest != null
                && mState.compareTo(newest.getValue().mState) > 0) {
            // 状况晋级
            forwardPass(lifecycleOwner);
        }
    }
    mNewEventOccurred = false;
}

同理，进入 sync() 的第二个判别条件，把当时宿主的状况和每个调查者的状况进行比较，假如大于0，生命周期行进(比方后台切换到前台)，从 STARTES 状况切换到 RESUME 状况， forwardPass(lifecycleOwner) 逻辑与 backwardPass() 类似，只不过这是状况行进的进程，会调用 Event.upForm(observer.mState)，依据当时调查者的状况在生命周期行进的时分核算出它应该分发哪一个事情。

private void forwardPass(LifecycleOwner lifecycleOwner) {
    Iterator<Map.Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
            mObserverMap.iteratorWithAdditions();
    // 循环遍历一切调查者
    while (ascendingIterator.hasNext() && !mNewEventOccurred) {
        Map.Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
        ObserverWithState observer = entry.getValue();
        // 调查者状小于于宿主状况，则将调查者状况晋级处理
        while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
                && mObserverMap.contains(entry.getKey()))) {
            pushParentState(observer.mState);
            // 依据mState状况晋级，获取对应的分发事情Event
            final Event event = Event.upFrom(observer.mState);
            // 分发完后就和宿主抵达共同的状况
            observer.dispatchEvent(lifecycleOwner, event);
            popParentState();
        }
    }
}

observer.dispatchEvent() 分发完就会与宿主抵达共同的状况，直到 Observer 调集傍边一切调查者与宿主的状况保持共同，而且退出这个循环。

到这儿，宿主的生命周期和宿主状况的联系，每个生命周期改动的时分，都会分发相应的事情，而且依据这个事情推导出宿主的状况，遍历一切的调查者，让他们的状况也随之晋级，或许降级，而且把本次事情分发给调查者。

7.怎么区别LifecycleObserver的类型

那么这个事情它在分发的时分，是怎么区别的 LifecycleObserver 仍是 FullLifecycleObserver,亦或许是 LifecycleEventObserver 这三种类类型的？在 addObserver() 里边，每次注册一个 Observer 都会把它包装成一个 ObserverWithState：

static class ObserverWithState {
    State mState;
    LifecycleEventObserver mLifecycleObserver;
    //把传递进来的observer转换成LifecycleEventObserver
    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);
        // 分发事情
        mLifecycleObserver.onStateChanged(owner, event);
        mState = newState;
    }
}

它把传递进来的 observer 转换成 LifecycleEventObserver，分发事情的时分调用了 mLifecycleObserver.onStateChanged() 办法，可是咱们在运用的时分明明是 LifecycleObserver 或许 FullLifecycleObserver，首要是原理在 Lifecycling.lifecycleEventObserver(observer) 里边，本质上是一个东西类，把传递进来的 observer 转化成 LifecycleEventObserver，首要是经过适配器来转化的。

static LifecycleEventObserver lifecycleEventObserver(Object object) {
    // 是否为LifecycleEventObserver类型
    boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
    // 是否为FullLifecycleObserver类型
    boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
    // 1.这种情况产生在自界说Observer,上面两种都完结了
    if (isLifecycleEventObserver && isFullLifecycleObserver) {
        return new FullLifecycleObserverAdapter((FullLifecycleObserver) object,
                (LifecycleEventObserver) object);
    }
    // 2. FullLifecycleObserver 将object当做FullLifecycleObserver传递
    if (isFullLifecycleObserver) {
        return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);
    }
    // 3. LifecycleEventObserver 直接回来object自身
    if (isLifecycleEventObserver) {
        return (LifecycleEventObserver) object;
    }
    //
}

判别 observer 是否为 LifecycleEventObserver && FullLifecycleObserver，假如条件都成立（一般产生在自界说的 Observer，即完结了两个接口），回来了一个FullLifecycleObserverAdapter，它完结了 LifecycleEventObserver 接口，复写了onStateChanged()办法，判别 Event 的类型，然后回调传递进来的 FullLifecycleObserver 相应的办法，假如还完结了 mLifecycleEventObserver 接口，则最终还会回调mLifecycleEventObserver.onStateChanged()办法。

// 完结LifecycleEventObserver接口
class FullLifecycleObserverAdapter implements LifecycleEventObserver {
    // mFullLifecycleObserver回调生命周期办法
    @Override
    public void onStateChanged(LifecycleOwner source, 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;
        }
        // 回调mLifecycleEventObserver的onStateChanged()办法
        if (mLifecycleEventObserver != null) {
            mLifecycleEventObserver.onStateChanged(source, event);
        }
    }
}

假如仅仅是完结了 FullLifecycleObserver，同样是回来了一个FullLifecycleObserverAdapter，可是 lifecycleEventObserver 为 null，阐明不再回调 onStateChanged(source, event) 办法，实践上经过 FullLifecycleObserverAdapter 包装完结转化进程，将 LifecycleObserver 转化为 LifecycleEventObserver。
假如是直接完结了 LifecycleEventObserver 的则直接回来，那么在生命周期事情分发的时分， Observer 就能直接分发到 onStateChanged() 这个办法里边。

static LifecycleEventObserver lifecycleEventObserver(Object object) {
    
    final Class<?> klass = object.getClass();
    // 获取Observer结构器类型，是否增加了注解编译器
    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);
        }
        // 回来CompositeGeneratedAdaptersObserver
        return new CompositeGeneratedAdaptersObserver(adapters);
    }
    // 回来ReflectiveGenericLifecycleObserver，内部完结依靠反射
    return new ReflectiveGenericLifecycleObserver(object);
}

上面的代码则是判别 LifecycleOberver，咱们知道它只是一个空完结，可是为什么还要界说这个接口呢？这儿仅仅是起到一个约束和规范的效果，方便在运转的时分判别 Observer 是那种类型。

public interface LifecycleObserver {
}

假如 Observer 是完结了 LifecycleOberver 这个接口的，它在运转的时分，分发事情的时分它供给了两种战略：

第一种是把 Observer 包装成一个 ReflectiveGenericLifecycleObserver，同样是完结了LifecycleEventObserver，在 onStateChanged() 调用了 invokeCallbacks() 办法经过反射的办法来调用自界说的 Observer 中相关办法。

// LifecycleObserver内部完结依靠反射
class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
    @Override
    public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Event event) {
        //经过反射的办法来调用自界说的Observer中相关办法
        mInfo.invokeCallbacks(source, event, mWrapped);
    }
}

第二种假如在 gradle 文件中增加了 lifecycle_compiler 依靠，它实践上是编译器的意思，里边包含了一个注解处理器，在编译阶段就会为 Observers 生成相应适配的类。

比方上面 Lifecycle 完结办法的第一种：

public class MyLifecycleObserver implements LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    void onStart(@NotNull LifecycleOwner owner) {
    }
    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    void onStop(@NotNull LifecycleOwner owner) {
    }
}

编译时会在 build.generated.source.kapt.debug 文件下主动生成MyLifecycleObserver_LifecycleAdapter.java 文件，在它的完结里边，便是依据事情的类型，回调到 MyLifecycleObserver 的 onStart() 和 onStop() 办法，这儿为什么能直接回调呢？由于它在编译阶段生成的这个类，就能扫描到 MyLifecycleObserver 中的办法上符号的注解OnLifecycleEvent，然后拿到办法的称号，以及它的参数，生成下面的源码，就不必运用反射调用 MyLifecycleObserver 类中的办法了。

可是怎么判别有没有引入 lifecycle-compiler 这个编译器的，经过 int type = getObserverConstructorType(klass) 判别结构器类型，跟踪来到 generatedConstructor() 中：

// 传入一个Class，实践上是便是上面界说的MyLifecycleObserver
private static Constructor<? extends GeneratedAdapter> generatedConstructor(Class<?> klass) {
    try {
        //获取包名
        Package aPackage = klass.getPackage();
        //获取类名
        String name = klass.getCanonicalName();
        final String fullPackage = aPackage != null ? aPackage.getName() : "";
        // 获取adapterName拼接后的类名
        final String adapterName = getAdapterName(fullPackage.isEmpty() ? name :
                name.substring(fullPackage.length() + 1));
        final Class<? extends GeneratedAdapter> aClass =
                (Class<? extends GeneratedAdapter>) Class.forName(
                        fullPackage.isEmpty() ? adapterName : fullPackage + "." + adapterName);
        Constructor<? extends GeneratedAdapter> constructor =
                aClass.getDeclaredConstructor(klass);//反射加载这个类，
        if (!constructor.isAccessible()) {//假如没有反常，阐明类存在
            constructor.setAccessible(true);
        }
        return constructor;
    } catch (ClassNotFoundException e) {
        return null;
    } catch (NoSuchMethodException e) {
        throw new RuntimeException(e);
    }
}

adapterName 的类名拼接，实践上是 MyLifecycleObserver 拼接上 _LifecycleAdapter，如下:

public static String getAdapterName(String className) {
    return className.replace(".", "_") + "_LifecycleAdapter";
}

假如类存在了，阐明引入了 lifecycle-compiler 这个编译器，假如抛出反常就阐明没有引入这个编译器。

这样它就可以区别，对所以直接完结 LifecycleObserver 的情况，是回来 CompositeGeneratedAdaptersObserver 仍是回来 ReflectiveGenericLifecycleObserver，然后选用不同的战略来回调办法。

四、总结

Lifecycle 原理时序图如下：

监听进程便是 Activity/Fragment 承继 LifecycleOwner，并在子类 CommponentActivity 中创立 Lifecycle 的子类 LifecycleRegistry。复写 getLifecycle() 的办法中将子类 LifecycleRegistry 回来。
在 onCreate() 中注入 ReportFragment，在生命周期回调后，经过 getLifecycle() 的办法得到 LifecycleRegistry 方针中的 handleLifecycleEvent(event) 办法给每个调查者派产生命周期事情。
addObserver() 中先初始化状况，然后核算出它应该抵达的状况（方针状况），while()循环会让当时的调查者的状况从init状况行进到方针状况，再依据状况获取相应的事情，Observe 调用 dispatchEvent() 分发事情。
宿主每个生命周期办法里边履行 handleLifecycleEvent(event)，event.getTargetState() 依据当时的事情推导出每个调查者方针的生命周期状况，进行晋级或许降级处理。然后遍历一切调查者，依据当时调查者的状况，核算出它对应的事情，别离进行 observer.dispatchEvent() 分发事情。

关于 Lifecycle 面试常问几个问题：

Activity 里边是怎么完结 Lifecycle 事情的分发的？

答：是经过增加透明 ReportFragment.

在 onResume 办法里边注册 Observer，是否能接受到完好的分发事情?

答：能。

Lifecycle 几乎是 Jetpack 组件的中心，一切具有生命周期感知才能的组件都会用到 Lifecycle，包含 ViewModel和 Livedata。Lifecycle 完结了履行的逻辑和活动的别离，代码解耦而且增加了代码的额可读性。Lifecycle 在活动结束时主动移除监听，防止了生命周期的问题。

总的来说，调查宿主生命周期有三种写法，引荐第二种和第三种，第一种需求运用注解符号，要么是反射，要么是要增加注解处理器，生成适配的类。

一个大型的 Android 项目架构最佳实践，基于Jetpack组件 + MVVM架构办法，加入 组件化、模块化、协程、Flow、短视频。项目地址：github.com/suming77/Su…

点重视，不走失

好了各位，以上便是这篇文章的全部内容了，很感谢您阅读这篇文章。我是suming，感谢各位的支撑和认可，您的点赞便是我创造的最大动力。山水有相逢，咱们下篇文章见！

自己水平有限，文章不免会有过错，请批评指正，不胜感激！

参阅链接：

Lifecycle官网

希望咱们能成为朋友，在 Github、上一同分享常识，一同共勉！Keep Moving!

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。

Android架构灵魂组件Lifecycle的生命周期机制详解

前言

什么是Lifecycle

一、Lifecycle的运用

1.承继LifecycleObserver

2.完结DefaultLifecycleObserver接口

3.完结LifecycleEventObserver

二、Lifecycle 组件架构

三、Lifecycle 原理剖析

1.Fragment是怎么完结Lifecycle的

2.Activity是怎么是完结Lifecycle的

3.LifecycleRegistry 源码剖析

4.状况与事情

5.状况比较和升降级

6.Lifecycle是怎么分发宿主状况的

7.怎么区别LifecycleObserver的类型

四、总结

点重视，不走失

参阅链接：

希望咱们能成为朋友，在 Github、上一同分享常识，一同共勉！Keep Moving!

近期文章

近期评论

Android架构灵魂组件Lifecycle的生命周期机制详解

前言

什么是Lifecycle

一、Lifecycle的运用

1.承继LifecycleObserver

2.完结DefaultLifecycleObserver接口

3.完结LifecycleEventObserver

二、Lifecycle 组件架构

三、Lifecycle 原理剖析

1.Fragment是怎么完结Lifecycle的

2.Activity是怎么是完结Lifecycle的

3.LifecycleRegistry 源码剖析

4.状况与事情

5.状况比较和升降级

6.Lifecycle是怎么分发宿主状况的

7.怎么区别LifecycleObserver的类型

四、总结

点重视，不走失

参阅链接：

希望咱们能成为朋友，在 Github、 上一同分享常识，一同共勉！Keep Moving!

近期文章

近期评论

希望咱们能成为朋友，在 Github、上一同分享常识，一同共勉！Keep Moving!