原理概述

Lifecycle主要用于Activity、Fragment这一类具备状态的组件的状态监听，最主要的一个做用就是将原先Activity、Fragment中的大量的生命周期相关的回调函数移出View层文件，从设计角度上来讲，使得MVVM中的View层文件的结构更加清晰、简单，简化了View层的任务，使得代码更清晰、易于维护。html

Lifecycle实现监听的原理主要有两种方式，在API29如下的版本主要采用的是方法一，而在API29+的版本采用的是方法二。java

和Glide插件同样的，采用一个专门用于报告状态的Fragment，当这个特殊的空白Fragment被插入到宿主Activity时，就能够获取到宿主的生命周期状态改变。
实现Application.ActivityLifecycleCallbacks，监听相关的生命周期的改变。

大概的使用步骤以下：android

声明本身的监听组件:MyUtil实现LifecycleObserver接口。
采用注解声明生命周期回调函数：

@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    private void fun1(){
        //on_create时须要作的事情
    }
复制代码

在MainActivity.java中调用：

getLifecycle().addObserver(new MyUtil());
复制代码

显然，在这个模型中，lifecycle自己只是一个事件的源头，而咱们本身实现的监听者MyUtil则是观察者，咱们像lifecycle注册咱们的工具，一旦lifecycle收到了生命周期的变化通知，那么就通知一系列的观察者进行更新：git

Lifecycle自己更像是一个代理，咱们的工具类不须要本身去作监听这一件事情了，因此这实际上能够看作是两个观察者模式的合成，而中间的lifecycle是一个系统为咱们提供的接口，用于得到回调。咱们只须要注册咱们的Observer便可。这样一来，分析lifecycle的过程明显被拆成了两个子问题：github

问题1. MyUtil(LifecycleObserver)是如何监听lifecycle的？web

问题2. lifecycle是如何监听宿主（LifecycleOwner）生命周期变化的？编程

构成

Lifecycle的构成对象：markdown

Lifecycle：即生命周期，某个组件（Activity、Fragment）可能会具备本身的Lifecycle。
LifecycleOwner：Lifecycle的持有者，某个组件（Activity、Fragment）。
LifecycleObserver：即观察者，咱们须要对某个组件的生命周期进行观察，那么就必须实现LifecycleObserver，经过lifecycle的addObserver方法对LifecycleObserver进行注册监听，这样一来对应的LifecycleObserver的类就可以获得生命周期的相关回调了。
Event：即生命周期回调的方法，例如ON_CREATE、ON_START等等。
State：当某个Event发生后，会致使State的转变，例如ON_CREATE事件发生时，State将会从INITIALIZED走向CREATED，以下【模型】中的状态转移关系图。
- INITIALIZED：刚刚被初始化。
- CREATED：ON_CREATE以后、ON_STOP以后。
- STARTED：ON_START以后、ON_PAUSE以后。
- RESUMED：ON_RESUME以后、ON_PAUSE以前。
- ON_DESTORYED：ON_DESTROY以后，还未被建立或者已经销毁。

模型

//对应的状态转移函数
@NonNull
public State getTargetState() {
  	//枚举类，this标识的是某种事件，例如ON_CREATE、ON_STOP等等。
    switch (this) {
        //对于ON_CREATE和ON_STOP事件，都对应CREATED状态。（图上两者都指向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;
    }
    throw new IllegalArgumentException(this + " has no target state");
}
复制代码

源码

1. addObserver(observer)

LifecycleOwner做为事件的源头，Fragment、Activity都是LifecycleOwner。换句话说就是这二者会产生一些列生命周期相关的事件。网络

public class ComponentActivity extends androidx.core.app.ComponentActivity implements LifecycleOwner 复制代码

LifecycleOwner提供了惟一一个方法，而且，在ComponentActivity类中，使用的是Lifecycle的一个实现类：mLifecycleRegistryapp

public interface LifecycleOwner {
    @NonNull
    Lifecycle getLifecycle();
}

private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
复制代码

