Android mvvm之LiveData原理案例详解

1. 生命周期感知

1.1 生命周期感知组件

我们知道,Controller(Activity or Fragment) 都是有生命周期的,但是传统的 Controller 实现方式只负责 Controller 本身的生命周期管理,而与业务层的数据之间并没有实现良好解耦的生命周期事件交换。所以业务层都需要自己主动去感知 Controller 生命周期的变化,并在 Controller 的生存期处理数据的保活,而在消亡时刻解除与 Controller 之间的关系,这种处理方式随着业务规模的扩大往往显得代码臃肿和难以维护。

Jetpack 框架让 Controller 变得可感知,成为一个生命周期事件变化的通知中心,我们实现的任何组件或对象都可以通过订阅这个通知中心实时知道 Controller 生命周期的变化(这样的组件或对象我们称之为生命周期感知组件),而不需要繁琐的主动询问;同时,Jetpack 推荐将数据封装成 LiveData,因为 LiveData 自带感知 Controller 的生命周期变化,自我维护数据更新与生命周期更新的协调关系。LiveData 是典型的生命周期感知组件。而现在的 Controller 我们称之为生命周期可感知 Controller,在 Jetpack 的实现中,有一个专门的接口来代表它——LifecycleOwner,名副其实,Controller 是生命周期的所有者。

1.2 LifecycleOwner 的状态和事件模型

LifecycleOwner 中维护一个叫做 Lifecycle 的接口,它规定了生命周期的状态和状态切换的事件流模型。在 android developer 的官方文档中,给出了一个非常清晰的时序图来说明这个模型:

  • 生命周期的状态总共有 5 个:DESTROYED,INITIALIZED,CREATED,STARTED,RESUMED;
  • 状态切换事件总共有 7 个:ON_CREATE,ON_START,ON_RESUME,ON_PAUSE,ON_STOP,ON_DESTROY,ON_ANY;
  • 每个事件除了 ON_ANY 以外,都严格在 Controller 的 onXXX() 回调中产生,比如 ON_CREATE 事件在 Activity.onCreate() 和 Fragment.onCreate() 中进行分派;
  • 需要注意 CREATED 和 STARTED 两个状态的入度都为 2,即有两个不同的事件都能达到这个状态。

2. LiveData 与 LifecycleOwner 的双向订阅

在讲述 LiveData 的原理时,没有办法孤立地谈 LiveData,因为它的实现和 LifecycleOwner 的交互是分不开的,所以这里需要将两者结合进行说明。

2.1 LiveData 订阅生命周期变化

LiveData 作为 View 的 UI 状态数据源,并不是在 LifecycleOwner 的每个生命周期状态中都可用的,而必须在 View 完成所有的测量和布局操作后,才能基于 LiveData 进行 UI 状态更新。这说明 LiveData 是有一个可用状态标记的,在源代码中,标记为 active:

LiveData 中更新 active 标记的方法:

boolean shouldBeActive() {
    return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);
}

这说明,只有当 LifecycleOwner 的状态至少是 STARTED,LiveData 才是处于激活状态的。再看 Lifecycle.State 的枚举顺序:

public enum State {
    DESTROYED,
    INITIALIZED,
    CREATED,
    STARTED,
    RESUMED;

    /**
     * Compares if this State is greater or equal to the given {@code state}.
     *
     * @param state State to compare with
     * @return true if this State is greater or equal to the given {@code state}
     */
    public boolean isAtLeast(@NonNull State state) {
        return compareTo(state) >= 0;
    }
}

进一步说明,只有当 LifecycleOwner 的状态是 STARTED 和 RESUMED 时,LiveData 才是处于激活状态的,而只有在激活状态下,LiveData 才会将最新数据变化通知给它的订阅者:

private void considerNotify(ObserverWrapper observer) {
    if (!observer.mActive) { // 没有激活,不进行通知
        return;
    }

    // 在 LifecycleOwner 的生命周期变化事件分派之前,需要提前主动更新一下激活状态,
    // 如果未激活,同样不进行通知
    if (!observer.shouldBeActive()) {
        observer.activeStateChanged(false);
        return;
    }

    //...省略非关键代码

    observer.mObserver.onChanged((T) mData);
}

