【译】Google官方推出的Android架构组件系列文章（三）处理生命周期

系列文章导航：

1. 【译】Google官方推出的Android架构组件系列文章（一）App架构指南
2. 【译】Google官方推出的Android架构组件系列文章（二）将Architecture Components引入工程
3. 【译】Google官方推出的Android架构组件系列文章（三）处理生命周期
4. 【译】Google官方推出的Android架构组件系列文章（四）LiveData
5. 【译】Google官方推出的Android架构组件系列文章（五）ViewModel
6. 【译】Google官方推出的Android架构组件系列文章（六）Room持久化库

---

原文地址：https://developer.android.com/topic/libraries/architecture/lifecycle.html

android.arch.lifecycle 包提供了类和接口允许你构建生命周期感知（lifecycle-aware）的组件——可以基于当前activity或fragment生命周期自动调节它们的行为的组件。

注意：将 android.arch.lifecycle 导入Android工程，请参见将Architecture Components引入工程。

大部分定义在Android框架中的组件都包含附加到其上的生命周期。这些生命周期由操作系统或运行在你的进程中的框架代码管理。它们是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;

    public void onCreate(...) {
        myLocationListener = new MyLocationListener(this, (location) -> {
            // update UI
        });
  }

    public void onStart() {
        super.onStart();
        myLocationListener.start();
    }

    public void onStop() {
        super.onStop();
        myLocationListener.stop();
    }
}

即使这个例子看起来不错，在一个真正的应用中，你最终会遇到太多像这样的调用，然后onStart()和onStop()方法会变得非常大。

此外，一些组件不能刚刚在onStart()中启动。如果我们需要在启动位置观察之前检查一些配置怎么办？有可能某些情况检查是在activity已经停止之后才结束，这意味着myLocationListener.start()的调用是在myLocationListener.stop()调用之后，基本上就会一直保持连接了。

class MyActivity extends AppCompatActivity {
    private MyLocationListener myLocationListener;

    public void onCreate(...) {
        myLocationListener = new MyLocationListener(this, location -> {
            // update UI
        });
    }

    public void onStart() {
        super.onStart();
        Util.checkUserStatus(result -> {
            // what if this callback is invoked AFTER activity is stopped?
            if (result) {
                myLocationListener.start();
            }
        });
    }

    public void onStop() {
        super.onStop();
        myLocationListener.stop();
    }
}

android.arch.lifecycle包提供了类和接口，帮助你以灵活和隔离的方式解决这些问题。

Lifecycle

Lifecycle类保存有组件（如activity或fragment）的生命周期状态信息，并允许其他对象观察此状态。

Lifecycle使用两个主要的枚举来跟踪其相关组件的生命周期状态。

Event

从框架和Lifecycle类分派的生命周期事件。这些事件映射到activity和fragment的回调事件。

State

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

lifecycle-states.png

将状态视作图的结点，事件看作这些结点之间的边。

一个类可以通过给方法添加注解来观察组件的生命周期。

public class MyObserver implements LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    public void onResume() {
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    public void onPause() {
    }
}
aLifecycleOwner.getLifecycle().addObserver(new MyObserver());

LifecycleOwner

LifecycleOwner 是一个单一方法接口，表示该类拥有一个Lifecycle。它的唯一方法getLifecycle()必须被这个类实现。

此类从单独的类（比如activity和fragment）里抽象了Lifecycle的所有权，并允许编写与两者兼容的组件。任何自定义应用程序类可以实现LifecycleOwner接口。

注意：由于Architecture Components还处于Alpha阶段，Fragment和AppCompatActivity类不能实现它（因为我们不能从一个稳定的组件中添加一个依赖，导致其变成不稳定的API）。在Lifecycle稳定之前，为了方便，提供了LifecycleActivity和LifecycleFragment类。在Lifecycle工程发布后，支持库的fragment和activity将会实现LifecycleOwner接口。到时将不推荐使用LifecycleActivity和LifecycleFragment。另请参阅在自定义activity和fragment中实现LifecycleOwner。

对于上面的例子，我们可以让MyLocationListener类成为LifecycleObserver，然后在onCreate中使用我们的Lifecycle初始化它。这允许MyLocationListener类是自足的，意味着它可以在必要的时候进行自我清理。

class MyActivity extends LifecycleActivity {
    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.getState().isAtLeast(STARTED)) {
            // connect if not connected
        }
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    void stop() {
        // disconnect if connected
    }
}

通过这个实现，我们的LocationListener类是完全生命周期感知的了。它可以自行初始化和清理，而不受activity的管理。如果我们需要从另一个Activity或Fragment使用它，我们只需要初始化它。所有的安装和拆卸操作都由类本身管理。

可以与Lifecycle一起使用的类被称为生命周期感知组件。鼓励那些提供需要使用Android生命周期的类的库提供生命周期感知组件，以便客户端可以轻松继承这些类，而无需在客户端手动进行生命周期管理。

LiveData是生命周期感知组件的示例。与ViewModel一起使用LiveData，可以在遵循Android生命周期的情况下，更容易使用数据填充UI。

Lifecycle最佳实践

• 保持UI控制器（activity和fragment）尽可能瘦。它们不应该视图获取自己的数据，而是使用ViewModel来做，并观察LiveData以将更改反映到View中。
• 尝试别写数据驱动的UI，你的UI控制器负责在数据更改时更新View，而不是将用户操作通知回ViewModel。
• 把你的数据逻辑放到ViewModel类中。ViewModel应该扮演你的UI控制器和应用其余部分之间的连接器。但是请注意，不是ViewModel的责任来拉取数据（比如，从网络）。相反，ViewModel应该调用相应的组件来做这个事儿，然后把结果返回给UI控制器。
• 使用Data Binding来保持view和UI控制器之间干净的接口。这可以让你的视图更具声明性，并最大限度减少你需要在activity和fragment之间编写的更新代码。如果你更喜欢Java中这么做，使用像ButterKnife这样的库来避免模板代码，并进行更好的抽象。
• 如果你的UI很复杂，考虑创建一个Presenter类来处理UI修改。这通常是过度的，但可能让你的UI更容易测试。
• 永远不要在ViewModel中引用view或activity context。如果ViewModel的生命周期超过activity（比如更改配置的情况），activity将会泄漏，无法正确地被垃圾回收。

附录

自定义的activity和fragment实现LifecycleOwer

任何自定义的activity和fragment可以通过实现内置的LifecycleRegistryOwner接口（而不是扩展LifecycleFragment或LifecycleActivity）来转换成LifecycleOwner

public class MyFragment extends Fragment implements LifecycleRegistryOwner {
    LifecycleRegistry lifecycleRegistry = new LifecycleRegistry(this);

    @Override
    public LifecycleRegistry getLifecycle() {
        return lifecycleRegistry;
    }
}

如果你想把一个自定义类转换成LifecycleOwner，你可以使用LifecycleRegistry类，但是你需要把事件转发给这个类。对于实现了LifecycleRegistryOwner的activity和fragment来说，转换将会自动完成。