//LifecycleRegistry.java
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
    enforceMainThreadIfNeeded("addObserver");//主线程断言
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;//若是mState是已经销毁的则就标记为已经销毁；若是是其余的（全部有效的），就标记为已初始化过的。
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);//传入自定义的观察者（非被观察者）和状态。
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);//尝试放入被观察者维护的观察者对象集合中（若是不存在的话，防止屡次注册）。若是存在，返回既有值的value；若是不存在put，并返回null。
  	//若是以前存在一个相同的observer，那么直接return；
    if (previous != null) {
        return;
    }
  	//取得lifecycleOwner对象，一般是Activity或者是Fragment，注意，此处的LifecycleOwner是被WeakReference<LivecycleOwner>引用住的。是在LifecycleRegistry的构造函数中，被注入了值。
   	//private final WeakReference<LifecycleOwner> mLifecycleOwner;
  
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
  
  	//若是为空，说明对象已经被回收了，return掉。
    if (lifecycleOwner == null) {
        // it is null we should be destroyed. Fallback quickly
        return;
    }

    boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
    State targetState = calculateTargetState(observer);
    mAddingObserverCounter++;
		//正在注册的观察者数量+1
  	
  	//ENUM Class之间的比较，两者相等会返回0。这个循环做用就是追加以前的生命周期事件派发（粘性）
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
      	//该行代码的内部实现是：mParentStates.add(state);其中的mParentStates是一个ArrayList，用于存储一些“旧”的消息。例如咱们在running（create、start、resume都走完了）状态经过点击按钮注册一个监听，此时的pushParentState中的参数：statefulObserver.mState就是“INITIALIZED”。
        pushParentState(statefulObserver.mState);
      	//接着上面的状况，传入的参数是：INITIALIZED，从upFrom中取出的Event是“ON_CREATE”，可是此时onCreate状态实际上早已走完了。
        final Event event = Event.upFrom(statefulObserver.mState);
        if (event == null) {
            throw new IllegalStateException("no event up from " + statefulObserver.mState);
        }
      	//注意，咱们在实例中的ON_CREATE等等回调都是在这步里面执行的【图1】，主要是更新状态，和派发事件，走完这代码，statefulObserver.mState就变成了CREATED
        statefulObserver.dispatchEvent(lifecycleOwner, event);
      	
      	//和pushParentState对应，此时删除后parentState长度为0。
        popParentState();
      
      	
        targetState = calculateTargetState(observer);
      	//此时statefulObserver.mState为CREATED，而targetState的值被更新为：RESUME。
    }
  	
    if (!isReentrance) {
        // we do sync only on the top level.
        sync();
    }
    mAddingObserverCounter--;
}
复制代码

接下来的第二轮代码的，其实和第一轮相似，就是从Event从ON_CREATE变成了ON_START，而后派发了ON_START事件。ON_RESUME同理。大概的流程是，添加Observer的时候。以statefulObserver为主，不论Activity是什么状态，进入时initialState都是INITIALIZED状态，而后利用Event.upFrom函数，根据状态（State，例如CREATED），取出事件（Event，例如ON_CREATE），而后， statefulObserver.dispatchEvent(lifecycleOwner, event);更新了statefulObserver的状态，依次类推。

以上代码的几个比较关键的展开：

private State calculateTargetState(LifecycleObserver observer) {
  	
  	//mObserverMap即上面addObserver主干代码中的第七行：
  	//ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
  	//此处是对该Map惟一的加入调用。
	
  	//取出临近的ObserverWithState,FastSafeIterableMap，注释中说是：Poor's man LinkedHashMap
  	//LifecycleObserver在androidx.core.app.ComponentActivity中能够看到，ComponentActivity实现了该接口。
  	//因此，该Map是一个Activity对应ObserverWithState(一个State、一个LifecycleEventObserver)的结构：
  	
    Map.Entry<LifecycleObserver, ObserverWithState> previous = mObserverMap.ceil(observer);

  	//若是不为空，那么就设置siblingState为previous中存储对象的mState else null
    State siblingState = previous != null ? previous.getValue().mState : null;
  	//若是有parentState，那么获取其中的最后一个的State else null
    State parentState = !mParentStates.isEmpty() ? mParentStates.get(mParentStates.size() - 1)
            : null;
  	//取mState、siblingState和parentState中最小值。
    return min(min(mState, siblingState), parentState);
}


