使用生命周期感知组件处理生命周期
Lifecycle-aware组件执行操作会响应另一个组件的生命周期状态的变化,如活动和碎片。这些组件可以帮助您生成组织性更好，且重量更轻的代码，更易于维护。
一个常见的模式是在activity和fragment的生命周期方法中实现依赖组件的动作。但是，这种模式导致代码的组织不良以及错误的扩散。通过使用生命周期感知组件，您可以将依赖组件的代码从生命周期方法移出并移入组件本身。
android.arch.lifecycle 软件包提供了类和接口，使您可以构建支持生命周期的组件，这些组件可以根据活动或片段的当前生命周期状态自动调整其行为。
注意：要导入android.arch.lifecycle到您的Android项目中，请参阅向项目添加组件
Android Framework中定义的大多数应用程序组件都附带有生命周期。生命周期由操作系统或在进程中运行的框架代码进行管理。它们是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()，使组件保持比所需的更长的时间。
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软件包提供的类和接口可帮助您以弹性和独立的方式解决这些问题。
1.生命周期
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 接口，这在下面的章节中有解释。
2. LifecycleOwner
LifecycleOwner是一个单一的方法接口，表示该类有一个 Lifecycle。它有一个方法，getLifecycle()必须由类实现。如果您试图管理整个应用程序进程的生命周期，请参阅 ProcessLifecycleOwner。
这个接口从独立的类中抽象出Lifecycle的所有权，例如Fragment和AppCompatActivity，并允许编写与它们一起工作的组件。任何自定义应用程序类都可以实现该 LifecycleOwner 接口
实现 LifecycleObserver的组件可以无缝地与实现LifecycleOwner的组件协同工作， 因为所有者可以提供一个生命周期，观察者可以注册观察。
对于位置跟踪的例子，我们可以使MyLocationListener类实现LifecycleObserver ，然后用活动的onCreate()方法初始化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生命周期，我们建议您使用生命周期感知组件。您的库可以轻松集成这些组件，无需在客户端手动管理生命周期。
3.实现一个自定义的LifecycleOwner
支持库中26.1.0中的activites和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;
}
}
4. lifecycle-aware组件的最佳实践
-
保持你的UI控制器（活动和片段）尽可能的精简。他们不应该让
View获取自己的数据。相反，使用一个 ViewModel来获取数据，并观察一个LiveData对象，获取变化更新到View。 -
尝试编写数据驱动的用户界面，其中您的用户界面控制器的职责是更新数据更改视图，或通知用户操作ViewModel。
-
把你的数据逻辑放在你的 ViewModel类中。 ViewModel应作为您的UI控制器和其他应用程序之间的连接器。但要记住，获取数据（例如从网络）不是ViewModel的责任。相反， ViewModel应调用相应的组件来获取数据，然后将结果提供给UI控制器。
-
使用data-binding来保持视图和UI控制器之间的干净界面。这样可以让你的视图更具说明性，并最大限度地减少需要在活动和片段中写入的更新代码。如果你喜欢用Java编程语言来完成这个工作，可以使用像Butter Knife这样的库来避免样板代码，并有更好的抽象。
-
如果您的UI很复杂，请考虑创建一个 presenter 类来处理UI修改。这可能是一项艰巨的任务，但它可以使您的UI组件更容易测试。
-
避免在你的
ViewModel中引用View或Activity上下文。如果ViewModel比活动更持久（在配置更改的情况下），则活动会泄漏，并且垃圾收集器无法正确处理。
5.生命周期的组件的用例
支持生命周期的组件可以使您在各种情况下更容易地管理生命周期。一些例子是：
-
精度和高精度位置信息的切换。使用支持生命周期的组件在位置应用程序可见时启高精度位置更新，并在应用程序处于后台时切换到低精度更新。LiveData，这个生命周期感知组件，允许您的应用程序在位置更改时自动更新UI。
-
停止并开始视频缓冲。尽可能使用支持生命周期的组件来启动视频缓冲，延迟播放直到应用程序完全启动。您也可以使用生命周期感知组件终止缓冲当应用程序销毁时。
-
启动和停止网络连接。使用生命周期感知组件可以在应用程序处于前台时实时更新（流式传输）网络数据，并在应用程序进入后台时自动暂停。
-
暂停和恢复动画绘制。使用生命周期感知组件来处理在应用程序处于后台时暂停动画的绘制，并在应用程序处于前台后恢复绘制。
6.处理停止事件
当一个Lifecycle属于一个AppCompatActivity或Fragment时，Lifecycle状态改变为 CREATED；而AppCompatActivity或Fragment的onSaveInstanceState()被调用时，ON_STOP 事件被分发。
当一个Fragment或者AppCompatActivity状态通过onSaveInstanceState()被保存时，UI被认为是不可变的，直到 ON_START被调用。尝试在保存状态后修改UI可能会导致应用程序的导航状态不一致，这就是为什么FragmentManager抛出异常,当保存状态后应用程序运行FragmentTransaction。见commit()细节。
LiveData阻止这种极端情况，通过避免调用相关Lifecycle 没有处于STARTED的观察者。在幕后，它在决定调用观察者之前调用isAtLeast() 。
不幸的是，在onSaveInstanceState()之后AppCompatActivity的onStop()方法被调用，这造成了一个UI状态不允许变化的间隙，但是这期间Lifecycle还没有被移动到 CREATED 状态。
为了防止出现这个问题，beta2或更低版本中的Lifecycle类将此状态标记为CREATED 不调度事件，以便任何检查当前状态的代码都会获得真实值，即使该事件未被调度直到onStop()被系统调用。
不幸的是，这个解决方案有两个主要问题
-
在API等级23或更低时，Android系统实际上保存了
activity的状态，即使它被另一activity部分覆盖。换句话说，Android系统调用onSaveInstanceState()但不一定会调用onStop()。这将创建一个潜在的长时间间隔，这期间即使其UI状态无法修改，观察者仍然认为生命周期处于活动状态。
注意：为了使这个流程更简单，并提供与旧版本的更好的兼容性，从版本`1.0.0-rc1开始，Lifecycle对象被标记为CREATED 并且ON_STOP被分发在onSaveInstanceState()被调用时，而不用等待对该onStop()方法的调用。这不太可能影响您的代码，但您需要注意，因为它不符合ActivityAPI级别26及以下级别的调用顺序。
网友评论