Android 结构组件之 Lifecycle

2018-05-14 本文已影响51人 Ggx的代码之旅

早在去年Architecture Components刚出来的时候，就简单的翻译过这些内容.隔了这么久了，东西也有不少的变化，自己用的也少，但是看形势感觉大势所趋的样子，因此好好的在学一下。要学习Architecture Component，的先学会如何使用它，进而才能去理解并深入。所以现在还是第一个阶段——使用阶段.本文大部分内容基本都是翻译。您也可以直接去官网直接看原文。本篇介绍Lifecycle

准备工作

我们需要引入一些必要的依赖,在这篇文章中已经介绍了Android 结构组件之Adding Components to your Project

Handling Lifecycles

我们的App在运行过程中被android系统管理着各种生命周期，这些生命周期是app的核心，所以我们必须关心它们，妥善处理，否则就会产生内存泄漏风险甚至程序崩溃。
现在我们想象一个场景，我们有一个显示位置的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();
    }
}

尽管这个例子看起来不错，但在真实的应用中，你最终会变成大量的调用start()和stop()方法，此外，有一些组件我们不能仅仅只在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();
    }
}

因此，Lifecycles提供了一组有弹性且解耦的类来帮助我们解决这一系列问题。

Lifecycle

Lifecycle是一个持有activity或者fragment的生命周期状态信息的类，并且允许其他对象来观察这些状态。
Lifecycle主要通过两种枚举来追踪组件的生命周期状态。
1.Event：表示从系统框架和Lifecycle类中发送的生命周期事件，这些事件被映射到activity和fragment生命周期的回调中。
2.State：Lifecycle对象追踪当前组件的状态。

我们可以把State想象成图的节点而Event就好比是这些点之间的边
下面是一个简单的例子，通过注解的形式来监视组件的生命周期。

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是一个拥有单一方法的接口，代表一个有生命周期的类。它需要实现一个叫做getLifecycle()方法。如果您试图管理整个应用程序流程的生命周期。查阅ProcessLifecycleOwner.
这个接口是从Lifecycle类中抽象出来。如Activities和Fragments允许编写能同时使用它们的组件，其他的自定义类也可以实现这个LifecycleOwner接口。
实现LifecycleObserver的组件与实现LifecycleOwner的组件无缝地工作，因为所有者可以提供一个观察者可以注册观看的生命周期。

对于上面的例子，我们让我们的MyLocationListener实现LifecycleObserver接口，并且在Activity的onCreate生命周期方法中初始化它。

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();
            }
        });
  }
}

有一个普通的使用案例，就是可以避免生命周期如果在一个不好的状态时使用回调。例如，一个回调运行在一个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中使用LocationListener，仅仅只需要初始化它既可，其他任何的安装和拆卸操作都将被它自身所管理。
如果一个库工作在android 生命周期上，我们推荐你使用生命周期织入组件。库中提供了需要与Android生命周期一起工作的类鼓励使用生命周期感知。我们可以很容易地将这些类集成到客户端上，而无需手动生命周期管理。
LiveData是一个生命周期织入组件的例子。使用LiveData和ViewModel组合可以更容易在Android生命周期内更新数据。

自定义 LifecycleOwner

Fragments 和Activities兼容库在26.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;
    }
}

最佳的Lifecycles实践

1.精可能的保持你的UI控制器精简（activities 和fragments），它们不应该试图自己获取数据。而是用ViewModel去代替它来观察LiveData反映回来的变化。
2.当数据发生变化后在UI界面上写数据驱动，或者通知作用会ViewModel。
3.把你的数据逻辑放在ViewModel类中，ViewModel应该作为你的UI控制器和应用程序的其余部分之间的连接器。还是要注意的是，取数据不是ViewModel的责任（如从网络获取），相反ViewModel应该调用相应的组件来做这项工作，并提供结果反馈给UI控制器。
4.使用DataBinding把视图和控制器之间的接口降到最低。它可以使你的视图更具有声明性并且可以最小减少你在activity和fragment中做的更新代码。如果你更喜欢用java代码去做它，那可以使用像Butter Knife的库来避免样板化代码，保持一个更好的抽象。
5.如果你的UI比较复杂，可以考虑使用一个Presenter类来管理它的修改。通常情况下这是多余的，但可以让你的界面更容易做测试。
6.在你的ViewModel中不要引用任何一个View或者Activity的Context。这样会导致你的Activity泄露，不会被GC回收。

处理on stop 事件

当生命周期属于AppCompatActivity或者Fragment时，当生命周期状态的onCreate和onStop被发送后，AppCompatActivity和Fragment的onSaveInstanceState()方法会被调用。
当Fragment or AppCompatActivity的状态通过[onSaveInstanceState()](https://developer.android.com/reference/android/support/v7/app/AppCompatActivity.html#onSaveInstanceState(android.os.Bundle)保存。UI被认为知道onStart方法调用前都是不可变的。在保存状态后尝试修改UI可能会导致应用程序的状态不一致，这就是为什么在保存了状态后，FragmentManager会抛出一个异常。具体可以看commit()
LiveData预防了这一个情况，如果观察者的相关生命周期不启动，LiveData就可以避免通过调用它的观察者来避免这种边缘情况。
不幸的是，AppCompatActivity的onStop方法在 onSaveInstanceState()之后被调用。这就留下了不允许UI状态更改的一个间隙，但是生命周期还没有被转移到创建的状态上。
为了解决这个问题，Lifecycle的一个bate2版本中，在不调度事件的情况下，将状态标记为创建状态，这样，即使在系统调用onStop()之前，任何检查当前状态的代码都会得到真正的值。
不幸的是这个方案仍然有两个主要的问题：
1. 在API23或者更低的版本上，Android系统实际上如果另一个activity部分所覆盖，则只会保存了一个activity的状态，换句话说，Android系统调用onSaveInstanceState()，但它并不一定调用onStop()。这将创建一个潜在的长时间间隔，观察者仍然认为生命周期是活动的，即使它的UI状态不能被修改。
2. 任何想要暴露LiveData类似行为的类必须都要实现Lifecycle版本beta 2和更低版本提供的解决方案。

注意:为了使这个流程更简单，并提供与旧版本更好的兼容性，从版本1.0.0-rc1开始，Lifecycle对象在调用onSaveInstanceState()时被标记为CREATED和ON_STOP，而无需等待onStop()方法的调用。这不大可能影响您的代码，但是您需要注意的是，它与API级别26和以下的Activity类中的调用顺序不匹配。

Android 结构组件之 Lifecycle

准备工作

Handling Lifecycles

Lifecycle

LifecycleOwner

自定义 LifecycleOwner

最佳的Lifecycles实践

处理on stop 事件

欢迎共同探讨更多安卓，java，c/c++相关技术QQ群：392154157

猜你喜欢

热点阅读