甜美蛋糕,喜剧班的春天,百田弹弹堂2
奉上翻译原文地址： ；翻译过程中加上了自己的一点理解。理解不对的地方直接评论就好。
生命周期感知组件可以感知其他组件的生命周期，例如 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;
}
}
## 生命周期感知组件的最佳实践
## 生命周期感知组件的用例
生命周期感知组件可以让你在各种情况下都很好的管理生命周期，例如：
当生命周期属于 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（） 才调度事件，任何检查当前状态的代码都将获得真实值。
不幸的是，此解决方案有两个主要问题：
activity 的状态，即使该 activity 已被另一个 activity 部分覆盖 。 换句话说，android 系统调用 onsaveinstancestate（） ，但不一定调用 onstop（） 。 这将创建一个可能较长的时间间隔，在该时间间隔中，即使无法修改其 ui 状态，观察者仍认为生命周期处于活动状态。livedata 类公开类似行为的类都必须实现 lifecycle beta 2 及更低版本提供的解决方法。注意： 为了简化流程并提供与旧版本的更好兼容性，从版本 1.0.0-rc1 开始，生命周期对象被标记为
created，并且在调用onsaveinstancestate（）时分派on_stop，而无需等待对onstop（）的调用。 这不太可能影响你的代码，但是需要注意这一点，因为它与 api 级别 26 及更低级别的activity类中的调用顺序不匹配。
参考资料
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Android studio 解决logcat无过滤工具栏的操作
Android Studio 恢复小窗口停靠模式(Docked Mode)
Android studio保存logcat日志到本地的操作
Android Studio快捷键生成TAG、Log.x日志输出介绍
网友评论