Android Jetpack架构篇：Lifecycles - 好文

<>Android Jetpack架构篇：Lifecycles

<>使用生命周期感知组件处理生命周期

生命周期感知组件执行操作以响应另一个组件（例如Activity和Fragment）的生命周期状态的更改。这些组件可帮助您生成更易于组织且通常更轻量级的代码，这些代码更易于维护。

一种常见的模式是在Activity和Fragment的生命周期方法中实现依赖组件的操作。但是，这种模式导致代码组织不良以及错误的增加。通过使用生命周期感知组件，您可以将依赖组件的代码移出生命周期方法并移入组件本身。

该android.arch.lifecycle 包提供了类和接口，使您可以构建生命周期感知组件 -
这些组件可以根据Activity和Fragment的当前生命周期状态自动调整其行为。

注意：要导入 android.arch.lifecycle Android项目，请参阅向项目添加组件
<https://developer.android.google.cn/topic/libraries/architecture/adding-components#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()，使组件保持活动的时间大于其所需的时间。
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 使用两个主要枚举来跟踪其关联组件的生命周期状态：

<>Event(事件)

从框架和Lifecycle类调度的生命周期事件。这些事件映射到活动和片段中的回调事件。

<>State(状态)

Lifecycle对象跟踪的组件的当前状态。

将状态视为图形的节点，将事件视为这些节点之间的边。

类可以通过向其方法添加注释来监视组件的生命周期状态。然后，可以通过调用类的 addObserver() 方法Lifecycle
并传递观察者的实例来添加观察者，如以下示例所示：
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。

此接口Lifecycle从各个类（例如Fragment和AppCompatActivity）中抽象出所有权
，并允许编写与其一起使用的组件。任何自定义应用程序类都可以实现LifecycleOwner 接口。

与实现的组件LifecycleObserver 无缝实现工作的组件， LifecycleOwner 因为所有者可以提供生命周期，观察者可以注册观察。

对于位置跟踪的例子，我们可以使MyLocationListener类实现LifecycleObserver ，然后用Activity的初始化
Lifecycle的onCreate()方法。这允许 MyLocationListener类自给自足，这意味着响应生命周期状态变化的逻辑被声明
MyLocationListener而不是Acitity。使各个组件存储自己的逻辑使得Activity和Fragment逻辑更易于管理。
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现在不处于良好状态，则应避免调用某些回调
。例如，如果回调在保存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类完全可以识别生命周期。如果我们需要使用LocationListener
另一个Activity或Fragment，我们只需要初始化它。所有设置和拆卸操作都由类本身管理。

如果库提供了需要使用Android生命周期的类，我们建议您使用生命周期感知组件。您的库客户端可以轻松地集成这些组件，而无需在客户端进行手动生命周期管理。

<>实现自定义LifecycleOwner

支持库26.1.0及更高版本中的Activity和Fragment已实现该LifecycleOwner 接口。

如果您要创建自定义类，则 LifecycleOwner可以使用 LifecycleRegistry 类，但需要将事件转发到该类，如以下代码示例所示：
public class MyActivity extends Activity implements LifecycleOwner { private
LifecycleRegistry mLifecycleRegistry; @Override protected void onCreate(Bundle
savedInstanceState) { super.onCreate(savedInstanceState); mLifecycleRegistry =
new LifecycleRegistry(this); mLifecycleRegistry.markState(Lifecycle.State.
CREATED); } @Override public void onStart() { super.onStart();
mLifecycleRegistry.markState(Lifecycle.State.STARTED); } @NonNull @Override
public Lifecycle getLifecycle() { return mLifecycleRegistry; } }
<>生命周期感知组件的最佳实践

*
保持UI控制器（Activity和Fragment）尽可能精简。他们不应该试图获取自己的数据; 相反，使用 ViewModel执行此操作，并观察
LiveData 对象以将更改反映回视图。

*
尝试编写数据驱动的UI，您的UI控制器负责在数据更改时更新视图，或者将用户操作通知给 ViewModel。

