关于LiveData全面详解（附事件总线）-六虎

前语：缤纷颜色闪出的美丽是因它没有分隔每种颜色

前语

MVVM 架构形式中，ViewModel 是不会持有宿主的信息，事务逻辑在 ViewModels 层中完结，而不是在 Activities 或 Fragments 中。LiveData 在里边担任数据驱动的效果：

以往咱们运用 Handler，EventBus，RxjavaBus 进行音讯通信，LiveData 也是一个种调查者形式，效果跟 RxJava 类似，是调查数据的类，相比 RxJava，一般配合 Jetpack 组件配合运用。它能够在 Activity、Fragment 和 Service 之中正确的处理生命周期。

一、什么是LiveData

1.介绍

LiveData 组件是 Jetpack 新推出的根据调查者的音讯订阅/分发组件，具有宿主（Activity/Fragment）生命周期感知才干。这种感知才干可保证 LiveData 仅分发音讯给与活泼状况的调查者，即只要处于活泼状况的调查者才干收到音讯。

LiveData 的音讯分发机制，是以往 Handler，EventBus，RxjavaBus 无法比拟的，它们不会顾及当时页面是否可见，一股脑的有音讯就转发。导致即便运用在后台，页面不可见，还在做一些无用的绘制，计算（微信的音讯列表是在可见状况下才会更新列表最新信息的）将有限的资源让给可见的页面运用。

活泼状况：Observer地点宿主处于STARTED，RESUMED状况。

本文需求 Lifecycle 的相关常识作为基础，假如有不了解的能够先看看《Android架构魂灵组件Lifecycle的生命周期机制详解》

根据生命周期，其实便是在当时宿主 LifecycleOnwer 注册一个 Observer，那么宿主每次生命周期的改变，都会回调给调查者的 onStateChange() 办法，即便是刚刚注册的调查者宿主也会回调 onStateChange() 办法，会有一个状况同步的进程，LiveData 也是利用这个才干，奇妙完结了当宿主毁掉的时分，自动移除注册进来的 Observer，从而避免了手动移除的费事。更不会造成内存走漏，这个也是它的中心思维。

2.LiveData的特点

运用 LiveData 具有以下几点优势：

保证界面契合数据状况：LiveData 遵循调查者形式。当底层数据产生改变时，LiveData 会告诉Observer 目标。
不会产生内存走漏：调查者会绑定到Lifecycle 目标，并在其相关的生命周期遭到毁掉后进行自我清理。
不会因 Activity 停止而导致溃散：假如调查者的生命周期处于非活泼状况（如回来堆栈中的 Activity），它便不会接纳任何 LiveData 事情。
不再需求手动处理生命周期：界面组件仅仅调查相关数据，不会停止或康复调查。LiveData 将自动办理一切这些操作，由于它在调查时能够感知相关的生命周期状况改变。
数据一直保持最新状况：假如生命周期变为非活泼状况，它会在再次变为活泼状况时接纳最新的数据。
恰当的装备更改：假如由于装备更改（如设备旋转）而从头创立了 Activity 或 Fragment，它会当即接纳最新的可用数据。
共享资源：您能够运用单例形式扩展LiveData 目标以封装体系服务，以便在运用中共享它们。LiveData目标连接到体系服务一次，然后需求相应资源的任何调查者只需调查LiveData目标。

LiveData不足之处：

粘性事情不支撑撤销（后边注册的调查者也能接纳数据，无法反注册，但有办法解决）。

3.LiveData中心办法

办法名	效果
observe(LifecycleOwner owner, Observer observer)	注册和宿主生命周期相关的调查者， owner当时生命周期的宿主，当宿主毁掉了observer能自动解除注册
observeForever(Observer observer)	注册调查者，不会反注册，需自行保护，没有owner无法办理宿主生命周期
setValue(T value)	发送数据，没有活泼的调查者时不分发，只能在主线程
postValue(T value)	setValue一样，可是不受线程约束，内部也是经过handelr.post到主线程，最终仍是经过setValue来分发的
onActive()	当且仅当有一个活泼的调查者时会触发
onInactive()	不存在活泼的调查者时会触发

二、LiveData的几种用法

1.MutableLiveData

