初探Architecture Components之Lifecycle

Demo地址： Kotlin-Dagger-2-Retrofit-Android-Architecture-Components

在Android框架中，我们所熟悉的大多数组件都有生命周期的，而这些生命周期由Android系统本身管理，或者在程序运行时，由代码动态管理。如果忽略了对其的管理，可能会造成内存泄漏或者应用程序崩溃。这是我们不希望看到的。甚至有时候，我们在各个生命周期中，比如onCreate或者onPause方法中，添加了各种逻辑处理，从而影响了应用程序的性能。本文，我们将了解Architecture Component中的lifecycle库，在
android.arch.lifecycle包提供的类和接口， 可以构建基于Activity/Fragment的生命周期的组件 - 此组件可以根据Activity/Fragment的当前生命周期自动调整它。让我们来看看，它是如何完美处理组件生命周期的变化。

Lifecycle

对于Lifecyle而言，我们是这么定义的：Lifecycle是一个抽象类，该类保存了有关组件(如Activity/Fragment)生命周期状态的信息， 并且允许其他对象观察此状态。

Lifecycle怎样管理组件的生命周期的状态呢？在Lifecycle类中有两个枚举Event和State：

• Event：生命周期事件由Android框架和Lifecycle分发，这些事件映射到Activity和Fragment中的回调事件。
• State：Lifecycle对象关联的组件的当前生命周期状态

下面，我们先看Event：

• ON_CREATE：关联onCreate事件
• ON_START：关联onStart事件
• ON_RESUME：关联onResume事件
• ON_PAUSE：关联onPause事件
• ON_STOP：关联onStop事件
• ON_DESTROY：关联onDestroy事件
• ON_ANY：关联所有的生命周期的事件

Event关联所对应的LifecycleOwner的生命周期，当Activity或者Fragment等组件的生命周期发生变化时，其会分发相应的事件，这些事件就会调用相应的回调。

接下来看，State这个枚举(以Activity作为组件示例)

• DESTROYED：表示LifecycleOwner的DESTROYED状态。此事件之后，此Lifecycle不会再分发任何事件。在此状态之前，Activity调用了onDestroy。
• INITIALIZED：LifecycleOwner的INITIALIZED状态。当Activity被创建，但是未调用onCreate之前的状态。

• CREATED：LifecycleOwner的CREATED状态。对于Activity而言有两种情况达到此状态：

  • 调用onCreate方法之后
  • 调用OnSotp方法之前

• STARTED：LifecycleOwner的STARTED状态。对于Activity而言有两种情况可以达到此状态：

  • onStart方法调用之后
  • onPause方法调用之前
• RESUMED：LifecycleOwner的RESUMED状态。当调用onResume方法之后，会到达此状态

现在，我们已经了解到Event中的事件和State中LifecycleOwner的状态，从下图中，可以清晰的看出它们之间的联系：

这里，我们可以把State当作生命周期中各个状态的节点，而Event就是生命周期状态发生变化时分发的事件。

LifecycleOwner

LifecycleOwner是一个单一的接口，表示实现类有一个Lifecycle的实例。在LifecycleOwner接口中的getLifecycle()必须由实现类实现,其返回Lifecycle的实现类实例。

该类从单个组件(例如Activity/Fragment）的生命周期与其Lifecycle实例相关联，并且允许多个组件共用一个LifecycleOwner。任何一个自定义的Android组件类都可以实现LifecycleOwner接口。

注意：由于Architecture Components处于Alpha阶段，故而Fragment和AppCompatActivity类并未实现该接口，那是因为不能将不稳定的API添加到定组件的依赖关系中。在Lifecycle稳定之前，提供了LifecycleActivity和LifecycleFragment类暂时使用。在Architecture Components正式发布后，Fragment和AppCompatActivity将实现实现LifecycleOwner接口，以取代LifecycleActivity和LifecycleFragment。

自定义Activity/Fragment实现LifecycleOwner 接口

任何自定义的Activity/Fragment可以通过实现LifecycleRegistryOwner接口， 而不是继承LifecycleFragment或LifecycleActivity。因为每个类只能继承自一个父类，有时候第三方框架要求必须继承自其定义的组件，如果这里再继承，就显得捉襟见肘了。

class PersonActivity : LifecycleActivity(), LifecycleRegistryOwner {

    val mRegistry: LifecycleRegistry = LifecycleRegistry(this)

    val personObserver: PersonObserver = PersonObserver()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_person)
        lifecycle.addObserver(personObserver)
        Log.i("tea", " onCreate")
    }

    override fun onStart() {
        super.onStart()
        Log.i("tea", " onStart")
    }

    override fun onResume() {
        super.onResume()
        Log.i("tea", " onResume")
    }

    override fun onPause() {
        super.onPause()
        Log.i("tea", " onPause")
    }

    override fun onStop() {
        super.onStop()
        Log.i("tea", " onStop")
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.i("tea", " onDestroy")
    }

    override fun getLifecycle(): LifecycleRegistry {
        return mRegistry
    }
}

