重新学习Android——（五）LiveData概念、用法以及源码分析

可观察的LiveData#

在上一篇笔记中，我们在Fragment中编写了这样的代码：

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)

    // ...

    val viewModel = ViewModelProvider(requireActivity()).get(UserViewModel::class.java)

    viewModel.addOnUserSelectedListener {
        username.text = it.name
        ageAndSex.text = "${it.age}岁 ${it.sex}"
        desc.text = it.description
    }

}

它观察ViewModel中用户选中状态的改变，一旦发生改变，就调整UI。

同时，我们必须在ViewModel中添加相应的代码来暴露让外部组件监听变化的API：

class UserViewModel : ViewModel() {

    // ... 

    private val onUserSelectedListeners: MutableSet<(User) -> Unit> = mutableSetOf()

    fun addOnUserSelectedListener(listener: (User) -> Unit) {
        onUserSelectedListeners.add(listener)
        // 当该listener添加之前已经有用户被选中了，先回调一下
        selectedUser?.let {
            listener(it)
        }
    }

    fun removeOnUserSelectedListener(listener: (User) -> Unit) {

      onUserSelectedListeners.remove(listener)
    }
}

上面的代码在Fragment的onCreate中向ViewModel添加了监听器，用观察者模式的话来说就是订阅了一个观察者。这个操作很危险，它把原来在Fragment中的观察者回调函数的引用交给了ViewModel，而ViewModel的生命周期如果长于这个Fragment（一般情况下都是的），这时就会发生内存泄漏。因为Fragment已经销毁，但这个回调还被ViewModel所引用，无法销毁，并且这时当用户再次发生改变时，ViewModel还会通知这个监听器，这样可能发生程序崩溃。

所以我们最后还添加了一个生命周期感知型组件，让它来观察Fragment的生命周期，在适当的时候移除用户选择的监听。

class UserSelectedListener(
    private val viewModel: UserViewModel,
    private val userSeletedListener: (User) -> Unit
) : DefaultLifecycleObserver{
    override fun onCreate(owner: LifecycleOwner) {
        super.onCreate(owner)
        viewModel.addOnUserSelectedListeners(userSeletedListener)
    }

    override fun onDestroy(owner: LifecycleOwner) {
        super.onDestroy(owner)
        viewModel.removeOnUserSelectedListeners(userSeletedListener)
    }

}

But！需要这么麻烦？？我们才写了一个小小的功能啊，就要写这么多代码？？ViewModel维护了所有用户改变监听器的列表，ViewModel提供添加和移除监听器的API，ViewModel负责在选中用户时通知所有监听器。。。同时我们还得为了安全来维护和组件生命周期相关的代码。。。

这时LiveData就出现了，它是一个可观察对象，Fragment等组件可以向其添加观察者，添加观察者时，LiveData会感知组件的生命周期，当组件销毁（DESTROYED）时，LiveData便会自动退订这个观察者，当组件处于非活跃状态时（非STARTED和RESUMED），LiveData也不会向其发送通知。

所以，我们只需要在ViewModel中暴露一个LiveData对象，然后再让Fragment去观察它，即可完成我们上篇笔记中写了很久的逻辑，来修改一下。

class UserViewModel : ViewModel() {
    val users = arrayListOf(/*...userlist...*/)

    val userSelected: MutableLiveData<User> = MutableLiveData()

    fun select(user: User) {
        userSelected.value = user
    }
}

然后修改Fragment中的代码

class UserDetailsFragment : Fragment() {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        // ...bind view...

        val viewModel = ViewModelProvider(requireActivity()).get(UserViewModel::class.java)

        viewModel.userSelected.observe(viewLifecycleOwner) {
            username.text = it.name
            ageAndSex.text = "${it.age}岁 ${it.sex}"
            desc.text = it.description
        }

    }
}

上面的所有功能就完成了，我们来解释一下这些代码。

首先ViewModel中通过MutableLiveData<User>创建了一个可变的LiveData对象，并且泛型指定了这个LiveData对象用于存储User。

然后在Fragment中，通过观察viewModel中的这个LiveData对象来进行选中用户更改时UI更新

viewModel.userSelected.observe(viewLifecycleOwner) {
  // update ui...
}

observe方法接收两个参数，第一个参数是LifecycleOwner对象，第二个参数是LiveData中数据更新时的回调。LiveData会观察这个LifecycleOwner的生命周期，在它活跃时才回调它，并且在他销毁时丢弃它的回调，不再向它发送更新。

还有一个问题，viewLifecycleOwner是啥？Fragment也是一个LifecycleOwner，为什么这里不使用this。

因为在Fragment中，this绑定到Fragment总体生命周期上，也就是它本身的onCreate和onDestroy这些方法，而viewLifecycleOwner绑定到UI相关的生命周期上，也就是onCreateView和onDestroyView上。

