Lifecycle 的意义：
早期的架构中，生命周期的事件监听和状态查询，需要直接在Activity/Fragment的生命周期钩子中处理。而实际开发中，往往需要在Activity/Fragment外部进行事件监听和状态查询。在Lifecycle引入前，需要开发者自定义一套提供侦测功能的Activity/Fragment基类及回调接口。
Lifecycle的引入，即是对以上需求的官方支持。类似的，在官方推出ViewModels以前，已经存在通过Fragment实现相同功能的方案。
Lifecycle 的主要类：
以下基于AndroidX 1.1.0
-
Lifecycle：
核心抽象类。
架构的核心，继承该类的子类，表示本身是一个 具有Android生命周期特性 的对象，能对外提供如下能力：
1.Android生命周期 事件的监听
2.Android生命周期 状态的获取
抽象类内部，定义了2个用于生命周期相关的枚举类：
1.enum Event： 生命周期事件
2.enum State： 生命周期状态
LifecycleOwner：
核心接口。
顾名思义，该接口的实现类表示能够为外部提供Lifecycle实例。
系统框架中，接口的实现类为ComponentActivity和Fragment，两者提供的Lifecycle对象，是系统框架实现中Lifecycle的唯一子类LifecycleRegistry。-
LifecycleRegistry：
核心类。
Lifecycle子类，系统框架实现中Lifecycle的唯一子类。
实现Lifecycle定义生命周期观察订阅，生命周期查询的方法。还实现了架构中，生命周期变化时触发的自身状态处理和相关对观察者的订阅回调的逻辑。简单来说，就是对生命周期持有者提供一组状态迁移方法，生命周期持有者在对应的生命周期方法中，增加对这组方法的调用。而方法调用后，
Lifecycle则会执行具体的变换处理，及执行回调观察者的逻辑。 -
LifecycleObserver：
核心接口。
Lifecycle架构中，该接口的实现类表示为关注生命周期事件的观察者。
注意的是，该接口仅起标记实现类为观察者的作用，内部不存在任何方法定义。实际的工作一般根据需求使用其子类接口或者使用注解实现，而主要包括：LifecycleObserver：
即该接口本身，采用注解方式，@OnLifecycleEvent标记自定义的方法以实现回调。
注解的工作方式有两种：反射，预编译适配类，默认的工作方式为反射。
反射方式：
很好理解，就是通过包装和处理后，最终通过invoke调用被注解的方法。
预编译方式：
需要引入注解编译器：androidx.lifecycle:lifecycle-compiler:<*>。
对被注解标记 且 继承/实现LifecycleObserver接口的 类/接口，自动编译生成对应的继承GeneratedAdapter的_LifecycleAdapter.class FullLifecycleObserver：
LifecycleObserver子接口。为所有的生命周期事件都定义了对应的回调方法。
实现该接口，就需要把不需要观察的方法回调都做一个空实现。在没有java8的default关键字时，如果仅需要1-2个回调方法，那么最终实现类中的空方法会相当碍眼，这种情况下推选使用@OnLifecycleEvent注解方式替代。(当然也可以自己弄一个空实现的BaseLifecycleObserver)。DefaultLifecycleObserver：
FullLifecycleObserver子接口。使用java8的default关键字空实现了FullLifecycleObserver的所有方法。
需要引入："androidx.lifecycle:lifecycle-common-java8:<*>。
如果项目中使用了java8或者开启java8特性，那么官方强烈推选DefaultLifecycleObserver替代的@OnLifecycleEvent注解实现 (注解后续可能被弃用)，包括预编译。
引入DefaultLifecycleObserver后，就需要把注解实现相关逻辑移除。即使保留注解，由于Lifecycling的处理逻辑（系统架构逻辑中所有传入的观察者都会经过Lifecycling处理），任何FullLifecycleObserver的实现类 (即包括DefaultLifecycleObserver) 内部所有的@OnLifecycleEvent注解都会失效。LifecycleEventObserver：
LifecycleObserver子接口。只有一个onStateChanged方法，以Lifecycle.Event入参提供事件区分的形式，进行统一方法回调。
与FullLifecycleObserver不冲突，但是也会无效化@OnLifecycleEvent注解。
同时实现LifecycleEventObserver和FullLifecycleObserver，可以得到2次相同的生命周期回调，后者的具体方法回调优先于前者的统一方法回调。ReflectiveGenericLifecycleObserver：
LifecycleEventObserver子类。适应于注解方式的反射工作方式。
通过该类对观察者进行包装，处理观察者关注的回调的反射调用，由Lifecycling处理包装过程。SingleGeneratedAdapterObserver：
LifecycleEventObserver子类。适应于注解方式的预编译工作方式。
通过该类对观察者的GeneratedAdapter进行包装，处理GeneratedAdapter的方法调用，由Lifecycling处理包装过程。CompositeGeneratedAdaptersObserver：
SingleGeneratedAdapterObserver的复数版，内部逻辑基本与其一致，只是提供"复数"GeneratedAdapter的支持。
怎么理解"复数"呢？
首先要知道，在程序运行过程，Lifecycling会查找传入观察者自身的对应的GeneratedAdapter，假如不存在，则会查找其所有父类/接口对应的GeneratedAdapter。
假如存在自身的对应的GeneratedAdapter，那么此时GeneratedAdapter数量等于1，则会实例化这个GeneratedAdapter并使用SingleGeneratedAdapterObserver保存（所以叫做Single）。
假如目标观察者类自身不包含注解方法，而是继承或实现包含注解方法的LifecycleObserver类/接口。根据前面的预编译规则，由于目标类不包含注解方法，注解编译器不会为其生成GeneratedAdapter。
根据查找逻辑，自身对应的GeneratedAdapter不存在，Lifecycling将会查找其所有父类/接口对应的GeneratedAdapter。
如果结果GeneratedAdapter数量等于1，则走SingleGeneratedAdapterObserver流程。
如果结果GeneratedAdapter数量大于1 （继承+实现，或多实现等等，都可能发生），Lifecycling将会结果GeneratedAdapter实例化并打包成数组，并使用CompositeGeneratedAdaptersObserver保存（所以叫做Composite）。 Lifecycling：
核心工具类。
系统框架实现中，对所有LifecycleObserver的包装适配器选择和相关处理都由本类完成。
Lifecycle 的基本使用
使用Lifecycle基本也就是3个方法：
getLifecycle().addObserver(LifecycleObserver);
getLifecycle().removeObserver(LifecycleObserver);
getLifecycle().getCurrentState();
根据实际需求自定义LifecycleObserver。
Lifecycle 的关键源码分析：
Lifecycle 与生命周期组件的交互：
虽然ComponentActivity实现了LifecycleOwner接口并持有LifecycleRegistry实例，但是操作LifecycleRegistry生命周期变化的逻辑却是在ReportFragment中。
ComponentActivity会在初始化阶段添加一个ReportFragment实例，以此对自身维护的LifecycleRegistry进行生命周期变化管理。
androidx.activity 1.0.0-alpha01引入前，LifecycleOwner由FragmentActivity实现。引入后，迁移到alpha01中新增的ComponentActivity。
不直接在ComponentActivity对LifecycleRegistry进行操作，原因是出于适配考虑，开发者有可能直接继承Activity，对这种情况不能直接把Lifecycle生命周期变化的逻辑直接写到ComponentActivity。
ReportFragment 中相关的注释 (lifecycle-runtime 2.1.0)
public class ReportFragment extends Fragment {
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 注入方式
ReportFragment作为Lifecycle的实际操作者，在ComponentActivity中通过injectIfNeededIn()注入:
ComponentActivity (androidx.activity 1.1.0)
public class ComponentActivity {
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mSavedStateRegistryController.performRestore(savedInstanceState);
ReportFragment.injectIfNeededIn(this);
if (mContentLayoutId != 0) {
setContentView(mContentLayoutId);
}
}
}
ReportFragment.injectIfNeededIn把一个ReportFragment实例添加到Activity中：
ReportFragment (lifecycle-runtime 2.1.0)
public class ReportFragment extends Fragment {
public static void injectIfNeededIn(Activity activity) {
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
manager.executePendingTransactions();
}
}
}
ReportFragment 自动注入
上文ReportFragment的注释中，提及到了ProcessLifecycleOwner，但实际上ProcessLifecycleOwner也需要依赖ReportFragment的生命周期监听特性。真正实现自动注入ReportFragment的类是LifecycleDispatcher。
ProcessLifecycleOwner及LifecycleDispatcher
需要引入androidx.lifecycle:lifecycle-process:<*>或android.arch.lifecycle:extensions:<*>。
后者中所有API在2.2.0版本中完全被拆分，并被弃用及停止维护。一般建议根据具体功能引入具体的库。
当LifecycleDispatcher.init被调用时，将会通过Application.registerActivityLifecycleCallbacks添加全局的Activity生命周期钩子，并在Activity.onCreated时向其注入ReportFragment。
LifecycleDispatcher (lifecycle-process 2.2.0)
class LifecycleDispatcher {
static void init(Context context) {
((Application) context.getApplicationContext())
.registerActivityLifecycleCallbacks(new DispatcherActivityCallback());
}
static class DispatcherActivityCallback extends EmptyActivityLifecycleCallbacks {
@Override
public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
ReportFragment.injectIfNeededIn(activity);
}
}
}
LifecycleDispatcher.init被ProcessLifecycleOwnerInitializer调用，原理是基于ContentProvider会跟随Application的创建而创建的特性，自动获取Application，而无需开发者显示初始化。
这个技巧在很多框架中都有使用，例如Picasso中的
PicassoProvider。
ProcessLifecycleOwnerInitializer (lifecycle-process 2.2.0)
public class ProcessLifecycleOwnerInitializer extends ContentProvider {
@Override
public boolean onCreate() {
LifecycleDispatcher.init(getContext());
ProcessLifecycleOwner.init(getContext());
return true;
}
}
Manifest 中自动注册 ProcessLifecycleOwnerInitializer
这里有个坑，SDK Manager下载的API28 Source中包含了
AndroidX的相关源码，注意分析的不要弄错源码位置。
ReportFragment 与 Lifecycle 的交互
ReportFragment会在侦测到Activity生命周期变化的时候调用LifecycleRegistry.handleLifecycleEvent()传入对应的状态。
在不同版本, ReportFragment对Activity的侦测方法实现有所不同。
API28及以下:
主要是通过ReportFragment将自身添加到Activity中实现。
ReportFragment (lifecycle-runtime 2.1.0)
public class ReportFragment extends Fragment {
public static void injectIfNeededIn(Activity activity) {
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 中的 LifecycleRegistry 并调用 handleLifecycleEvent
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);
}
}
}
// 各个生命周期钩子中，调用 dispatch
@Override
public void onStart() {
super.onStart();
dispatch(Lifecycle.Event.ON_START);
}
}
API29：
Activity中增加一组ActivityLifecycleCallbacks的相关方法，可以直接通过注册ActivityLifecycleCallbacks观察生命周期。而该版本的ReportFragment则把生命周期侦测方案迁移到ActivityLifecycleCallbacks形式。
为了前向兼容，ReportFragment依然会被添加到Activity，并在dispatch()中增加过滤避免出现二次调用。
ReportFragment (lifecycle-runtime 2.2.0)
public class ReportFragment extends Fragment {
public static void injectIfNeededIn(Activity activity) {
if (Build.VERSION.SDK_INT >= 29) {
// On API 29+, we can register for the correct Lifecycle callbacks directly
activity.registerActivityLifecycleCallbacks(new LifecycleCallbacks());
}
// Prior to API 29 and to maintain compatibility with older versions of
// ProcessLifecycleOwner (which may not be updated when lifecycle-runtime is updated and
// need to support activities that don't extend from FragmentActivity from support lib),
// use a framework fragment to get the correct timing of Lifecycle events
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
manager.executePendingTransactions();
}
}
static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks {
// ActivityLifecycleCallbacks的各个生命周期钩子中，调用 dispatch
@Override
public void onActivityPostCreated(@NonNull Activity activity,
@Nullable Bundle savedInstanceState) {
dispatch(activity, Lifecycle.Event.ON_CREATE);
}
......
}
// 2.1.0 及之前版本调用的方法
private void dispatch(@NonNull Lifecycle.Event event) {
if (Build.VERSION.SDK_INT < 29) {
// Only dispatch events from ReportFragment on API levels prior
// to API 29. On API 29+, this is handled by the ActivityLifecycleCallbacks
// added in ReportFragment.injectIfNeededIn
dispatch(getActivity(), event);
}
}
// 2.2.0 新增的 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);
}
}
}
}
至此，生命周期组件对
LifecycleRegistry的调用已分析完成，接下来就是分析LifecycleRegistry如何管理自身的生命周期状态，及如何回调到开发者注册的观察者。
LifecycleRegistry (基于lifecycle-runtime 2.2.0)
在开始分析LifecycleRegistry前，需要了解下面的设计点。
不变式
在LifecycleRegistry中，传入的Observer通过链表mObserverMap保存，链表存在一个不变式：
根据添加顺序，链表中的任意节点(Observer)，对应的状态State，始终大于等于后驱节点的状态。
该不变式在影响到整个源码的逻辑实现，所以需要优先了解。
/**
* 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<>();
状态与事件
Lifecycle的生命状态状态并没有精确到对应每个生命周期事件，例如onPause->onStop不存在对应的STOPED状态，而是STARTED。状态迁移时，需要通过升降级方向，计算出对应触发的生命周期事件。例如当前RESUMED，降级到STARTED，则对应事件onPause。
生命周期状态的数值对比：
DESTROYED < INITIALIZED < CREATED < STARTED < RESUMED
基于状态等级的相关方法：
// 计算事件发生后, 将会迁移到的状态
static State getStateAfter(Event event) {...}
// 计算传入状态降级所对应的事件
private static Event downEvent(State state) {...}
// 计算传入状态升级所对应的事件
private static Event upEvent(State state) {...}
// 获取两个状态中的较小值
static State min(@NonNull State state1, @Nullable State state2) {...}
状态和事件可以参考下图：
LifecycleRegistry 成员变量：
-
mObserverMap:
Observer列表，采用FastSafeIterableMap，key为Observer，value为对Observer的封装对象ObserverWithState。ObserverWithState在持有Observer的同时，保存了Observer对应的状态。LiveData也是类似的实现。FastSafeIterableMap是SafeIterableMap的子类，本质并不是java.util.Map的实现类。
SafeIterableMap内部是通过自定义Entry实现的链表，通过遍历Entry对比Key值存取Value实现的类似LinkedHashMapEntry的Map，是一个使用场景比较狭窄的容器，非线程安全，支持在遍历的过程中删除任意元素。
可以参考：SafeIterableMap：一个能在遍历中删除元素的数据结构
而FastSafeIterableMap可以说是LifecycleRegistry的专用容器，是在SafeIterableMap的基础上增加一个HashMap记录contains()快速判断是否存在对应的Key，以及ceil()查找目标Key对应的Entry的前结点的能力。 mState：
当前LifecycleRegistry的生命周期状态。mLifecycleOwner：
当前对应的生命周期提供者，使用弱引用防止内存泄漏。mAddingObserverCounter：
记录正在初始化同步的新添加Observer的数量，大于0时，表示正在对新添加的Observer进行初始化同步。
防止addObserver()重入时，多次调用sync()。使sync()仅仅在最外层的addObserver()同步逻辑完成后执行一次。mHandlingEvent：
标记正在进行状态事件同步。
防止moveToState()重入时，多次调用sync()。mNewEventOccurred：
标记发生事件嵌套。
主要作用在moveToState()重入时，将mNewEventOccurred设置为true，打断正在发生的sync()同步逻辑，并重新执行。mParentStates：
用于解决addObserver()过程中可能发生的remove+add，保证链表的不变式成立。
从上可以分析出，LifecycleRegistry的存在两种同步逻辑：
- 对新添加的
Observer进行初始化同步，在添加Observer时调用addObserver()触发。 - 对所有
Observer进行状态事件同步，在生命周期事件迁移中调用sync()触发。
并且LifecycleRegistry在设计时，对同步过程中可能发生重入进行了支持。
ObserverWithState 静态内部类：
对传入的Observer进行封装，通过Lifecycling转为统一的LifecycleEventObserver对象，并同时保存对应的mState状态。
static class ObserverWithState {
// 当前状态
State mState;
// observer封装
LifecycleEventObserver mLifecycleObserver;
ObserverWithState(LifecycleObserver observer, State initialState) {
// 这里就是上文提及到的Lifecycling对observer进行适配
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;
}
}
LifecycleRegistry 方法：
生命周期操作方法
生命周期操作方法有2个, 分别是
-
setCurrentState(State state)：迁移到传入的指定状态 -
handleLifecycleEvent(Lifecycle.Event event)：迁移到传入事件发生后对应的状态
两者的内部，实际调用的方法为moveToState()。
public class LifecycleRegistry extends Lifecycle {
public void setCurrentState(@NonNull State state) {
moveToState(state);
}
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
State next = getStateAfter(event);
moveToState(next);
}
}
moveToState(State next)：
将LifecycleRegistry设置到对应的传入状态next，并触发sync()进行状态事件同步。
private void moveToState(State next) {
// 状态没有发生迁移时, 直接返回不进行处理
if (mState == next) {
return;
}
// 记录当前状态为传入状态
mState = next;
// 检查moveToState是否重入
// 检查addObserver是否重入
if (mHandlingEvent || mAddingObserverCounter != 0) {
mNewEventOccurred = true;
return;
}
// 标记开始状态事件同步
mHandlingEvent = true;
// 同步新状态事件
sync();
// 移除状态事件同步标记
mHandlingEvent = false;
}
sync()：
同步新状态到所有保存的Observer。
while循环通过isSynced()判断是否完成同步，尝试使用backwardPass()和backwardPass()进行同步操作直到同步完成，前者处理前台到销毁的过程，后者则相反。
private void sync() {
// 同步时，假如生命周期组件已回收，抛出异常
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
throw new IllegalStateException("...");
}
// 循环，直到isSynced判断同步完成
while (!isSynced()) {
// 移除新事件标记
mNewEventOccurred = false;
// 头节点状态大于当前状态，降级同步
// 例：RESUMED->STARTED
// 不用对头结点做非空判断，因为头结点不存在时，isSynced返回true
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
backwardPass(lifecycleOwner);
}
// 尾节点状态小于当前状态，升级同步
// 例：STARTED->RESUMED
// 需要检测mNewEventOccurred，降级同步时有可能发生事件嵌套
// 需要对尾节点作出空判断，降级同步时有可能将节点移除，
Entry newest = mObserverMap.newest();
if (!mNewEventOccurred && newest != null
&& mState.compareTo(newest.getValue().mState) > 0) {
forwardPass(lifecycleOwner);
}
}
// 移除新事件标记
mNewEventOccurred = false;
}
isSynced():
判断是否已经完成同步。
当mObserverMap首尾节点状态相同，且尾节点状态等于当前状态时，认为同步完成。
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;
}
backwardPass(LifecycleOwner lifecycleOwner):
降级同步，同步过程优先进行降级同步。
为确保不变式，mObserverMap的遍历从尾部指向头部，优先减少尾节点的状态值，通过descendingIterator()构建逆向的迭代器实现。
private void backwardPass(LifecycleOwner lifecycleOwner) {
// 逆向迭代器，源码比较简单，此处不贴出
Iterator> descendingIterator =
mObserverMap.descendingIterator();
// 通过迭代器遍历，遇到新事件标识时中断
while (descendingIterator.hasNext() && !mNewEventOccurred) {
Entry entry = descendingIterator.next();
ObserverWithState observer = entry.getValue();
// 循环对比单个观察者的状态，直到单个观察者同步到目标状态
while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey()))) {
// 获取状态对应的事件
Event event = downEvent(observer.mState);
// 缓存observer的状态，用于remove+add问题
pushParentState(getStateAfter(event));
// 派分事件
observer.dispatchEvent(lifecycleOwner, event);
// 移除observer状态缓存
popParentState();
}
}
}
forwardPass(LifecycleOwner lifecycleOwner)和backwardPass()类似，只是迭代器正向遍历，链表头部优先升级，以确保不变式成立。
至此可以了解到，
LifecycleRegistry如何在生命周期改变时，外部通过setCurrentState()和handleLifecycleEvent()，最终调用moveToState()执行新状态设置和Observe同步。
基于不变式，升级时Observe先进先同步，降级时Observe后进先同步。
addObserver(LifecycleObserver observer)：
通过addObserver()将Observer添加到LifecycleRegistry。
Observer在添加过程中，会优先被初始化同步到一个最小状态，这个状态通过calculateTargetState()获取。
calculateTargetState()：
主要是对比当前LifecycleRegistry的状态、Observer链表的尾节点及mParentStates的最后一个元素，取出其中的最小值。
private State calculateTargetState(LifecycleObserver observer) {
Entry 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);
}
继续分析addObserver()方法。
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
// 获取的observer需要设置的初始状态
// 假如当前状态为DESTROYED则设置为DESTROYED, 否则设置为INITIALIZED
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
// 通过ObserverWithState对observer进行包装，并绑定初始的生命周期状态
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
// 将包装的observer添加到mObserverMap，以observer自身作为Key值
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
// 假如observer已添加，不进行后续操作
if (previous != null) {
return;
}
// 假如lifecycleOwner已销毁，不进行后续操作
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
return;
}
// 判断是否重入，重入有2个指标
// mHandlingEvent表示正在执行生命周期迁移导致的sync()同步
// mAddingObserverCounter>0 表示addObserver()导致的单个Observer同步
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
// 通过calculateTargetState获取当前目标需要迁移的目标状态
State targetState = calculateTargetState(observer);
// 正在添加Observer的记录自增
mAddingObserverCounter++;
// 使Observer迁移到目标状态
//
// 当Observer的状态小于目标状态时，升级到目标状态
// Observer的初始状态时DESTROYED或INITIALIZED，且当初始状态为DESTROYED时，目标状态
// 也应为DESTROYED，所以新添加的Observer在初始化同步的时候只需要考虑升级同步。
//
// 这里同时做了mObserverMap.contains(observer)的判断，之所以要这么处理，是因为有时候
// 用户会在observer的生命周期回调中removeObserver移除自身，当发生这种情况时，立即结束
// 迁移操作
while ((statefulObserver.mState.compareTo(targetState) < 0 &&
mObserverMap.contains(observer))) {
// 缓存observer的状态，用于remove+add问题
pushParentState(statefulObserver.mState);
// 派分事件
statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
// 移除状态缓存
popParentState();
// 由于可能存在的变更，重新调用calculateTargetState获取当前目标需要迁移的目标状态
targetState = calculateTargetState(observer);
}
// 非重入状态执行sync同步
if (!isReentrance) {
sync();
}
// 正在添加Observer的记录自减
mAddingObserverCounter--;
}
至此，完成对
addObserver()在添加Observer时，进行初始化同步的分析。
重入问题：
LifecycleRegistry设计了mAddingObserverCounter，mHandlingEvent，mNewEventOccurred，主要是确保sync()只在最顶层执行同步，以免出现同步错误。
在调用sync()之前，通过判断mAddingObserverCounter != 0或mHandlingEvent判断sync()是否需要执行：
-
mHandlingEvent = true：
表示正在进行状态事件同步，此时sync()正在执行，无需再次调用。moveToState(state1) -> sync() -> moveToState(state2) -> sync() // 无需执行 moveToState(state1) -> sync() -> addObserver() -> sync() // 无需执行 -
mNewEventOccurred != 0：
表示正在进行Observer初始化同步，在同步结束时会调用sync()，无需在同步内部调用。addObserver() -> addObserver() -> sync() // 无需执行 -> sync() addObserver() -> moveToState(state1) -> sync() // 无需执行 -> sync()
remove+add问题：
在源码中存在注释说明：
// 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 mParentStates = new ArrayList<>();
假如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;
}
在onStart()中，Observer1从链表中移除，添加Observer2。Observer2执行初始化同步，同步的目标状态通过calculateTargetState()获取，假如不引入mParentStates，将会使Observer2直接同步到STARTED：
private State calculateTargetState(LifecycleObserver observer) {
// 由于Observer1已移除，previous == null
Entry 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状态，破坏了链表的有序性。引入mParentStates，就是为了解决以上的情况。由于mParentStates缓存了Observer1的值，即使Observer1从链表中移除，依然能从mParentStates中获取，防止后续添加的Observer2初始化同步越界。
private State calculateTargetState(LifecycleObserver observer) {
...
// 缓存值为CREATED
State parentState = !mParentStates.isEmpty() ?
mParentStates.get(mParentStates.size() - 1): null;
// 相当于 min(STARTED, CREATED), 返回CREATED
return min(min(mState, siblingState), parentState);
}
Fragment的LifeCycle
AndroidX提供的Fragment（androidx.fragment.app）实现了LifecycleOwner接口，支持通过getLifecycle()获取Lifecycle，进行生命周期事件侦测。
处理逻辑基本和ReportFragment相同，即在对应的生命周期会调用调用对应的操作方法。
Fragment (androidx.fragment 1.1.0)
/**
* ...
* The main differences when using this support version instead of the framework version are:
*
* - Your activity must extend {@link FragmentActivity}
*
- You must call {@link FragmentActivity#getSupportFragmentManager} to get the
* {@link FragmentManager}
*
*/
public class Fragment implements LifecycleOwner, ... {
// 创建 LifecycleRegistry 相关
LifecycleRegistry mLifecycleRegistry;
public Fragment() {
initLifecycle();
}
private void initLifecycle() {
mLifecycleRegistry = new LifecycleRegistry(this);
}
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
// 调用示例
void performCreate(Bundle savedInstanceState) {
onCreate(savedInstanceState);
mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
}
}
FragmentActivity的生命周期方法中，通过FragmentController、FragmentManagerImpl，最终调用Fragment中相应的生命周期方法。
由于涉及的源码数量较多且比较简单，此处不贴出源码。
回调顺序
需要注意的是，除了onCreate()、onResume()外，FragmentActivity对FragmentController的调用发生在相应的生命周期内，所以Fragment的生命周期回调（包括Observer）会比开发者定义的逻辑（super.onXXX()之后及Observer）优先：
class Activity {
final void performStart(String reason) {
// 调用 Activity.onStart()
mInstrumentation.callActivityOnStart(this);
// ReportFragment onStart (2)
mFragments.dispatchStart();
}
}
class FragmentActivity {
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Fragment onStart (1)
mFragments.dispatchCreate();
}
}
onCreate()
FragmentActivity.onCreate()中，super.onCreate()发生在mFragments.dispatchCreate()之前：
class FragmentActivity {
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Fragment onCreate (2)
mFragments.dispatchCreate();
}
}
class Activity {
protected void onCreate(@Nullable Bundle savedInstanceState) {
// ReportFragment onStart (1)
mFragments.dispatchCreate();
}
}
onResume()
为了对旧版本的适配，FragmentActivity没有在onResume()中调用mFragments.dispatchResume()，而是延迟到super.onPostResume()之后。
class FragmentActivity {
/**
* Dispatch onResume() to fragments. Note that for better inter-operation
* with older versions of the platform, at the point of this call the
* fragments attached to the activity are not resumed.
*/
protected void onResume() {
super.onResume();
}
/**
* Dispatch onResume() to fragments.
*/
protected void onPostResume() {
super.onPostResume();
onResumeFragments();
}
/**
* This is the fragment-orientated version of {@link #onResume()} that you
* can override to perform operations in the Activity at the same point
* where its fragments are resumed. Be sure to always call through to
* the super-class.
*/
protected void onResumeFragments() {
// Fragment onResume (2)
mFragments.dispatchResume();
}
}
class Activity {
final void performResume(boolean followedByPause, String reason) {
// ReportFragment onResume (1)
mFragments.dispatchResume();
}
}
更具体的逻辑可以自行阅读 ActivityThread，Instrumentation以及Activity 的源码。
FragmentActivity.mFragmentLifecycleRegistry
基于Fragment-1.1.0，暂时还没有实际用于（或者我没发现，官方文档也没有发现提及相关的修改）。根据TODO的说明，后续应该会用于管理Fragment的LifecycleRegistry对象。
class FragmentActivity {
/**
* A {@link Lifecycle} that is exactly nested outside of when the FragmentController
* has its state changed, providing the proper nesting of Lifecycle callbacks
*
* TODO(b/127528777) Drive Fragment Lifecycle with LifecycleObserver
*/
final LifecycleRegistry mFragmentLifecycleRegistry =
new LifecycleRegistry(this);
}
以上即为Lifecycle的分析。
水平有限，如有错误，欢迎指正。