//statefulObserver.dispatchEvent(lifecycleOwner, event); 
void dispatchEvent(LifecycleOwner owner, Event event) //根据event（ENUM）获取其状态，这个和上面的状态图是同样的。 State newState = event.getTargetState();
	 //取最小状态
   mState = min(mState, newState);
   //更新状态，响应回调
   mLifecycleObserver.onStateChanged(owner, event);
	 //设置新状态
   mState = newState;
}

复制代码

2. sync()

private void sync() {
  	//即Activity、Fragment这类生命周期持有者。
    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.");
    }
  	//若是mObserverMap中的元素尚未彻底同步就进行循环,进行全部保存着的观察者的状态同步。
    while (!isSynced()) {
      	//标记是否有新的事件出现，当moveToState被调用时，知足条件（mHandlingEvent || mAddingObserverCounter != 0）时，该属性会被置为true。
      	//这两个条件是：1是否正在处理事件，2是是否正在处理新加入的观察者。
        mNewEventOccurred = false;
        //利用mState和mObserverMap中最老的元素状态相比较，若是更小（最小的是DESTROY，INITIALIZED，一直到RESUMED），那么久从最先被加入的元素，顺着这个LinkedHashMap进行后向的更新。例如CREATED < RESUMED
        if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
          	//后向传播
            backwardPass(lifecycleOwner);
        }
        Map.Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
      	//若是没有新的事件出现（期间没有moveToState被触发），最新的观察者不为空，而且有当前组件的状态更先于最新组件的状态。
      	//例如mState = RESUMED和newest.mState = CREATED，那么就触发前向传播。
        if (!mNewEventOccurred && newest != null
                && mState.compareTo(newest.getValue().mState) > 0) {
          	//前向传播
            forwardPass(lifecycleOwner);
        }
      	//在这个循环中，直到全部Observer状态所有同步为止。
    }
    mNewEventOccurred = false;
}

private boolean isSynced() {
  	if (mObserverMap.size() == 0) {
    	return true;
  	}
  	State eldestObserverState = mObserverMap.eldest().getValue().mState;
  	State newestObserverState = mObserverMap.newest().getValue().mState;
  	//判断最晚加入的 是否等于 最先加入的 是否等于 当前的状态。
  	return eldestObserverState == newestObserverState && mState == newestObserverState;
}
复制代码

//forwardPass同理；
private void backwardPass(LifecycleOwner lifecycleOwner) {
  	//迭代器
    Iterator<Map.Entry<LifecycleObserver, ObserverWithState>> descendingIterator =
            mObserverMap.descendingIterator();
  	//在forwardPass中：
    //Iterator<Map.Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
    // mObserverMap.iteratorWithAdditions();
  	//在没有新的事件（moveToState触发）的状况下进行迭代。
    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()))) {
          	//和addObserver中类似的逻辑，同步时主动去回调其余滞后的监听者的状态。
            Event event = Event.downFrom(observer.mState);
            if (event == null) {
                throw new IllegalStateException("no event down from " + observer.mState);
            }
            pushParentState(event.getTargetState());
            observer.dispatchEvent(lifecycleOwner, event);
            popParentState();
        }
    }
}
复制代码

3. setCurrentState、moveToState

这一类的方法用于外部调用，用于lifecycle的状态转移。例如咱们能够显式地在一个Activity的全部生命周期中，调用setCurrentState方法来标记（通知）lifecycle状态。标记完成后，将触发sync进行全部观察者状态的同步。