严格的说这里并不应该叫 LiveData 的激活状态,而应该是向 LiveData 进行订阅的 LifecycleOwner 的激活状态,此时 LifecycleOwner 作为观察者观察 LiveData 的变化。所以这里可能叫 LiveData 在每一个 LifecycleOwner 上的分身的激活状态更合适,为了表述方便,我们就统称叫 LiveData 的激活状态。我们将在 2.2 节描述 LifecycleOwner 如何订阅 LiveData。

以上,只为了说明一个问题:LiveData 需要订阅 LifecycleOwner,感知其生命周期变化:

图示说明,LiveData 订阅 LifecycleOwner,而由 LifecycleOwner.Lifecycle 代理完成生命周期状态变化通知,所以 LiveData 直接能感知的是 Lifecycle。

2.2 LifecycleOwner 订阅数据变化

LifecycleOwner 在 STARTED 和 RESUMED 的状态下可以根据 LiveData 更新 UI 的状态,所以 LifecycleOwner 需要订阅 LiveData 的数据变化。

在实际实现当中,LifecycleOwner 作为抽象层并不具体负责订阅 LiveData,而是由业务层在 LifecycleOwner 中完成具体的订阅工作,此时我们称 LifecycleOwner 为 Controller 更合适,虽然它们往往是同一个东西:

注意图示,一个 User-defined Observer 必须和一个 LifecycleOwner 唯一绑定,否则将无法订阅。试想,如果一个 Observer 同时绑定两个 LifecycleOwner:L1 和 L2,假如 L1 处于 RESUMED 的状态,而 L2 处于 DESTROYED 的状态,那么 LiveData 将无所适从:如果遵循 L1 的状态,将变化通知给 Observer,则更新 L2 会出错;如果遵循 L2 的状态,不将变化通知给 Observer,则 L1 得不到及时更新。

2.3 多对多的双向订阅网

LiveData 和 LifecycleOwner 之间因为需要相互观察对方状态的变化,从而需要实现双向订阅;同时,为了支持良好的可扩展能力,各自都维护了一个观察者列表,形成一个多对多的双向订阅网络:

我们看到一个 LiveData 是可以同时向多个 LifecycleOwner 发起订阅的,所以,LiveData 本身其实并不实际维护一个激活状态,真正的激活状态维护在 LifecycleOwner 的 User-defined observer 中。

3 LiveData 的事件变化

LiveData 值更新之后的需要通知订阅者(观察者),其通知流程非常简单:

其中,判断观察者是否激活,即判断 LifecycleOwner 是否处于 STARTED 或 RESUMED 状态,在 2.1 节中已有说明。

我们看一下关键的源代码:

// 入口
@MainThread
protected void setValue(T value) {
    // 必须在主线程调用
    assertMainThread("setValue");

    //..省略非关键代码

    // 设置新值并派发通知
    mData = value;
    dispatchingValue(null);
}

// 通知派发流程
void dispatchingValue(@Nullable ObserverWrapper initiator) {
    //..省略非关键代码

    // 遍历观察者列表
    for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator =
            mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
        // 尝试通知观察者
        considerNotify(iterator.next().getValue());

        //..省略非关键代码
    }
}

其中 LiveData.considerNotify() 在 2.1 节中已有说明。

4 LifecycleOwner 的事件变化

对于 LifecycleOwner 来说,其变化的事件即为生命周期状态的变化。在 LifecycleOwner 的事件委托者 Lifecycle 看来,无论是发生了 ON_CREATE 事件还是 ON_START 事件,或是任何其它的事件,其事件的切换流程都是通用的。

换言之,只要 Lifecycle 接口的实现者实现这一通用切换流程,便只需给 LifecycleOwner 暴露一个切换入口,就能在 LifecycleOwner 的各个生命周期回调函数中调用这个入口就可以了。这样我们在 LifecycleOwner 中应该可以看到形如这样的流程(伪代码表示):

