什么是 Lifecycle
Lifecycle 是生命周期感知型组件，它可以通过响应另一个组件（ Activity 或 Fragment ）的生命周期的变化来执行相应的操作，有助于产出更有条理、更轻量级、更易于维护的代码。
Lifecycle 是 LiveData 和 ViewModel 的基础，下面就先介绍为何使用 Lifecycle 及如何使用 Lifecycle 。
使用 Lifecycle 之前
假设我们有一个在屏幕上显示设备位置信息的 Activity ，常见的实现可能如下所示：
class MyLocationListener {
public MyLocationListener(Context context, Callback callback) {
// 构造方法
}
void start() {
// 开启定位服务
}
void stop() {
// 停止定位服务
}
}
class MyActivity extends AppCompatActivity {
private MyLocationListener myLocationListener;
@Override
public void onCreate(...) {
myLocationListener = new MyLocationListener(this, (location) -> {
// 更新 UI
});
}
@Override
public void onStart() {
super.onStart();
myLocationListener.start();
}
@Override
public void onStop() {
super.onStop();
myLocationListener.stop();
}
}
上面的示例看起来好像没问题，但在实际应用中，随着业务越来越复杂，你需要在 Activity 相应的生命周期方法（如上例中的 onStart() 、 onStop() ）中写很多代码处理业务的启动和回收工作，这时候你就会发现这些代码很难维护。
此外，无法保证Activity在执行 onStop() 之前执行 myLocationListener 的 start() 方法，例如下面这种情况：
class MyActivity extends AppCompatActivity {
private MyLocationListener myLocationListener;
public void onCreate(...) {
myLocationListener = new MyLocationListener(this, location -> {
// 更新 UI
});
}
@Override
public void onStart() {
super.onStart();
Util.checkUserStatus(result -> {
// 如果 checkUserStatus() 方法耗时较长，在 Activity 执行完 onStop() 方法后才回调，
// 那么 myLocationListener 执行完 start() 方法后就没办法执行 stop() 方法了，
// 又因为 myLocationListener 持有 MyActivity 的引用，会造成内存泄漏。
if (result) {
myLocationListener.start();
}
});
}
@Override
public void onStop() {
super.onStop();
myLocationListener.stop();
}
}
由于 checkUserStatus() 方法耗时较长，在 Activity 执行完 onStop() 方法后才回调， myLocationListener 执行完 start() 方法后就没办法执行 stop() 方法了，又因为 myLocationListener 持有 Activity 的引用，从而导致内存泄漏。
总结一下，上面出现了2个问题：
- Activity 的生命周期方法中会存在大量管理 UI 和其他业务的代码，难以维护；
- 无法保证在退出 Activity 前执行相应的回收方法，容易导致内存泄露问题；
使用 Lifecycle 可以帮助你解决这些问题。
Lifecycle 的使用
引入依赖
- 非 androidx 项目引入:
implementation "android.arch.lifecycle:extensions:1.1.1"
- androidx 项目引入:
implementation 'androidx.appcompat:appcompat:1.2.0'
因为 appcompat 依赖了 androidx.fragment，而 androidx.fragment 又依赖了 ViewModel 和 LiveData ， LiveData 内部又依赖了 Lifecycle 。
- 如果想要单独引入依赖，官方给出的依赖如下：
dependencies {
def lifecycle_version = "2.2.0"
def arch_version = "2.1.0"
// ViewModel
implementation "androidx.lifecycle:lifecycle-viewmodel:$lifecycle_version"
// LiveData
implementation "androidx.lifecycle:lifecycle-livedata:$lifecycle_version"
// 只有Lifecycles (不带 ViewModel or LiveData)
implementation "androidx.lifecycle:lifecycle-runtime:$lifecycle_version"
// Saved state module for ViewModel
implementation "androidx.lifecycle:lifecycle-viewmodel-savedstate:$lifecycle_version"
// lifecycle注解处理器
annotationProcessor "androidx.lifecycle:lifecycle-compiler:$lifecycle_version"
// 替换 - 如果使用Java8,就用这个替换上面的lifecycle-compiler
implementation "androidx.lifecycle:lifecycle-common-java8:$lifecycle_version"
// 以下按需引入
// 可选 - 帮助实现Service的LifecycleOwner
implementation "androidx.lifecycle:lifecycle-service:$lifecycle_version"
// 可选 - ProcessLifecycleOwner给整个 app进程 提供一个lifecycle
implementation "androidx.lifecycle:lifecycle-process:$lifecycle_version"
// 可选 - ReactiveStreams support for LiveData
implementation "androidx.lifecycle:lifecycle-reactivestreams:$lifecycle_version"
// 可选 - Test helpers for LiveData
testImplementation "androidx.arch.core:core-testing:$arch_version"
}
看着有很多，实际上如果只使用 Lifecycle，只需要引入 lifecycle-runtime 即可，但通常都是和 ViewModel、 LiveData 配套使用的，所以 lifecycle-viewmodel、lifecycle-livedata 一般也会引入。另外，lifecycle-process 是给整个 App 进程提供一个 lifecycle ，后面也会提到。
基本使用
Lifecycle 的使用方法很简单，主要分为 2 步：
- 生命周期拥有者使用 getLifecycle() 获取 Lifecycle 实例，然后调用 addObserver() 添加观察者；
- 观察者实现 LifecycleObserver，方法上使用 @OnLifecycleEvent 注解关注对应的生命周期，生命周期触发时就会执行相应的方法；
下面是在 Kotlin 中使用的代码：
class LifecycleTestActivity : AppCompatActivity() {
private val TAG = LifecycleTestActivity::class.java.simpleName
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
lifecycle.addObserver(MyObserver())
}
override fun onResume() {
super.onResume()
Log.i(TAG, "onResume: ")
}
override fun onPause() {
super.onPause()
Log.i(TAG, "onPause: ")
}
}
class MyObserver : LifecycleObserver {
private val TAG = "LifeCycleTest_MyObserver"
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
fun connect() = Log.d(TAG,"connect run ...")
@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
fun disconnect() = Log.d(TAG,"disconnect run ...")
}
进入LifecycleTestActivity后，打印如下：
2024-03-24 09:58:05.577 LifecycleTestActivity com.example.test I onResume:
2024-03-24 09:58:05.582 LifeCycleTest_MyObserver com.example.test D connect run ...
退出LifecycleTestActivity后，打印如下：
2024-03-24 10:01:35.794 LifeCycleTest_MyObserver com.example.test D disconnect run ...
2024-03-24 10:01:35.795 LifecycleTestActivity com.example.test I onPause:
这里看到，MyObserver 类中的方法会紧随着关注的对应的生命周期触发，但是，connect run ...在onResume:之后打印，而disconnect run ...在onPause:之前打印，这是为什么呢？这个问题我们留到后面分析源码的时候再来解释。
自定义LifecycleOwner
直接在 Activity 中使用 getLifecycle() 就能获取到 Lifecycle 实例，getLifecycle() 方法来自LifecycleOwner 接口，顾名思义，生命周期拥有者：
public interface LifecycleOwner {
@NonNull
Lifecycle getLifecycle();
}
support library 26.1.0 及以上的 Fragment 和 Activity 已经实现了 LifecycleOwner 接口，所以我们在Activity 中可以直接使用 getLifecycle() 方法。
如果你想要自己定义一个类实现 LifecycleOwner 接口，你可以使用 LifecycleRegistry ，它是 Lifecycle 的实现类，但你需要将事件转发到该类：
public class LifecycleRegistry extends Lifecycle {
private State mState;
private final WeakReference<LifecycleOwner> mLifecycleOwner;
public LifecycleRegistry(@NonNull LifecycleOwner provider) {
this(provider, true);
}
private LifecycleRegistry(@NonNull LifecycleOwner provider, boolean enforceMainThread) {
mLifecycleOwner = new WeakReference<>(provider);
mState = INITIALIZED;
...
}
@Deprecated
@MainThread
public void markState(@NonNull State state) {
...
setCurrentState(state);
}
}
public class MyActivity extends Activity implements LifecycleOwner {
private LifecycleRegistry lifecycleRegistry;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
lifecycleRegistry = new LifecycleRegistry(this);
lifecycleRegistry.markState(Lifecycle.State.CREATED);
}
@Override
public void onStart() {
super.onStart();
lifecycleRegistry.markState(Lifecycle.State.STARTED);
}
@NonNull
@Override
public Lifecycle getLifecycle() {
return lifecycleRegistry;
}
}
MyActivity 实现了 LifecycleOwner 接口，getLifecycle() 返回 lifecycleRegistry 实例。lifecycleRegistry 实例是在 onCreate() 方法中创建的，并且在各个生命周期内调用 markState() 方法完成生命周期事件的传递。这就完成了 LifecycleOwner 的自定义，也即 MyActivity 变成了 LifecycleOwner ，然后就可以和实现了 LifecycleObserver 接口的类配合使用了。
补充一点，观察者的方法可以接收一个参数 LifecycleOwner 用来获取当前状态，或者继续添加观察者。 若注解的是 ON_ANY 还可以接收 Event ，用于区分是哪个事件，代码如下：
class TestObserver implements LifecycleObserver {
@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
void onCreated(LifecycleOwner owner) {
//owner.getLifecycle().addObserver(anotherObserver);
//owner.getLifecycle().getCurrentState();
}
@OnLifecycleEvent(Lifecycle.Event.ON_ANY)
void onAny(LifecycleOwner owner, Lifecycle.Event event) {
//event.name()
}
}
MVP 架构中使用 Lifecycle
在 MVP 架构中可以把 presenter 作为观察者：
public class LifecycleTestActivity extends AppCompatActivity implements IView {
private String TAG = "Lifecycle_Test";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_lifecycle_test);
//Lifecycle 生命周期
//getLifecycle().addObserver(new MyObserver());
//MVP中使用Lifecycle
getLifecycle().addObserver(new MyPresenter(this));
Log.i(TAG, "onCreate: ");
}
@Override
protected void onResume() {
super.onResume();
Log.i(TAG, "onResume: ");
}
@Override
protected void onPause() {
super.onPause();
Log.i(TAG, "onPause: ");
}
@Override
public void showView() {}
@Override
public void hideView() {}
}
//Presenter
class MyPresenter implements LifecycleObserver {
private static final String TAG = "Lifecycle_Test";
private final IView mView;
public MyPresenter(IView view) {mView = view;}
@OnLifecycleEvent(value = Lifecycle.Event.ON_START)
private void getDataOnStart(LifecycleOwner owner){
Log.i(TAG, "getDataOnStart: ");
Util.checkUserStatus(result -> {
//checkUserStatus是耗时操作，回调后检查当前生命周期状态
if (owner.getLifecycle().getCurrentState().isAtLeast(STARTED)) {
start();
mView.showView();
}
});
}
@OnLifecycleEvent(value = Lifecycle.Event.ON_STOP)
private void hideDataOnStop(){
Log.i(TAG, "hideDataOnStop: ");
stop();
mView.hideView();
}
}
//IView
interface IView {
void showView();
void hideView();
}
这里是让 Presenter 实现 LifecycleObserver 接口，同样在方法上添加相应的 @OnLifecycleEvent 注解，最后在 Activity 中作为观察者添加到 Lifecycle 中。
这样做好处是啥呢？ 当 Activity 生命周期发生变化时，MyPresenter 就可以感知并执行方法，不需要在 MainActivity 的 onStart()、onStop() 方法中调用 MyPresenter 的实例的方法了。
Presenter 类自动感知生命周期，如果需要在其他的 Activity 或 Fragment 也使用这个 Presenter ，只需添加其为观察者即可。让 Presenter 存储自己的逻辑，减轻 Activity 或 Fragment 中代码，更易于管理。
另外，注意到 getDataOnStart() 中耗时校验回调后，对当前生命周期状态进行了检查：至少处于 STARTED 状态才会继续执行 start() 方法，也就是保证了 Activity 停止后不会走 start() 方法。
这样，使用 LifeCycle 后，文章前面遇到的 2 个问题得到了解决。
Application 生命周期 ProcessLifecycleOwner
以前对 App 进入前后台的判断是通过在 Application 中调用 registerActivityLifecycleCallbacks(callback) ，然后在 callback 中利用一个全局变量做计数，在 onActivityStarted() 中计数加 1 ，在 onActivityStopped() 方法中计数减 1 ，从而判断前后台切换。
而使用 ProcessLifecycleOwner 可以直接获取应用前后台切换状态。（记得先引入 lifecycle-process 依赖）
使用方式和 Activity 中类似，只不过要使用 ProcessLifecycleOwner.get() 获取 ProcessLifecycleOwner ，代码如下：
public class MyApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
// 注册Application生命周期观察者
ProcessLifecycleOwner.get().getLifecycle().addObserver(new ApplicationLifecycleObserver());
}
/**
* Application生命周期观察，提供整个应用进程的生命周期
*
* Lifecycle.Event.ON_CREATE只会分发一次，Lifecycle.Event.ON_DESTROY不会被分发。
*
* 进入第一个Activity时，ProcessLifecycleOwner将分发Lifecycle.Event.ON_START，
* Lifecycle.Event.ON_RESUME。
* 而Lifecycle.Event.ON_PAUSE，Lifecycle.Event.ON_STOP将在最后一个Activit退出后后延迟分发。
* 如果由于配置更改而重建Activity，此延迟足以保证ProcessLifecycleOwner不会分发任何事件。
*
* 作用：监听应用程序进入前台或后台
*/
private static class ApplicationLifecycleObserver implements LifecycleObserver {
@OnLifecycleEvent(Lifecycle.Event.ON_START)
private void onAppForeground() {
Log.w(TAG, "ApplicationObserver: app moved to foreground");
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
private void onAppBackground() {
Log.w(TAG, "ApplicationObserver: app moved to background");
}
}
}
看到确实很简单，和前面 Activity 的 Lifecycle 用法几乎一样，而我们使用 ProcessLifecycleOwner 就显得很优雅了。
源码分析
本文源码基于 androidx.lifecycle:lifecycle-runtime:2.3.1
Lifecycle 主要使用两个枚举类型来追踪与其关联的组件（Activity 或 Fragment）的生命周期状态，Lifecycle 代码如下：
public abstract class Lifecycle {
// 对应 LifecycleOwner 的 Event
public enum Event {
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY;
}
// 对应 LifecycleOwner 的状态
public enum State {
// 对于 Activity 来说，在 Activity 的 onDestroy() 方法调用之前到达这个状态。
DESTROYED,
// 对于 Activity 来说，这是 Activity 已经构建但是 onCreate() 方法调用前的状态。
INITIALIZED,
// 对于 Activity 来说，这是 Activity 调用 onCreate() 后，调用 onStop() 前的状态。
CREATED,
//对于 Activity 来说，这是 Activity 调用 onStart() 后，调用 onPause() 前的状态。
STARTED,
// 对于 Activity 来说，是调用 Activity 的 onResume() 方法后到达的状态。
RESUMED;
// 比较当前状态是否 >= 传入的状态
public boolean isAtLeast(@NonNull State state) {
return compareTo(state) >= 0;
}
}
}
这两个枚举类型分别是：
- Event：分发的生命周期事件，对应于 LifecycleOwner（Activity 或 Fragment）的生命周期方法。
- State：生命周期状态，对应于 LifecycleOwner 所处的生命周期状态，Event 会触发 State 的改变。
关于 Activity 中 State 与 Event 的关系，官网有张图很清晰：
其中 State 是图中的一个个节点， Event 是触发节点改变的事件。
前面提到 Activity 实现了 LifecycleOwner 接口，所以才能直接使用 getLifecycle() 方法，具体是在androidx.activity.ComponentActivity 中，Activity 继承自 ComponentActivity ，我们来看看 ComponentActivity 中是怎么处理的:
public class ComponentActivity extends androidx.core.app.ComponentActivity implements LifecycleOwner{
private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
...
// 使用 ReportFragment 监听 Activity 的生命周期状态
ReportFragment.injectIfNeededIn(this);
...
}
@NonNull
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
}
乍一看，并没有在 ComponentActivity 的生命周期方法中找到对应的代码，实际监听生命周期的处理在 ReportFragment 的 injectIfNeededIn() 方法中：
public class ReportFragment extends android.app.Fragment {
public static void injectIfNeededIn(Activity activity) {
if (Build.VERSION.SDK_INT >= 29) {
// API 29+，直接使用 registerActivityLifecycleCallbacks() 监听生命周期
LifecycleCallbacks.registerIn(activity);
}
// API 29之前，添加 ReportFragment 监听生命周期
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();
}
}
@Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
dispatch(Lifecycle.Event.ON_CREATE);
}
@Override
public void onStart() {
super.onStart();
dispatch(Lifecycle.Event.ON_START);
}
@Override
public void onResume() {
super.onResume();
dispatch(Lifecycle.Event.ON_RESUME);
}
@Override
public void onPause() {
super.onPause();
dispatch(Lifecycle.Event.ON_PAUSE);
}
@Override
public void onStop() {
super.onStop();
dispatch(Lifecycle.Event.ON_STOP);
}
@Override
public void onDestroy() {
super.onDestroy();
dispatch(Lifecycle.Event.ON_DESTROY);
}
private void dispatch(@NonNull Lifecycle.Event event) {
if (Build.VERSION.SDK_INT < 29) {
// API 29之前才需要这样分发
dispatch(getActivity(), event);
}
}
//在API 29及以上，使用的生命周期回调
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);
}
}
}
在 API 29及以上，使用 registerActivityLifecycleCallbacks() 来监听 Activity 的生命周期，在LifecycleCallbacks 类中可以看到， dispatch(activity, Lifecycle.Event.ON_RESUME) 在onActivityPostResumed()方法中调用，而 dispatch(activity, Lifecycle.Event.ON_PAUSE) 在onActivityPrePaused()方法中调用，这两个生命周期方法一个在 onResume() 方法之后触发，一个在 onPause() 方法之前触发，这就是前面的打印为什么一个在 onResume() 之后，一个在 onPause() 之前的原因。
API 29 以下，添加 ReportFragment 来监听 Activity 的生命周期。一般我们通过重写 onCreateView() 方法来给自定义 Fragment 添加布局，注意这里 ReportFragment 中没有重写这个方法，ReportFragment 是没有布局的透明Fragment。ReportFragment 的作用就是获取生命周期，因为 fragment 生命周期是依附于 Activity 的，好处就是把这部分逻辑抽离出来，实现 Activity 的无侵入。如果你对 Glide 比较熟，就会知道它也是使用透明Fragment 来获取生命周期的。
上面的代码中无论是使用 LifecycleCallbacks 还是使用 ReportFragment 最后都会在对应的生命周期方法中执行对应的dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event)方法：
public class ReportFragment extends android.app.Fragment {
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);
}
}
}
}
当前 Activity 实现了 LifecycleOwner 接口，会调用LifecycleRegistry的handleLifecycleEvent(event)方法来对相应的事件进行处理，这样就把生命周期事件的处理转移到了 LifecycleRegistry 中：
public class LifecycleRegistry extends Lifecycle {
// LifecycleObserver 当前状态
private State mState;
// LifecycleOwner 的弱引用
private final WeakReference<LifecycleOwner> mLifecycleOwner;
public LifecycleRegistry(@NonNull LifecycleOwner provider) {
this(provider, true);
}
private LifecycleRegistry(@NonNull LifecycleOwner provider, boolean enforceMainThread) {
mLifecycleOwner = new WeakReference<>(provider);
// 默认初始化为 INITIALIZED
mState = INITIALIZED;
mEnforceMainThread = enforceMainThread;
}
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
State next = getStateAfter(event); // 获取 event 触发后的下一个状态
moveToState(next); // 移动到这个状态
}
// 对应于官网那张图
static State getStateAfter(Event event) {
switch (event) {
case ON_CREATE:
case ON_STOP:
return CREATED;
case ON_START:
case ON_PAUSE:
return STARTED;
case ON_RESUME:
return RESUMED;
case ON_DESTROY:
return DESTROYED;
case ON_ANY:
break;
}
throw new IllegalArgumentException("Unexpected event value " + event);
}
}
在 handleLifecycleEvent() 方法中先调用getStateAfter()方法获取 event 触发后的下一个状态，对应前面那张图，然后调用了moveToState()方法：
private void moveToState(State next) {
if (mState == next) {
return;
}
// 更新状态
mState = next;
// 正在 sync() 或正在 addObserver()
if (mHandlingEvent || mAddingObserverCounter != 0) {
mNewEventOccurred = true;
// we will figure out what to do on upper level.
return;
}
mHandlingEvent = true;
// 同步
sync();
mHandlingEvent = false;
}
在 moveToState() 方法中将 LifecycleOwner 当前状态 mState 与下一个状态 next 比较，如果相等，直接 return；如果不相等，调用 sync() 方法同步。在 sync() 方法中出现了一个新的数据结构 mObserverMap， 我们先来分析一下这个数据结构，mObserverMap 是 FastSafeIterableMap<K, V> 类型的，代码如下：
// 简陋版的 LinkedHashMap，支持遍历时的元素修改，比 SafeIterableMap 占用的内存多，非线程安全
public class FastSafeIterableMap<K, V> extends SafeIterableMap<K, V> {
private HashMap<K, Entry<K, V>> mHashMap = new HashMap<>();
@Override
protected Entry<K, V> get(K k) {
return mHashMap.get(k);
}
@Override
public V putIfAbsent(@NonNull K key, @NonNull V v) {
// 从 mHashMap 中获取 key 对应的 current( current 类型是 Entry<K,V> )
Entry<K, V> current = get(key);
// 如果存在，返回 current.mValue
if (current != null) {
return current.mValue;
}
// 如果不存在，存入 mHashMap
mHashMap.put(key, put(key, v));
return null;
}
@Override
public V remove(@NonNull K key) {
V removed = super.remove(key);
mHashMap.remove(key);
return removed;
}
public boolean contains(K key) {
return mHashMap.containsKey(key);
}
// 获取 mHashMap 中 k 对应的节点在链表中的上一个节点
public Map.Entry<K, V> ceil(K k) {
if (contains(k)) {
return mHashMap.get(k).mPrevious;
}
return null;
}
}
其添加元素的方法为 putIfAbsent() 方法，其实是把数据存储在其内部成员 mHashMap 中。它的 eldest()、newest() 方法来自父类 SafeIterableMap ，下面来看看 SafeIterableMap：
// 看起来是 map ,实际是 LinkedList ,支持遍历时修改元素，非线程安全
public class SafeIterableMap<K, V> implements Iterable<Map.Entry<K, V>> {
// 最早添加的 entry
Entry<K, V> mStart;
// 最新添加的 entry
private Entry<K, V> mEnd;
private int mSize = 0;
// 返回最早添加的 entry 或 null
public Map.Entry<K, V> eldest() {
return mStart;
}
// 返回最新添加的 entry 或 null
public Map.Entry<K, V> newest() {
return mEnd;
}
static class Entry<K, V> implements Map.Entry<K, V> {
@NonNull
final K mKey;
@NonNull
final V mValue;
// 下一个节点
Entry<K, V> mNext;
// 上一个节点
Entry<K, V> mPrevious;
}
}
分析发现 SafeIterableMap 实际上是一个 Entry<K, V> 组成的双链表，FastSafeIterableMap 是对SafeIterableMap 的进一步封装，在 Entry<K, V> 的基础上添加了K，存储在HashMap<K, Entry<K, V>>中，这样方便快速通过 key 获取 value ，就不需要通过链表一个个遍历了。
mObserverMap 是用来存储观察者的，mObserverMap 添加观察者的地方就在 getLifecycle().addObserver() 中，代码如下：
public class LifecycleRegistry extends Lifecycle {
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
// 检查是否是主线程
enforceMainThreadIfNeeded("addObserver");
// 初始状态
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
// 将 observer 与 initialState 一起封装到 ObserverWithState 中，ObserverWithState 是一个内部类
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
// observer 作为 key，ObserverWithState 作为 value，添加到 mObserverMap
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
if (previous != null) {
return; // 已经添加过，直接返回
}
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
// LifecycleOwner被回收了，直接返回
return;
}
// isReentrance为 true 表示正在 sync() 或正在 addObserver()
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
// 获取目标状态
State targetState = calculateTargetState(observer);
mAddingObserverCounter++;
// 关注 1
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--;
}
static class ObserverWithState {
State mState;
LifecycleEventObserver mLifecycleObserver;
// 构造函数
ObserverWithState(LifecycleObserver observer, State initialState) {
// 初始化mLifecycleObserver
mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
mState = initialState;
}
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
// mState的作用是：新的事件触发后遍历通知所有观察者时，
// 判断是否已经通知这个观察者了，即防止重复通知。
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}
}
在 addObserver() 方法中用 observer 创建带状态的观察者 ObserverWithState ， observer 作为key，ObserverWithState 作为value，添加到 mObserverMap 中。
关注 1 处代码的目的就是通过分发 Event 把当前添加的观察者的 State 一步一步同步到最新状态 targetState 。这就导致，比如你在 Activity 的 onResume() 方法中通过 addObserver() 添加观察者，但是 onResume() 之前的事件（ ON_CREATE 、 ON_START ）也会分发给观察者，这样就导致了粘性问题。这里我们后面还会提到。
我们回到最前面 LifecycleRegistry 中的 sync() 方法，前面我们已经分析了 mObserverMap 的数据结构：
public class LifecycleRegistry extends Lifecycle {
// 存储 observers ，遍历时可以删除或添加
// 后添加的 observer 的 state <= 先添加的 observer 的 state
private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap
= new FastSafeIterableMap<>();
// happens only on the top of stack (never in reentrance),
// so it doesn't have to take in account parents
private void sync() {
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
// LifecycleOwner 已经被回收了
if (lifecycleOwner == null) {
throw new IllegalStateException("LifecycleOwner of this LifecycleRegistry is already"
+ "garbage collected. It is too late to change lifecycle state.");
}
while (!isSynced()) { // isSynced() 表示所有观察者都同步完了
mNewEventOccurred = false;
// mObserverMap 中存储的是观察者，状态按照从大到小排列，
// 如果 mState 比 mObserverMap 中状态最大的小
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
backwardPass(lifecycleOwner);
}
Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
// 如果 mState 比 mObserverMap 中状态最小的大
if (!mNewEventOccurred && newest != null
&& mState.compareTo(newest.getValue().mState) > 0) {
forwardPass(lifecycleOwner);
}
}
mNewEventOccurred = false;
}
private boolean isSynced() {
if (mObserverMap.size() == 0) {
return true;
}
// mObserverMap 中最早添加的观察者的状态
State eldestObserverState = mObserverMap.eldest().getValue().mState;
// mObserverMap 中最新添加的观察者的状态
State newestObserverState = mObserverMap.newest().getValue().mState;
return eldestObserverState == newestObserverState && mState == newestObserverState;
}
}
在 sync() 方法中使用了 while (!isSynced())，isSynced() 表示最早和最新添加的观察者的状态一致，且都是当前状态 mState ，说明已经同步完了。其中 mObserverMap.eldest().getValue() 返回的是最早添加的到 mObserverMap 中的带状态的观察者 ObserverWithState ，mObserverMap.eldest().getValue().mState 就是最早添加到 mObserverMap 中的观察者的状态。
为什么使用 while 循环呢？因为如果 LifecycleOwner 当前状态为 RESUMED ，而观察者的状态为 INITIALIZED ，观察者的状态需要从 INITIALIZED -> CREATED -> STARTED -> RESUMED 一步一步转变，需要多次分发事件进行状态同步。
如果 mObserverMap 中有观察者的状态比 mState 大，观察者走 backwardPass() 方法；如果 mObserverMap 中有观察者的状态比 mState 小，观察者走 forwardPass() 方法。
public class LifecycleRegistry extends Lifecycle {
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();
// 取 mObserverMap 中的状态比 mState 小的观察者
while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey()))) {
pushParentState(observer.mState);
// 观察者分发事件
observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));
popParentState();
}
}
}
private void backwardPass(LifecycleOwner lifecycleOwner) {
// 倒序遍历链表，从新到老
Iterator<Entry<LifecycleObserver, ObserverWithState>> descendingIterator =
mObserverMap.descendingIterator();
while (descendingIterator.hasNext() && !mNewEventOccurred) {
Entry<LifecycleObserver, ObserverWithState> entry = descendingIterator.next();
ObserverWithState observer = entry.getValue();
while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey()))) {
Event event = downEvent(observer.mState);
pushParentState(getStateAfter(event));
// 观察者分发事件
observer.dispatchEvent(lifecycleOwner, event);
popParentState();
}
}
}
// 回退
private static Event downEvent(State state) {
switch (state) {
case INITIALIZED:
throw new IllegalArgumentException();
case CREATED:
return ON_DESTROY;
case STARTED:
return ON_STOP;
case RESUMED:
return ON_PAUSE;
case DESTROYED:
throw new IllegalArgumentException();
}
throw new IllegalArgumentException("Unexpected state value " + state);
}
// 前进
private static Event upEvent(State state) {
switch (state) {
case INITIALIZED:
case DESTROYED:
return ON_CREATE;
case CREATED:
return ON_START;
case STARTED:
return ON_RESUME;
case RESUMED:
throw new IllegalArgumentException();
}
throw new IllegalArgumentException("Unexpected state value " + state);
}
}
backwardPass() 方法，从新到老分发，循环使用 downEvent() 和 observer.dispatchEvent() ，连续分发事件；forwardPass() 方法，从老到新分发，循环使用 upEvent() 和 observer.dispatchEvent() ，连续分发事件。
有没有发现上面代码11-16行与前面关注1处的代码基本一致，它们的作用是一样的，都是进行事件分发、状态同步。
observer.dispatchEvent() 最终执行 ObserverWithState 的 dispatchEvent() 方法：
public class LifecycleRegistry extends Lifecycle {
static class ObserverWithState {
State mState;
LifecycleEventObserver mLifecycleObserver;
// 构造函数
ObserverWithState(LifecycleObserver observer, State initialState) {
// 初始化 mLifecycleObserver
mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
mState = initialState;
}
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
// mState 的作用是：新的事件触发后遍历通知所有观察者时，
// 判断是否已经通知这个观察者了，即防止重复通知。
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}
}
ObserverWithState的dispatchEvent()方法又调用了 mLifecycleObserver 的onStateChanged()方法，在 ObserverWithState 的构造方法中通过 Lifecycling.lifecycleEventObserver(observer) 初始化了mLifecycleObserver，最终返回 ReflectiveGenericLifecycleObserver 对象，代码如下：
public class Lifecycling {
@NonNull
static LifecycleEventObserver lifecycleEventObserver(Object object) {
...
return new ReflectiveGenericLifecycleObserver(object);
}
}
其中ReflectiveGenericLifecycleObserver代码如下：
class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
private final Object mWrapped;
private final CallbackInfo mInfo;
ReflectiveGenericLifecycleObserver(Object wrapped) {
// mWrapped 即为我们添加的观察者
mWrapped = wrapped;
// mInfo 为观察者对应的 CallbackInfo
mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
}
@Override
public void onStateChanged(LifecycleOwner source, Event event) {
mInfo.invokeCallbacks(source, event, mWrapped);
}
}
ReflectiveGenericLifecycleObserver 的 onStateChanged() 方法又会调用mInfo.invokeCallbacks(source, event, mWrapped)，其中 mWrapped 是我们添加的观察者，而 mInfo 来自 ClassesInfoCache 中的静态内部类CallbackInfo：
final class ClassesInfoCache {
// 单例
static ClassesInfoCache sInstance = new ClassesInfoCache();
// 使用 mCallbackMap 缓存观察者类对应的 CallbackInfo
private final Map<Class<?>, CallbackInfo> mCallbackMap = new HashMap<>();
CallbackInfo getInfo(Class<?> klass) {
CallbackInfo existing = mCallbackMap.get(klass);
// 如果存在，直接返回
if (existing != null) {
return existing;
}
// 如果不存在，创建
existing = createInfo(klass, null);
return existing;
}
// klass为观察者类
private CallbackInfo createInfo(Class<?> klass, @Nullable Method[] declaredMethods) {
Class<?> superclass = klass.getSuperclass();
// 使用 handlerToEvent 来存储观察者类中方法对应的 Lifecycle.Event
Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();
if (superclass != null) {
CallbackInfo superInfo = getInfo(superclass);
if (superInfo != null) {
handlerToEvent.putAll(superInfo.mHandlerToEvent);
}
}
Class<?>[] interfaces = klass.getInterfaces();
for (Class<?> intrfc : interfaces) {
for (Map.Entry<MethodReference, Lifecycle.Event> entry : getInfo(
intrfc).mHandlerToEvent.entrySet()) {
verifyAndPutHandler(handlerToEvent, entry.getKey(), entry.getValue(), klass);
}
}
Method[] methods = declaredMethods != null ? declaredMethods : getDeclaredMethods(klass);
boolean hasLifecycleMethods = false;
// 遍历观察者类中的方法
for (Method method : methods) {
// 获取方法上的 @OnLifecycleEvent 注解
OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
if (annotation == null) {
continue;
}
hasLifecycleMethods = true;
Class<?>[] params = method.getParameterTypes(); // 获取方法参数
int callType = CALL_TYPE_NO_ARG;
// 如果有参数
if (params.length > 0) {
callType = CALL_TYPE_PROVIDER;
// 第 1 个参数必须是 LifecycleOwner
if (!params[0].isAssignableFrom(LifecycleOwner.class)) {
throw new IllegalArgumentException(
"invalid parameter type. Must be one and instanceof LifecycleOwner");
}
}
Lifecycle.Event event = annotation.value();
// 如果有 2 个参数
if (params.length > 1) {
callType = CALL_TYPE_PROVIDER_WITH_EVENT;
//第 2 个参数必须是Lifecycle.Event
if (!params[1].isAssignableFrom(Lifecycle.Event.class)) {
throw new IllegalArgumentException(
"invalid parameter type. second arg must be an event");
}
//有 2 个参数，注解值只能是 ON_ANY
if (event != Lifecycle.Event.ON_ANY) {
throw new IllegalArgumentException(
"Second arg is supported only for ON_ANY value");
}
}
// 如果参数超过 2 个
if (params.length > 2) {
throw new IllegalArgumentException("cannot have more than 2 params");
}
MethodReference methodReference = new MethodReference(callType, method);
// 将methodReference对应的event存入handlerToEvent
verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
}
CallbackInfo info = new CallbackInfo(handlerToEvent);
// 将观察者对应的 CallbackInfo 存入 mCallbackMap 中
mCallbackMap.put(klass, info);
mHasLifecycleMethods.put(klass, hasLifecycleMethods);
return info;
}
static class CallbackInfo {
// Lifecycle.Event 对应的方法
final Map<Lifecycle.Event, List<MethodReference>> mEventToHandlers;
// 方法对应的 Lifecycle.Event
final Map<MethodReference, Lifecycle.Event> mHandlerToEvent;
CallbackInfo(Map<MethodReference, Lifecycle.Event> handlerToEvent) {
mHandlerToEvent = handlerToEvent;
mEventToHandlers = new HashMap<>();
// 遍历 handlerToEvent ，将 Lifecycle.Event 对应的方法存入 mEventToHandlers
for (Map.Entry<MethodReference, Lifecycle.Event> entry : handlerToEvent.entrySet()) {
Lifecycle.Event event = entry.getValue();
List<MethodReference> methodReferences = mEventToHandlers.get(event);
if (methodReferences == null) {
methodReferences = new ArrayList<>();
mEventToHandlers.put(event, methodReferences);
}
methodReferences.add(entry.getKey());
}
}
}
}
ClassesInfoCache 看起来代码很复杂，其实就是用来做缓存的，因为反射是比较昂贵的，所以用缓存来提升反射的效率。
ClassesInfoCache类中缓存了添加的观察者类、方法和对应的 Lifecycle.Event ，里面主要使用了 3 个HashMap:
- mCallbackMap：ClassesInfoCache 类中的 HashMap ，缓存观察者类对应的 CallbackInfo 。
- mEventToHandlers：CallbackInfo 类中的 HashMap ，缓存 Lifecycle.Event 对应的方法 。
- mHandlerToEvent：CallbackInfo 类中的 HashMap ，缓存方法对应的 Lifecycle.Event 。
回到 ReflectiveGenericLifecycleObserver 的 onStateChanged() 方法，onStateChanged() 方法会调用CallbackInfo 的 invokeCallbacks() 方法：
final class ClassesInfoCache {
static class 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);
}
private static void invokeMethodsForEvent(List<MethodReference> handlers,
LifecycleOwner source, Lifecycle.Event event, Object mWrapped) {
if (handlers != null) {
// 遍历 Lifecycle.Event 对应的 MethodReference
for (int i = handlers.size() - 1; i >= 0; i--) {
// 执行 MethodReference 的 invokeCallback() 方法
handlers.get(i).invokeCallback(source, event, mWrapped);
}
}
}
}
}
invokeCallbacks() 方法调用了 invokeMethodsForEvent() 方法，最终通过遍历该 event 对应的List<MethodReference> ，然后一个个执行 MethodReference 的 invokeCallback() 方法：
final class ClassesInfoCache {
static final class MethodReference {
final int mCallType;
final Method mMethod;
void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) {
switch (mCallType) {
case CALL_TYPE_NO_ARG:
mMethod.invoke(target); // 没有参数的
break;
case CALL_TYPE_PROVIDER:
mMethod.invoke(target, source); // 一个参数的：LifecycleOwner
break;
case CALL_TYPE_PROVIDER_WITH_EVENT:
mMethod.invoke(target, source, event); // 两个参数的：LifecycleOwner，Event
break;
}
}
}
}
上面就是分发相应的 event ，就会调用观察者中 event 对应的方法的流程。
总结一下 Lifecycle 的流程：
- 通过 getLifecycle().addObserver() 添加自定义的类为观察者存入 mObserverMap。
- 当 Activity 或 Fragment 的生命周期方法触发时，会触发 mState 改变，mObserverMap 中观察者的状态需要与 mState 对齐，判断需要前进还是后退，分发相应 Lifecycle.Event，触发 ObserverWithState 的 onStateChanged() 方法。
- ClassesInfoCache 中缓存了观察者的类、方法和对应的 Lifecycle.Event ，onStateChanged() 方法会通过反射调用 Lifecycle.Event 对应的方法。
感谢与参考