@MainThread
    public void setCurrentState(@NonNull State state) {
        enforceMainThreadIfNeeded("setCurrentState");//断言主线程
        moveToState(state);
    }

    /** * Sets the current state and notifies the observers. * <p> * Note that if the {@code currentState} is the same state as the last call to this method, * calling this method has no effect.（若是在相同的State下调用此方法无效。） * * @param event The event that was received */
    public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
        enforceMainThreadIfNeeded("handleLifecycleEvent");//断言主线程
        moveToState(event.getTargetState());
    }

    private void moveToState(State next) {
      	//相同状态下调用无效。
        if (mState == next) {
            return;
        }
        mState = next;
      	//若是正在处理事件，或者含有某个刚刚加入的Observer（数量不为0），那么久标记当前有新的事件出现了。
        if (mHandlingEvent || mAddingObserverCounter != 0) {
            mNewEventOccurred = true;
            // we will figure out what to do on upper level.
            return;
        }
        mHandlingEvent = true;//标记正在处理事件，有点像锁
        sync();//同步（先后向传播）
        mHandlingEvent = false;//结束
    }


复制代码

监听

从moveToState提及，它有三个调用。

@Deprecated
@MainThread
public void markState(@NonNull State state) {
    enforceMainThreadIfNeeded("markState");
    setCurrentState(state);
}

@MainThread
public void setCurrentState(@NonNull State state) {
    enforceMainThreadIfNeeded("setCurrentState");
    moveToState(state);
}

public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
    enforceMainThreadIfNeeded("handleLifecycleEvent");
    moveToState(event.getTargetState());
}
复制代码

markState已经被标记为@Deprecated，可是咱们能够找到它的一个调用：package androidx.core.app下的ComponentActivity中的onSaveInstanceState仍然保持着这个方法的调用。

package androidx.core.app;

@CallSuper
@Override
protected void onSaveInstanceState(@NonNull Bundle outState) {
    mLifecycleRegistry.markState(Lifecycle.State.CREATED);//
    super.onSaveInstanceState(outState);
}
复制代码

setCurrentState则在package androidx.activity;中的ComponentActivity被引用：

package androidx.activity;

@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);
}
复制代码

至于handleLifecycleEvent：

很明显在AppcompatActivity中，handleLifecycleEvent和lifecyle的关系比较密切。

例如，在onCreate方法中，有：

protected void onCreate(@Nullable Bundle savedInstanceState) {
        mFragments.attachHost(null /*parent*/);

        if (savedInstanceState != null) {
           //若是是重建的Activity进行的操做，如下省略
           ......
        }

        if (mPendingFragmentActivityResults == null) {
            mPendingFragmentActivityResults = new SparseArrayCompat<>();
            mNextCandidateRequestIndex = 0;
        }

        super.onCreate(savedInstanceState);

        mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);//派发事件
        mFragments.dispatchCreate();
    }

复制代码

每当咱们的Activity父类的FragmentActivity的方法：onCreate被回调时，必然会触发handleLifecycleEvent()的执行，这样一来很是简单地就实现了监听。

可是，在androidx.activity.ComponentActivity;中，有一段很是特殊的代码：

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    mSavedStateRegistryController.performRestore(savedInstanceState);
    ReportFragment.injectIfNeededIn(this);//
    if (mContentLayoutId != 0) {
        setContentView(mContentLayoutId);
    }
}
复制代码

public static void injectIfNeededIn(Activity activity) {
    if (Build.VERSION.SDK_INT >= 29) {
        // On API 29+(Android 10.0 +), 咱们能够直接注册正确的lifecycle监听,内部将会直接实现监听：在Activity类中的mActivityLifecycleCallbacks中，加入一个Callback：mActivityLifecycleCallbacks.add(callback);
        activity.registerActivityLifecycleCallbacks(
                new LifecycleCallbacks());
    }
		
    android.app.FragmentManager manager = activity.getFragmentManager();
    if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
      	//注意这里，咱们向当前的Activity中新加入了一个new ReportFragment()。
        manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
        manager.executePendingTransactions();
    }
}
复制代码

任取一个Fragment的生命周期函数做为观察，进入dispatch()方法。

@Override
public void onStart() {
    super.onStart();
    dispatchStart(mProcessListener);
    dispatch(Lifecycle.Event.ON_START);
}

@Override
public void onResume() {
    super.onResume();
    dispatchResume(mProcessListener);
    dispatch(Lifecycle.Event.ON_RESUME);
}

