前言

MVVM作为一种架构模式，在Android中的主要落地实践脱离不开两个核心类LiveData和ViewModel。阅读之前需要你具备使用LiveData和ViewModel的基本使用。

有的放矢，带着目的的看这篇文或许你会更有收获。这篇文能帮你解除这些疑惑

• ViewModel怎么实现多个Fragment之间数据共享?
• Activity横竖屏切换时，ViewModle是怎么死里逃生的？
• ViewModleScope是怎么感知组件生命周期而自杀（cancel）？
• LiveData如何防止内存泄漏风险？
• LiveData的观察者活跃时才响应是怎么回事？
• 子线程中连续多次向LiveData发送值，observer能接受到所有的值吗？

1）ViewModel

ViewModel的职责，在以注重生命周期的方式存储和管理界面相关的数据

1.1) ViewModel 特性

1.1.1）注重生命周期

• ViewModel注重组件生命周期主要体现在，当横竖屏转换等配置发生变化时导致Activity重建时，ViewModel 不会被销毁重建。换句话说，ViewModel的生命周期要比它所服务的组件（Activity/Fragment）的生命周期本身要长。

1.1.2） ViewModel相关类

a) ViewModelStoreOwner

public interface ViewModelStoreOwner {
    ViewModelStore getViewModelStore();
}

• 提供并管理ViewModelStore，在当因配置改变发生重建时，会保存重建前的ViewModelStore。
• 在Destroy的时候调用ViewModelStore的clear()方法

b) ViewModelStore

//有删减，伪代码
public class ViewModelStore {
    private final HashMap<String, ViewModel> mMap = new HashMap<>();
    final void put(String key, ViewModel viewModel) {
        ViewModel oldViewModel = mMap.put(key, viewModel);
        if (oldViewModel != null) {
            oldViewModel.onCleared();
        }
    }
    final ViewModel get(String key) {
        return mMap.get(key);
    }
    public final void clear() {
        for (ViewModel vm : mMap.values()) {
            vm.clear();
        }
        mMap.clear();
    }
}

• ViewModelStore里有一个Map,用以存储ViewModel;
• 对外提供获取、存储和清空 ViewModel 的方法。
• 当clear的时候会调用 ViewModel 的 clear（）方法。

c) ViewModel

public abstract class ViewModel {
    private final Map<String, Object> mBagOfTags = new HashMap<>();
    final void clear() {
        ..
      synchronized (mBagOfTags) {
           for (Object value : mBagOfTags.values()) {             
                if (obj instanceof Closeable) 
                     ((Closeable) obj).close();
            }
       }
        onCleared();
    }
    <T> T setTagIfAbsent(String key, T newValue) {... }

    <T> T getTag(String key) { ...}
    }
}

• 关键点内部维护了一个Map类的mBagOfTags，用以追踪与该ViewModel对象相关的数据，如viewModelScope，SavedSateHandle数据
• 另，被调用clear()方法时，对遍历出mBagOfTags中 Closeable 接口的value，执行其close方法。同时会调用自身的onClear()方法

1.2）ViewModel 的构建

通常我们使用

//伪代码
public <T extends ViewModel> T get(Class<T> class){
        ViewModel viewModle =  viewModelStrore.get(key)
        if(viewModel == null){
                viewModle  = factory.create(class)
                viewModelStore.put(key,viewModel);
     }
        return viewModel
}
flowViewModel = ViewModelProvider(this).get(FlowViewModel::class.*java*)

• ViewModelProviderl两个成员属性，ViewModeStore和ViewModelProvider.Factory。
• 默认生成的每个ViewModle分配一个key ("androidx.lifecycle.ViewModelProvider.DefaultKey + modelClass.*canonicalName"*)
• 反射调用ViewModel的构造方法，ViewModelStoreOwner中获取出ViewModelStore起到 [缓存作用]，这样就能够实现在一个ViewModelStoreOwner范围内能够实现ViewModel的共享。即，多个组件共同使用一个ViewModel。
• 最终达到的效果是在一个ViewModelStoreOwner范围内只会创建出一个ViewModel。
• 哪些 Factory:KeyFactory、OnRequeryFactory、AndroidViewModelFactory

1.3) ViewModel 与 Kotlin 的 Coroutine 结合

getLifecycle().addObserver(new LifecycleEventObserver() {
            @Override
            public void onStateChanged(@NonNull LifecycleOwner s,Lifecycle.Event e) {
                if (e == Lifecycle.Event.ON_DESTROY) {
                    if (!isChangingConfigurations()) {
                        getViewModelStore().clear();
                    }
                }

• Fragment/Activity都实现了ViewModelStoreOwner接口。当组件生命周期状态切换到ON_DESTORY的的时候就会调用ViewModelStroe的clear()方法。这里有个isChangeingConfigurations()的判断。当因为配置变化导致的Activity重建时不会清除ViewModelStore中的数据，ViewModelStore会在新Activity创建时重新被使用。

• 当调用其clear()方法的时候，会遍历出内部 Closeable 类型的值调用其close方法。其中viewModelScope作为ViewModel的一个扩展属性,如下

• 获取 ViewModelScope 的时候，这个 CloseableCoroutineScope 对象会被添加到 ViewModle的成员属性mBagOfTags 这个Map里。同时CloseableCoroutineScope实现了 Closeble 接口。当ViewModle clear的时候被调用到 CoroutineCotext.cancel() 已达到取消协程Job的效果。

2) LiveData

• ViewModel与View层建立起连接主要依靠LiveDataI(当然也可Flow)。能够达到View层持有ViewModel的引用，ViewModel不持有View的引用。这样的好处也显而易见，View层和ViewModel层解耦；提高ViewModel的可测性。
• 实现方式使用带自动解注册的观察者模式，具体内部实现见下一章节(2.1),View层拿到ViewModel层的liveData然后注册观察者，当LiveData的数据发生变化时，自动更新UI。
• 因为具备自动解注册功能，所以天然的能够防止内存泄漏(destory时清除掉原理见下文)

2.1 ) 自动解注册是怎么实现的？

在看自动解注册之前先看怎么注册的观察者的

 //伪代码有删减
 @MainThread
    public void observe( LifecycleOwner owner,  Observer<? super T> observer) {
        LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);
        ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
        owner.getLifecycle().addObserver(wrapper);
    }

