赞
踩
官方文档翻译
生命周期感知组件响应于另一组件的生命周期状态(如Activity和Fragment)的变化而执行动作。这些组件有助于产生更好的组织性和更轻的重量代码,这更易于维护。
一种常见的模式是在Activity和Fragment的生命周期方法中实现依赖组件的动作。然而,这种模式导致代码的组织和错误扩散。通过使用生命周期感知组件,可以将依赖组件的代码从生命周期方法中移入组件本身。
android.arch.lifecycle包提供了类和接口,这些类和接口允许您构建生命周期感知组件,这些组件可以根据Activity或Fragment的当前生命周期状态自动调整其行为。
Lifecycle的依赖,包括LiveData和 ViewModel。
dependencies {
def lifecycle_version = "1.1.1"
// ViewModel and LiveData
implementation "android.arch.lifecycle:extensions:$lifecycle_version"
// alternatively - just ViewModel
implementation "android.arch.lifecycle:viewmodel:$lifecycle_version" // use -ktx for Kotlin
// alternatively - just LiveData
implementation "android.arch.lifecycle:livedata:$lifecycle_version"
// alternatively - Lifecycles only (no ViewModel or LiveData).
// Support library depends on this lightweight import
implementation "android.arch.lifecycle:runtime:$lifecycle_version"
annotationProcessor "android.arch.lifecycle:compiler:$lifecycle_version" // use kapt for Kotlin
// alternately - if using Java8, use the following instead of compiler
implementation "android.arch.lifecycle:common-java8:$lifecycle_version"
// optional - ReactiveStreams support for LiveData
implementation "android.arch.lifecycle:reactivestreams:$lifecycle_version"
// optional - Test helpers for LiveData
testImplementation "android.arch.core:core-testing:$lifecycle_version"
}
AndroidX
dependencies {
def lifecycle_version = "2.0.0-beta01"
// ViewModel and LiveData
implementation "androidx.lifecycle:lifecycle-extensions:$lifecycle_version"
// alternatively - just ViewModel
implementation "androidx.lifecycle:lifecycle-viewmodel:$lifecycle_version" // use -ktx for Kotlin
// alternatively - just LiveData
implementation "androidx.lifecycle:lifecycle-livedata:$lifecycle_version"
// alternatively - Lifecycles only (no ViewModel or LiveData). Some UI
// AndroidX libraries use this lightweight import for Lifecycle
implementation "androidx.lifecycle:lifecycle-runtime:$lifecycle_version"
annotationProcessor "androidx.lifecycle:lifecycle-compiler:$lifecycle_version" // use kapt for Kotlin
// alternately - if using Java8, use the following instead of lifecycle-compiler
implementation "androidx.lifecycle:lifecycle-common-java8:$lifecycle_version"
// optional - ReactiveStreams support for LiveData
implementation "androidx.lifecycle:lifecycle-reactivestreams:$lifecycle_version" // use -ktx for Kotlin
// optional - Test helpers for LiveData
testImplementation "androidx.arch.core:core-testing:$lifecycle_version"
}
在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();
}
}
android.arch.lifecycle包提供了类和接口,帮助您以弹性和独立的方式解决这些问题。
Lifecycle是一个包含组件生命周期状态(如activity或fragment)信息的类,并允许其他对象观察该状态。
Lifecycle主要使用两个枚举来跟踪其相关组件的生命周期状态:
从框架和Lifecycle类中分派的生命周期事件。这些事件映射到activities和fragments中的回调事件。
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接口,这在下面的章节中解释。
LifecycleOwner是一个单一的方法接口,表示该类具Lifecycle。它有一个方法,getLifecycle(),它必须被实现。如果您试图管理整个应用程序的生命周期,请参阅ProcessLifecycleOwner。
该接口从单个类(如Fragment和AppCompatActivity)抽象出Lifecycle的所有权,并允许编写与其共同工作的组件。任何自定义应用程序类都可以实现LifecycleOwner接口。
实现LifecycleObserver的组件与实现LifecycleOwner的组件无缝协作,因为所有者可以提供一个生命周期,观察者可以注册来监视该生命周期。
对于位置跟踪示例,我们可以使MyLocationListener类实现LifecycleObserver,然后在activity的Lifecycle的onCreate()方法中初始化它。这允许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现在不处于一个合适的状态,常见的做法是避免调用某些回调。例如,如果一个回调函数运行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.getCurrentState().isAtLeast(STARTED)) {
// connect if not connected
}
}
@OnLifecycleEvent(Lifecycle.Event.ON_STOP)
void stop() {
// disconnect if connected
}
}
通过这个实现,我们的LocationListener类完全是生命周期感知的。如果我们需要从另一个activity或fragment中使用我们的LocationListener,我们只需要初始化它。所有的设置和拆卸操作都是由类本身管理的。
如果一个库提供的类需要与Android lifecycle 一起使用,我们建议您使用生命周期感知组件。您客户端的lib可以轻松地将这些组件集成在客户端上而无需手动管理生命周期。
支持库26.1.0中的Fragment和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控制器(activities和fragments)尽可能轻量级。他们不应该试图获取他们自己的数据;相反,使用ViewModel来做这件事,并观察LiveData对象,以将数据变化返回给视图。
尝试编写数据驱动的UI,其中UI控制器的职责是在数据更改时更新视图,或将用户操作通知回ViewModel。
将你的数据逻辑放在ViewModel类中。ViewModel应充当UI控制器和应用程序其余部分之间的连接器。但是要注意,ViewModel的责任不是用来获取数据(例如,从一个网络获取数据)。相反,ViewModel应该调用适当的组件来获取数据,然后将结果提供给UI控制器。
使用Data Binding来维护View和UI控制器之间的干净接口。这可以让您的视图更具声明性,并最小化您需要在activities和fragments中写入的更新代码。如果你习惯用Java编程语言做这件事,使用像Butter Knife这样的库来避免样板代码并有更好的抽象。
如果UI复杂,请考虑创建一个presenter类来处理UI修改。这可能是一项费力的任务,但它可以使UI组件更容易测试。
避免在ViewModel中引用View或者Activity的上下文。如果ViewModel超出了activity(在配置改变的情况下),那么您的activity就会内存泄漏,并且不能被垃圾收集器正确地处理。
生命周期感知组件可以使您在各种情况下更容易管理生命周期。举几个例子:
在粗粒度和细粒度位置更新之间切换。使用生命周期感知的组件,使细粒度的位置更新,而您的位置应用程序是可见的,并切换到粗粒度更新时,应用程序是在后台。LiveData是一个生命周期感知组件,允许你的app自动更新UI,在用户更改位置的时候。
停止和启动视频缓冲。使用生命周期感知的组件尽快启动视频缓冲,但推迟播放直到应用程序完全启动。当应用程序被销毁时,还可以使用生命周期感知组件来终止缓冲。
启动和停止网络连接。当应用程序处于前台,使用生命周期感知的组件来启用网络数据的实时更新(流),并且当应用程序进入后台时也会自动暂停。
停止和恢复动画drawables。当应用程序处于后台时,使用生命周期感知的组件来停止动画,当应用程序处于前台之后恢复动画播放。
当Lifecycle属于AppCompatActivity或Fragment时,生命周期的状态将更改为CREATED,而当AppCompatActivity或Fragment的onSaveInstanceState()被调用时,ON_STOP事件将被调度。
当通过onSaveInstanceState()保存Fragment或AppCompatActivity的状态时,其UI被认为是不可变的,直到调用ON_START。试图在保存状态后修改UI可能会导致应用程序导航状态的不一致,这是为什么如果在保存状态后应用程序运行FragmentTransaction,则FragmentManager抛出异常。有关详细信息,请参阅commit()。
LiveData阻止了它的边缘情况,通过阻止调用observer,如果observer关联的Lifecycle不是在STARTED状态。在幕后,它调用isAtLeast(),然后决定调用它的observer。
不幸的是,AppCompatActivity的onStop()方法是在onSaveInstanceState()之后调用的,它留下了一个不允许UI状态改变的间隙,但是Lifecycle还没有被移动到创建的状态。
为了防止这种情况,BETA2版本以及更低版本标记这个状态为CREATED,并且没有分发这个事件,以至于任何代码段检查当前的状态来获取真正的值,尽管事件在 onStop()被调用的时候 才会被分发。
不幸的是,这个解决方案有两个主要问题:
在API级别23和更低的情况下,Android系统实际上保存了活动的状态,即使它被另一个activity部分覆盖。换句话说,Android系统调用onSaveInstanceState(),但它不一定调用onStop()。这就形成了一个潜在的长间隔,以至于观察者仍然认为生命周期是活动的,而此时它的UI状态不能被修改。
任何想要向LiveData类暴露类似行为的类都必须实现Lifecycle Beta2版本或者更低版本提供的解决方案。
注意: 为了使流程更简单,并与旧版本提供更好的兼容性,从版本1.0.0 RC1开始,Lifecycle对象被标记为CREATED,当onSaveInstanceState()被调用时, ON_STOP事件被分发,而不需等待调用onStop()方法。这不太可能影响您的代码,但这里你需要注意,因为它与API级别26和更低的Activity类中的调用顺序不匹配。
尝试lifecycle 组件 codelab.
生命周期感知组件是Android Jetpack的一部分。在Sunflower演示应用程序中可以看到他们。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。