在运用 LiveData 做音讯分发的时分，需求运用这个子类，设计的原因是考虑到单一开闭原则，只要拿到 MutableLiveData 才能够发送音讯，LiveData 只能接纳音讯，避免拿到 LiveData 既能发送音讯又能接纳音讯的紊乱运用。

public class MutableLiveData<T> extends LiveData<T> {
    @Override
    public void postValue(T value) {
        super.postValue(value);
    }
    @Override
    public void setValue(T value) {
        super.setValue(value);
    }
}

MutableLiveData 仅仅是把上面两个办法从父类的 protect 改为 public 罢了，由于在 LiveData 中无法调用 postValue() 和 setValue()。所以咱们在运用 LiveData 做音讯分发的时分，咱们需求运用它的子类 MutableLiveData。

fun mediatorLiveData() {
    val liveData1 = MutableLiveData<String>()
    val liveData2 = MutableLiveData<String>()
    //在创立一个聚合类MediatorLiveData
    val mediatorLiveData = MediatorLiveData<String>()
    //分别把LiveData合并到mediatorLiveData中
    mediatorLiveData.addSource(liveData1, Observer { data ->
        mediatorLiveData.value = data
    })
    mediatorLiveData.addSource(liveData2, Observer { data ->
        mediatorLiveData.value = data
    })
    //数据监听，一旦liveData1或许LiveData2发送了数据，observer便能调查到，以便一致处理更新
    mediatorLiveData.observe(this, Observer { data ->
        LogUtil.e("mediatorLiveData:$data")
    })
    // 模仿发送数据
    liveData1.postValue("liveData1 苏火火苏火火")
    liveData2.postValue("liveData2 苏火火苏火火")
}

打印数据如下：

/com.sum.tea E/LogUtil: mediatorLiveData: liveData1 苏火火苏火火
/com.sum.tea E/LogUtil: mediatorLiveData: liveData2 苏火火苏火火

3.Transformations.map操作符

Transformations.map 能够对 LiveData 的数据在分发给调查者之前进行转化，而且回来一个新的 LiveData 目标。

fun transformationsMap() {
    val mapLiveData = MutableLiveData<Int>()
    //数据转化
    val transformLiveData: LiveData<Int> = Transformations.map(mapLiveData) { input ->
        input * 2
    }
    //运用转化后生成的transformLiveData去调查数据
    transformLiveData.observe(this) { output ->
        LogUtil.e("transformationsMap 数据转化改变:$output")
    }
    //运用原始的LiveData发送数据
    mapLiveData.value = 10
}

打印数据如下：

/com.sum.tea E/LogUtil: transformationsMap 数据转化改变:20

三、LiveData完结原理

1.粘性事情分发流程

先从 LiveData 注册调查者看起:

#LiveData.java
@MainThread
public void observe(LifecycleOwner owner, Observer<? super T> observer) {
    // 假如宿主是DESTROYED状况则直接退出
    if (owner.getLifecycle().getCurrentState() == DESTROYED) {
        return;
    }
    // 把observer包装一个具有生命周期边界的调查者
    LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);
    // 存储到mObservers调集
    ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
    if (existing != null) {
        return;
    }
    // 注册到宿主的生命周期里边
    owner.getLifecycle().addObserver(wrapper);
}

把 observer 包装成了 LifecycleBoundObserver，它是一个具有生命周期边界的调查者，它是 LifecycleEventObserver 的子类，
接着把 LifecycleBoundObserver 存储到 mObservers 调集傍边。
最终把 LifecycleBoundObserver 注册到宿主的生命周期里边。

所以 wrapper 就能接纳到宿主生命周期改变的事情，当第一次注册进去的时分也会触发状况的同步，也能接纳到完整的生命周期事情。

由于后边还要做数据的分发，订阅音讯便是把这个 Observer 包装成 LifecycleBoundObserver，然后存储到 mObservers 调集傍边，有音讯的时分就遍历这个调集去分发。

// 具有生命周期边界才干的Observer
class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {
    @Override
    boolean shouldBeActive() {
        // 判别调查者是否处于活泼的状况
        return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);
    }
    @Override
    public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
        // 判别当时宿主的状况是否为destory
        if (mOwner.getLifecycle().getCurrentState() == DESTROYED) {
            // 自动进行反注册，把Observer移除去
            removeObserver(mObserver);
            return;
        }
        // 状况改变
        activeStateChanged(shouldBeActive());
    }
}

