生命周期感知组件执行操作以响应另一个组件的生命周期状态变化，例如Activity和Fragment。 这些组件可帮助您生成组织更好，更轻量的代码，更易于维护。
一种常见的模式是在Activity和Fragment的生命周期方法中实现依赖组件的动作。 但是这种模式导致代码的组织不善，并导致错误扩散。 通过使用支持生命周期的组件，您可以将依赖组件的代码移出生命周期方法，然后移入组件本身。
androidx.lifecycle包提供了一些类和接口，可让您构建可感知生命周期的组件，这些组件可根据Activity或Fragment的当前生命周期状态自动调整其行为。
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;
@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();
}
}
androidx.lifecycle包提供了一些类和接口，可帮助您以弹性和隔离的方式解决这些问题。
Lifecycle
生命周期是一个类，其中包含有关组件生命周期状态（如活动或片段）的信息，并允许其他对象观察此状态。
生命周期使用两个主要枚举来跟踪其相关组件的生命周期状态：
Event 是从framewrok和Lifecycle类调度的生命周期事件。 这些事件映射到activity和fragment中的回调事件。
State 被Lifecycle对象跟踪的组件的当前状态。
上图构成Android activity生命周期的状态和事件
将State视为图形的节点，将Event视为这些节点之间的边缘。
类可以通过向其方法添加注释来监视组件的生命周期状态。 然后，您可以通过调用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是一个单一方法接口，表示该类具有生命周期。它有一个方法getLifecycle()，必须由该类实现。如果要尝试管理整个应用程序流程的生命周期，请参阅ProcessLifecycleOwner。
此接口从诸如Fragment和AppCompatActivity之类的单个类中抽象出生命周期的所有权，并允许编写与其一起使用的组件。任何自定义应用程序类都可以实现LifecycleOwner接口。
实现LifecycleObserver的组件与实现LifecycleOwner的组件无缝地工作，因为所有者可以提供生命周期，观察者可以注册该生命周期以观看。
对于位置跟踪示例，我们可以使MyLocationListener类实现LifecycleObserver，然后在onCreate()方法中使用活动的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();
}
});
}
}
一个常见的用例是，如果生命周期当前状态不佳，则避免调用某些回调。 例如，如果回调在保存活动状态后运行片段事务，那么它将触发崩溃，因此我们永远都不想调用该回调。
为了简化此用例，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生命周期一起使用的类，则建议您使用可识别生命周期的组件。 您的库客户端可以轻松集成这些组件，而无需在客户端进行手动生命周期管理。
实现自定义的LifecycleOwner
在Support Library 26.1.0中的Fragments和Activities 及最新版本已经实现了 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;
}
}
lifecycle组件最佳实践
- 保持UI控制器（activities和fragments）尽可能的精简。他们不应该尝试获取自己的数据。取而代之的是，使用
ViewModel做到这一点，并观察LiveData对象以将更改反映回视图。 - 尝试编写
数据驱动的UI，其中UI控制器的职责是在数据更改时更新视图，或将用户操作通知给ViewModel。 - 将数据逻辑放入
ViewModel类中。ViewModel应该用作UI控制器与应用程序其余部分之间的连接器。但是请注意，获取数据（例如，从网络）不是ViewModel的责任。相反，ViewModel应该调用适当的组件以获取数据，然后将结果提供回UI控制器。 - 使用
Data Binding可在视图和UI控制器之间保持干净的界面。这使您可以使视图更具声明性，并最大程度地减少需要在activity和framgment中编写的更新代码。如果您更喜欢使用Java编程语言来执行此操作，请使用Butter Knife之类的库来避免样板代码并获得更好的抽象性。 - 如果您的UI很复杂，请考虑创建一个
presenter类来处理UI修改。这可能是一项艰巨的任务，但是它可以使您的UI组件更易于测试。 - 避免在
ViewModel中引用View或Activity上下文。如果ViewModel超出活动寿命（在配置发生更改的情况下），则您的活动会泄漏并且不会被垃圾收集器正确处置。 - 使用
Kotlin协程来管理长时间运行的任务以及可以异步运行的其他操作。