LiveData的Oberver()方法中主要做两件事，

• 把observer存在自己的一个Map类型的mObservers属性里。
• observer被包装成一个LifecycleBoundObserver，这个LifecycleBoundObserver继承了LifecycleEventObserver，因此这个observer也会被注册到livefeCycle上。

这样这个LifecycleBoundObserver对象就可以同时观察监听LiveData的事件和LifeCycle的事件。这样在对应的LifeCycle的事件里就可以做对应的处理。比如移除从注册，不活跃时不通知回调。

class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {
                ...
        @Override
        public void onStateChanged(@NonNull LifecycleOwner source,
                @NonNull Lifecycle.Event event) {    
            if (currentState == DESTROYED) {
                ObserverWrapper removed = mObservers.remove(observer); //从与LiveData解绑
                removed.detachObserver() //与生命周期组件接绑
            }
              ...
        }
        @Override
        void detachObserver() {
            mOwner.getLifecycle().removeObserver(this);
        }
    }

2.2）观察者活跃时才响应是怎么回事？

• LiveData的监听者observer在内部被包装成了LifecycleBoundObserver如上一章节描述，这个observer所监听的生命周期组件如果处于ON_START 或者 ON_RESUME时该监听者才会被通知回调。

内部实现也比较简单，主要是依托observer监听了组件生命周期，自身进入决定自身是否是处于active状态。

• 有一个问题，如果Observer从非活跃状态变为活跃状态一定会被回调吗？答案是不一定。

原因，liveData内部维护了一个版本，当恢复到活跃状态时，如果oberver中版本小于了liveData的版本，才会把最近的值分发非observer进而触发回调方法。liveData中版本会虽然每次新值的设置自动+1，代码如下。也就是说，当observer处于非活跃状态期间，如果liveData没有新值被设定进来，当observer回到活跃状态的时候不会被通知回调。

protected void setValue(T value) {
    assertMainThread("setValue");
    mVersion++;
    mData = value;
    dispatchingValue(null);
}

• 又有另外一个问题，既然不会被重新回调，网上说的数据倒灌是怎么回事？

2.3) 子线程中连续多次向LiveData发送值，observer能接受到所有的值吗？

fun postValueIntWorkThread(){
    liveData.post(1)
    liveData.post(2)
}

LiveData有一个理念，只保留最新值。体现在两点

• 短时间内多次从子线程向liveData post值的时候，observer不保证每个值都收到通知。具体实现如下代码：
• 当observer处于非活跃状态期间，liveData中多次设置了值，当liveData恢复活跃状态后，只会接受到最新值。

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

protected void postValue(T value) {
        boolean postTask;
        synchronized (mDataLock) {
            postTask = mPendingData == NOT_SET;//注释5
            mPendingData = value;//注释2处，value赋值给mPendingData
        }
        if (!postTask) {//注释1：有值正在分发过程中
            return;
        }
        ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);
    }

这段代码比较有意思

• 1> 注释5处，进入被mDataLock这个monitor划定的临界区；计算出postTask的值，如果postTask为ture说明当前没有等待被分发的值，如果值为false说明有正在被分发的值。

• 2> 注释2处，无论postTask的值为true或者false，都会把value的值赋值给mPendingData。

• 3 >注释3处，如果有正在分发的值，就不执行接下来的操作了。此时注释2处已经把值赋值给了mPendingData，这个mPending还能分发吗？

• 4>注释3处这段逻辑通过handler机制，最终在Main线程中执行，把mPendingData赋值给newValue，最终newValue被分发出去了

上面这个步骤下来，思考这样一种情况，连续post 1和2两个值，当post 2的时候，如果此时mPendingData值还为1，那么postTask就为false。但还是把值赋值给了mPendingData。接下来，注释1处正好符合判断条件，就不会向下执行。 当主线程执行到注释3处的runable时，会把2复制给newValue，最后把值分发出去了。

小结

本文主要围绕ViewModel和LiveData一些特性以及内部实现展开，阅读完之后，开头的那几个问题能找到答案了吗？

最后，我整理了一些学习资料，里面包括Java基础、Android进阶、架构设计、NDK、音视频开发、跨平台、底层源码等技术，还有2022年一线大厂最新面试题集锦，都分享给大家，助大家学习路上披荆斩棘~ 能力得到提升，思维得到开阔~ 有需要的可以点击下方公号链接免费获取。

公众号链接：https://mp.weixin.qq.com/s/ZDvWgZ_huo4natNk26ovlw