宿主生命周期每一次事情的告诉都会回调到 LifecycleEventObserver 的 onStateChanged()，先判别当时宿主的状况是否为 DESTORYED，假如是则自动进行反注册，把 Observer 移除去。从而自动避免内存走漏的问题。

假如不是 DESTORYED，那就阐明宿主的状况产生了别的改变，触发 activeStateChanged(shouldBeActive()) 这个办法，会先判别调查者是否处于活泼的状况，只要处于活泼状况的调查者才干接纳到数据:

// 注册调查者，不会反注册，需自行保护，没有owner无法办理宿主生命周期
public void observeForever(Observer<? super T> observer) {
    //把`observer`包装成一个`AlwaysActiveObserver`目标
    AlwaysActiveObserver wrapper = new AlwaysActiveObserver(observer);
    // 将Observer存储到mObservers调集中
    ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
    // 设置为tru则不管宿主是否处于可见状况，一向接纳数据
    wrapper.activeStateChanged(true);
}

observeForever()：它会把 observer 包装成一个 AlwaysActiveObserver 目标， shouldBeActive() 永远为 true，不管你的宿主是否处于可见状况，这就意味着它能够一向接纳数据。

除了 observeForever() 这种状况外，调查者是否处于活泼状况其实就等于宿主是否处于活泼的状况。

假如场景是在后台要处理一些事情，能够运用 observeForever() 注册调查者，可是需求在宿主被毁掉的时分撤销注册，或许运用传统的 callback 形式。

void activeStateChanged(boolean newActive) {
    // 假如状况一致，则退出
    if (newActive == mActive) {
        return;
    }
    // 当即设置状况，就不会分发给非活泼状况
    mActive = newActive;
    // 非活泼状况，mActiveCount表明活泼状况数量
    boolean wasInactive = LiveData.this.mActiveCount == 0;
    LiveData.this.mActiveCount += mActive ? 1 : -1;
    // 注册第一个调查者而且是活泼状况
    if (wasInactive && mActive) {
        // 只要一个调查者时才会触发
        onActive();
    }
    if (LiveData.this.mActiveCount == 0 && !mActive) {
        // 没有调查者时触发
        onInactive();
    }
    if (mActive) {
        // 活泼状况，开端分发数据
        dispatchingValue(this);
    }
}

首要判别 mActiveCount == 0，假如等于0阐明里边的调查者没有一个处于活泼的状况。在注册第一个调查者的时分，活泼调查者的数量肯定是等于0的，当注册了第一个调查者之后，它的状况就会产生改变，变成 mActive，此时就会触发 onActive() 办法，假如没有任何一个调查者就会触发 onInactive() 办法，假如 mActive == true，则阐明当时调查者处于活泼状况，它是能够接纳数据的。

// 分发数据
void dispatchingValue(ObserverWrapper initiator) {
    // 
    do {
        mDispatchInvalidated = false;
        if (initiator != null) {
            // 1.把数据分发给自己
            considerNotify(initiator);
            initiator = null;
        } else {
            // 2.有新的数据，把mObservers调集傍边一切的调查者遍历分发数据
            for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator =
                    mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
                considerNotify(iterator.next().getValue());
                if (mDispatchInvalidated) {
                    break;
                }
            }
        }
    } while (mDispatchInvalidated);
    mDispatchingValue = false;
}
// 设置数据
protected void setValue(T value) {
    mVersion++;
    mData = value;
    dispatchingValue(null);
}

假如 initiator 为空，本次分发数据就把数据分发给自己 considerNotify(initiator)；
假如 initiator 不为空，一般是从 setVlue() 过来的，这时分就阐明有了新的数据，就会把 mObservers 调集傍边一切的调查者遍历分发数据。

无论是新注册的调查者仍是 setVlue() 触发的音讯分发，都会调用 considerNotify() 办法

// 预备告诉更新，宿主在康复活泼状况时也会履行到这儿
private void considerNotify(ObserverWrapper observer) {
    // observer非活泼状况直接退出
    if (!observer.mActive) {
        return;
    }
    // 也许它改变了状况，但咱们还没有得到事情
    if (!observer.shouldBeActive()) {
        observer.activeStateChanged(false);
        return;
    }
    // observer的版别大于LiveData版别不会发送数据，避免多次重复发送 
    if (observer.mLastVersion >= mVersion) {
        return;
    }
    // 同步调查者的Version数据
    observer.mLastVersion = mVersion;
    observer.mObserver.onChanged((T) mData);
}