如果使用this，而非viewLifecycleOwner的话，视图销毁了但Fragment本身还没有销毁时，LiveData会继续向观察者发送改变事件，这可能会引起程序崩溃。

Google也推荐我们使用viewLifecycleOwner。

查看LiveData源码#

我们可以通过查看LiveData的源码，看看它是如何实现这些的。

@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);
  }

我们只看observe方法，首先它判断了observe必须是在主线程被调用的，然后检测了一下当前LifecycleOwner是否已经销毁，已经销毁就直接退出方法了。

然后使用传入的LifecycleOwner和LiveData数据更改回调创建了一个LifecycleBoundObserver，后面所有的数据更新时回调，对LifecycleOwner生命周期的监听都托管给这个对象处理。

然后就是判断了以下是否以不同的生命周期添加了相同的观察者，如果是就抛出异常。然后如果传入的生命周期是第一次观察该LiveData，那么向那个生命周期中添加观察者，添加的观察者就是刚刚的LifecycleBoundObserver。

现在我们的视线就完全转入了LifecycleBoundObserver中。

class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver

看它类的签名，我们能知道，它首先是一个LiveData的ObserverWrapper，它的一个作用是包装其他组件对LiveData传入的观察者。其次，它还是一个LifecycleEventObserver，它会检测观察者的生命周期，并在特定的生命周期时做特定的事。

@Override
public void onStateChanged(@NonNull LifecycleOwner source,
        @NonNull Lifecycle.Event event) {
    Lifecycle.State currentState = mOwner.getLifecycle().getCurrentState();

    // 如果当前状态是销毁，那么移除LiveData观察者
    if (currentState == DESTROYED) {
        removeObserver(mObserver);
        return;
    }

    // 下面的循环用于更新当前的状态是否是活跃状态
    // 并且在其他状态转入活跃状态时，调用LiveData监听者的回调
    Lifecycle.State prevState = null;
    while (prevState != currentState) {
        prevState = currentState;
        activeStateChanged(shouldBeActive());
        currentState = mOwner.getLifecycle().getCurrentState();
    }
}

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

看下activeStateChanged方法中的内容，它是ObserverWrapper类的方法

void activeStateChanged(boolean newActive) {
    if (newActive == mActive) {
        return;
    }
    // immediately set active state, so we'd never dispatch anything to inactive
    // owner
    mActive = newActive;
    changeActiveCounter(mActive ? 1 : -1);
    if (mActive) {
        dispatchingValue(this);
    }
}

它会在当前转入的状态是活跃状态时调用dispatchingValue来给LiveData观察者分派值（就是调用观察者的回调）。所以，如果LiveData中有值时，尽管是在当前观察者开始观察之前被设置的，当前观察者也能够立即观察到该值，而不用等到下次LiveData值更改。这种特性叫做“粘性事件”，上一篇笔记中我们自己编写出的代码也具有这种特性。在某些业务中，我们需要这种特性，在某些业务中，我们不需要并且完全不能容忍这种情况出现。后面会说如何解决这个问题。

dispatchingValue是LiveData类的方法了，所以你也能看到，这里将this传入，也就是将ObserverWrapper传入，这样dispatchingValue方法才知道将值分配到哪一个观察者身上。如果dispatchingValue参数中的ObserverWrapper为null，那么它会向所有注册的观察者分配值。相关代码如下

void dispatchingValue(@Nullable ObserverWrapper initiator) {
    // ...

    // 如果observerWrapper不为null，那么只考虑通知指定的观察者
    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());
            // ... 
        }
    }
    // ...
}

setValue和postValue方法里也都是调用了dispatchingValue方法来通知observer更新值，不同的是，这两个方法就没有传入ObserverWrapper，也就是说，它们会向所有观察者分派值。

dispatchingValue中又会调用considerNotify来视情况考虑是否通知观察者LiveData值是否已经改变。

private void considerNotify(ObserverWrapper observer) {
    if (!observer.mActive) {
        return;
    }
    if (!observer.shouldBeActive()) {
        observer.activeStateChanged(false);
        return;
    }
    if (observer.mLastVersion >= mVersion) {
        return;
    }
    observer.mLastVersion = mVersion;
    observer.mObserver.onChanged((T) mData);
}

这里就是再次判断当前观察者的生命周期是否在活跃状态，并且检测当前观察者的值的版本和当前LiveData中值的版本，只有当观察者生命周期活跃并且观察者中的版本小于当前LiveData中值的版本时才会调用观察者的回调，通知观察者LiveData中的值更改了。

所以，总结一下：

