用生命周期感知组件处理生命周期

摘要：生命周期感知组件会执行操作来响应另一个组件如和的生命周期状态的改变。使用两个主要枚举来追踪其关联组件的生命周期状态从和类中分发的生命周期事件，这些事件映射到和的回调事件中。

生命周期感知组件会执行操作来响应另一个组件（如 activity 和 fragment）的生命周期状态的改变。这些组件可以帮助你生成组织性更好、更轻量级、更易于维护的代码。

一个常见的模式是在 activity 和 fragment 的生命周期方法中实现依赖组件的动作。但是，这种模式会导致代码的组织不良以及错误的扩散。通过使用生命周期感知组件，可以将依赖组件的代码从生命周期方法中转移到组件本身。

android.arch.lifecycle 包提供了一些类和接口，让你可以构建生命周期感知组件，这些组件可以根据活动或片段的当前生命周期状态自动调整自己的行为。

注意：要将 android.arch.lifecycle 包导入到你的 Android 项目中, 请参阅 adding components to your project。

Android Framework 中定义的大多数应用程序组件都附带有生命周期。生命周期由操作系统或在你的进程中运行的框架代码进行管理。它们是 Android 工作的核心，你的应用程序必须尊重它们。不这样做可能会触发内存泄漏，甚至导致应用程序崩溃。

想象一下，我们有一个在屏幕上显示设备位置的 Activity 。常见的实现可能如下所示：

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 是一个类，它保存组件（如 activity 或 fragment）的生命周期状态信息，并允许其他对象观察此状态。

Lifecycle 使用两个主要枚举来追踪其关联组件的生命周期状态：

Event

 从 framework 和 Lifecycle 类中分发的生命周期事件，这些事件映射到 activity 和 fragment 的回调事件中。

State

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

把 states 看作图形的节点，events 看作这些节点的边。

一个类可以通过给它的方法添加注解来监听组件的生命周期，然后，你可以通过调用 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是一个表示该类有一个 Lifecycle 的单方法接口。它有一个必须被该类实现的 getLifecycle() 方法。如果你试图去管理整个应用程序进程的生命周期，请参阅 ProcessLifecycleOwner。

这个接口从各个类（如 Fragment 和 AppCompatActivity）提取 Lifecycle 的所有权，并允许编写与它们一起工作的组件。任何自定义的应用程序类都可以实现 LifecycleOwner 接口。

实现 LifecycleObserver 的组件与实现 LifecycleOwner的组件无缝协作，因为 owner 可以提供 observer 可以注册的生命周期。

对位置追踪示例来说，我们可以让 MyLocationListener 类实现 LifecycleObserver，然后 在 onCreate() 方法中 用 activity 的 Lifecycle 来初始化它。这允许 MyLocationListener 类自给自足，意味着对生命周期状态的变化做出反应的逻辑是在
MyLocationListener 而不是 activity 中声明的。让各个组件存储自己的逻辑使得 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 不在一个好的状态，那么避免调用某些 callback。例如，如果 callback 在 activity 状态被保存之后执行一个 fragment 事务，会触发崩溃，所以我们绝对不会调用该 callback。

为了简化这个用例，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 或 fragment 中使用我们的 LocationListener，我们只需要初始化它。所有的设置和删除操作都是由类自身管理。

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

26.1.0 及更高版本的 Support Library 中的 Fragments and Activities 已经实现了 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 控制器尽可能精简，它们不应该试图获取自己的数据，作为替代，使用 ViewModel 来做到这一点，并观察一个 LiveData 对象，将变化反映给视图。

尝试编写数据驱动的 UI，该 UI 的 UI 控制器的职责是在数据变化时更新视图，或者将用户操作通知给ViewModel。

把数据逻辑放在 ViewModel 类中， ViewModel 应该充当 UI 控制器和应用程序其他部分的连接器。但是要小心，获取数据（例如从网络）并不是 ViewModel 的职责，作为替代， ViewModel 应该调用适当的组件来获取数据，然后将结果提供给 UI 控制器。

使用 Data Binding 在视图和 UI 控制器之间维护一个清爽的接口。这允许你让视图更具声明性，并最大限度的减少需要在 activities 和 fragments 中写入的更新代码。如果你更喜欢用 Java 编程语言来实现这一点，请使用类似 Butter Knife 的库来避免样板代码，并具有更好的抽象。

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

避免在 ViewModel 中引用View 或 Activity 上下文。如果 ViewModel 存活时间比 activity 更长（在配置更改的情况下），那么 activity 会泄露，并且无法被 GC 正确处理。

生命周期感知组件可以使你在各种情况下更容易管理生命周期。这里是一些例子：

在粗略和精细的位置信息更新之前切换。使用生命周期感知组件，在 location app 可见时启用精细的位置更新，当应用处于后台时切换到粗略的位置更新。LiveData 是一种生命周期感知组件，它允许应用程序在位置改变时自动更新 UI。

停止和启动视频缓冲。使用生命周期感知组件尽快启动视频缓冲，但是将播放推迟到应用完全启动的时候。你也可以使用生命周期感知组件在应用销毁时终止缓冲。

启动和停止网络连接。使用生命周期感知组件，在应用处于前台时启动网络数据传输，在应用进入后台时自动暂停。

暂停和恢复动画绘制。使用生命周期感知组件，在应用处于后台时暂停动画绘制，当应用处于前台时恢复绘制。

当 Lifecycle 属于AppCompatActivity 或 Fragment ，在 AppCompatActivity 或 Fragment 的 onSaveInstanceState() 被调用时，Lifecycle 的状态改变为CREATED，ON_STOP 事件被分发。

当 Fragment 或 AppCompatActivity 的状态通过 onSaveInstanceState() 保存时，直到 ON_START 被调用为止，它的 UI 被认为是不可变的。尝试在保存状态后修改 UI，可能会导致应用的导航状态不一致，这就是如果应用程序在保存状态后运行 FragmentManager，FragmentManager 抛出异常的原因，详情请参阅 commit()。

如果 observer 关联的 Lifecycle 的状态至少不是 STARTED，LiveData 可以通过避免调用它的 observer 来防止这种极端情况的出现。在幕后，它在决定调用 observer 之前调用了 isAtLeast()。

不幸的是，AppCompatActivity 的 onStop() 方法是在 onSaveInstanceState() 之后被调用的，这会在 UI 状态更改不被允许但 Lifecycle 还没有移至 CREATED 状态情况下留下空隙。

为了避免这个问题，beta2 和更低版本的 Lifecycle 类，将状态标记为 CREATED，而不分发事件，这样任何检查当前状态的代码都会得到真实值，即使事件直到 onStop() 被系统调用才会被分发。

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

在 API 23及更低版本上，Android 系统实际上保存了 activity 的状态，即使它被另一个 activity 部分覆盖。换句话说，Android 系统调用 onSaveInstanceState()，但不一定调用 onStop()。这会产生一个潜在的长时间间隔，即使其 UI 状态不能被修改，观察者仍认为生命周期是活动的。

任何想要暴露类似行为给 LiveData 类的类必须实现 beta 2以下版本 Lifecycle 提供的变通方法。

注意：为了使这个流程更简单，并提供与旧版本更好的兼容性，从 1.0.0-rc1 开始，Lifecycle 对象被标记为CREATED ，并且在 onSaveInstanceState() 被调用时分发 ON_STOP，而不等待 onStop() 方法的调用。这不太可能影响你的代码，但你需要注意的是，这与 API 26 以下的 Activity 中的调用顺序不匹配。