LifecycleObserver

前面，我们已经了解到了Lifecycle如何与组建的声明周期相关联，可是，该如何处理生命周期变化时分发的事件呢？接下来，我们来了解另外一个接口 - LifecycleObserver。该接口内没有任何方法，而它是依赖于@OnLifecycleEvent注解的方法，来监听分发Lifecycle事件。

下面，我们来创建LifecycleObserver的实现类 - PersonObserver，通过使用@OnLifecycleEvent注解其方法，以达到监视组件的生命周期状态变化的目的，我们来看看相关方法执行的先后顺序：

class PersonObserver(val lifecycle: Lifecycle) : LifecycleObserver {

    fun initObserver() {
        if (lifecycle.currentState.isAtLeast(Lifecycle.State.STARTED)) {

        }
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    fun onCreate() {
        Log.i("tea", "PersonObserver - onCreate")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        Log.i("tea", "PersonObserver - onStart")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun onResume() {
        Log.i("tea", "PersonObserver - onResume")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun onPause() {
        Log.i("tea", "PersonObserver - onPause")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    fun onStop() {
        Log.i("tea", "PersonObserver - onStop")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    fun onDestroy() {
        Log.i("tea", "PersonObserver - onDestroy")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_ANY)
    fun onAny() {
        Log.i("tea", "PersonObserver - onAny")
    }
}

在前面自定义的PersonActivity中，已经通过addObserver方法将PersonObserver添加至LifecycleObserver状态变化的可观察列表中。接下来，我们来看看，当LifecycleObserver状态放生变化时，PersonObserver中的方法是如何回调的呢？

I/tea: onCreate
I/tea: PersonObserver - onCreate
I/tea: PersonObserver - onAny

I/tea: onStart
I/tea: PersonObserver - onStart
I/tea: PersonObserver - onAny

I/tea: onResume
I/tea: PersonObserver - onResume
I/tea: PersonObserver - onAny

I/tea: PersonObserver - onPause
I/tea: PersonObserver - onAny
I/tea: onPause

I/tea: PersonObserver - onStop
I/tea: PersonObserver - onAny
I/tea: onStop

I/tea: PersonObserver - onDestroy
I/tea: PersonObserver - onAny
I/tea: onDestroy

从上述Log中，我们清晰的看到：

• 在每次LifecycleObserver状态变化时，Lifecycle都会分发Event.ON_ANY事件；并且Event.ON_ANY事件的分发晚于其所对应的状态事件分发；
• 在onCreate、onStart、onResume等状态中，Lifecycle事件分发晚于相应LifecycleObserver的状态变化；而在onPause、onStop、onDestroy等状态中，Lifecycle事件分发早于相应LifecycleObserver的状态变化。

通过这种做法，PersonObserver类可以监控生命周期状态的变化，从而它可以执行本身的初始化和资源释放，而不受当前Activity的管理。 如果在另外一个Activity或者Fragment中使用PersonObserver， 我们只需要初始化MyLocationListener， 所有的设置和资源释放操作由其本身管理。这样做：

• 保证UI持有者(Activity/Fragment)更可能的简洁。在其内，不应该获取所需的数据，而是使用ViewModel来执行此操作，并通过LiveData监测数据的变化并将数据变化映射到UI中。
• UI持有者的职责在于数据更改时更新UI，或者将用于的操作反馈给ViewHolde，由数据驱动UI的更新
• 将数据逻辑操作放在ViewhHolder类中。ViewModel作为UI持有者和应用程序其他部分之间的桥梁。需要注意的是，ViewHoler的职责不是获取数据(例如，从网络获取数据)，相反的是，ViewModel应当调用相应的组件来执行此操作，然后将结果反馈给UI持有者。
• 使用Data Binding来保证UI持有者和视图之间的简洁。
• 如果UI很复杂，可以考虑创建一个Presenter类来处理UI修改。
• 不要在ViewModel中引用View或Activity的Context。如果ViewModel寿命长于Acvivity，那么将造成内存泄漏。