LiveData可以添加观察者
LiveData添加观察者时具有粘性事件特性，如果添加之前LiveData中已经有值，那么该观察者一旦处于活跃状态时便会立即接收到最新的值
LiveData并没有提供关闭粘性事件的API，不过我们仿佛可以通过一些手段（比如修改值版本）来关闭粘性事件特性
使用observe方法时，LiveData会观察它的观察者的生命周期，只有当观察者生命周期处于活跃时才会接收到LiveData值的更新，当观察者处于销毁状态时，该观察者会被移除
当观察者状态由其他状态转为活跃时(比如旋转屏幕)，如果观察者中的值比LiveData中的最新值更旧（版本小于LiveData中的版本），观察者会立即接收到LiveData最新值，该条其实已经包含了第三条。

LiveData和MutableLiveData#

MutableLiveData意为“可变的LiveData”，它允许在主线程中通过setValue（或kotlin中的value属性）对其值进行更改，允许在其他线程中通过postValue对值进行更改，但无论如何，观察者的回调都会在主线程中被调用，postValue完成了子线程到主线程的转换，具体可以查看其代码，这里就不分析了。

那如果我们在ViewModel中直接暴露MutableLiveData，那外部就随便更改值了，要知道，根据分离关注点原则，Fragment、Activity这些地方不应该直接改变UI状态，它们只是负责接收并上报用户事件，接收UI状态的更新，渲染界面。

所以我们应该改改之前ViewModel中的代码：

private val _userSelected: MutableLiveData<User> = MutableLiveData()
val userSelected: LiveData<User>
get() = _userSelected

fun select(user: User) {
_userSelected.value = user
}

这是一个常见的手法，LiveData是不可变的，它不可以setValue、postValue。因为可变类型是不可变类型的子类，所以通过私有化可变类型，并且公开一个不可变类型，该不可变类型其实就是可变类型的向下转型，但没办法，因为类型已经向下转为不可变的了，所以外界无法调用setValue和postValue，同时在ViewModel类内部还保留着更改原始可变类型的值的权力。

扩展LiveData#

可以通过继承LiveData类来编写个性化的LiveData类。

下面是官方示例中一个用于持续监听股票价格的LiveData：

class StockLiveData(symbol: String) : LiveData<BigDecimal>() {
    // 初始化股票管理器
    private val stockManager = StockManager(symbol)

    // 股票管理器的监听器，一旦股票价格发生改变，就更新LiveData的Value
    // 现在的模式是：股票价格监听器 -> LiveData -> LiveData观察者
    private val listener = { price: BigDecimal ->
        value = price
    }

    // onActive是当LiveData开始具有活跃观察者时会被回调的方法
    override fun onActive() {
        // 开始监听股票价格更新
        stockManager.requestPriceUpdates(listener)
    }

    // onInactive时当LiveData没有任何活跃观察者时被回调的方法
    override fun onInactive() {
        // 不再监听股票价格更新
        stockManager.removeUpdates(listener)
    }
}

当从没有观察者转到有观察者时，onActive会被调用，当从有观察者转到无观察者时onInactive会被调用。

您可以在多个Activity和Fragment之间共享同一LiveData对象，这没什么大不了的，它可以不依赖任何组件的生命周期而存在，同时它又可以感知每一个观察者的生命周期，保证不会发生崩溃和内存泄漏。

比如通过如下代码将它实现为一个单例：

class StockLiveData(symbol: String) : LiveData<BigDecimal>() {
    private val stockManager: StockManager = StockManager(symbol)

    private val listener = { price: BigDecimal ->
        value = price
    }

    override fun onActive() {
        stockManager.requestPriceUpdates(listener)
    }

    override fun onInactive() {
        stockManager.removeUpdates(listener)
    }

    companion object {
        private lateinit var sInstance: StockLiveData

        @MainThread
        fun get(symbol: String): StockLiveData {
            sInstance = if (::sInstance.isInitialized) sInstance else StockLiveData(symbol)
            return sInstance
        }
    }
}

MediatorLiveData#

LiveData的子类，它可以合并多个LiveData源，当原始LiveData源中任意LiveData值发生改变，MediatorLiveData的观察者就会收到更新。

转换LiveData#

如下代码使用Trasformations.map函数，它将userLiveData转换成了另一个LiveData<String>。当userLiveData的值发生改变时，这个userName也会发生改变。有点像Vue里的computed。

val userLiveData: LiveData<User> = UserLiveData()
val userName: LiveData<String> = Transformations.map(userLiveData) {
    user -> "${user.name} ${user.lastName}"
}

这么高科技的功能如何实现的？其实map方法里只是用了MediatorLiveData，并且只给它添加一个源，这样就做到了当源LiveData更新，这个MediatorLiveData也更新。

@MainThread
public static <X, Y> LiveData<Y> map(
        @NonNull LiveData<X> source,
        @NonNull final Function<X, Y> mapFunction) {
    final MediatorLiveData<Y> result = new MediatorLiveData<>();
    result.addSource(source, new Observer<X>() {
        @Override
        public void onChanged(@Nullable X x) {
            result.setValue(mapFunction.apply(x));
        }
    });
    return result;
}