本文基于：
androidx.lifecycle:lifecycle-common-java8:2.3.0
androidx.fragment:fragment:1.1.0
androidx.appcompat:appcompat:1.2.0
一.Lifecycle简介
Lifecycle是google随Jetpack发布的，用于生命周期感知型组件可执行操作来响应另一个组件的生命周期状态的变化，详细的文档介绍参考：
https://developer.android.com/topic/libraries/architecture/lifecycle
二.Lifecycle的实现原理
1. 示例
这个例子基本上就是上面google文档中的例子，Activity实现LifecycleOwner，自定义的Listener实现LifecycleObserver。
public class LifecycleActivitySelfImpl extends Activity implements LifecycleOwner {
private final LifecycleRegistry mLifecycleRegistry;
public LifecycleActivitySelfImpl() {
mLifecycleRegistry = new LifecycleRegistry(this);
getLifecycle().addObserver(new MyListenerSelfImplRetention(this));
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.lifecycle);
mLifecycleRegistry.setCurrentState(Lifecycle.State.CREATED);
}
@Override
public void onStart() {
super.onStart();
mLifecycleRegistry.setCurrentState(Lifecycle.State.STARTED);
}
@Override
public void onResume() {
super.onResume();
mLifecycleRegistry.setCurrentState(Lifecycle.State.RESUMED);
}
@Override
public void onStop() {
super.onStop();
mLifecycleRegistry.setCurrentState(Lifecycle.State.DESTROYED);
}
@NonNull
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
}
public class MyListenerSelfImplRetention implements LifecycleObserver {
private static final String TAG = "MyListenerSelfImplRetention";
public MyListenerSelfImplRetention(Context context) {
// ...
}
@OnLifecycleEvent(Lifecycle.Event.ON_START)
void start() {
Log.d(TAG, "start-retention");
}
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
void resume() {
Log.d(TAG, "resume-retention");
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
void stop() {
Log.d(TAG, "stop-retention");
}
}主要涉及3个需要重要的类：LifecycleOwner，LifecycleObserver和LifecycleRegistry，LifecycleOwner是拥有生命周期的类，比如我们的LifecycleActivitySelfImpl是一个Activity，其拥有生命周期，实现 LifecycleOwner，这个接口的唯一方法就是getLifecycle，返回的Lifecycle对象，其具体实现就是LifecycleRegistry，LifecycleRegistry就是对Lifecycle进行统一注册的，LifecycleObserver就是观察者，当LifecycleOwner的生命周期变化时，会通知LifecycleObserver。当然前提是通过LifecycleRegistry的addObserver将LifecycleOwner和LifecycleObserver关联起来。明显地，这是一个典型的观察者模式。LifecycleActivitySelfImpl的生命周期变化时，通过LifecycleRegistry修改状态，其内部实现就会通知给各个LifecycleObserver。
2. Lifecycle类图
Lifecycle类关系如下
（1）Lifecycle
抽象类，定义了addObserver，removeObserver，getCurrentState方法，还有两个重要的Enum定义在这里：Event和State，
State是状态，Event是事件，一般流程就是Event导致State变化。
（2）LifecycleRegistry
Lifecycle子类，是整体的注册器，LifecycleOwner和LifecycleObserver通过它关联起来，其重要成员如下：
- mObserverMap
Observer列表，采用FastSafeIterableMap，key为Observer，value为对Observer的封装对象ObserverWithState。ObserverWithState在持有Observer的同时，保存了Observer当前的状态。
FastSafeIterableMap是SafeIterableMap的子类，本质并不是java.util.Map的实现类。SafeIterableMap内部是通过自定义Entry<K, V>实现的链表，通过遍历Entry对比Key值存取Value实现的类似LinkedHashMapEntry的Map，是一个使用场景比较狭窄的容器，非线程安全，支持在遍历的过程中删除任意元素。FastSafeIterableMap在SafeIterableMap的基础上增加一个HashMap记录<Key,Entry<K, V>>，主要是提供了contains()快速判断是否存在对应的Key，以及ceil()查找目标Key对应的Entry<K, V>的前结点的能力。
- mState
当前LifecycleRegistry的生命周期状态。
- mLifecycleOwner
当前对应的生命周期提供者，使用弱引用防止内存泄漏。
- mAddingObserverCounter
记录正在初始化同步的新添加Observer的数量，大于0时，表示正在对新添加的Observer进行初始化同步。防止addObserver()重入时，多次调用sync()。使sync()仅仅在最外层的addObserver()同步逻辑完成后执行。
- mHandlingEvent
标记正在进行状态事件同步。防止moveToState()重入时，多次调用sync()。
- mNewEventOccurred
标记发生事件嵌套。主要作用在moveToState()重入时，将mNewEventOccurred设置为true，打断正在发生的sync()同步逻辑，因为sync执行的时候会判断该变量，并重新执行。
- mParentStates
用于解决addObserver()过程中可能发生的remove+add，保证链表的不变式成立。
（3）LifecycleOwner
接口，只有一个方法：getLifecycle()，用来返回Lifecycle对象，一般返回其子类LifecycleRegistry。
（4）LifecycleObserver
是空接口，这个有点奇怪，原因后面会分析。
（5）ObserverWithState
组合了State和Observer的类。
3. addObserver过程分析
上面的demo中，MyListenerSelfImplRetention实现的是LifecycleObserver接口，我们看到这是个空接口，而State有5种状态，那么在状态更新的时候，怎么让不同的状态调用不同的监听方法呢？比如LifecycleActivitySelfImpl的onCreate调用了下面的代码更新了状态是RESUMED：
mLifecycleRegistry.setCurrentState(Lifecycle.State.RESUMED);在MyListenerSelfImplRetention中怎么调用RESUMED对应的监听方法呢？例如demo中的：
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
void resume() {
Log.d(TAG, "resume-new");
}由于LifecycleObserver和LifecycleOwner二者是通过addObserver方法关联起来的，在状态变化的调用setCurrentState的时候，内部肯定是需要逐个通知各个Observer的，我们来梳理下这个流程，先看addObserver的代码 ：
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一个初始状态，接着根据LifecycleObserve生成ObserverWithState，ObserverWithState内部持有State和Observer，这个Observer并不是addObserver传入的参数，是根据这个参数生成的，如下：
static class ObserverWithState {
State mState;
LifecycleEventObserver mLifecycleObserver;
ObserverWithState(LifecycleObserver observer, State initialState) {
mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
mState = initialState;
}
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}mLifecycleObserver是通过静态方法：
Lifecycling.lifecycleEventObserver(observer)生成的，也即是说，内部通过传入的LifecycleObserver构造了另外一个LifecycleEventObserver，构造过程如下表所示：
| oberver instanceof LifecycleEventObserver | oberver instanceof FullLifecycleObserver | 结果 |
| Yes | Yes | FullLifecycleObserverAdapter |
| No | Yes | FullLifecycleObserverAdapter |
| Yes | No | LifecycleEventObserver |
| No | No | SingleGeneratedAdapter CompositeGeneratedAdaptersObserver ReflectiveGenericLifecycleObserver |
在分析构造新的Observer之前，我们先给出Observer相关的类图：
注意，FullLifecycleObserver定义了所有的是生命周期方法，由于java8之前接口没有default实现，实现起来需要实现所有接口方法，所以google并没有公布出来，是package的访问权限，不能直接使用，其子类DefaultLifecycleObserver是public的，但是需要java8，因为这个接口有default行为，如果使用的是java8,强烈推荐DefaultLifecycleObserver
回到前面表格，这个表是有优先顺序的，前面的不满足才可能返回后面的，也就是说如果有任何FullLifecycleObserver的实现类，就不会有后面的，内部所有的@OnLifecycleEvent注解都会失效，因为注解的方式满足的是表格第四种情况，对这种方式，需要进一步的判断条件，来决定使用反射方式还是预编译方式：
private static final int REFLECTIVE_CALLBACK = 1;
private static final int GENERATED_CALLBACK = 2;
private static int resolveObserverCallbackType(Class<?> klass) {
......//代码逻辑参考下面的解释
}这是Lifecycling里面的代码。resolveObserverCallbackType的实现过程如下：
（1）如果查找到了名为<ClassName>_LifecycleAdapter.class的适配类，则使用GENERATED_CALLBACK，例如前面demo中，找到
MyListenerSelfImplRetention_LifecycleAdapter，怎么样才能生成这个类呢？
需要引入注解编译器：androidx.lifecycle:lifecycle-compiler:<*>。对被注解标记且继承/实现LifecycleObserver接口的类/接口，自动编译生成对应的继承GeneratedAdapter的<ClassName>_LifecycleAdapter.class适配类，以减少反射消耗。在我们的demo中，对方法使用了注解@OnLifecycleEvent，如果在build.gradle中引入注解编译器：
annotationProcessor 'androidx.lifecycle:lifecycle-compiler:2.3.0'就会在编译的时候会生成一个类MyListenerSelfImplRetention_LifecycleAdapter
public class MyListenerSelfImplRetention_LifecycleAdapter implements GeneratedAdapter {
final MyListenerSelfImplRetention mReceiver;
MyListenerSelfImplRetention_LifecycleAdapter(MyListenerSelfImplRetention receiver) {
this.mReceiver = receiver;
}
@Override
public void callMethods(LifecycleOwner owner, Lifecycle.Event event, boolean onAny,
MethodCallsLogger logger) {
boolean hasLogger = logger != null;
if (onAny) {
return;
}
if (event == Lifecycle.Event.ON_START) {
if (!hasLogger || logger.approveCall("start", 1)) {
mReceiver.start();
}
return;
}
if (event == Lifecycle.Event.ON_RESUME) {
if (!hasLogger || logger.approveCall("resume", 1)) {
mReceiver.resume();
}
return;
}
if (event == Lifecycle.Event.ON_STOP) {
if (!hasLogger || logger.approveCall("stop", 1)) {
mReceiver.stop();
}
return;
}
}
}可以看到MyListenerSelfImplRetention对象当成MyListenerSelfImplRetention_LifecycleAdapter的构造参数传入，并将Event和我们的监听方法进行了映射。
（2）如果查找到了被注解@OnLifecycleEvent标记的方法，并且没有1中的注解编译器，则使用REFLECTIVE_CALLBACK方式，例如本demo中，在类
MyListenerSelfImplRetention找到了几个@OnLifecycleEvent标记的方法
（3）如果父类是REFLECTIVE_CALLBACK方式，则使用REFLECTIVE_CALLBACK方式。
（4）如果实现的接口是REFLECTIVE_CALLBACK方式，则使用REFLECTIVE_CALLBACK方式。
（5）最后，默认REFLECTIVE_CALLBACK方式。
综上，如果是条件返回GENERATED_CALLBACK，那么使用SingleGeneratedAdapter或者CompositeGeneratedAdaptersObserver，一个是单数版，一个是复数版，如果返回的是REFLECTIVE_CALLBACK，则使用ReflectiveGenericLifecycleObserver。
怎么理解复数版呢？首先要知道，在程序运行过程，Lifecycling会查找传入观察者自身的对应的GeneratedAdapter，假如不存在，则会查找其所有父类/接口对应的GeneratedAdapter（就是上面步骤的3和4）。
假如存在自身的对应的GeneratedAdapter，那么此时GeneratedAdapter数量等于1，则会实例化这个GeneratedAdapter并使用SingleGeneratedAdapterObserver保存（所以叫做Single）。
假如目标观察者类自身不包含注解方法，而是继承或实现包含注解方法的LifecycleObserver类/接口。根据前面的预编译规则，由于目标类不包含注解方法，注解编译器不会为其生成GeneratedAdapter。根据查找逻辑，自身对应的GeneratedAdapter不存在，Lifecycling将会查找其所有父类/接口对应的GeneratedAdapter。如果结果GeneratedAdapter数量等于1，则走SingleGeneratedAdapterObserver流程。如果结果GeneratedAdapter数量大于1 （继承+实现，或多实现等等，都可能发生），Lifecycling将会结果GeneratedAdapter实例化并打包成数组，并使用CompositeGeneratedAdaptersObserver保存，所以叫做Composite。
ReflectiveGenericLifecycleObserver中，由于使用反射，没有了GeneratedAdapter进行Event和调用方法之间的映射，其内部会使用CallbackInfo的类来存储信息：
static class CallbackInfo {
final Map<Lifecycle.Event, List<MethodReference>> mEventToHandlers;
final Map<MethodReference, Lifecycle.Event> mHandlerToEvent;
......
}其实反射得到所有的方法，并根据注解@OnLifecycleEvent信息生成的映射表，比如mEventToHandlers，标识的就是Event到方法的映射，例如
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
void resume() {
Log.d(TAG, "resume-new");
}标识RESUME EVENT到方法resume的映射，注意，mEventToHandlers的value是个List，也就是可以存在多个处理方法。
4. moveState过程分析
更新状态有2种方式，一种是调用setCurrentState，另外一种是调用handleLigfecycleEvent，内部实现是调用的moveToState，如下：
private void moveToState(State next) {
if (mState == next) {
return;
}
mState = next;
if (mHandlingEvent || mAddingObserverCounter != 0) {
mNewEventOccurred = true;
// we will figure out what to do on upper level.
return;
}
mHandlingEvent = true;
sync();
mHandlingEvent = false;
}控制条件mHandlingEvent，mAddingObserverCounter和mNewEventOccurred的使用后续再讨论，我们直接来看状态同步sync的实现：
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()) {
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;
}
State eldestObserverState = mObserverMap.eldest().getValue().mState;
State newestObserverState = mObserverMap.newest().getValue().mState;
return eldestObserverState == newestObserverState && mState == newestObserverState;
}在分析代码之前，需要注意一下mObserverMap的几个特征，最重要的一个：存在一个不变式：根据添加顺序，链表中的任意节点(Observer)，对应的状态State，始终大于等于后驱节点的状态，这是代码中一直在维护的一个特征，从google代码的注释中也可以看到：
/**
* Custom list that keeps observers and can handle removals / additions
during traversal.
* Invariant: at any moment of time for observer1 & observer2:
* if addition_order(observer1) < addition_order(observer2), then
* state(observer1) >= state(observer2),
*/
private FastSafeIterableMap mObserverMap = new FastSafeIterableMap<>();另外FastSafeIterableMap还会按照元素的添加顺序，记录start和end，分别表示第一个和最后一个元素。并且，每个元素都有prev和next指针。
先看sync的条件isSynced：
Map中的第一个元素和最后一个元素的状态相同，并且都等于新状态（就是moveToState参数指定的状态）。满足这个就表示已经同步完成。
注意State的compareTo，由于Lifecycle.State是Enum类型，所以其大小按照定义的顺序，关系如下：
DESTROYED < INITIALIZED < CREATED < STARTED < RESUMED
执行sync的时候，有两种形式：
（1）如果mState比最老的（第一个）元素的状态小，则执行backwardPass，降级
（2）如果mState比最新的（最后一个）元素的状态大，则执行forwardPass，升级。
来看升级的实现：
private void forwardPass(LifecycleOwner lifecycleOwner) {
Iterator<Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
mObserverMap.iteratorWithAdditions();
while (ascendingIterator.hasNext() && !mNewEventOccurred) {
Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
ObserverWithState observer = entry.getValue();
while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey()))) {
pushParentState(observer.mState);
observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));
popParentState();
}
}
}为了维护不变性，保证Oberver前面的状态大于后面额状态，升级的时候是从前往后升级的：mObserverMap.iteratorWithAdditions就是从前往后的迭代器，执行过程如下：
对Map中的每一个observer，将其状态一步一步的执行到mState为止。注意是一步一步执行，如果跨多个状态，需要一个状态一个状态往前执行。状态变更都是调用的dispatchEvent，这个是ObserverWithState类里的方法，其中参数，upEvent(observer.mState)，是将State转化成Event。反过来，执行backwardPass的时候，为了维护不变性，降级的时候是从后往前降级的，mObserverMap.descendingIterator就是从后往前的迭代器，同理的有参数downEvent(observer.mState)，也是将State转化成Event，这二者的区别是一个向前，一个向后，参考下图：
注意图中的箭头，例如：如果State=CREATED，那么upEvent=ON_START，downEvent=ON_DESTROY，最后来看看dispatchEvent的实现：
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}getStateAfter是获取该Event的下一个状态，参考图中的箭头指向的状态。接下来获取mState和newState的更小值，并执行onStateChanged回调，注意，这个mState和前面moveToState方法保存的mState不是同一个，moveToState的是Lifecycle的当前状态，而这里的mState是属于ObserverWithState的，也就是当前Observer的状态，刚才说过，Observer的状态是一步一步迁移的，其最终状态会和Lifecycle里的状态一致。onStateChanged是构造ObserverWithState时创建出来的Observer，参考前面的分析，如果我们注解方式，则这个Observer对象是ReflectiveGenericLifecycleObserver，我们来看他的onStateChanged实现：
class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
private final Object mWrapped;
private final CallbackInfo mInfo;
ReflectiveGenericLifecycleObserver(Object wrapped) {
mWrapped = wrapped;
mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
}
@Override
public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Event event) {
mInfo.invokeCallbacks(source, event, mWrapped);
}
}CallbackInfo的实现：
void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) {
invokeMethodsForEvent(mEventToHandlers.get(event), source, event, target);
invokeMethodsForEvent(mEventToHandlers.get(Lifecycle.Event.ON_ANY), source, event,
target);
}可以看到，先根据mEventToHandlers取出该Event对应的Method列表，并进行反射调用，内部会回调到我们定义的回调方法中，比如我们demo中的start()，resume()等方法。
5. 重入
moveToState会调用sync进行状态同步，sync要么执行forwardPass()，要么执行backwardPass()，为了保证不变式，其迭代顺序不一样。
其实addOberver也会调用sync，很简单的道理，例如当前LifecycleOwner状态已经到了第3个状态，这时候新增一个Observer，其默认状态时第1个，肯定时需要sync到最新状态的。前面讲addOberver的时候，只说了Map数据的Observer类型，没有讲解同步逻辑。
public void addObserver(@NonNull LifecycleObserver observer) {
......//map数据构造参考前面的章节
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) {
// we do sync only on the top level.
sync();
}
mAddingObserverCounter--;
}在调用sync()之前，需要判断是否重入，如果不是重入才执行sync，判断是否重入，有2个条件:
（1）mHandlingEvent表示正在进行状态事件同步，此时sync正在执行，无需再次调用。
（2）mAddingObserverCounter>0 表示正在进行Observer初始化同步，无需再次调用。
接下来同步状态，会先计算一个最小状态，这个状态通过calculateTargetState()获取。对比当前LifecycleRegistry的状态、Observer链表的尾节点及mParentStates的最后一个元素，取出其中的最小值。
private State calculateTargetState(LifecycleObserver observer) {
Entry<LifecycleObserver, ObserverWithState> previous = mObserverMap.ceil(observer);
State siblingState = previous != null ? previous.getValue().mState : null;
State parentState = !mParentStates.isEmpty() ?
mParentStates.get(mParentStates.size() - 1) : null;
return min(min(mState, siblingState), parentState);
}当Observer的状态小于目标状态时，升级到目标状态，Observer的初始状态时DESTROYED或INITIALIZED，且当初始状态为DESTROYED时，目标状态也应为DESTROYED，所以新添加的Observer在初始化同步的时候只需要考虑升级同步。这里同时做了mObserverMap.contains(observer)的判断，之所以要这么处理，是因为有时候用户会在observer的生命周期回调中removeObserver移除自身，当发生这种情况时，立即结束迁移状态操作。来看看mParentStates的作用：
// we have to keep it for cases:
// void onStart() {
// mRegistry.removeObserver(this);
// mRegistry.add(newObserver);
// }
// newObserver should be brought only to CREATED state during the execution of
// this onStart method. our invariant with mObserverMap doesn't help, because parent
// observer is no longer in the map.
private ArrayList<State> mParentStates = new ArrayList<>();这个是为了防止remove-add的过程出现不变性被破坏而加的。假如Observer链表中仅存在一个Observer1，这个Observer在onStart()中，从链表中移除，且添加一个新的Observer2。在onStart()回调执行过程中，实际上Observer1的状态还没转变为STARTED，而是还处在CREATED:
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
mState = min(mState, newState);
// 先执行回调 Event = ON_START
mLifecycleObserver.onStateChanged(owner, event);
// 再设置状态 mState = STARTED
mState = newState;
}在onStateChange()回调到onStart()中，Observer1从链表中移除，添加Observer2。Observer2执行初始化同步，同步的目标状态通过calculateTargetState()获取，假如不引入mParentStates，将会使Observer2直接同步到STARTED：
private State calculateTargetState(LifecycleObserver observer) {
// 由于Observer1已移除，previous == null
Entry<LifecycleObserver, ObserverWithState> previous = mObserverMap.ceil(observer);
// previous == null 导致 siblingState == null
State siblingState = previous != null ? previous.getValue().mState : null;
// 由于siblingState == null, min()返回mState，即STARTED
return min(mState, siblingState);
}此时会导致Observer2优先Observer1进入STARTED状态，破坏了mObserverMap的不变性。引入mParentStates，就是为了解决以上的情况。由于mParentStates缓存了Observer1的值，即使Observer1从链表中移除，依然能从mParentStates中获取，防止后续添加的Observer2初始化同步越界。moveToState时，也会使用这几个变量mHandlingEvent，mAddingObserverCounter和mNewEventOccurred进行判断是否需要执行sync。
三.FragmentActivity的Lifecycle实现
FragementActivity默认就是实现了Lifecycle，其类结构如下：
FragementActivity的类关系上有多个LifecycleOwner，ComponentActivity继承的是Activity生命周期的Lifecycle，而Fragment的就是Fragment生命周期的Lifecycle，以onCreate为例，其实现如下：
public class FragmentActivity extends ComponentActivity {
......
final LifecycleRegistry mFragmentLifecycleRegistry = new LifecycleRegistry(this);
......
protected void onCreate(@Nullable Bundle savedInstanceState) {
......
super.onCreate(savedInstanceState);
mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
mFragments.dispatchCreate();
}注意，onCreate最后3句代码可能涉及3个Lifecycle的使用：
（1）super.onCreate()，ComponentActivity的Lifecycle使用的是getLifeCycle()，其LifeCycle是在ComponentActivity中定义的。
（2）mFragmentLifecycleRegistry，这个是在FragmentActivity中定义的，它不能给开发者使用，是给内部的OnBackPressedDispatcher.LifecycleOnBackPressedCancellable使用的。
（3）mFragments.dispatchCreate()，这个会触发fragment的Lifecycle，经过FragmentController、FragmentManagerImpl，这里不再列出其调用路径，可以自己跟踪，最终调用Fragment中的performCreate方法，并调用fragment的handleLifecycleEvent：
void performCreate(Bundle savedInstanceState) {
mState = CREATED;
......
onCreate(savedInstanceState);
......
mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
}第一条的super.onCreate()，会有ReportFragement的使用，我们再看看到底做了什么。
//androidx.activity.ComponentActivity
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
......
ReportFragment.injectIfNeededIn(this);
......
}injectIfNeededIn将一个空白的fragment注入到了当前activity，注意这个类的super（androidx.core.app.ComponentActivity）也调用了injectIfNeededIn，在注入的时候，会判断是否已经存在：
public static void injectIfNeededIn(Activity activity) {
// ProcessLifecycleOwner should always correctly work and some activities may not
// extend FragmentActivity from support lib, so we use framework fragments for
// activities
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
manager.beginTransaction().add(new ReportFragment(),REPORT_FRAGMENT_TAG).commit();
// Hopefully, we are the first to make a transaction.
manager.executePendingTransactions();
}
}继续分析ReportFragment的实现：
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
dispatchCreate(mProcessListener);
dispatch(Lifecycle.Event.ON_CREATE);
}
public void onStart() {
super.onStart();
dispatchStart(mProcessListener);
dispatch(Lifecycle.Event.ON_START);
}
......
private void dispatch(Lifecycle.Event event) {
Activity activity = getActivity();
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);
}
}
}可以看到，fragment的生命周期方法，例如onStart调用的dispatch中，会调用getLifecycle()的handleLifecycleEvent，我们知道这个getLifecycle返回不是FragmentActivity中的，而是其父类ComponentActivity的。也就是说ComponentActivity的Lifecycle是通过ReportFragment来实现的，这就有个奇怪的问题，为什么不直接使用FragmentActivity的Lifecycle，比如上面的第2条Lifecycle。其实看ReportFragment的注释就可以理解，这是为了兼容旧的Activity没有继承FragementActivity的情况。
综上，对于应用的开发者来说，如果继承FragmentActivity，则可以直接收到LifecycleRegistry的生命周期回调，否则，就要通过实现LifecycleOwner接口的方式来监听生命周期了，实现的时候，可以ReportFragment注入简化回调函数，也可以自己逐一调用回调函数。
注意，有些文章介绍ReportFragment兼容的时候，使用了LifecycleDispatcher和ProcessLifecycleOwner，但是在最新的代码中，没有找到这2个类，可能已被淘汰。这里的FragmentActivity是1.1版本的代码。
四.Application.ActivityLifecycleCallbacks
这个是Application中监听各个Activity生命周期回调的，和前面的Lifecycle不是一回事
五.Demo的其他实现方式
前面demo使用的listener是注解的方式实现的，如果java8，可以通过DefaultLifecycleObserver 来实现：
public class MyListenerSelfImplFull implements DefaultLifecycleObserver {
private static final String TAG = "MyListenerSelfImplFull";
public MyListenerSelfImplFull(Context context) {
// ...
}
@Override
public void onStart(@NonNull LifecycleOwner owner) {
Log.d(TAG, "start-full");
}
@Override
public void onResume(@NonNull LifecycleOwner owner) {
Log.d(TAG, "resume-full");
}
@Override
public void onStop(@NonNull LifecycleOwner owner) {
Log.d(TAG, "stop-full");
}
}如果继承顶层的Activity可以使用ReportFragment来实现，这样可以简化Activity生命周期各方法的注入。注意ReportFragment默认不允许在外面调用，需要package name前缀相同，但是可以通过SuppressLint忽略：
public class LifecycleActivityInjectImpl extends Activity implements LifecycleOwner {
private final LifecycleRegistry mLifecycleRegistry;
public LifecycleActivityInjectImpl() {
mLifecycleRegistry = new LifecycleRegistry(this);
}
@SuppressLint("RestrictedApi")
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.lifecycle);
ReportFragment.injectIfNeededIn(this);
getLifecycle().addObserver(new MyListenerSelfImplRetention(this));
getLifecycle().addObserver(new MyListenerSelfImplFull(this));
}
@NonNull
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
}最后，如果继承的AppCompatActivity，FragmentActivity或者androidx.activity.ComponentActivity，甚至androidx.core.app.ComponentActivity（默认不允许在外面调用，需要package name前缀相同，但是可以通过SuppressLint忽略），就很简单了：
public class LifecycleActivityAutoImpl extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.lifecycle);
getLifecycle().addObserver(new MyListenerSelfImplRetention(this));
getLifecycle().addObserver(new MyListenerSelfImplFull(this));
}
}六.总结
Lifecycle的实现就是一个观察者模式，由于Observer接口较多，在java8之前没有默认接口实现，所以引入了注解，编译时注解会生成一个Adapter类进行Event到方法的映射，而运行时注解通过反射来进行映射。新的FragmentActivity默认实现了LifeCycle，为了兼容旧的Activty，内部是通过注入ReportFragment实现的，Fragment也有自己的LifeCycle。
791
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
