深入理解 Jetpack 之 LiveData

mj-tangonan-1540675-unsplash.jpg
mj-tangonan-1540675-unsplash.jpg

0. 前言

本文是深入理解「Android Architecture Components」系列文章第三篇

源码基于 android.arch.lifecycle:livedata-core:1.1.1

在之前我们深入研究了 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 上述特性的原理是怎么样的呢?<br />使用 LiveData 又需要注意些什么呢?

本文将围绕此展开。

<a name="d7f29183"></a>

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 = [程序亦非猿]

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

这样就算是用上 LiveData 了。

接下来,上干货!

<a name="5f1eee0e"></a>

2. LiveData 的原理分析

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

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

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

image.png
image.png

<br />(图1.LiveData 类图)

OK, here we go!

<a name="fd594c2d"></a>

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;

这里出现了几个新的类 LifecycleBoundObserverObserverWrapper 来看看。

<a name="8fee89a9"></a>

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。<br />【2.3】答:LifecycleBoundObserver 在 onStateChanged() 方法里处理了生命周期改变的事件,当接收到 DESTROYED 的事件会自动解除跟 owner 的绑定。

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

此时的流程是:

observe--><br /> onStateChanged--><br /> activeStateChanged--><br /> dispatchingValue--><br /> considerNotify--><br /> onChanged

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

<a name="73851cc0"></a>

2.3 activeStateChanged(boolean)

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

接下去探索 dispatchingValue 。<br />

<a name="bc1af81b"></a>

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

需要着重讲一下。

<a name="7e259814"></a>

2.4.1 ObserverWrapper 不为 null 的情况

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

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

<a name="7a435db2"></a>

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 对同时多次修改数据做了处理,如果同时多次修改,只会修改为最新的数据。

<a name="a43d4d52"></a>

3. 图解 LiveData

<a name="b932eca5"></a>

3.1 LiveData 类图

再看一遍类图,回顾一下:<br />
image.png
image.png

<br />(图2.LiveData 类图)
<a name="c979bac4"></a>

3.2 LiveData 流程图

Lifecycle 改变触发流程:

livedata-lifecycle-changes.png
livedata-lifecycle-changes.png

<br />(图3.Lifecycle 改变触发流程图)

Lifecycle postValue/setValue 触发流程:

livedata-postvalue.png
livedata-postvalue.png

<br />(图4.setValue 改变触发流程图)

<a name="6becaec8"></a>

4. LiveData tips and recipes

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

<a name="2c5a5752"></a>

4.1 Sticky Event

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

<a name="873f2dd4"></a>

4.2 AlwaysActiveObserver

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

<a name="4cea7239"></a>

4.3 MediatorLiveData

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

<a name="769af84f"></a>

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) {

  }
});

<a name="661cfeb8"></a>

4.4 LiveDataBus

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

<a name="719fecf9"></a>

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

<a name="aa5fbf5b"></a>

6. 总结

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

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

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

<a name="b5b4ac7f"></a>

7. 参考与推荐

  1. LiveData Overview : https://developer.android.com/topic/libraries/architecture/livedata
  2. LiveData doc : https://developer.android.com/reference/android/arch/lifecycle/LiveData
  3. https://developer.android.com/reference/android/arch/lifecycle/LiveData.html
  4. https://developer.android.com/reference/android/arch/lifecycle/Transformations.html
  5. https://github.com/googlesamples/android-architecture-components
  6. https://github.com/googlesamples/android-sunflower
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,723评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,003评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,512评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,825评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,874评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,841评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,812评论 3 416
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,582评论 0 271
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,033评论 1 308
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,309评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,450评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,158评论 5 341
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,789评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,409评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,609评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,440评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,357评论 2 352

推荐阅读更多精彩内容