【AAC 系列三】深入理解架构组件：LiveData

0. 前言

在之前我们深入研究了 Lifecycle 的实现原理，并在文末提到了LiveData 以及 ViewModel，这次我们来讲讲 LiveData。

LiveData 是 Android Architecture Components 中的一员，先看下官方是如何介绍的：

LiveData is an observable data holder class. Unlike a regular observable, LiveData is lifecycle-aware, meaning it respects the lifecycle of other app components, such as activities, fragments, or services. This awareness ensures LiveData only updates app component observers that are in an active lifecycle state. [见 9.1]

This class is designed to hold individual data fields of ViewModel, but can also be used for sharing data between different modules in your application in a decoupled fashion. [见 9.2]

简单讲 LiveData 是一个能够感知生命周期、可观察的数据持有类 ，它被设计成 ViewModel 的一个成员变量；可以以一个 更解耦 的方式来共享数据。

实际使用下来发现 LiveData 有几个特性：

1. LiveData 的实现基于观察者模式；
2. LiveData 跟 LifecycleOwner 绑定，能感知生命周期变化，并且只会在 LifecycleOwner 处于 Active 状态（STARTED/RESUMED）下通知数据改变；
3. LiveData 会自动在 DESTROYED 的状态下移除 Observer ，取消订阅，所以不用担心内存泄露；

那么 LiveData 上述特性的原理是怎么样的呢？
使用 LiveData 又需要注意些什么呢？

本文将围绕此展开。

1. LiveData 的基本使用

虽然 LiveData 通常跟 ViewModel 配合使用，不过也可以单独使用，为了简单起见，这里不配合 ViewModel。

以下是一个简单的例子：

MutableLiveData<String> liveString = new MutableLiveData<>();
liveString.observe(this, new Observer<String>() {
  @Override
  public void onChanged(@Nullable final String s) {
    Log.d(TAG, "onChanged() called with: s = [" + s + "]");
  }
});

liveString.postValue("程序亦非猿"); 

运行后可以看到日志输出：onChanged() called with: s = [程序亦非猿] 。

释义：
定义一个 MutableLiveData （LiveData 的一个常用子类），通过 observe 方法可以订阅修改数据的通知，通过 postValue() 或者 setValue() 方法可以更新数据，已经订阅的 Observer 能够得到数据更改的通知，也即回调 onChanged() 方法。

这样就算是用上 LiveData 了。

接下来，上干货！

2. LiveData 的原理分析

在分析原理前，再明确一下我们的疑问：

1. LiveData 是如何跟 LifecycleOwner 进行绑定，做到感知生命周期的？
2. LiveData 只在 LifecycleOwner active 状态发送通知，是怎么处理的？
3. LiveData 会自动在 DESTROY 的状态下取消订阅，是怎么处理的？
4. 通过 setValue()/postValue() 更新数据的处理流程是如何？
5. 生命周期变化后数据处理流程是怎么样的？

同时提前看下我整理的 LiveData UML 图，对 LiveData 有个整体的了解，后续的涉及到的类都在这里了，有助于理解。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Jb460h1o-1629894227049)(https://user-gold-cdn.xitu.io/2019/5/22/16adfb178ce25e50?imageView2/0/w/1280/h/960/ignore-error/1)]

(图1.LiveData 类图)

OK， here we go!

2.1 LiveData.observe()

LiveData 的使用流程从 observe() 开始，咱们尝试从 observe() 方法 开始分析：

 @MainThread
    public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<T> observer) {
        //如果是 DESTROYED 的状态则忽略
        if (owner.getLifecycle().getCurrentState() == DESTROYED) {
            // ignore
            return;
        }
        //把 Observer 用 LifecycleBoundObserver 包装起来
        LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);
        //缓存起来
        ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
        //如果已经 observe 过 并且两次的 owner 不同则报错
        if (existing != null && !existing.isAttachedTo(owner)) {
            throw new IllegalArgumentException("Cannot add the same observer"
                    + " with different lifecycles");
        }
        if (existing != null) {
            return;
        }
        //绑定 owner
        owner.getLifecycle().addObserver(wrapper);
    } 

