美文网首页Kotlin
08 项目架构-MVVM-2

08 项目架构-MVVM-2

作者: 凤邪摩羯 | 来源:发表于2021-11-16 09:21 被阅读0次

    前言

    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相关类

    image.png
    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、OnRequeryFactoryAndroidViewModelFactory

    1.3) ViewModel 与 Kotlin 的 Coroutine 结合

    image.png
    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

    image.png
    • 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,最后把值分发出去了。

    相关文章

      网友评论

        本文标题:08 项目架构-MVVM-2

        本文链接:https://www.haomeiwen.com/subject/wteqtrtx.html