Android官方架构组件介绍之LifeCycle
使用生命周期感知组件处理生命周期
支持生命周期的组件会响应另一个组件(如活动和片段)的生命周期状态更改而执行操作。这些组件可以帮助您生成组织性更好,且重量更轻的代码,更易于维护。
一个常见的模式是在活动和片段的生命周期方法中实现依赖组件的动作。但是,这种模式导致代码的组织不良以及错误的扩散。通过使用生命周期感知组件,可以将相关组件的代码从生命周期方法中移出并移入组件本身。
该android.arch.lifecycle 软件包提供了类和接口,使您可以构建支持生命周期的 组件,这些组件可以根据活动或片段的当前生命周期状态自动调整其行为。
Note: 导入 android.arch.lifecycle 到你的项目中, 请参阅adding components to your project.
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(),这使得它们很难维护。
而且,不保证组件在活动或片段停止之前启动。例如我们需要在start位置监听前做用户状态检测,检测是一个耗时的任务,那么很有可能在检测结束前用户提前退出了Activity,这时候就会导致 myLocationListener.start() 在 myLocationListener.stop() 后面调用,从而引起很多难以定位的问题。代码如下:
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 使用两个主要枚举来跟踪其关联组件的生命周期状态:
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()必须由class来执行。如果您试图管理整个应用程序进程的生命周期,请参阅 ProcessLifecycleOwner。
这个接口抽象Lifecycle出个别类的所有权 ,例如Fragment和AppCompatActivity,并允许编写与它们一起工作的组件。任何自定义应用程序类都可以实现该 LifecycleOwner 接口
组件可以 LifecycleObserver 无缝地与实现组件的组件实现, LifecycleOwner 因为所有者可以提供一个生命周期,观察者可以注册观察。
对于位置跟踪的例子,我们可以使MyLocationListener类实现LifecycleObserver ,然后用活动的初始化 Lifecycle的onCreate()方法。这允许 MyLocationListener类是自给自足的,这意味着对生命周期状态中的变化作出反应的逻辑被声明MyLocationListener而不是活动。让各个组件存储自己的逻辑使得活动和片段逻辑更容易管理。
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生命周期的类,我们建议您使用生命周期感知组件。您的library可以在客户端无需手动生命周期管理即可轻松集成这些组件。
实现一个自定义的LifecycleOwner
支持库中的Fragment片和Activity26.1.0及更高版本已经实现了该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 对象,以反映到视图的变化。
- 尝试编写数据驱动的用户界面,其中您的用户界面控制器的职责是更新数据更改视图,或通知用户操作回 ViewModel。
- 把你的数据逻辑放在你的 ViewModel class上。 ViewModel应作为您的UI控制器和其他应用程序之间的连接器。但要小心,ViewModel取数据(例如从网络)是没有 责任的。相反, ViewModel应调用相应的组件来获取数据,然后将结果提供给UI控制器。
- 使用 Data Binding 来保持视图和UI控制器之间的干净界面。这样可以让你的视图更具说明性,并最大限度地减少需要在活动和片段中写入的更新代码。如果你喜欢用Java编程语言来完成这个工作,可以使用像Butter Knife这样的库 来避免样板代码,并有更好的抽象。
- 如果您的UI很复杂,请考虑创建一个 presenter 类来处理UI修改。这可能是一项艰巨的任务,但它可以使您的UI组件更容易测试。
- 避免 在你的引用中View或Activity上下文ViewModel。如果超出ViewModel activity (在配置更改的情况下),则Activity会泄漏,并且垃圾收集器无法正确处理。
用于支持生命周期的组件的用例
支持生命周期的组件可以使您在各种情况下更容易地管理生命周期。一些例子是:
在粗略和细粒度的位置更新之间切换。使用支持生命周期的组件在位置应用程序可见时启用细粒度的位置更新,并在应用程序处于后台时切换到粗粒度更新。LiveData,一个生命周期感知组件,允许您的应用程序在使用更改位置时自动更新UI。
停止并开始视频缓冲。尽可能使用支持生命周期的组件来启动视频缓冲,但延迟播放直到应用程序完全启动。您也可以使用生命周期感知组件终止应用程序销毁时的缓冲。
启动和停止网络连接。使用生命周期感知组件可以在应用程序处于前台时实时更新(流式传输)网络数据,并在应用程序进入后台时自动暂停。
暂停和恢复动画绘制。使用生命周期感知组件来处理在应用程序处于后台时暂停动画的可绘画,并在应用程序处于前台后恢复绘制。
处理停止事件
当一个Lifecycle属于一个AppCompatActivity 或Fragment,所述Lifecycle的状态改变为 CREATED与所述ON_STOP 事件被调度时AppCompatActivity或 Fragment的onSaveInstanceState() 被调用。
当一个Fragment或者AppCompatActivity一个状态被保存时 onSaveInstanceState(),UI被认为是不可变的,直到 ON_START被调用。尝试在保存状态后修改UI可能会导致应用程序的导航状态不一致,这就是为什么FragmentManager当应用程序运行FragmentTransaction后保存状态时抛出异常 。见 commit() 细节。
LiveData如果观察者的相关Lifecycle 性不是至少 ,则通过避免调用观察者来防止这种边缘情况出现STARTED。在后台,它需要 isAtLeast() 允许才能调用观察者observer。
不幸的是,AppCompatActivity这个onStop()方法被调用后 onSaveInstanceState(),在UI状态变化不允许的地方留下了一个空隙,但是这个空间 Lifecycle还没有被移动到 CREATED 状态。
为了防止出现这个问题,Lifecycle版本中的类beta2 和低级将状态标记为 CREATED 不调度事件,以便任何检查当前状态的代码都会获得真实值,即使该事件未被调度直到onStop()被系统调用。
不幸的是,这个解决方案有两个主要问题
- 在API等级23以下,Android系统实际上保存活动的状态,即使它被另一活动部分覆盖。换句话说,Android系统调用,onSaveInstanceState() 但不一定会调用onStop()。这将创建一个潜在的长时间间隔,即使其UI状态不能被修改,观察者仍认为生命周期是活动的。
- 任何想要向类暴露类似行为的 LiveData类都必须实现Lifecycle版本beta 2和更低版本提供的解决方法 。
注意:为了使这个流程更简单,并且提供与旧版本的更好的兼容性,从版本开始1.0.0-rc1,Lifecycle对象被标记为CREATED 并且ON_STOP 在onSaveInstanceState() 被调用时被调度,而不用等待对该onStop()方法的调用。这不太可能影响您的代码,但您需要注意,因为它不符合ActivityAPI级别26及以下级别的呼叫顺序。
请点赞!因为你的鼓励是我写作的最大动力!
欢迎关注 Lee-Wang 的简书!
不定期分享关于安卓开发的干货,让坚持成为一种习惯
冰冻三尺,非一日之寒
人生最可悲的事,莫过于胸怀大志,却又虚度光阴!!!
不要在该奋斗的年纪选择了安逸
生命不息,奋斗不止,万事起于忽微,量变引起质变
每当你在感叹,如果有这样一个东西就好了的时候,请注意,其实这是你的机会
人不会死在绝境,却往往栽在十字路口
知道+做到=得到