这儿是数据最终发送的当地，先判别调查者是否处于活泼状况，假如说调查者不活泼，就会 return，当宿主康复活泼状况的时分就会触发 onStateChanged()，最终也会到这儿。

重点来了，LiveData 的 Version 字段和 Observer 的 Vierson 在刚开端创立的时分都是-1，假如 LiveData 现已发送数据了，它的 Version 字段就会加1，假如这个时分新注册了一个 Observer，那么在触发音讯分发的时分，这两个字段就不持平，所以 Observer 就能接纳到之前发送的音讯，在第一次注册的数据的时分（先发数据，后注册的 Observer 也会收到数据）。

这便是粘性事情，意图是为了避免数据多次重复发送，由于每次生命周期的改变都会走到这儿。最终调用 observer.mObserver.onChanged() 回调数据。

这便是一个新的注册的 Observer 是如何接纳到之前发送的数据的流程。

2.一般音讯分发流程

一般音讯分发流程即调用 postValue()，setValue() 才会触发音讯的分发。

postValue() 发送数据的流程:

#LiveData.java
// 不约束线程，主线程，子线程都能够调用
protected void postValue(T value) {
    boolean postTask;
    // 加锁
    synchronized (mDataLock) {
        postTask = mPendingData == NOT_SET;
        mPendingData = value;
    }
    if (!postTask) {
        return;
    }
    // 发送到主线程履行
    ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);
}

由于需求 Handler 把这个音讯 post 到主线程里边，所以需求把传递进来的 value 保存 mPendingData，当这条音讯被履行的时分，就会触发 mPostValueRunnable，里边实际也是调用 setValue()，把上面存储的 mPendingData 传递进去。

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

无论是从哪里发送的数据，接纳的当地一直都会发送在主线程，每发送一条音讯 mVersion 增加了1，在音讯派发的时分就会和 Observer 的 version 进行对比，避免音讯重复发送的问题。

就会调用 dispatchingValue(null) 传递了 null，根据上面的剖析，假如参数为 null，就会遍历 mObserver 调集中的调查者去逐个判别是否能把数据分发给他们。

@MainThread
protected void setValue(T value) {
    assertMainThread("setValue");
    mVersion++;
    mData = value;
    // 分发数据
    dispatchingValue(null);
}

setValue() 里边调用 dispatchingValue(null) 进行分发数据，就又回到了上面的流程。

四、总结

1.粘性事情分发流程

经过 observe(owner,observer) 向 LiveData 注册调查者，而且把 observer 包装成一个 LifecycleBoundObserver，它是一个具有生命周期边界的调查者，由于这个调查者只要当宿主处于 STARTED 或许 RESUMED 状况的它才会接纳数据，其他时分它是不会接纳数据的。
把包装好的 Observer 注册到 Lifecycle 傍边，handlerLifecycleEvent(event) 利用 Lifecycle 才干，它能感知宿主生命周期才干的要害当地。注册时和宿主每次生命周期改变都会回调 onStateChanged() 办法，刚进去的时分会触发办法的同步。
会判别这个事情宿主是否被毁掉了，从而自动地把 Observer 从 LiveData 中移除去，流程结束。假如不是 DESTORY，阐明宿主当时的状况产生了改变，它会触发 activeStateChanged(boolean newActive) 办法，它会判别当时 Observer 是否处于活泼的状况，假如宿主的状况为 STARTED，RESUMED 则会分发最新数据到每个调查者。
从而调用 dispatchingValue(ObserverWrapper) 分发数据，假如 ObserverWrapper 为空则分发数据给 liveData 中存储的一切调查者，假如不为空，则分发数据给该 Observer。
considerNotify(ObserverWrapper) 中先判别调查者地点的宿主不活泼，则不分发；接着假如 observer 的 mLastVersion 大于或等于 LiveData 的 mVersion 则不分发，避免重复发送数据；最终经过 observer.mObserver.onChanged((T) mData) 分发数据，同步 mVersion 数据。

那么 LiveData 先发送数据，后注册的 Observer 能接纳到数据吗？答案是能够的。

2.一般音讯发送流程