public class Activity/Fragment implements LifecycleOwner {
    @Override
    public onCrate() {
        //...省略非关键代码

        // 在 Jetpack 框架中,LifecycleImpl 被命名为 LifecycleRegistry
        LifecycleImpl.handleLifecycleEvent(ON_CREATE);
    }

    @Override
    public onStart() {
        //...省略非关键代码
        LifecycleImpl.handleLifecycleEvent(ON_START);
    }

    @Override
    public onResume() {
        //...省略非关键代码
        LifecycleImpl.handleLifecycleEvent(ON_RESUME);
    }

    @Override
    public onPause() {
        //...省略非关键代码
        LifecycleImpl.handleLifecycleEvent(ON_PAUSE);
    }

    @Override
    public onDestroy() {
        //...省略非关键代码
        LifecycleImpl.handleLifecycleEvent(ON_DESTROY);
    }
}

当然,在具体的源代码中,与上述伪代码会有一些出入,但是大体的结构是一致的。在 Jetpack 框架中,这个 Lifecycle 的实现者叫做 LifecycleRegistry。所以我们这里重点需要关注的就是 LifecycleRegistry 这个 Lifecycle 的代理接口的实现类是如何通知生命周期事件变化的。

4.1 Lifecycle 接口的实现——LifecycleRegistry

4.1.1 LifecycleRegistry 的订阅实现

如 2.2 节所述,通过 LiveData.observe(owner, user-defined observer),LifecycleOwner 的业务层向 LiveData 订阅数据变化,而在 LiveData.observe() 方法内,同时会自动通过 Lifecycle.addObserver(LiveData-defined observer) 向 LifecycleOwner 订阅生命周期变化:

// LiveData.observe()
@MainThread
public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {

    //...省略非关键代码

    LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);

    //...省略非关键代码

    // 向 LifecycleOwner 发起订阅
    owner.getLifecycle().addObserver(wrapper);
}

以上方法内的 owner.getLifecycle() 的实际对象即为 LifecycleRegistry,我们来看一下 LifecycleRegistry.addObserver() 的基本订阅流程:

从整个流程来看,总体可以分为三步:

  • 第一步是初始化观察者对象的状态,并将观察者缓存入队;
  • 第二步是以模拟派发生命周期事件的形式,将新加入的观察者的状态提升到目前为止可提升的最大状态;
  • 第三步是同步所有观察者的状态到全局状态。

我们可以看到,最后所有的观察者的状态都要同步到全局状态,全局状态即为 LifecyclerOwner 最新的状态。那么为什么需要进行这么繁琐的逐步模拟派发事件来进行同步呢?直接一步到位不行么?

我们可以考虑一个生命周期感知组件 LifeLocation,其功能是用于进行定位,它订阅了 LifecycleOwner,我们假设 LifeLocation 需要在 CREATED 的时候进行一些必要的初始化,而在 STARTED 的时候开始执行定位操作。假如在 LifecycleRegistry 中的状态同步可以一步同步到全局状态,那么有可能当前的全局状态已经是 RESUMED 的了,这样 LifeLocation 既得不到初始化,也无从启用定位功能了。

所以,以上这种看似繁琐的模拟派发状态事件的步骤是完全必要的,它让用户自定义的生命周期感知组件的状态切换流程是可预测的。

4.1.2 LifecycleRegistry 中的事件流

我们在 4.1.1 节中的流程图的第 6 步中提到,要根据 observer.state 来计算下一个状态事件,也就是说按照事件的流向,根据当前的状态,下一个要发生的事件是什么。我们修改一下 1.2 节的时序图如下:

观察到图中左边的蓝色箭头,举个例子,假如当前的状态是 CREATED,那么接下来要发生的事件应该是 ON_START。蓝色箭头指示的事件流方向是生命周期由无到生的过程,我们称为 upEvent 流;与此对应,右边的红色箭头指示的事件流方向是生命周期由生到死的过程,我们称之为 downEvent。

