Android Jetpack系列之Handling Lifec

Lifecycle-aware组件可以在另外一些组件的生命周期发生变化的时候作出响应，比如Activity和Fragment。这些组件可以帮助你写出更好组织，更好维护的代码。
对于在Activity或者Fragment生命周期中需要处理的一些事情，通常的做法就是，直接在生命周期方法中处理逻辑。然而，这种做法会导致一些问题，比如不能很好的组织代码，并且还可能产生新的很难找出的错误。通过使用Lifecycle-aware组件，你可以将生命周期中的一些处理逻辑转移到这些组件之中。
android.arch.lifecycle包提供了一些类和接口，这些类和接口可以基于Activity或者Fragment的生命周期的状态来改变它们自己的行为。
Android Framework中大多数组件都有生命周期，而这些生命周期是被操作系统或者Framework代码来管理，你的应用必须要遵守它们的规则。如果不这样做，将会导致内存泄漏或者直接crash。
想象一个显示地理位置的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
    }
}

尽管这个例子看起来没什么问题，但是如果在一个真实的App中，如果在生命周期方法中管理更多的组件，将会在生命周期方法中产生更多的代码，并且难以维护。
另外，你也不能保证，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包提供了一些类和接口来帮助你以一种有弹性和简单的方式处理这些问题。

Lifecycle

Lifecycle是一个包含了组件生命周期信息并且允许其他对象观察这些状态的类。LifeCycle使用两个主要的枚举来追踪其相关组件的生命周期状态：
Event
生命周期事件是被Framework和Lifecycle类分发的，这些事件会对应映射到activity和fragment中的回调事件中。
State
当前被Lifecycle追踪的组件(Activity,Fragment)的当前状态

image

想象在这些节点之间，状态(state)作为图形的节点，事件作为边。

一个类可以通过注解在方法上来监视这个组件的生命周期状态，然后你通过调用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只有一个方法，这个方法指定当前这个类有一个Lifecycle对象。它只有一个必须被当前类实现的getLifecycle()方法。如果你尝试管理整个应用进程的生命周期，你应该使用ProcessLifecycleOwner.
这个接口从单独的类中抽象出Lifecycle的所有权，比如Fragment和AppCompatActivity，并且允许写入和它们一起工作的组件，任何自定义的application类可以实现LifecycleOwner接口。
实现了LifecycleObserver的组件和实现了LifecycleOwner的组件可以很好地在一起工作，因为拥有者可以提供生命周期，另一个观察者可以注册然后被通知。
对于定位的例子，我们可以让MyLocationListener实现LifecycleObserver,然后在onCreate()方法中通过activity的Lifecycle初始化它。这就允许本来在生命周期方法中的逻辑处理放到了MyLocationListener 中来处理。有了这种独立组件处理它们自己的逻辑之后，Activity和Fragment的逻辑就更容易管理了。

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

//TODO