@Override
public void onPause() {
    super.onPause();
    dispatch(Lifecycle.Event.ON_PAUSE);
}
复制代码

在dispatch方法中，发现将activity当作LifecycleOwner获取了其Lifecycle进行事件的处理。

@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);//
        }
    }
}
复制代码

其中，LifecycleRegistryOwner是LifecycleOwner接口的子类，能够看到返回值不一样。显然，当Activity生命周期发生变更时，Fragment的生命周期也会相应地发生变更，由ReportFragment的生命周期函数中进行handleLifecycleEvent就很是巧妙地实现了监听这一功能。这一点和Glide的实现(采用一个空白的RequestManagerFragment)很是类似。

可是，在API29+，程序会走这样一段代码：

public static void injectIfNeededIn(Activity activity) {
    if (Build.VERSION.SDK_INT >= 29) {
        // On API 29+, we can register for the correct Lifecycle callbacks directly
        LifecycleCallbacks.registerIn(activity);
    }
    //……
}

static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks {

  	//有作省略
    static void registerIn(Activity activity) {
        activity.registerActivityLifecycleCallbacks(new LifecycleCallbacks());
    }
    @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);
    }
    @Override
    public void onActivityPreStopped(@NonNull Activity activity) {
        dispatch(activity, Lifecycle.Event.ON_STOP);
    }
    @Override
    public void onActivityPreDestroyed(@NonNull Activity activity) {
        dispatch(activity, Lifecycle.Event.ON_DESTROY);
    }
}
复制代码

同时，Api29+的机型，也会走到：插入一个ReportFragment。理论上，经过Application.ActivityLifecycleCallbacks 回调就已经可以注册到监听了，至于为何这么设计并不清楚。可是到派发事件时的dispatch方法：

private void dispatch(@NonNull Lifecycle.Event event) {
    if (Build.VERSION.SDK_INT < 29) {
        dispatch(getActivity(), event);//TAG
    }
}
复制代码

它限制了经过Fragment生命周期回调产生的监听只在Api<29才会进行派发，因此不会产生两次派发。而标记的TAG处的dispatch是一个静态方法，注意，API29+的dispatch直接就是调用的这个静态方法。

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);
        }
    }
}

//API29中的调用，走的是上面的静态方法。
@Override
public void onActivityPostStarted(@NonNull Activity activity) {    
	  dispatch(activity, Lifecycle.Event.ON_START);
}
复制代码

不管是API29如下经过Fragment监听，仍是API29以上，经过Application.ActivityLifecycleCallbacks进行监听，走的都是lifecycle.handleLifecycleEvent()方法。这也是为何在上文中提handleLifecycleEvent有大量调用的调用:

其余

1. Application.ActivityLifecycleCallbacks

该接口含有大量的回调函数，和平常开发中的那三对回调函数不一样，这里的划分更加细致，有三组，而且每组又区分pre和post，外加一个onActivitySaveInstanceState，每当Activity发生生命周期转变时，该回调函数都会被回调到，而且参数是发生变化的Activity。咱们能够自定义一个类实现该接口，而后this.registerActivityLifecycleCallbacks(callbacks);注册一下便可。该类还能够实现更灵活的Activity 实例数量管控。大部分的事件都是在POST部分中处理的，而不是Pre。
@Override
public void onActivityResumed(@NonNull Activity activity) {
}
@Override
public void onActivityPostResumed(@NonNull Activity activity) {
    dispatch(activity, Lifecycle.Event.ON_RESUME);//向监听者（MyUtils类等等）派发事件
}
复制代码

总结

从监听开始，在API29如下的版本中，会向Activity中加入一个ReportFragment，该Fragment的生命周期发生变化时，将会进行派发时间，更新lifecycle的生命周期，再由Lifecycle统一通知LifecycleObserver生命周期更新；而API29+，则会直接经过监听Application.ActivityLifecycleCallbacks接口，进行获取Activity的状态，同时也会插入ReportFragment，可是该用于报告状态的Fragment的生命周期中的dispatch将不会生效，Fragment和Activity都添加一个监听，并在onStop先后添加输出，两种方式（API29+和API29如下）的回调顺序也是不一样的。

