Lifecycles-aware组件执行操作以响应另一个组件(activity/fragment)声明周期状态的更改。这些组件可帮助您生成更易于组织且通常更轻量级的代码,这些代码更易于维护。
一种常见模式是在activity和fragment的生命周期方法中实现依赖组件的操作。 然而,这种模式导致代码组织不良和错误扩散。 通过使用Lifyclycles-aware组件,您可以将依赖组件的代码移出生命周期方法并移入组件本身。
`android.arch.lifecycle`包提供了类和接口,使您可以构建生命周期感知组件 - 这些组件可以根据活动或片段的当前生命周期状态自动调整其行为。
**注意: 要将android.arch.lifecycle导入Android项目,请参阅[Lifecycle](https://developer.android.google.cn/jetpack/androidx/releases/lifecycle#declaring_dependencies)发行说明中有关声明依赖项的说明 。**
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() ,这使得它们难以维护。
此外,无法保证组件在活动或片段停止之前启动。 如果我们需要执行长时间运行的操作,例如onStart()某些配置检查,则尤其如此。 这可能会导致onStop()方法在onStart()之前完成的竞争条件,从而使组件保持活动时间超过其所需的时间。
android.arch.lifecycle包提供了类和接口,可帮助您以弹性和隔离的方式解决这些问题。
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是一个类,它包含有关组件生命周期状态的信息(如活动或片段),并允许其他对象观察此状态。
Lifecycle使用两个主要枚举来跟踪其关联组件的生命周期状态:
事件
从框架和Lifecycle类调度的生命周期事件。 这些事件映射到活动和片段中的回调事件。
状态
Lifecycle对象跟踪的组件的当前状态。
类可以通过向其方法添加注释来监视组件的生命周期状态。 然后,您可以通过调用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抽象出Lifecycle的所有权,并允许编写与其一起使用的组件。 任何自定义应用程序类都可以实现LifecycleOwner接口。
实现LifecycleObserver组件与实现LifecycleObserver组件无缝LifecycleOwner因为所有者可以提供生命周期,观察者可以注册观察。
对于位置跟踪示例,我们可以使MyLocationListener类实现LifecycleObserver ,然后在onCreate()方法中使用activity的Lifecycle初始化它。 这允许MyLocationListener类自给自足,这意味着响应生命周期状态变化的逻辑在MyLocationListener而不是activity中声明。 使各个组件存储自己的逻辑使得活动和片段逻辑更易于管理。
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();
}
});
}
}
一个常见的用例是,如果Lifecycle现在不处于良好状态,则应避免调用某些回调。 例如,如果回调在保存活动状态后运行片段事务,则会触发崩溃,因此我们永远不会想要调用该回调。
为了简化此用例, 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类完全可以识别生命周期。 如果我们需要使用来自另一个活动或片段的LocationListener ,我们只需要初始化它。 所有设置和拆卸操作都由类本身管理。
如果库提供了需要使用Android生命周期的类,我们建议您使用生命周期感知组件。 您的库客户端可以轻松地集成这些组件,而无需在客户端进行手动生命周期管理。
实现自定义LifecycleOwner
支持库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;
}
}
**生命周期感知组件的最佳实践**
1.保持UI控制器(活动和片段)尽可能精简。 他们不应该试图获取自己的数据; 相反,使用ViewModel执行此操作,并观察LiveData对象以将更改反映回视图。
2.尝试编写数据驱动的UI,其中UI控制器负责在数据更改时更新视图,或将用户操作通知给ViewModel 。
3.将您的数据逻辑放在ViewModel类中。 ViewModel应该充当UI控制器和应用程序其余部分之间的连接器。 但要小心, ViewModel不负责获取数据(例如,从网络中获取)。 相反, ViewModel应调用适当的组件来获取数据,然后将结果提供回UI控制器。
4.使用数据绑定来维护视图和UI控制器之间的干净界面。 这使您可以使视图更具说明性,并最大限度地减少在活动和片段中编写所需的更新代码。 如果您更喜欢用Java编程语言执行此操作,请使用像Butter Knife这样的库来避免样板代码并具有更好的抽象。
5.如果您的UI很复杂,请考虑创建一个presenter类来处理UI修改。 这可能是一项艰巨的任务,但它可以使您的UI组件更容易测试。
6.避免在ViewModel引用View或Activity上下文。 如果ViewModel超过活动(在配置更改的情况下),您的活动将泄漏,并且垃圾收集器未正确处理。
7.使用Kotlin协程来管理长时间运行的任务以及可以异步运行的其他操作。
生命周期感知组件的用例
生命周期感知组件可以使您在各种情况下更轻松地管理生命周期。 一些例子是:
在粗粒度和细粒度位置更新之间切换。 使用生命周期感知组件可在您的位置应用程序可见时启用细粒度位置更新,并在应用程序位于后台时切换到粗粒度更新。 LiveData是一个生命周期感知组件,允许您的应用在用户更改位置时自动更新UI。
停止并开始视频缓冲。 使用生命周期感知组件尽快启动视频缓冲,但推迟播放直到应用程序完全启动。 您还可以使用生命周期感知组件在销毁应用程序时终止缓冲。
启动和停止网络连接。 使用生命周期感知组件在应用程序处于前台时启用网络数据的实时更新(流式传输),并在应用程序进入后台时自动暂停。
暂停和恢复动画drawables。 当app在后台时使用生命周期感知组件处理暂停动画drawables,并在app在前台后恢复drawables。
处理停止事件
当Lifecycle属于AppCompatActivity或Fragment , Lifecycle的状态将更改为CREATED并且在ON_STOP AppCompatActivity或Fragment的onSaveInstanceState()时调度ON_STOP事件。
当Fragment或AppCompatActivity的状态通过onSaveInstanceState()保存时,在调用ON_START之前,它的UI被认为是不可变的。 保存状态后尝试修改UI可能会导致应用程序的导航状态不一致,这就是如果应用程序在保存状态后运行FragmentTransaction , FragmentManager会抛出异常的原因。 有关详细信息,请参阅commit() 。
如果观察者的关联Lifecycle至少没有STARTED LiveData通过禁止调用其观察者LiveData防止这种边缘情况开箱即用。 在幕后,它在决定调用其观察者之前调用isAtLeast() 。
不幸的是, 在 onSaveInstanceState() 之后调用了AppCompatActivity的onStop()方法,这留下了一个间隙,其中不允许UI状态更改但Lifecycle尚未移至CREATED状态。
为防止出现此问题,版本beta2及更低版本的Lifecycle类将状态标记为CREATED而不调度事件,以便检查当前状态的任何代码都获得实际值,即使事件未调度,直到onStop()为止系统。
不幸的是,这个解决方案有两个主要问题: