生命周期感知 Lifecycle
奉上翻译原文地址： ；翻译过程中加上了自己的一点理解。理解不对的地方直接评论就好。
生命周期感知组件可以感知其他组件的生命周期，例如 activity，fragment等，以便于在组件的生命周期状态变化时做出相应的操作。支持生命感知的组件可以帮你更好的组织代码，让你的代码更轻，更好维护。
对于需要响应生命周期变化的组件，我们通常是在 activity 和 fragment 的生命周期方法里实现一些操作。然而，这种模式会导致代码不好管理，容易出现错误。通过支持生命周期的组件，可以将原本在生命周期方法里的操作移到组件内部。
androidx.lifecycle 包提供的接口和类可以帮助我们构建可感知生命周期的组件，这些组件就可以根据 activity 或者 fragment 的生命周期状态自行调整行为。
在项目添加生命周期感知组件的依赖，可以参加这个页面：
//包含 viewmodel 和 livedata
implementation "androidx.lifecycle:lifecycle-extensions:$lifecycle_version"
// 或者 - 只包含 viewmodel
implementation "androidx.lifecycle:lifecycle-viewmodel:$lifecycle_version"
// kotlin使用 lifecycle-viewmodel-ktx
// implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:$lifecycle_version"
// 或者，只包含 livedata
implementation "androidx.lifecycle:lifecycle-livedata:$lifecycle_version"
// 或者，只有 lifecycle（没有 livedata,viewmodel）
implementation "androidx.lifecycle:lifecycle-runtime:$lifecycle_version"
// kotlin 使用 kapt 替代 annotationprocessor
annotationprocessor "androidx.lifecycle:lifecycle-compiler:$lifecycle_version"
// 如果使用了 java8 使用这个替代上面的 lifecycle-compiler
implementation "androidx.lifecycle:lifecycle-common-java8:$lifecycle_version"
// 可选 - reactstreams 对 livedata 的支持
implementation "androidx.lifecycle:lifecycle-reactivestreams:$lifecycle_version"
//kotlin 使用 lifecycle-reactivestreams-ktx
implementation "androidx.lifecycle:lifecycle-reactivestreams-ktx:$lifecycle_version"
// 可选 livedata 的测试
testimplementation "androidx.arch.core:core-testing:$lifecycle_version"
如果使用的是 kotlin 记得添加 kotlin-kapt 插件
android 框架中定义的大多数应用组件都具有生命周期。生命周期是由操作系统或框架代码管理的。
虽然组件的生命周期不由我们控制，但是我们必须尊重组件的生命周期，不然很可能会导致内存泄漏甚至崩溃。
假如我们有个 activity 在屏幕上显示设备位置信息，最常见的实现可能就是这样了：
kotlin
internal class mylocationlistener(
private val context: context,
private val callback: (location) -> unit
) {
fun start() {
// 连接系统位置服务
}
fun stop() {
// 断开系统位置服务
}
}
class myactivity : appcompatactivity() {
private lateinit var mylocationlistener: mylocationlistener
override fun oncreate(...) {
mylocationlistener = mylocationlistener(this) { location ->
// 更新 ui
}
}
public override fun onstart() {
super.onstart()
mylocationlistener.start()
// 管理其他需要响应 activity 生命周期的组件
}
public override fun onstop() {
super.onstop()
mylocationlistener.stop()
// 管理其他需要响应 activity 生命周期的组件
}
}
java
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();
// 管理其他需要响应 activity 生命周期的组件
}
@override
public void onstop() {
super.onstop();
mylocationlistener.stop();
// 管理其他需要响应 activity 生命周期的组件
}
}
目前看起来这样还不错，但在真实情况下，可能还会有其他需要响应生命周期的组件，也有可能是在 onstart() 和 onstop() 。一个两个还好，如果多了的话把这些都放在生命周期方法里，就比较难以维护。
此外，这并不能保证在 activity 或者 fragment 停止之前启动我们的组件。特别是那些需要长期运行的操作，例如在 onstart() 里的检查配置操作。这就可能会出现在 onstart() 里的操作还未启动，而 onstop() 里却要停止的情况。
kotlin
class myactivity : appcompatactivity() {
private lateinit var mylocationlistener: mylocationlistener
override fun oncreate(...) {
mylocationlistener = mylocationlistener(this) { location ->
//更新 ui
}
}
public override fun onstart() {
super.onstart()
util.checkuserstatus { result ->
// 如果在活动停止后调用此回调该怎么办？
if (result) {
mylocationlistener.start()
}
}
}
public override fun onstop() {
super.onstop()
mylocationlistener.stop()
}
}
java
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 -> {
// 如果在活动停止后调用此回调该怎么办？
if (result) {
mylocationlistener.start();
}
});
}
@override
public void onstop() {
super.onstop();
mylocationlistener.stop();
}
}
androidx.lifecycle 包提供了一些类和接口，可帮助你以弹性和隔离的方式解决这些问题。
生命周期
lifecycle 是一个类，它持有相关组件（例如 activity 和 fragment）的生命周期状态信息并且可以让其他对象观察到这个状态。
lifecycle 使用两个主要枚举来跟踪相关组件的生命周期状态。
event
android 框架和 lifecycle 类发出的生命周期事件。它对应到 activity 和 fragment 里的生命周期回调。
state
lifecycle 类跟踪的相关组件的当前生命周期状态。
类可以通过添加注解来侦听组件的生命周期事件。通过调用 lifecycle 的 addobserver() 方法传递进去一个你的观察对象即可，如下所示：
kotlin
class myobserver : lifecycleobserver {
@onlifecycleevent(lifecycle.event.on_resume)
fun connectlistener() {
...
}
@onlifecycleevent(lifecycle.event.on_pause)
fun disconnectlistener() {
...
}
}
mylifecycleowner.getlifecycle().addobserver(myobserver())
java
public class myobserver implements lifecycleobserver {
@onlifecycleevent(lifecycle.event.on_resume)
public void connectlistener() {
...
}
@onlifecycleevent(lifecycle.event.on_pause)
public void disconnectlistener() {
...
}
}
mylifecycleowner.getlifecycle().addobserver(new myobserver());
这个示例中，mylifecycleowner 实现了 lifecycleowner 接口。
生命周期所有者
lifecycleowner 是一个单方法的接口，它表示这个类有生命周期。它有一个类必须实现的方法： getlifecycle() 。如果你想管理整个应用进程的生命周期可以看看这个 processlifecycleowner
这个接口从单个类中抽象出生命周期的所有权，例如 activity 和 fragment，可以与你写的组件共享生命周期。任何类都可以实现 lifecycleowner 接口。
实现 lifecycleobserver 的组件与实现 lifecycleowner 的组件可以无缝地衔接，因为所有者可以提供生命周期，观察者可以注册该生命周期以观察。
对于上面显示位置的例子，就可以让 mylocationlistener 实现 lifecycleobserver ，并在 activity 的生命周期方法 oncreate() 里初始化。这样的话 mylocationlistener 类就可以自给自足，在自己本身内部实现响应生命周期变化的逻辑处理。每个组件都在自己内部响应生命周期变化就让 activity 和 fragment 的逻辑变得很清晰。
kotlin
class myactivity : appcompatactivity() {
private lateinit var mylocationlistener: mylocationlistener
override fun oncreate(...) {
mylocationlistener = mylocationlistener(this, lifecycle) { location ->
// 更新 ui
}
util.checkuserstatus { result ->
if (result) {
mylocationlistener.enable()
}
}
}
}
java
class myactivity extends appcompatactivity {
private mylocationlistener mylocationlistener;
public void oncreate(...) {
mylocationlistener = new mylocationlistener(this, getlifecycle(), location -> {
// 更新 ui
});
util.checkuserstatus(result -> {
if (result) {
mylocationlistener.enable();
}
});
}
}
一个常见的用例是，如果生命周期当前状态不佳，则避免调用某些回调。 例如，如果回调在保存活动状态后运行 fragment 事务，那么它将触发崩溃，因此我们永远都不想调用该回调。
为了简化此用例，lifecycle 类允许其他对象查询当前状态。 通过方法: lifecycle.state.isatleast()
kotlin
internal class mylocationlistener(
private val context: context,
private val lifecycle: lifecycle,
private val callback: (location) -> unit
) {
private var enabled = false
@onlifecycleevent(lifecycle.event.on_start)
fun start() {
if (enabled) {
// 连接
}
}
fun enable() {
enabled = true
if (lifecycle.currentstate.isatleast(lifecycle.state.started)) {
// 如果还没连接，就去连接
}
}
@onlifecycleevent(lifecycle.event.on_stop)
fun stop() {
// 如果连接了就断开
}
}
java
class mylocationlistener implements lifecycleobserver {
private boolean enabled = false;
public mylocationlistener(context context, lifecycle lifecycle, callback callback) {
...
}
@onlifecycleevent(lifecycle.event.on_start)
void start() {
if (enabled) {
// 连接
}
}
public void enable() {
enabled = true;
if (lifecycle.getcurrentstate().isatleast(started)) {
// 如果还没连接，就去连接
}
}
@onlifecycleevent(lifecycle.event.on_stop)
void stop() {
// 如果连接了就断开
}
}
通过以上实现，我们的 locationlistener 已经具备了感知生命周期的能力并且可以做出相应的操作。如果其他的 activity 或者 fragment 想使用它，只需要初始化它即可。其他所有操作都由 locationlistener 自己处理。
如果你的库提供了需要与 android 生命周期一起使用的类，则建议使用可识别生命周期的组件。 你的库可以轻松集成这些组件，而无需在客户端进行手动生命周期管理。
自定义生命周期所有者
支持库 26.1.0 以及更高版本中的 fragment 和 activity 已经实现了 lifecycleowner 接口。
如果想要创建 lifecycleowner 的自定义类，则可以使用 lifecycleowner 类，但是需要将事件转发到该类中，如以下代码示例所示：
kotlin
class myactivity : activity(), lifecycleowner {
private lateinit var lifecycleregistry: lifecycleregistry
override fun oncreate(savedinstancestate: bundle?) {
super.oncreate(savedinstancestate)
lifecycleregistry = lifecycleregistry(this)
lifecycleregistry.markstate(lifecycle.state.created)
}
public override fun onstart() {
super.onstart()
lifecycleregistry.markstate(lifecycle.state.started)
}
override fun getlifecycle(): lifecycle {
return lifecycleregistry
}
}
java
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;
}
}
## 生命周期感知组件的最佳实践
- 尽可能的让 ui 控制器（activity 和 fragment） 保持精简。让 viewmodel 去获取数据，数据更改通过 livedata 响应到视图。
- 尝试编写数据驱动的 ui ，其中 ui 控制器的职责是在数据更改时更新视图，或者将用户操作通知给 viewmodel 。
- 将数据业务逻辑放在 viewmodel 类。viewmodel 类的定位应该是 ui 控制器和应用中其他部分的连接器。但并不是说让 viewmodel 类去获取数据，相反的应该让其他合适的组件去获取数据，viewmodel 类只是把结果提供给 ui 控制器。
- 使用数据绑定库维护视图和 ui 控制器的整洁。这让视图更具声明性，并减少在 ui 控制器的更新代码。如果你倾向于使用 java ，可以使用 butter knife 减少重复代码。
- 如果 ui 过于复杂，可以考试创建一个 presenter 类管理 ui 更新，这可能更麻烦，但是可以更好的管理 ui 。
- 避免在 viewmodel 引用 view和 activity 上下文。如果 viewmodel 生命超过 activity （配置发生更改的情况下）可能会造成 activity 泄漏，并且不被垃圾处理器回收。
- 使用 kotlin 协程来管理长时间运行的任务以及可以异步运行的其他操作。
## 生命周期感知组件的用例
生命周期感知组件可以让你在各种情况下都很好的管理生命周期，例如：
- 在粗略和细粒度的位置更新之间切换。 使用生命周期感知组件在应用可见时启用细粒度的位置更新，在应用处于后台时切换到粗粒度的更新。
- 停止和开启视频缓冲。 使用支持生命周期的组件尽快开始视频缓冲，但是将播放推迟到应用程序完全启动。 还可以使用可识别生命周期的组件在应用程序销毁时终止缓冲。
- 启动和停止网络连接。 使用可感知生命周期的组件可以在应用程序处于前台状态时实时更新（流式传输）网络数据，并在应用程序进入后台时自动暂停。
- 暂停和恢复动画绘制。 当应用程序在后台运行时，使用生命周期感知组件处理暂停动画绘制，并在应用程序在前台运行后恢复绘制。
处理停止事件
当生命周期属于 appcompatactivity 或 fragment 时，生命周期的状态更改为 created ，并且在调用 appcompatactivity 或 fragment 的 onsaveinstancestate（） 时调度 on_stop 事件。
当通过 onsaveinstancestate（） 保存 fragment 或 appcompatactivity 的状态时，在调用 on_start 之前，它的 ui 被认为是不可变的。 保存状态后尝试修改 ui 可能会导致应用程序的导航状态不一致，这就是为什么如果状态保存后应用程序运行 fragmenttransaction ，则 fragmentmanager 会引发异常的原因。 详情参见： commit()
如果观察者的关联生命周期至少不是 started， livedata 不会调用观察者，从而避免了这种极端情况。 在幕后，它在决定调用其观察者之前调用 isatleast（） 判断当前状态。
不幸的是，在 onsaveinstancestate（） 之后调用了 appcompatactivity 的 onstop（） 方法，这留下了一个空白，在该空白中，不允许 ui 状态更改，但生命周期尚未移至 created 状态。
为避免此问题，版本 beta2 及更低版本中的 lifecycle 类将状态标记为 created 而不调度事件，因此，即使直到系统调用了 onstop（） 才调度事件，任何检查当前状态的代码都将获得真实值。
不幸的是，此解决方案有两个主要问题：
- 在 api 级别 23 和更低级别上，android 系统实际上会保存
activity的状态，即使该activity已被另一个activity部分覆盖 。 换句话说，android 系统调用onsaveinstancestate（），但不一定调用onstop（）。 这将创建一个可能较长的时间间隔，在该时间间隔中，即使无法修改其 ui 状态，观察者仍认为生命周期处于活动状态。 - 任何要向
livedata类公开类似行为的类都必须实现lifecyclebeta 2 及更低版本提供的解决方法。
注意： 为了简化流程并提供与旧版本的更好兼容性，从版本 1.0.0-rc1 开始，生命周期对象被标记为
created，并且在调用onsaveinstancestate（）时分派on_stop，而无需等待对onstop（）的调用。 这不太可能影响你的代码，但是需要注意这一点，因为它与 api 级别 26 及更低级别的activity类中的调用顺序不匹配。
参考资料