附：官方文档部分截取

原文地址：处理 ON_STOP 事件（Google的连接不必定能打开）

1. 处理 ON_STOP 事件

若是 Lifecycle 属于 AppCompatActivity 或 Fragment，那么调用 AppCompatActivity 或 Fragment 的 onSaveInstanceState() 时，Lifecycle 的状态会更改成 CREATED 而且会分派 ON_STOP 事件。

经过 onSaveInstanceState() 保存 Fragment 或 AppCompatActivity 的状态后，其界面被视为不可变，直到调用 ON_START。若是在保存状态后尝试修改界面，极可能会致使应用的导航状态不一致，所以应用在保存状态后运行 FragmentTransaction 时，FragmentManager 会抛出异常。**如需了解详情，请参阅 commit()。

LiveData 自己可防止出现这种极端状况，方法是在其观察者的关联 Lifecycle 尚未至少处于 STARTED状态时避免调用其观察者。在后台，它会在决定调用其观察者以前调用 isAtLeast()。

遗憾的是，AppCompatActivity 的 onStop() 方法会在 onSaveInstanceState() 以后调用，这样就会留下一个缺口，即不容许界面状态发生变化，但 Lifecycle 还没有移至 CREATED 状态。

为防止出现这个问题，beta2 及更低版本中的 Lifecycle 类会将状态标记为 CREATED 而不分派事件，这样一来，即便未分派事件（直到系统调用 onStop()），检查当前状态的代码也会得到实际值。

遗憾的是，此解决方案有两个主要问题：

在 API 23 及更低级别，Android 系统实际上会保存 Activity 的状态，即便它的一部分被另外一个 Activity 覆盖。换句话说，Android 系统会调用 onSaveInstanceState()，但不必定会调用 onStop()。这样可能会产生很长的时间间隔，在此时间间隔内，观察者仍认为生命周期处于活动状态，虽然没法修改其界面状态。
任何要向 LiveData 类公开相似行为的类都必须实现由 Lifecycle 版本 beta 2 及更低版本提供的解决方案。

注意：为了简化此流程并让其与较低版本实现更好的兼容性，自 1.0.0-rc1 版本起，当调用 onSaveInstanceState() 时，会将 Lifecycle 对象标记为 CREATED 并分派 ON_STOP，而不等待调用 onStop() 方法。这不太可能影响您的代码，但您须要注意这一点，由于它与 API 26 及更低级别的 Activity类中的调用顺序不符。

2. 生命周期感知型组件的最佳作法

使界面控制器（Activity 和 Fragment）尽量保持精简。它们不该试图获取本身的数据，而应使用 ViewModel 执行此操做，并观察 LiveData 对象以将更改体现到视图中。
设法编写数据驱动型界面，对于此类界面，界面控制器的责任是随着数据更改而更新视图，或者将用户操做通知给 ViewModel。
将数据逻辑放在 ViewModel 类中。ViewModel 应充当界面控制器与应用其他部分之间的链接器。不过要注意，ViewModel 不负责获取数据（例如，从网络获取）。可是，ViewModel 应调用相应的组件来获取数据，而后将结果提供给界面控制器。
使用数据绑定在视图与界面控制器之间维持干净的接口。这样一来，您可使视图更具声明性，并尽可能减小须要在 Activity 和 Fragment 中编写的更新代码。若是您更愿意使用 Java 编程语言执行此操做，请使用诸如 Butter Knife 之类的库，以免样板代码并实现更好的抽象化。
若是界面很复杂，不妨考虑建立 presenter 类来处理界面的修改。这多是一项艰巨的任务，但这样作可以使界面组件更易于测试。
避免在 ViewModel 中引用 View 或 Activity 上下文。若是 ViewModel 存在的时间比 Activity 更长（在配置更改的状况下），Activity 将泄漏而且不会得到垃圾回收器的妥善处置。
使用 Kotlin 协程管理长时间运行的任务和其余能够异步运行的操做。

Andorid 状态管理（一）Lifecycle浅析