MVVM你到底由多少秘密-有解無憂

前言

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一些特性以及內部實作展開，閱讀完之后，開頭的那幾個問題能找到答案了嗎？

轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/356139.html

標籤：其他

上一篇：庫克建議想要側載的用戶購買安卓手機，蘋果這是飄了？

下一篇：Swift 函式與閉包