可以看到 observe 方法里把我们传递的 observer 用 LifecycleBoundObserver 包装了起来，并且存入了 mObservers ，并且跟 owner 进行了关联。

并且做了两个特殊处理：

1. 忽视处于 DESTROYED 的 owner 的注册行为；
2. 将一个 Observer 同时绑定两个 owner 的行为视为非法操作，也即一个 Observer 只能绑定一个 owner，而 owner 可以有多个 Observer；

这里出现了几个新的类 LifecycleBoundObserver 、ObserverWrapper 来看看。

2.2 LifecycleBoundObserver

 class LifecycleBoundObserver extends ObserverWrapper implements GenericLifecycleObserver {
        @NonNull final LifecycleOwner mOwner;

        LifecycleBoundObserver(@NonNull LifecycleOwner owner, Observer<T> observer) {
            super(observer);
            mOwner = owner;
        }

        @Override
        boolean shouldBeActive() {
            // 判断 owner 当前的状态是否是至少 STARTED
            return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);
        }

        @Override
        public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
            //生命周期改变，如果是 DESTROYED 就自动解除
            if (mOwner.getLifecycle().getCurrentState() == DESTROYED) {
                removeObserver(mObserver);
                return;
            }
            //ObserverWrapper.activeStateChanged
            activeStateChanged(shouldBeActive());
        }

        @Override
        boolean isAttachedTo(LifecycleOwner owner) {
            return mOwner == owner;
        }

        @Override
        void detachObserver() {
            mOwner.getLifecycle().removeObserver(this);
        }
    } 

**ObserverWrapper **:

 private abstract class ObserverWrapper {
        final Observer<T> mObserver;
        boolean mActive;
        int mLastVersion = START_VERSION;

        ObserverWrapper(Observer<T> observer) {
            mObserver = observer;
        }
				//是否是 active 状态
        abstract boolean shouldBeActive();

        boolean isAttachedTo(LifecycleOwner owner) {
            return false;
        }

        void detachObserver() {
        }

        void activeStateChanged(boolean newActive) {
            if (newActive == mActive) {
                return;
            }
            // immediately set active state, so we'd never dispatch anything to inactive
            // owner
            mActive = newActive;
            boolean wasInactive = LiveData.this.mActiveCount == 0;
            LiveData.this.mActiveCount += mActive ? 1 : -1;
            if (wasInactive && mActive) {
                onActive();
            }
            if (LiveData.this.mActiveCount == 0 && !mActive) {
                onInactive();
            }
            //如果 active 状态下，则发送数据更新通知
            if (mActive) {
                dispatchingValue(this);
            }
        }
    } 

仔细看下这两个类其实就能解答疑问了。

LifecycleBoundObserver 是 抽象类 ObserverWrapper 的子类，重写了 shouldBeActive() 方法，在 owner 处于至少是 STARTED 的状态下认为是 active 状态；并且它也实现了 GenericLifecycleObserver 接口，可以监听 lifecycle 回调，并且在 onStateChanged() 方法里处理了生命周期改变的事件，当接收到 DESTROYED 的事件会自动解除跟 owner 的绑定，并且将下个流程交给了 activeStateChanged() 。

到这里 【2.1】、【2.3】的问题已经有了答案：

【2.1】答：LifeData 在 observe 方法中用 LifecycleBoundObserver 包装了 observer ，并且通过它绑定了owner。
【2.3】答：LifecycleBoundObserver 在 onStateChanged() 方法里处理了生命周期改变的事件，当接收到 DESTROYED 的事件会自动解除跟 owner 的绑定。

这里需要注意的是，当我们调用 observe() 注册后，由于绑定了 owner，所以在 active 的情况下，LiveData 如果有数据，则 Observer 会立马接受到该数据修改的通知。

此时的流程是:

observe–>
onStateChanged–>
activeStateChanged–>
dispatchingValue–>
considerNotify–>
onChanged

可以称之为生命周期改变触发的流程，另外还有一种流程是 postValue&setValue 触发的流程，共两种。

2.3 activeStateChanged(boolean)

在 activeStateChanged() 方法里，处理了 onActive() 跟 onInactive() 回调的相关逻辑处理，并且调用了dispatchingValue(this) 。（MediatorLiveData 用到了 onActive() 跟 onInactive() 有兴趣自行了解，这里不展开）