4.1.1 节中的流程图的第 6 步中正好需要进行 upEvent 流操作。除此以外,我们在第 7 步同步到全局状态时,还需要用到 upEvent 和 downEvent 流操作,且在 LifecycleOwner 的每一次生命周期的变化中,都需要进行上述第 7 步的状态同步操作。接下来我们就看一看,当 LifecycleOwner 生命周期变化后,发生了什么。

4.1.3 处理生命周期的变化

在 4 节开头我们描述了 LifecycleImpl.handleLifecycleEvent() 方法,在 LifecycleRegistry 中也有一个同名的方法,其功能就是处理 LifecycleOwner 生命周期的变化。handleLifecycleEvent() 的处理过程是这样的:

如图所示:

  • Sync 标记的部分是进行状态同步的核心流程,同时也是 4.1.1 节流程图中的第 7 步的具体实现;
  • 每一次生命周期的变化有可能是从无到生的 up 变化,也有可能是从生到死的 down 变化;
  • 如果是 up 变化,则需要进行 upEvent 流处理,如果是 down 变化,则需要进行 downEvent 流处理;
  • 根据 4.1.1 节的描述,我们可以得出,在观察者队列中的所有观察者,从最老(最开始)到最新(最末),必定维持一个不变性质:非降序排列;
  • 所以当 STATE < eldestState 时,说明观察者队列中的所有观察者状态都大于全局状态,这时候说明生命周期变化顺序是 down 方向的,需要进行 downEvent 流处理;
  • 而当 STATE > newestState 时,说明观察者队列中的所有观察者状态都小于全局状态,这时候说明生命周期变化顺序是 up 方向的,需要进行 upEvent 流处理;
  • 无论是 downEvent 流还是 upEvent 流,都会逐步派发生命周期事件给各个观察者。

关于 downEvent 流和 upEvent 流,我画了一张更加形象的图用以加深理解:

至此,整个 LiveData 和 Lifecycle 的原理就介绍完成了。

5. 关于观察者模式的一点思考

不难看出,LiveData 和 Lifecycle 的核心是观察者模式。无论是 LiveData 还是 Lifecycle,它们的共同点就是都需要维护一个稳定的状态机:

  • LiveData 的状态机就是数据值的变化,每个值就是一个状态,理论上可以是一个无限状态机;
  • Lifecycle 的状态机就是生命周期的变化,每个生命周期阶段就是一个状态,它是一个有限状态机。

在涉及到状态机模型时,如果我们需要感知状态机当前的状态,一般有两种方式:主动询问和被动通知。在复杂的业务中,主动询问状态机往往是不好的实践;而被动通知,可以让我们的业务按照状态进行清晰的分段,更易于模块化和测试。观察者模式就是一种很好的被动通知模式。

所以,当我们的对象维护了一个状态机的时候,可以考虑是否可以采用观察者模式来读取状态。但是需要注意的是,观察者模式内部是维护了一个观察者引用的列表的,当状态发生变化的时候,是采用顺序遍历的方式逐个进行通知的,可以想到,当一个被观察者中维护的观察者数量很多,其中又有很多观察者对状态的响应处理都比较耗时的话,会出现性能瓶颈。尤其是在基于单线程的 UI 环境下,更加需要引起注意,我们通常应该有一个机制来移除不再需要的观察者,以减轻通知负载。

说明:

该文档参考的 androidx 版本为

core: 1.1.0

lifecyle: 2.2.0-alpha01

fragment: 1.1.0-alpha09