postValue() 发送一条数据，它能够在任意线程运用的，里边实际运用了 Handler.post 先把这个事情发送到主线程，然后在调用 setValue() 发送数据；
setValue() 代表着 LiveData 发送数据，每发送一次 mVersion++，别的 LifecycleBoundObserver 中也有一个，它代表这个 Observer 接纳了几次数据，在分发数据的时分，这两个 version 会进行比对，避免数据重复发送；
setValue() 里边也会触发 dispatchingValue(ObserverWrapper)，ObserverWrapper 为 null，dispatchingValue() 它会遍历 Observer 调集里边一切调查者，然后逐个调用 considerNotify(ObserverWrapper) 去做音讯的分发。

五、运用LiveData打造音讯总线

根据 LiveData 打造一款不会内存走漏不用反注册的音讯总线，且支撑粘性事情。

// 事情总线
private fun liveDataBus() {
    LiveDataBus.with<String?>("eventName").observeSticky(this, { data ->
        mBinding.tvUserInfo.text = data
        LogUtil.e("事情总线 数据改变:$data")
    }, true)
}

问题：LiveData 默认是支撑粘性事情的，而且无法撤销。

private void considerNotify(ObserverWrapper observer) {
    //调查者没有处于活泼状况，则不分发
    if (!observer.shouldBeActive()) {
        observer.activeStateChanged(false);
        return;
    }
    //调查者接受的音讯的次数>=liveData发送音讯的次数，不分发
    //假如之前现已发送过数据，新注册的Observer也能接受到最终一条数据
    if (observer.mLastVersion >= mVersion) {
        return;
    }
    //根本原因在于ObserverWrapper的version字段在创立时=-1，没有自动和LiveData字段的mVersion字段对齐
    observer.mLastVersion = mVersion;
    observer.mObserver.onChanged((T) mData);
}

满意上面两个条件才会触发 observer.mObserver.onChanged() 事情的分发：

首要判别 observer.shouldBeActive() 是否处于活泼状况，假如 observer 是根据 observer() 注册的，这个调查者是否处于活泼就等于它的宿主是否处于活泼状况，假如是用 observerForever() 注册的，它就一向处于活泼状况。这儿不需求操控它，能很好完结与宿主生命周期相相关。
要害在于 observer.mLastVersion >= mVersion，mLastVersion 和 mVersion 默认值都是为-1，在首次注册流程分发的时分，假如 LiveData 之前发送过数据，mVersion 就会为1，而新注册进来的 Observer 的 mLastVersion 仍是-1，上就会往下履行音讯分发。这样就导致了新注册的 Observer 也能够接纳到之前发送音讯的最终一条数据。
可是假如咱们在新注册 Observer 的时分自动和 LiveData 的 mVersion 对齐，保持一致，那么就不会持续分发音讯，这是根本原因。在于 Observer 的 mLastVersion 的值，可是 LifecycleBoundObserver 这个类咱们是拜访不到的，咱们也不能直接操控 mLastVersion 的值，可是咱们能够从头包装 Observer。

//包装StickyObserver，有新的音讯会回调onChanged办法，从这儿判别是否要分发这条音讯
//这仅仅完结StickyObserver的包装，用于操控事情的分发，可是事情的发送仍是依托LiveData来完结的
internal class StickyObserver<T>(
    liveData: StickyLiveData<T>,
    observer: Observer<T>,
    sticky: Boolean
) : Observer<T> {
    private val mLiveData: StickyLiveData<T>
    private val mObserver: Observer<T>
    //是否敞开粘性事情,为false则只能接受到注册之后发送的音讯，假如需求接受粘性事情则传true
    private val mSticky: Boolean
    //符号该Observer现已接纳几次数据了，过滤老数据避免重复接纳
    private var mLastVersion = 0
    init {
        //比如先运用StickLiveData发送了一条数据，StickLiveData#version=1
        //那么当创立WrapperObserver注册进去的时分，需求把它的version和StickLiveData的version保持一致
        mLastVersion = liveData.mVersion
        mLiveData = liveData
        mSticky = sticky
        mObserver = observer
    }
    override fun onChanged(t: T) {
        if (mLastVersion >= mLiveData.mVersion) { //假如持平则阐明没有更新的数据要发送
            //可是假如当时Observer是联系粘性事情的，则分发给他
            if (mSticky && mLiveData.mStickyData != null) {
                mObserver.onChanged(mLiveData.mStickyData)
            }
            return
        }
        mLastVersion = mLiveData.mVersion
        mObserver.onChanged(t)
    }
}