接下去探索 dispatchingValue 。

2.4 dispatchingValue(ObserverWrapper) 分析

 private void dispatchingValue(@Nullable ObserverWrapper initiator) {
        //如果正在分发则直接返回
        if (mDispatchingValue) {
            //标记分发失效
            mDispatchInvalidated = true;
            return;
        }
        //标记分发开始
        mDispatchingValue = true;
        do {
            mDispatchInvalidated = false;
            //生命周期改变调用的方法 initiator 不为 null
            if (initiator != null) {
                considerNotify(initiator);
                initiator = null;
            } else {
                //postValue/setValue 方法调用 传递的 initiator 为 null
                for (Iterator<Map.Entry<Observer<T>, ObserverWrapper>> iterator =
                        mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
                    considerNotify(iterator.next().getValue());
                    if (mDispatchInvalidated) {
                        break;
                    }
                }
            }
        } while (mDispatchInvalidated);
        //标记分发结束
        mDispatchingValue = false;
    } 

considerNotify(ObserverWrapper) 方法:

 private void considerNotify(ObserverWrapper observer) {
        //检查状态 确保不会分发给 inactive 的 observer
        if (!observer.mActive) {
            return;
        }
        // Check latest state b4 dispatch. Maybe it changed state but we didn't get the event yet.
        //
        // we still first check observer.active to keep it as the entrance for events. So even if
        // the observer moved to an active state, if we've not received that event, we better not
        // notify for a more predictable notification order.
        if (!observer.shouldBeActive()) {
            observer.activeStateChanged(false);
            return;
        }
        //setValue 会增加 version ,初始 version 为-1
        if (observer.mLastVersion >= mVersion) {
            return;
        }
        observer.mLastVersion = mVersion;
        //noinspection unchecked
        observer.mObserver.onChanged((T) mData);
    } 

可以看到 dispatchingValue 正是分发事件逻辑的处理方法，而 considerNotify 方法则确保了只将最新的数据分发给 active 状态下的 Observer 。

另外也可以看到 LiveData 引入了版本管理来管理数据 （mData）以确保发送的数据总是最新的。（具体不多讲）

dispatchingValue 这里分两种情况：

1. ObserverWrapper 不为 null
2. ObserverWrapper 为 null

需要着重讲一下。

2.4.1 ObserverWrapper 不为 null 的情况

上面提到过，LifecycleBoundObserver.onStateChanged 方法里调用了 activeStateChanged ，而该方法调用dispatchingValue(this);传入了 this ，也就是 LifecycleBoundObserver ，这时候不为 null 。

也就是说生命周期改变触发的流程就是这种情况，这种情况下，只会通知跟该 Owner 绑定的 Observer。

2.4.2 ObserverWrapper 为 null 的情况

上面我也提前说了，除了生命周期改变触发的流程外，还有 postValue&setValue 流程，来看下这俩方法。

private final Runnable mPostValueRunnable = new Runnable() {
    @Override
    public void run() {
        Object newValue;
        synchronized (mDataLock) {
            newValue = mPendingData;
            mPendingData = NOT_SET;
        }
        //noinspection unchecked
        //调用 setValue
        setValue((T) newValue);
    }
};

protected void postValue(T value) {
    boolean postTask;
    synchronized (mDataLock) {
        postTask = mPendingData == NOT_SET;
        mPendingData = value;
    }
    if (!postTask) {
        return;
    }
    ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);
}

@MainThread
protected void setValue(T value) {
    //必须在主线程调用 否则会 crash
    assertMainThread("setValue");
    mVersion++;//增加版本号
    mData = value;
    //传入了 null
    dispatchingValue(null);
} 

LiveData 的 postValue 方法其实就是把操作 post 到主线程，最后调用的还是 setValue 方法，注意 setValue 必须是在主线程调用。

并且可以看到** setValue 方法调用了 dispatchingValue 方法，并传入了 null ，这个时候的流程则会通知 active 的mObservers**。

到这里之前的剩下的所有疑问也都可以解答了。

LiveData 的两个流程都会走到 dispatchingValue 处理分发通知逻辑，并且在分发通知前会判断 owner 的状态，再加上 LiveData 本身内部的版本管理，确保了只会发送最新的数据给 active 状态下的 Observer。

