如果博客图片裂了,请访问下面备份地址:
语雀:https://www.yuque.com/cxyfy/blog/tg16bd
公众号:https://mp.weixin.qq.com/s/8vuOj8JnGk-hwl5AU2itkQ
0. 前言
本文是深入理解「Android Architecture Components」系列文章第二篇
源码基于 1.1.1 版本
在前文,我就提到 Android Architecture Components (后简称为 AAC),是一个帮助开发者设计 健壮 、 可测试 且 可维护 的一系列库的集合。
Lifecycle 就是 AAC 中的一员,它能够帮助我们方便的管理 Activity 以及 Fragment 的生命周期。
本文带大家深入了解 Lifecycle 。
注意:本文基于 Lifecycle 1.1.1 版本,Android API 26 ,依赖如下图。
并假设读者对 Lifecycle 有基本的了解,我绘制了一个基本的类图,如果对于下面类图所涉及到的类都还算了解则可以继续阅读下去,如果完全不知道,建议阅读一些教程先。
1. Lifecycle 使用基础
在 AppCompatActivity 里我们可以通过 getLifecycle() 方法拿到 Lifecycle ,并添加 Observer 来实现对 Activity 生命周期的监听。
一个简单的使用例子如下:
1 | public class MainActivity extends AppCompatActivity { |
启动 MainActivity 就可以看到如下日志:
1 | D/MainActivity: onResume: |
日志说明我们通过上述代码确实实现了监听生命周期的功能。
那么问题来了,这是怎么做到的?
我把这个问题拆分成了两块:
- 生命周期的感知问题:
是什么感知了Activity的生命周期? - 注解方法的调用问题:
是什么调用了我们使用注解修饰的方法?
2. 感知生命周期的原理
2.1 初现端倪 ReportFragment
我通过调试堆栈发现了一个叫做 ReportFragment 的类,非常可疑,遂跟踪之。
注意:Debug 查看堆栈是阅读源码手段中最常用最简单最好用最亲民的方法,没有之一,每个人都应该熟练掌握。
来看看这个类都写了什么:
1 | public class ReportFragment extends Fragment { |
一看代码我们就知道了,它重写了生命周期回调的方法,确实是这个 ReportFragment 在发挥作用,Lifecycle 利用了 Fragment 来实现监听生命周期,并在生命周期回调里调用了内部 dispatch 的方法来分发生命周期事件。(怎么分发后面讲)
2.2 幕后“黑手” SupportActivity
从方法来看注入 Fragment 的方法应该是调用 injectIfNeededIn(Activity) 的地方了。
在通过搜索 发现 SupportActivity 调用了该方法。(API 28 的版本是 ComponentActivity ,代码实现没什么差别)
1 | public class SupportActivity extends Activity implements LifecycleOwner, Component { |
可以看到 SupportActivity 内部包含了一个 LifecycleRegistry ,并实现了 LifecycleOwner , 并且在 onCreate 方法里 调用了 ReportFragment.injectIfNeededIn(this); 注入了 ReportFragment 。
LifecycleRegistry 是 Lifecycle 的实现,并负责管理 Observer ,在上面【2】章节的 dispatch 方法中已经看到了该类的出现,它的 handleLifecycEvent 接受了生命周期的回调。
2.3 Lifecycle 的生命周期事件与状态的定义
这小节补充一下 Lifecycle 的回调与 Activity 、Fragment 的生命周期对标相关知识,后面分析会出现。
Lifecycle 中定义了 Event : 表示生命周期事件, State : 表示当前状态。
2.3.1 Lifecycle.Event
Lifecycle 定义的生命周期事件,与 Activity 生命周期类似。
1 | public enum Event { |
2.3.2 Lifecycle.State
State 表示当前组件的生命周期状态。
1 | /** |
2.3.3 Event 与 State 的关系:

(图1.图来源见【8.2】)
2.4 小结
通过研究我们发现,SupportActivity 在 onCreate 方法里注入了 ReportFragment ,通过 Fragment 的机制来实现生命周期的监听。
实际上利用 Fragment 监听 Activity 生命周期的功能在开源社区由来已久, Lifecycle 并非原创,Lifecycle 的出现算是把这个实现官方化了。
相比于第三方的实现,嵌入到 Android 源码中的实现对开发者来说是非常有好处的,即屏蔽了细节,又降低了使用难度。
**
3. 注解方法被调用的原理
OnLifecycleEvent 注解:
1 | (RetentionPolicy.RUNTIME) |
看到有 RetentionPolicy.RUNTIME 修饰,我就猜测它是靠反射来实现了,不过还是看下具体实现验证下吧。
之前在了解完生命周期监听的原理的同时,我们也看到了生命周期事件的接收者 LifecycleRegistry ,是它的 handleLifecycleEvent() 接收了事件,我们继续追踪。
1 | /** |
其实从方法注释就能看出来了,就是它处理了状态并通知了 observer 。
看下 getStateAfter() 方法:
1 | static State getStateAfter(Event event) { |
getStateAfter() 这个方法根据当前 Event 获取对应的 State ,细看其实就是 【2.3.3】中那个图的代码实现。
接下去看 sync() 方法:
1 | private void sync() { |
sync 方法里对比了当前 mState 以及上一个 State ,看是应该前移还是后退,这个对应了生命周期的前进跟后退,打个比方就是从 onResume -> onPause (forwardPass),onPause -> onResume (backwardPass),拿 backwardPass() 举例吧。(forwardPass方法处理类似)
1 | private void backwardPass(LifecycleOwner lifecycleOwner) { |
通过源码可以看到, backwardPass() 方法调用 downEvent 获取往回退的目标 Event。
可能比较抽象,举个例子,在 onResume 的状态,我们按了 home,这个时候就是 RESUMED 的状态变到 STARTED 的状态,对应的要发送的 Event 是 ON_PAUSE,这个就是 backwardPass() 的逻辑了。
如果前面的代码都是引子的话,我们最终看到了一丝分发的痕迹了—— observer.dispatchEvent(lifecycleOwner, event) 。
1 | static class ObserverWithState { |
可以看到最后调用了 GenericLifecycleObserver.onStateChanged() 方法,再跟。
1 | class ReflectiveGenericLifecycleObserver implements GenericLifecycleObserver { |
这个类的代码比较多,不过也不复杂。可以看到最后代码走到了invokeCallback() ,通过反射调用了方法。
而这个方法是 createInfo() 方法中反射遍历我们注册的 Observer 的方法找到的被 OnLifecycleEvent 注解修饰的方法,并且按 Event 类型存储到了 info.mEventToHandlers 里。
到这里整个链路就清晰了,我们在 Observer 用注解修饰的方法,会被通过反射的方式获取,并保存下来,然后在生命周期发生改变的时候再找到对应 Event 的方法,通过反射来调用方法。
注意:源码中还有一些细节比较繁琐,比如怎么获取的方法,怎么包装的 Observer ,State 的管理以及存储等,就不在这里展开了,有兴趣的自行了解。
4. 图解 Lifecycle
如果被代码绕晕了,也没关系,我画了类图以及时序图,帮助大家理解,配合着类图跟时序图看代码,会容易理解很多。
4.1 Lifecycle 相关原理类的 UML 图
核心类 UML 图整理如下:

(图2. Lifecycle-UML图)
4.1 Lifecycle 原理时序图
图中起始于 onCreate ,顺便利用 onCreate 描绘整个流程。(其他生命周期原理一样,不重复画了)

(图3. Lifecycle 时序图)
4.3 Lifecycle State 与 Event 的关系图
图展示了 State 与 Event 的关系,以及随着生命周期走向它们发生的变化。

(图4. State 与 Event 的关系图)
5. Lifecycle 的实战应用
好了,重点的原理我们分析完毕了,如果看一遍没有理解,就多看几遍。
这个小节来讲讲 Lifecycle 的实战应用。
Lifecycle 的应用场景非常广泛,我们可以利用 Lifecycle 的机制来帮助我们将一切跟生命周期有关的业务逻辑全都剥离出去,进行完全解耦,比如视频的暂停与播放,Handler 的消息移除,网络请求的取消操作,Presenter 的 attach&detach View 等等,并且可以以一个更加优雅的方式实现,还我们一个更加干净可读的 Activity & Fragment。
下面举个简单的例子:
5.1 自动移除 Handler 的消息:LifecycleHandler
我们担心 Handler 会导致内存泄露,通常会在 onDestroy 里移除消息,写多了烦,但是结合 Lifecyc le ,我们可以写出一个 lifecycle-aware 的 Handler,自动在 onDestroy 里移除消息,不再需要写那行样板代码。
代码实现如下:

该代码已经包含在我的开源库 Pandora 里了,可以访问:https://github.com/AlanCheen/Pandora ,直接依赖使用,欢迎 star。
5.2 给 ViewHolder 添加 Lifecycle 的能力
有些 App 会有长列表的页面,里面塞了各种不用样式的 Item,通常会用 RecyclerView 来实现,有时候部分 Item 需要获知生命周期事件,比如包含播放器的 Item 需要感知生命周期来实现暂停/重播的功能,借助 Lifecycle 我们可以实现。
具体实现可以参考我的开源库 Flap:https://github.com/AlanCheen/Flap 。
6. 知识点梳理和汇总
**Lifecycle**库通过在SupportActivity的onCreate中注入ReportFragment来感知发生命周期;**Lifecycle**抽象类,是Lifecycle库的核心类之一,它是对生命周期的抽象,定义了生命周期事件以及状态,通过它我们可以获取当前的生命周期状态,同时它也奠定了观察者模式的基调;(我是党员你看出来了吗:-D)**LifecycleOwner**,描述了一个拥有生命周期的组件,可以自己定义,不过通常我们不需要,直接使用AppCompatActivity等即可;**LifecycleRegistry**是Lifecycle的实现类,它负责接管生命周期事件,同时也负责Observer的注册以及通知;**ObserverWithState**,是 Observer 的一个封装类,是它最终 通过ReflectiveGenericLifecycleObserve调用了我们用注解修饰的方法;**LifecycleObserver**,Lifecycle 的观察者,利用它我们可以享受 Lifecycle 带来的能力;**ReflectiveGenericLifecycleObserver**,它存储了我们在 Observer 里注解的方法,并在生命周期发生改变的时候最终通过反射的方式调用对应的方法。
7. 总结
Lifecycle 是一个专门用来处理生命周期的库,它能够帮助我们将 Acitivity、Framgent 的生命周期处理与业务逻辑处理进行完全解耦,让我们能够更加专注于业务;通过解耦让 Activity、Fragment 的代码更加可读可维护。
可以这么说 Lifecycle 的出现彻底解决了 Android 开发遇到的生命周期处理难题,并且还给开发者带来了新的架构姿势,让我们可以设计出更加合理的架构。
妈妈再也不用担心我遇到生命周期难题了!
同时 Lifecycle 作为 AAC 的基石,为 LiveData、ViewModel 的登场打下坚实的基础。
那么,LiveData、ViewModel 的背后又是什么原理呢?
尽请期待下一篇!