*
把你的数据逻辑放在你的 ViewModel 类。 ViewModel应该作为UI控制器和应用程序其余部分之间的连接器。但要小心，ViewModel
获取数据（例如，从网络）是没有责任的。相反，ViewModel应该调用适当的组件来获取数据，然后将结果提供回调给UI控制器。

*

使用数据绑定来维护视图和UI控制器之间的干净界面。这使您可以使视图更具声明性，并最大限度地减少在活动和片段中编写所需的更新代码。如果您更喜欢使用Java编程语言执行此操作，请使用Butter
Knife之类的库来避免样板代码并具有更好的抽象。

*
如果您的UI很复杂，请考虑创建一个 presenter 类来处理UI修改。这可能是一项艰巨的任务，但它可以使您的UI组件更容易测试。

*
避免引用你的内容View或Activity上下文ViewModel。如果ViewModel
活动超过活动（在配置更改的情况下），您的活动将泄漏并且垃圾收集器未正确处理。

<>生命周期感知组件的用例

生命周期感知组件可以使您在各种情况下更轻松地管理生命周期。一些例子是：

* 在粗粒度和细粒度位置更新之间切换。使用生命周期感知组件可在您的位置应用程序可见时启用细粒度位置更新，并在应用程序位于后台时切换到粗粒度更新。
LiveData，一个生命周期感知组件，允许您的应用在用户更改位置时自动更新UI。
* 停止并开始视频缓冲。使用生命周期感知组件尽快启动视频缓冲，但推迟播放直到应用程序完全启动。您还可以使用生命周期感知组件在销毁应用程序时终止缓冲。
* 启动和停止网络连接。使用生命周期感知组件在应用程序处于前台时启用网络数据的实时更新（流式传输），并在应用程序进入后台时自动暂停。
* 暂停和恢复动画drawables。当应用程序在后台时，使用生命周期感知组件处理暂停动画可绘制的内容，并在应用程序位于前台后恢复可绘制内容。
<>处理停止事件

当一个Lifecycle属于一个AppCompatActivity 或Fragment，所述Lifecycle的状态改变为 CREATED与所述ON_STOP
事件被调度时AppCompatActivity或 Fragment的onSaveInstanceState() 被调用。

当一个Fragment或者AppCompatActivity的状态被保存时 onSaveInstanceState()，它的UI在ON_START
被调用之前被认为是不可变的。保存状态后尝试修改UI可能会导致应用程序的导航状态不一致，这就是为什么FragmentManager在应用程序运行
FragmentTransaction保存后状态时会抛出异常的原因。详情 commit()请见。

LiveData如果观察者的关联Lifecycle 不是至少，则通过避免调用其观察者来防止这种边缘情况开箱即用STARTED。在幕后，它
isAtLeast() 在决定调用其观察者之前调用。

不幸的是，AppCompatActivity 的onStop() 方法被调用后 onSaveInstanceState()
，留下其中UI状态，但不允许更改，但差距Lifecycle还没有移动到 CREATED 状态。

为防止出现此问题，Lifecycle 版本beta2 和较低的类将状态标记为 CREATED
不调度事件，以便检查当前状态的任何代码都获得实际值，即使事件未被调度，直到**onStop()**系统调用。

不幸的是，这个解决方案有两个主要问题

* 在API级别23和更低级别，Android系统实际上保存了活动的状态，即使它被另一个活动部分覆盖。换句话说，Android系统调用
onSaveInstanceState() 但不一定要调用onStop()
。这会创建一个潜在的长间隔，即使无法修改其UI状态，观察者仍然认为生命周期处于活动状态。
* 任何想要向类公开类似行为的 LiveData类都必须实现Lifecycleversion beta 2和lower 提供的解决方法。
注意：为了使此流更简单并提供与旧版本的更好兼容性，从版本开始1.0.0-rc1，Lifecycle 对象被标记为CREATED 并ON_STOP 在
onSaveInstanceState() 调用时调度，而不等待对onStop()
方法的调用。这不太可能影响您的代码，但您需要注意这一点，因为它与ActivityAPI级别26及更低级别的类中的调用顺序不匹配。

其他资源
Lifecyle感知组件是Android Jetpack 的一部分。在Sunflower演示应用程序中查看它们的使用情况。

热门工具换一换