**注意：**LiveData 对同时多次修改数据做了处理，如果同时多次修改，只会修改为最新的数据。

3. 图解 LiveData

3.1 LiveData 类图

再看一遍类图，回顾一下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bDXlC7ul-1629894227051)(https://user-gold-cdn.xitu.io/2019/5/22/16adfb178ce25e50?imageView2/0/w/1280/h/960/ignore-error/1)]

(图2.LiveData 类图)

3.2 LiveData 流程图

Lifecycle 改变触发流程：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PVsqdNQO-1629894227052)(https://user-gold-cdn.xitu.io/2019/5/22/16adfb178cfb5ae3?imageView2/0/w/1280/h/960/ignore-error/1)]

(图3.Lifecycle 改变触发流程图)

Lifecycle postValue/setValue 触发流程：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yihnWyE0-1629894227053)(https://user-gold-cdn.xitu.io/2019/5/22/16adfb178e1be8db?imageView2/0/w/1280/h/960/ignore-error/1)]

(图4.setValue 改变触发流程图)

4. LiveData tips and recipes

LiveData 还有很多其他相关知识，这里列举一些，更多实践可以看一下【7.6】。

4.1 Sticky Event

LiveData 被订阅时，如果之前已经更改过数据，并且当前 owner 为 active 的状态，activeStateChanged() 会被调用，也即会立马通知到 Observer ，这样其实就类似 EventBus 的 sticky event 的功能，需要注意的是，很多时候我们并不需要该功能。具体可以看一下【7.6】的处理。

4.2 AlwaysActiveObserver

默认情况下，LiveData 会跟 LicycleOwner 绑定，只在 active 状态下更新，如若想要不管在什么状态下都能接收到数据的更改通知的话，怎么办？这时候需要使用 AlwaysActiveObserver ，改调用 observe 方法为调用 LiveData.observeForever(Observer) 方法即可。

4.3 MediatorLiveData

LiveData 还有一个子类是 MediatorLiveData，它允许我们合并多个 LiveData，任何一个 LiveData 有更新就会发送通知。比如我们的数据来源有两个，一个数据库一个网络，这时候我们会有两个 DataSource，也就是两个 LiveData，这个时候我们可以使用 MediatorLiveData 来 merge 这两个 LiveData。

4.4 Transformations

Transformations 允许我们把一个 LiveData 进行处理，变化成另外一个 LiveData，目前支持 map 跟 switchMap 两个方法，跟 RxJava 的操作类似。

比如，用 map 把一个 String 类型的 LiveData 转换成 Integer 类型：

Transformations.map(liveString, new Function<String, Integer>() {
  @Override
  public Integer apply(final String input) {
    return Integer.valueOf(input);
  }
}).observe(this, new Observer<Integer>() {
  @Override
  public void onChanged(@Nullable final Integer integer) {

  }
}); 

4.4 LiveDataBus

EventBus 基于观察者模式，LiveData 也是，所以 LiveData 可以被用来做成 LiveDataBus，有兴趣可以搜索。

5. 知识点汇总

1. LiveData 的实现基于观察者模式（reactive patterns）；
2. LiveData 跟 LifecycleOwner 绑定，能感知生命周期变化，并且只会在 LifecycleOwner 处于 Active 状态（STARTED/RESUMED）下通知数据改变；如果数据改变发生在非 active 状态，数据会变化，但是不发送通知，等 owner 回到 active 的状态下，再发送通知；
3. 如果想要一直收到通知，则需要用 observeForever() 方法；
4. LiveData 会自动在 DESTROYED 的状态下移除 Observer ，取消订阅，所以不用担心内存泄露；
5. 在 LifecycleOwner 处于 DESTROYED 的状态下，不能订阅；
6. postValue 方法其实最后调用了 setValue 只不过把操作放到主线程，适合在异步线程里调用，setValue 必须在主线程里调用；
7. 如果同时多次调用 postValue 或 setValue 修改数据，只会修改成最新的那个数据，也即只会收到一次通知（set post混合调用则不一定）；
8. 如果 LiveData 有数据，并且 owner 在 active 状态下，那么在订阅的时候，会立马收到一次通知；
9. 一个 Observer 实例，只能绑定一个 LifecycleOwner，而一个 owner 可以绑定多个 Observer 实例；
10. LiveData 利用版本管理、绑定 Lifecycle 确保了只会发送最新的数据给 active 状态下的 Observer；

6. 总结

LiveData 基于观察者模式，并且可以感知生命周期，这使得我们使用 LiveData 既可以享受观察者模式带来的隔离数据与 UI 等强大的解耦能力，还可以享受感知生命周期带来的巨大便利。并且还无需担心内存泄露这个令人头疼的问题。

我们可以使用 LiveData 非常轻松地做到一些非常高效的操作，如仅在 active 的状态下刷新 UI，可以避免不必要的数据刷新。

显而易见 LiveData 本身的优秀特性有着巨大的价值，利用好绝对是架构设计中的一大利器，另外 LiveData 配合 ViewModel 可以发挥更大的价值，机智的你一定已经知道下一篇文章讲什么了。

7. 参考与推荐

1. LiveData Overview : developer.android.com/topic/libra…
2. LiveData doc : developer.android.com/reference/a…
3. developer.android.com/reference/a…
4. developer.android.com/reference/a…
5. github.com/googlesampl…
6. github.com/googlesampl…

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IhIRo9gy-1629894227054)(https://user-gold-cdn.xitu.io/2019/5/22/16adfb1bea1a0373?imageView2/0/w/1280/h/960/ignore-error/1)]

最后

有小伙伴私信问Compose的问题，好不好用啊，现在要不要学啊？

其实答案很简单，自从谷歌2019年公布了声明式UI框架Jetpack Compose后，两年多的时间，各种大力宣传，和大量资源的倾斜，API功能都趋于稳定了。

至于好不好用，各种用过的同行都是持肯定态度的。优势大概就是这四点：

强大的工具和直观的Kotlin API
简化并加速了Android上的UI开发
可以帮助开发者用更少更直观的代码创建View
有更强大的功能，以及还能提高开发速度

这么大的优势，毋庸置疑，肯定是要学的嘛，而且越快掌握越好。别等刀架到脖子上了，才去练金钟罩。

至于怎么快速上手，可以给大家免费分享一份**《Jetpack Compose 完全开发手册》**，手把手教大家从入门到精通。

第一章 初识 Jetpack Compose

• 为什么我们需要一个新的UI 工具？

• Jetpack Compose的着重点

  加速开发
  强大的UI工具
  直观的Kotlin API

• API 设计

• Compose API 的原则
  一切都是函数
  顶层函数（Top-level function）
  组合优于继承
  信任单一来源

• 深入了解Compose
  Core
  Foundation
  Material

• 插槽API

第二章 Jetpack Compose构建Android UI

• Android Jetpack Compose 最全上手指南
  Jetpack Compose 环境准备和Hello World
  布局
  使用Material design 设计
  Compose 布局实时预览
  ……

• 深入详解 Jetpack Compose | 优化 UI 构建
  Compose 所解决的问题
  Composable 函数剖析
  声明式 UI
  组合 vs 继承
  封装
  重组
  ……

• 深入详解 Jetpack Compose | 实现原理
  @Composable 注解意味着什么？
  执行模式
  Positional Memoization (位置记忆化)
  存储参数
  重组
  ……

第三章 Jetpack Compose 项目实战演练（附Demo）

• Jetpack Compose应用1
  开始前的准备
  创建DEMO
  遇到的问题

• Jetpack Compose应用2
• Jetpack Compose应用做一个倒计时器
  数据结构
  倒计时功能
  状态模式
  Compose 布局
  绘制时钟

• 用Jetpack Compose写一个玩安卓App
  准备工作
  引入依赖
  新建 Activity
  创建 Compose
  PlayTheme
  画页面
  底部导航栏
  管理状态
  添加页面

• 用Compose Android 写一个天气应用
  开篇
  画页面
  画背景
  画内容
  ……

• 用Compose快速打造一个“电影App”
  成品
  实现方案
  实战
  不足
  ……

由于篇幅限制，文档的详解资料太全面，细节内容太多，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！

有需要的小伙伴，可以微信扫下方二维码免费领取