扩展 LiveData，支撑粘性事情的订阅，分发的 StickyLiveData：

//扩展LiveData，支撑粘性事情的订阅，分发的StickyLiveData
class StickyLiveData<T>(private val mEventName: String) : LiveData<T>() {
    var mStickyData: T? = null
    // 版别符号
    var mVersion = 0
    // 事情存储调集
    var mHashMap: ConcurrentHashMap<String, StickyLiveData<T>>? = null
     //调用mVersion++
     //注册一个Observer的时分，把它包装一下，意图是为了让Observer的version和LiveData的version对齐
     //可是LiveData的version字段拿不到，所以需求办理version，在对齐的时分
    override fun setValue(value: T?) {
        mVersion++
        super.setValue(value)
    }
    override fun postValue(value: T?) {
        mVersion++
        super.postValue(value)
    }
    //发送粘性事情,只能在主线程发送数据
    fun setStickData(stickyData: T) {
        mStickyData = stickyData
        value = stickyData
    }
    //发送粘性事情，不受线程约束
    fun postStickData(stickyData: T) {
        mStickyData = stickyData
        postValue(stickyData)
    }
    override fun observe(owner: LifecycleOwner, observer: Observer<in T?>) {
        observeSticky(owner, observer, false)
    }
     //暴露办法，是否关心之前发送的数据,再往宿主上面添加一个addObserver监听生命周期事情，假如是DESTORYED则自动移除LiveData
     //sticky  是否为粘性事情，sticky=true,假如之前存在现已发送数据，那么Observer就会收到之前的粘性事情音讯
    fun observeSticky(owner: LifecycleOwner, observer: Observer<in T>, sticky: Boolean) {
        owner.lifecycle.addObserver(LifecycleEventObserver { source, event ->
            if (event == Lifecycle.Event.ON_DESTROY) {
                mHashMap?.remove(mEventName)
            }
        })
        super.observe(owner, StickyObserver(this, observer as Observer<T>, sticky))
    }
}

这个还有别的一种处理方式便是经过反射，获取 LiveData 中的 mVersion 字段，来操控粘性事情的分发。

一个大型的 Android 项目架构最佳实践，根据Jetpack组件 + MVVM架构形式，加入 组件化、模块化、协程、Flow、短视频。项目地址：github.com/suming77/Su…

点关注，不迷路

好了各位，以上便是这篇文章的全部内容了，很感谢您阅读这篇文章。我是suming，感谢各位的支撑和认可，您的点赞便是我创造的最大动力。山水有相逢，咱们下篇文章见！

本人水平有限，文章难免会有错误，请批评指正，不胜感激！

参阅链接：

LiveData官网

关于LiveData全面详解（附事件总线）

前语

一、什么是LiveData

1.介绍

2.LiveData的特点

3.LiveData中心办法

二、LiveData的几种用法

1.MutableLiveData

3.Transformations.map操作符

三、LiveData完结原理

1.粘性事情分发流程

2.一般音讯分发流程

四、总结

1.粘性事情分发流程

2.一般音讯发送流程

五、运用LiveData打造音讯总线

点关注，不迷路

参阅链接：

希望咱们能成为朋友，在 Github、上一同分享常识，一同共勉！Keep Moving!

作者信息

关于LiveData全面详解（附事件总线）

前语

一、什么是LiveData

1.介绍

2.LiveData的特点

3.LiveData中心办法

二、LiveData的几种用法

1.MutableLiveData

3.Transformations.map操作符

三、LiveData完结原理

1.粘性事情分发流程

2.一般音讯分发流程

四、总结

1.粘性事情分发流程

2.一般音讯发送流程

五、运用LiveData打造音讯总线

点关注，不迷路

参阅链接：

希望咱们能成为朋友，在 Github、 上一同分享常识，一同共勉！Keep Moving!

相关文章

iOS 15.4 12小时制 时间格式转换崩溃

30 岁了！通过 AI 问答完成了这篇思考文章

自己写 YOLOv4 模型实现(Pytorch 版本)(1)

我在字节的这两年

作者信息

希望咱们能成为朋友，在 Github、上一同分享常识，一同共勉！Keep Moving!

iOS 15.4 12小时制时间格式转换崩溃