Android~LiveData原理

介绍

LiveData是一个数据持有类，数据可以被观察者订阅，能够感知组件(Fragment Activity Service)的生命周期。只有在组件处于激活状态（started resumed）才被被通知观察者更新数据。

为什么要做用LiveData？

它能够保证数据和UI的统一，即当数据有变化时才会通知UI，从而实现组件通信。

优点：

• 资源共享；
• 减少内存泄漏；
• 当Activity停止时不会引发奔溃，不需要解决生命周期带来的问题；
• 组件和数据相关的内容能够实时更新到UI；
• 对于横竖屏切换时不需要做额外的处理来保存数据，解决了Configuration Change问题。

LiveData源码分析

在分析源码前，我们需要大概知道，LiveData内部保存了LifecycleOwner和Observer，利用LifecycleOwner感知并处理声明中期的变化，Observer在数据改变时遍历所有观察者并回调方法。因为LiveData并不复杂离开了LifecycleOwner、Observer，LiveData可能啥都不是。接下来我按照正常的调用顺序来分析源码。

new MutableLiveData<>()

首先LiveData是抽象类不能直接初始化，我们需要使用MutableLiveData创建。我们直接去看它的父类的构造函数，两种实现，带参数的是用外部传进来的引用并且mVersion+1；不带参的，NOT_SET由LiveData自己内部创建，mVersion为-1。

static final Object NOT_SET = new Object();

public LiveData(T value) {
    mData = value;
    mVersion = START_VERSION + 1;
}

public LiveData() {
    mData = NOT_SET;
    mVersion = START_VERSION;
}

setValue & postValue

通过断言，setValue只能在主线程中调用，更新mVersion复制操作，然后dispatchingValue分发Value。dispatchingValue中则是通过mDispatchingValue、mDispatchInvalidated标记判断是否进行分发，最后遍历mObservers并调用considerNotify，在considerNotify中做真正的分发逻辑。

 @MainThread
 protected void setValue(T value) {
     assertMainThread("setValue");
     mVersion++;
     mData = value;
     dispatchingValue(null);
 }
 
 private SafeIterableMap<Observer<? super T>, ObserverWrapper> mObservers =
            new SafeIterableMap<>();
 void dispatchingValue(@Nullable ObserverWrapper initiator) {
     if (mDispatchingValue) {
         mDispatchInvalidated = true;
         return;
     }
     mDispatchingValue = true;
     do {
         mDispatchInvalidated = false;
         if (initiator != null) {
             considerNotify(initiator);
             initiator = null;
         } else {
             for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator =
                     mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
                 considerNotify(iterator.next().getValue());
                 if (mDispatchInvalidated) {
                     break;
                 }
             }
         }
     } while (mDispatchInvalidated);
     mDispatchingValue = false;
 }
 private void considerNotify(ObserverWrapper 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;
    }
    if (observer.mLastVersion >= mVersion) {
        return;
    }
    observer.mLastVersion = mVersion;
    observer.mObserver.onChanged((T) mData);
}

considerNotify

这里的mObservers是一个SafeIterableMap迭代器实现的HashMap容器，它是由ObserverWrapper构成，ObserverWrapper又包含了Observer接口实现。它内部调用ObserverWrapper对象判断，自带的属性mActive和mLastVersion，最终调用mObserver的onChanged，下发到具体的观察者。
postValue用于在异步线程中调用，内部则使用了对象锁，更新mPendingData取出数据最终setValue。

private final Runnable mPostValueRunnable = new Runnable() {
    @SuppressWarnings("unchecked")
    @Override
    public void run() {
        Object newValue;
        synchronized (mDataLock) {
            newValue = mPendingData;
            mPendingData = NOT_SET;
        }
        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);
}

observe

同样也是通过断言控制在主线程中执行，然后判断LifecycleOwner持有者的状态，假如不等于DESTROYED，创建LifecycleBoundObserver生命期范围的观察者，将它放到mObservers容器中，根据存放情况决定owner是否需要wrapper对象。observeForever则是用于观察不需要关联生命期类型的数据，逻辑和obseve类似只是AlwaysActiveObserver不同。

@MainThread
public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {
    assertMainThread("observe");
    if (owner.getLifecycle().getCurrentState() == DESTROYED) {
        // ignore
        return;
    }
    LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);
    ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
    if (existing != null && !existing.isAttachedTo(owner)) {
        throw new IllegalArgumentException("Cannot add the same observer"
                + " with different lifecycles");
    }
    if (existing != null) {
        return;
    }
    owner.getLifecycle().addObserver(wrapper);
}

@MainThread
public void observeForever(@NonNull Observer<? super T> observer) {
    assertMainThread("observeForever");
    AlwaysActiveObserver wrapper = new AlwaysActiveObserver(observer);
    ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
    if (existing instanceof LiveData.LifecycleBoundObserver) {
        throw new IllegalArgumentException("Cannot add the same observer"
                + " with different lifecycles");
    }
    if (existing != null) {
        return;
    }
    wrapper.activeStateChanged(true);
}

LiveData的粘性事件

粘性事件产生的原因：LiveData天生支持粘性事件，因为它的实现就是这样的。大多数场合我们还是需要用到粘性事件的。如果是多个界面公用同一个ViewModel时，会出现该情况，又比如obser里面还做了一些计算或复杂的业务操作，就会有影响。
正常流程，在注册时没有收到消息。非正常的流程则是，注册之前就有消息被收到，就导致mLastVersion<mVersion，从而触发onChange最终导致了粘性事件。

mLastVersion：观察者持有，
mVersion：被观察者持有。

通信方案对比总结

通信方案	优点	缺点
Handler	系统原生，能实现线程间通信	高耦合 不利于维护 容易导致内存泄漏和NullPointer
Broadercast	简单	性能差 传播数据有限 打乱代码的执行逻辑
interface	接口速度快，容易理解	实现起来复杂，不好维护
rxBus	效率高，无内存泄漏	基于RxJava，学习成本高且依赖包太大，rxJava2.2M
EventBus	使用简单	混淆问题 无法感知组件生命周期 实现复杂。

组件间通信可以如何做？
static最好不要随便用，容易内存泄漏，jvm中会管理它。如果用单例不合适，单例也会导致内存常驻。广播是用来监听系统的一系列变化，LiveData不能替代广播。观察者模式可以一对多，接口回调只能一对一。关于LiveData的粘性事件，解决方法有多种，可用用反射，也可以自己实现非粘性的LiveData，本文不做详细讨论，个人觉得与其想办法处理问题，不如设计时如何规避问题更来的有效，实在应用场景确实需要再用。

参考

1. Android消息总线的演进之路：用LiveDataBus替代RxBus、EventBus
2. 关于 LiveData 粘性事件 的个人思考
3. 踩坑之路：LiveData之粘性事件
4. 关于LiveData粘性事件所带来问题的解决方案