[TOC]
使用生命周期感知组件处理生命周期
生命周期的组件执行动作以响应另一个组件生命周期状态的变化,比如activities和fragments。这些组件可以帮助您生成更有组织、更轻量级、更易于维护的代码。
一种常见模式是在activities和fragments的生命周期方法中实现依赖组件的操作。但是,这种模式导致代码组织不良和错误扩散。通过使用生命周期感知组件,您可以将依赖组件的代码移出生命周期方法并移入组件本身。
android.arch.lifecycle
软件包提供了类和接口,使您可以构建生命周期感知 组件 - 这些组件可以根据activities或fragments的当前生命周期状态自动调整其行为。
注意:要导入 android.arch.lifecycle
到Android项目中,请参阅Lifecycle发行说明中有关声明依赖项的说明。
Android框架中定义的大多数应用程序组件都附加了生命周期。生命周期由操作系统或流程中运行的框架代码管理。它们是Android运作方式的核心,您的应用程序必须尊重它们。不这样做可能会触发内存泄漏甚至应用程序崩溃。
假设,我们有一个活动,在屏幕上显示设备位置。常见的实现可能如下所示:
class MyLocationListener {
public MyLocationListener(Context context, Callback callback) {
// ...
}
void start() {
// connect to system location service
}
void stop() {
// disconnect from system location service
}
}
class MyActivity extends AppCompatActivity {
private MyLocationListener myLocationListener;
@Override
public void onCreate(...) {
myLocationListener = new MyLocationListener(this, (location) -> {
// update UI
});
}
@Override
public void onStart() {
super.onStart();
myLocationListener.start();
// manage other components that need to respond
// to the activity lifecycle
}
@Override
public void onStop() {
super.onStop();
myLocationListener.stop();
// manage other components that need to respond
// to the activity lifecycle
}
}
即使这个示例看起来很好,但在真实的应用程序中,最终会有太多的调用来管理UI和其他组件以响应生命周期的当前状态。管理多个组件会在生命周期方法中放置大量代码,例如onStart()和onStop(),这使得它们难以维护。
此外,无法保证在activity或fragment停止之前启动组件。尤其是如果我们需要执行一个耗时操作,如在onStart()中检测一些配置。这可能会导致竞争条件,onStop()
方法在此之前完成onStart()
,使组件保持活动的时间超过其所需的时间。这可能导致竞争的情况,onStop()方法在onStart()之前完成,使组件保持活动的时间超过其所需的时间。
class MyActivity extends AppCompatActivity {
private MyLocationListener myLocationListener;
public void onCreate(...) {
myLocationListener = new MyLocationListener(this, location -> {
// update UI
});
}
@Override
public void onStart() {
super.onStart();
Util.checkUserStatus(result -> {
// what if this callback is invoked AFTER activity is stopped?
if (result) {
myLocationListener.start();
}
});
}
@Override
public void onStop() {
super.onStop();
myLocationListener.stop();
}
}
android.arch.lifecycle
提供的类和接口可以帮助您以一种灵活且独立的方式处理这些问题。
生命周期
Lifecycle
是一个类,它保存关于组件(如activity或fragment)的生命周期状态的信息,并允许其他对象观察该状态。
Lifecycle
使用两个主要枚举来跟踪其关联组件的生命周期状态:
Event
从框架和Lifecycle
类调度的生命周期事件 。这些事件映射到活动和片段中的回调事件。
State
Lifecycle
对象跟踪的组件的当前状态 。
[站外图片上传中...(image-a27353-1552355707972)]
将状态看作图的节点,将事件看作这些节点之间的边。
类可以通过向其方法添加注释来监视组件的生命周期状态。然后,您可以通过调用Lifecycle
类的addObserver()
方法来添加观察者,并传递观察者的实例,如以下示例所示:
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
LifecycleOwner
是仅有一个的方法接口,意味着该类有一个 Lifecycle
。它有一个方法getLifecycle()
,必须由该类实现。如果您试图管理整个应用程序流程的生命周期,请参阅ProcessLifecycleOwner
。
该接口将生命周期的所有权从各个类(如Fragment和AppCompatActivity)中抽象出来,并允许编写与其工作的组件。任何自定义应用程序类都可以实现 LifecycleOwner
接口。
实现LifecycleObserver
的组件与实现LifecycleOwner
的组件可以无缝地工作,因为所有者可以提供一个生命周期,观察者可以注册该生命周期来观察。
对于位置跟踪示例,我们可以让MyLocationListener
类实现LifecycleObserver
,然后在onCreate()方法中使用activity的Lifecycle
初始化它。这使得MyLocationListener
类能够自给自足,这意味着响应生命周期状态变化的逻辑是在MyLocationListener
中声明的,而不是在activity中。让各个组件存储它们自己的逻辑可以使activities和fragments的逻辑更容易管理。
class MyActivity extends AppCompatActivity {
private MyLocationListener myLocationListener;
public void onCreate(...) {
myLocationListener = new MyLocationListener(this, getLifecycle(), location -> {
// update UI
});
Util.checkUserStatus(result -> {
if (result) {
myLocationListener.enable();
}
});
}
}
一个常见的用例是,如果生命周期目前处于不好的状态,则避免调用某些回调。例如,如果回调在activity状态保存后运行fragment 事务,那么它将触发崩溃,因此我们永远不会调用该回调。
为了简化这个用例, Lifecycle
类允许其他对象查询当前状态。
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) {
// connect
}
}
public void enable() {
enabled = true;
if (lifecycle.getCurrentState().isAtLeast(STARTED)) {
// connect if not connected
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
void stop() {
// disconnect if connected
}
}
通过这种实现,我们的LocationListener
类完全可以识别生命周期。如果我们需要在另一个activity or fragment中使用LocationListener
,我们只需要初始化它。所有设置和拆卸操作都由类本身管理。
如果库提供了需要使用Android生命周期的类,我们建议您使用生命周期感知组件。您的库客户端可以轻松地集成这些组件,而无需在客户端进行手动生命周期管理。
实现自定义LifecycleOwner
Support Library 26.1.0 和以后版本中的片段和活动已经实现了LifecycleOwner
接口。
如果您需要一个自定义类来实现LifecycleOwner
,那么您可以使用LifecycleRegistry类,但是您需要将事件转发到该类中,如下面的代码示例所示:
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控制器(活动和片段)尽可能精简。他们不应该试图获取自己的数据; 相反,使用
ViewModel
来执行此操作,并观察LiveData
对象以将更改反映回视图。 - 尝试编写数据驱动的UI,您的UI控制器负责在数据更改时更新视图,或者将用户操作通知给
ViewModel
。 - 将数据逻辑放入
ViewModel
类中。ViewModel
应该作为UI控制器和应用程序其余部分之间的连接器。不过要小心,获取数据(例如从网络)不是ViewModel的职责。相反,ViewModel应该调用适当的组件来获取数据,然后将结果返回给UI控制器。 - 使用Data Binding来来维护视图和UI控制器之间简洁的接口。这使您可以使视图更具说明性,并最大限度地减少在
activities
和fragments
中编写所需的更新代码。如果您喜欢在Java编程语言中这样做,那么可以使用像Butter Knife这样的库来避免样板代码,并具有更好的抽象。 - 如果UI比较复杂,可以考虑创建presenter类来处理UI修改。这可能是一个费力的任务,但它可以使您的UI组件更容易测试。
- 避免在你的
ViewModel
引用View
orActivity
context,如果这个ViewModel
比Activity
d的寿命长(在 configuration changes的情况下),你的activity
会泄漏并且不会被垃圾回收器正确的处理
生命周期感知组件的用例
生命周期感知组件可以使您在各种情况下更轻松地管理生命周期。一些例子是:
- 在粗粒度和细粒度位置更新之间切换。使用生命周期感知组件可在您的位置应用程序可见时启用细粒度位置更新,并在应用程序位于后台时切换到粗粒度更新。
LiveData
,一个生命周期感知组件,允许您的应用在用户更改位置时自动更新UI。 - 停止和启动视频缓冲。使用生命周期感知组件尽快启动视频缓冲,但推迟播放直到应用程序完全启动。您还可以使用生命周期感知组件在销毁应用程序时终止缓冲。
- 启动和停止网络连接。使用生命周期感知组件在应用程序处于前台时启用网络数据的实时更新(流式传输),并在应用程序进入后台时自动暂停。
- 暂停和恢复动画绘制。当app在后台时使用生命周期感知组件处理暂停动画绘制,并在app在前台后恢复绘制。
处理停止事件
当Lifecycle
属于AppCompatActivity
或Fragment
,当AppCompatActivity
或 Fragment
的onSaveInstanceState()
被调用时,该Lifecycle
的状态改变为CREATED
并且ON_STOP
事件被分发。
当Fragment或AppCompatActivity的状态通过onSaveInstanceState()保存时,直到调用ON_START之前,它的UI被认为是不可变的。保存状态后试图修改UI很可能会导致应用程序导航状态的不一致,这就是为什么如果应用程序在保存状态后运行FragmentTransaction,FragmentManager会抛出异常。有关详细信息,请参见commit()。
LiveData
通过检测观察者相关的生命周期至少在STARTED状态才调用他的观察者来避免防止这种情况出现。在幕后,它在决定调用其观察者之前调用isAtLeast()
。
不幸的是,AppCompatActivity的onStop()方法是在onSaveInstanceState()之后调用的,这留下了一个空白,即UI状态更改是不允许的,但是Lifecycle
还没有移动到CREATED
状态。
为了防止出现这个问题,Lifecycle
类在beta2和更低的版本在没有事件调度的情况下将状态标记为CREATED
,以便任何检查当前状态的代码都获得实际值,即使事件未被调用,直到onStop()才被系统调用。
不幸的是,这个解决方案有两个主要问题:
- 在API级别23或更低的级别上,Android系统实际上保存了一个活动的状态,即使它被另一个活动部分覆盖。换句话说,Android系统调用onSaveInstanceState(),但它不一定调用onStop()。这就产生了一个潜在的长时间间隔,在这个时间间隔中,观察者仍然认为生命周期是活动的,即使它的UI状态不能被修改。
- 任何想要向
LiveData
类公开类似行为的类都必须实现Lifecycle
version beta 2或更低版本提供的解决方案。
注意:为了简化此流并提供与旧版本更好的兼容性,从1.0.0-rc1
版本开始,Lifecycle
对象被标记为CREATED
并分派ON_STOP
事件, 在onSaveInstanceState()
调用时调度,而不等待对onStop()
方法的调用。这不太可能影响您的代码,但您需要注意这一点,因为它与Activity
API级别26及更低级别的类中的调用顺序不匹配。
其他资源
要了解有关使用生命周期感知组件处理生命周期的更多信息,请参阅以下其他资源。
例子
- Android Architecture Components Basic Sample
- Sunflower, 一个演示应用程序演示了架构组件的最佳实践
Codelabs
- Android Lifecycle-aware components
Blogs
- Introducing Android Sunflowers