到此这篇关于Android mvvm之LiveData原理案例详解的文章就介绍到这了,更多相关Android mvvm之LiveData原理内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • vmware虚拟机安装安卓Android x86的方法步骤

    有时候只是想测试一个app,又不想在手机上做个测试,这个时候我们就可以用虚拟机来完成这件事情.首先到官网上去下载一个安卓系统(https://www.android-x86.org/),我这里用:android-x86-9.0-rc1.iso做演示. 或者选择本地安卓系统下载地址:https://www.jb51.net/softs/203311.html 在提供一个VMware15的下载地址:https://www.jb51.net/softs/638385.html VMware15 for

  • Android单项绑定MVVM项目模板的方法

    0.前言 事情还要从上周和同事的小聚说起,同事说他们公司现在app的架构模式用的是MVP模式,但是并没有通过泛型和继承等一些列手段强制使用,全靠开发者在Activity或者Fragment里new一个presenter来做处理,说白了,全靠开发者自觉.这引发了我的一个思考,程序的架构或者设计模式的作用,除了传统的做到低耦合高内聚,业务分离,我觉得还有一个更重要的一点就是用来约束开发者,虽然使用某种模式或者架构可能并不会节省代码量,有的甚至会增加编码工作,但是让开发者在一定规则内进行开发,保证一个

  • 详解Android框架MVVM分析以及使用

    Android MVVM 分析以及使用 首先我们需要知道什么是MVVM,他的功能和优点,以及他的缺点. MVVM是Model-View-ViewModel的简写.它本质上就是MVC 的改进版.MVVM 就是将其中的View 的状态和行为抽象化,让我们将视图 UI 和业务逻辑分开.当然这些事 ViewModel 已经帮我们做了,它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑.微软的WPF带来了新的技术体验,如Silverlight.音频.视频.3D.动画-

  • 详解Android的MVVM框架 - 数据绑定

    本教程是跟着 Data Binding Guide学习过程中得出的一些实践经验,同时修改了官方教程的一些错误,每一个知识点都有对应的源码,争取做到实践与理论相结合. Data Binding 解决了 Android UI 编程中的一个痛点,官方原生支持 MVVM 模型可以让我们在不改变既有代码框架的前提下,非常容易地使用这些新特性.其实在此之前,已经有些第三方的框架可以支持 MVVM 模型,无耐由于框架的侵入性太强,导致一直没有流行起来. 准备 Android Studio 更新到 1.3 版

  • Android端内数据状态同步方案VM-Mapping详解

    目录 背景 问题拆解 目标 方案调研 EventBus 基于k-v的监听.通知 全局共享数据Model实例 基于注解的对象映射方案VM-Mapping 特点 思考 突破View层级的限制 突破类型的限制 详细设计 映射 数据驱动UI 总体流程 其它细节 方案对比 方案收益 后续计划 背景 西瓜在feed.详情页.个人主页有一块功能区,包括了点赞.收藏.关注等功能.这些功能长久以来都是孤立的:多个场景下点赞.收藏.关注等状态或数量不一致.在以往的业务迭代中,都是业务A有了需求,就加个点赞的请求,把

  • Android Studio 报错failed to create jvm error code -4的解决方法

    安装完 Android Studio 后启动,却报错如下: 复制代码 代码如下: failed to create jvm error code -4 这一般应是内存不够用所致,解决方法参考如下. 打开 Android Studio 安装目录下的bin目录,查找并打开文件 studio.exe.vmoptions,修改代码: 复制代码 代码如下: -Xmx512m 为 -Xmx256m 保存后应即可正常打开了.

  • Android mvvm之LiveData原理案例详解

    1. 生命周期感知 1.1 生命周期感知组件 我们知道,Controller(Activity or Fragment) 都是有生命周期的,但是传统的 Controller 实现方式只负责 Controller 本身的生命周期管理,而与业务层的数据之间并没有实现良好解耦的生命周期事件交换.所以业务层都需要自己主动去感知 Controller 生命周期的变化,并在 Controller 的生存期处理数据的保活,而在消亡时刻解除与 Controller 之间的关系,这种处理方式随着业务规模的扩大往往

  • Android registerForActivityResult动态申请权限案例详解

    前言 这几天在做一个小工具app,结果在fragment里面动态申请权限提示原有的申请方法已经弃用,还画了很明显的删除线...这叫一个强迫症的我怎么受得了.赶紧网上找资料也找不出什么结果,看了官方文档才发现了有registerForActivityResult这么一个神奇好用的函数,可以代替我们现有的startActivityForResult和权限申请函数. 那么下面就分两种情况来讲一下如何使用这个函数动态申请权限. 一.申请单个权限 首先,我们需要定义一个launcher: Activity

  • jQuery 跨域访问解决原理案例详解

    浏览器端跨域访问一直是个问题,多数研发人员对待js的态度都是好了伤疤忘了疼,所以病发的时候,时不时地都要疼上一疼.记得很久以前使用iframe 加script domain 声明.yahoo js util 的方式解决二级域名跨域访问的问题. 时间过得好快,又被拉回js战场时, 跨域问题这个伤疤又开疼了.好在,有jQuery帮忙,跨域问题似乎没那么难缠了.这次也借此机会对跨域问题来给刨根问底,结合实际的开发项目,查阅了相关资料,算是解决了跨域问题...有必要记下来备忘, 跨域的安全限制都是指浏览

  • Android notifyDataSetChanged() 动态更新ListView案例详解

    有时候我们需要修改已经生成的列表,添加或者修改数据,notifyDataSetChanged()可以在修改适配器绑定的数组后,不用重新刷新Activity,通知Activity更新ListView.今天的例子就是通过Handler AsyncTask两种方式来动态更新ListView. <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://sc

  • Android 使用registerReceiver注册BroadcastReceiver案例详解

    android.context.ContextWrapper.registerReceiver public Intent registerReceiver (BroadcastReceiver receiver, IntentFilter filter) Register a BroadcastReceiver to be run in the main activity thread. The receiver will be called with any broadcast Intent

  • Android AlertDialog六种创建方式案例详解

    目录 一.setMessage:设置对话框内容为简单文本内容 二.setItem:设置文本框内容为简单列表项 三.setSingleChoiceItems()设置对话框内容为单选列表项 四.setMultiChoiceItems()设置对话框内容为多选项列表 五.setAdapter()设置对话框内容为自定义列表项(这里是一个布局) 六.setView()设置对话框为自定义View 创建AlertDialog的步骤: 创建AlertDialog.Builder对象 调用Builder对象的set

  • Android AlertDialog多种创建方式案例详解

    目录 一.setMessage:设置对话框内容为简单文本内容 二.setItem:设置文本框内容为简单列表项 三.setSingleChoiceItems()设置对话框内容为单选列表项 四.setMultiChoiceItems()设置对话框内容为多选项列表 五.setAdapter()设置对话框内容为自定义列表项(这里是一个布局) 六.setView()设置对话框为自定义View 创建AlertDialog的步骤: 创建AlertDialog.Builder对象 调用Builder对象的set

  • Android动画之TranslateAnimation用法案例详解

    我们在实际的开发过程中,有很多地方需要使用TranslateAnimation,本文是爱站技术频道小编为大家做的简单介绍,下面是详解Android 动画之TranslateAnimation应用的参数说明,希望对你学习这方面知识有帮助! android中提供了4中动画: AlphaAnimation 透明度动画效果 ScaleAnimation 缩放动画效果 TranslateAnimation 位移动画效果 RotateAnimation 旋转动画效果 本节讲解TranslateAnimati

  • Android Location服务之LocationManager案例详解

    上次介绍了位置服务中的Geocoder,这次就来介绍一下LocationManager.LocationManager系统服务是位置服务的核心组件,它提供了一系列方法来处理与位置相关的问题,包括查询上一个已知位置.注册和注销来自某个LocationProvider的周期性的位置更新.注册和注销接近某个坐标时对一个已定义的Intent的触发等.今天我们就一起探讨一下LocationManager的简单应用. 在进入正题之前,朋友们需要了解与LocationManager相关的两个知识点: prov

  • Java Spring之@Async原理案例详解

    目录 前言 一.如何使用@Async 二.源码解读 总结 前言 用过Spring的人多多少少也都用过@Async注解,至于作用嘛,看注解名,大概能猜出来,就是在方法执行的时候进行异步执行. 一.如何使用@Async 使用@Async注解主要分两步: 1.在配置类上添加@EnableAsync注解 @ComponentScan(value = "com.wang") @Configuration @EnableAsync public class AppConfig { } 2.在想要异

随机推荐