閑來無事強(qiáng)行看一波MVVM的實(shí)現(xiàn)預(yù)警篇幅比較長。這塊代碼實(shí)在太多了。本來想一篇寫完，發(fā)現(xiàn)只說了一小部分。

• 什么是mvvm

MVVM是Model-View-ViewModel的簡寫。它本質(zhì)上就是MVC 的改進(jìn)版。MVVM 就是將其中的View 的狀態(tài)和行為抽象化，讓我們將視圖 UI 和業(yè)務(wù)邏輯分開

說下個人理解把，MVVM是一種架構(gòu)思想,其實(shí)大體上和MVP是沒啥區(qū)別的，只不過MVP是野王，在官方給出MVVM這種架構(gòu)之前，在android界自發(fā)形成的一種先進(jìn)架構(gòu)思想，演進(jìn)的過程和android的發(fā)展也是有關(guān)系的，android剛興起的時候項(xiàng)目都不是很大，后面android生態(tài)慢慢的項(xiàng)目變多變大，官方的MVC架構(gòu)已經(jīng)廣為詬病了，因?yàn)榇蠹叶及褬I(yè)務(wù)代碼以及各種view的操作代碼塞進(jìn)Controller，導(dǎo)致其臃腫不堪，當(dāng)業(yè)務(wù)需要繼續(xù)迭代的時候，效率極低，更別說換一個人來接手項(xiàng)目了，然后各路大牛齊出招最終MVP這個野王因?yàn)槠鋬?yōu)雅的業(yè)務(wù)實(shí)現(xiàn)架構(gòu)被迅速傳播布道，長時間成為各大中小廠的主流架構(gòu)。

只不過19年Google刷了下存在感,推出了官方的解決方案，Google這些年推出了很多新東西，但不是每一個都能迅速傳播流行，MVVM能夠有這么大影響力，和他跟MVP對解決業(yè)務(wù)代碼爆炸這個詬病離不開關(guān)系的，在加上官方源碼在Activity和Fragment底層的支持，MVP還需要手動去管理業(yè)務(wù)的引用瞬間就不香了。
配合上Databinding的雙向數(shù)據(jù)綁定，只要業(yè)務(wù)數(shù)據(jù)實(shí)現(xiàn)了BaseObsevable接口，就能夠做到數(shù)據(jù)自動驅(qū)動UI，開發(fā)者無需到處編寫ui邏輯。

• 為什么用mvvm？

前面說到了MVVM的幾個優(yōu)點(diǎn)

1. 低耦合。視圖（View）可以獨(dú)立于Model變化和修改，一個ViewModel可以綁定到不同的"View"上，當(dāng)View變化的時候Model可以不變，當(dāng)Model變化的時候View也可以不變。
2. 可重用性。你可以把一些視圖邏輯放在一個ViewModel里面，讓很多view重用這段視圖邏輯。

以前在使用MVVM開發(fā)的時候，我時常有這么一個疑問，每次數(shù)據(jù)改變，采用DataBinding實(shí)現(xiàn)的數(shù)據(jù)驅(qū)動UI邏輯代碼，會導(dǎo)致全局刷新嗎？

會是這樣嗎？如果是這樣的話，那我自己使用代碼去更新ui反而效率更高，雖然代碼寫起來很多，但是起碼不會因?yàn)槿炙⑿拢瑢?dǎo)致一些UI閃屏等體驗(yàn)問題。

帶著這個問題我們打開一個布局文件fragment_webview.xml

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    xmlns:app="http://schemas.android.com/apk/res-auto">

    <data>
        <import type="android.view.View" />
        <variable
            name="p"
            type="com.xx.xxx.base_lib.refresh.RefreshPresenter" />
    </data>

    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical">

        <com.scwang.smart.refresh.layout.SmartRefreshLayout
            android:id="@+id/refreshWeb"
            onRefresh="@{p}"
            app:srlEnableLoadMore="false"
            android:layout_width="match_parent"
            android:layout_height="match_parent">

            <FrameLayout
                android:id="@+id/flWebContainer"
                android:layout_width="match_parent"
                android:layout_height="match_parent"/>
        </com.scwang.smart.refresh.layout.SmartRefreshLayout>


        <ProgressBar
            android:id="@+id/loading_progress"
            style="@style/Widget.AppCompat.ProgressBar.Horizontal"
            android:layout_width="match_parent"
            android:layout_height="2dp"/>

        <TextView
            android:layout_alignParentEnd="true"
            android:layout_alignBottom="@+id/debug_input"
            android:id="@+id/debug"
            android:text="打開"
            android:textStyle="bold"
            android:background="@color/white"
            app:corner_bgColor="@{`#EF7945`}"
            app:corner_radius="@{100f}"
            android:paddingStart="15dp"
            android:paddingEnd="15dp"
            android:paddingBottom="5dp"
            android:textColor="@color/white"
            android:paddingTop="5dp"
            android:visibility="gone"
            tools:visibility="visible"
            tools:background="#EF7945"
            android:layout_marginEnd="5dp"
            android:layout_marginBottom="10dp"
            app:layout_constraintEnd_toEndOf="parent"
            app:layout_constraintBottom_toTopOf="@id/debug_input"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"/>

        <EditText
            android:textCursorDrawable="@drawable/ic_cursor_input"
            android:id="@+id/debug_input"
            android:visibility="gone"
            tools:visibility="visible"
            app:corner_radius="@{100f}"
            android:layout_toStartOf="@+id/debug"
            android:layout_below="@+id/loading_progress"
            app:corner_bgColor="@{`#ffffff`}"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"/>

    </RelativeLayout>

</layout>

Databinding利用kapt工具會自動幫我們生成一個布局文件名+BindingImpl.java文件，如下圖：

WebviewFragment

當(dāng)然想要使用DataBinding我們就必須在項(xiàng)目對應(yīng)的gradle文件里加上

android{
    buildFeatures {
        dataBinding = true
    }
}

內(nèi)部方法有好幾個，執(zhí)行ui操作的代碼只有一段。
仔細(xì)觀察，我們會發(fā)現(xiàn)，每一個View的操作都會被一個dirtyFlags包裹，只有當(dāng)與指定的值&操作不等于0才執(zhí)行，這就是DataBinding的局部刷新邏輯了。

    @Override
    protected void executeBindings() {
        long dirtyFlags = 0;
        synchronized(this) {
            dirtyFlags = mDirtyFlags;
            mDirtyFlags = 0;
        }
        com.xxx.xxx.base_lib.refresh.RefreshPresenter p = mP;

        if ((dirtyFlags & 0x3L) != 0) {
        }
        // batch finished
        if ((dirtyFlags & 0x2L) != 0) {
            // api target 1

            com.xx.xx.common.extern.BindingAdaptersKt.cornerBg(this.debug, 100f, "#EF7945", (java.lang.Float)null, (java.lang.String)null, (java.lang.String)null);
            com.xx.xx.common.extern.BindingAdaptersKt.cornerBg(this.debugInput, 100f, "#ffffff", (java.lang.Float)null, (java.lang.String)null, (java.lang.String)null);
        }
        if ((dirtyFlags & 0x3L) != 0) {
            // api target 1

            com.xx.xxx.base_lib.extens.ViewBindsExtKt.bindOnRefresh(this.refreshWeb, p);
        }
    }

也就是只有指定的數(shù)據(jù)位刷新了，才會進(jìn)行ui更新，否則不會執(zhí)行。

就像下面這段代碼,會將mDirtyFlag的1號位置為0x1L
然后notifyPropertyChanged這個是重點(diǎn)，下面會講到。

public void setP(@Nullable com.tomoro.indonesia.base_lib.refresh.RefreshPresenter P) {
        this.mP = P;
        synchronized(this) {
            mDirtyFlags |= 0x1L;
        }
        notifyPropertyChanged(BR.p);
        super.requestRebind();
    }

我們回憶一下剛才看到的代碼

數(shù)據(jù)局部刷新

也就是說，DataBinding不會觸發(fā)全局刷新，每次executeBindings()只會執(zhí)行臟數(shù)據(jù)Ui修改。

• MVVM是如何實(shí)現(xiàn)數(shù)據(jù)綁定

既然數(shù)據(jù)改變能驅(qū)動Ui,我們很容易就能聯(lián)想到，數(shù)據(jù)源肯定是被UI訂閱了。
所以我們的數(shù)據(jù)源才需要實(shí)現(xiàn)BaseObserver接口，官方的DataBinding包中，做了很多基礎(chǔ)實(shí)現(xiàn)。

image.png

在源碼里我們看到很多Observable開頭的數(shù)據(jù)結(jié)構(gòu)包裝類。
打開其中一個ObservableByte會發(fā)現(xiàn)

BaseObserver子類

image.png

image.png

所以他們都是Observable的子類。

public class BaseObservable implements Observable {
    private transient PropertyChangeRegistry mCallbacks;
    
    /*** 
    .....
    省略一些不重要的方法以及細(xì)節(jié)
    ***/

    @Override
    public void addOnPropertyChangedCallback(@NonNull OnPropertyChangedCallback callback) {  ....  }
    @Override
    public void removeOnPropertyChangedCallback(@NonNull OnPropertyChangedCallback callback) { .... }
    public void notifyChange() { .... }
    public void notifyPropertyChanged(int fieldId) {
        synchronized (this) {
            if (mCallbacks == null) {
                return;
            }
        }
        mCallbacks.notifyCallbacks(this, fieldId, null);
    }
}

可以看到剛才我們在上面設(shè)置P的時候調(diào)用的notifyPropertyChanged方法原來來源于這里，也就是說其實(shí)ViewBinding就是那個被訂閱者，它負(fù)責(zé)數(shù)據(jù)分發(fā)，那么真相只有一個它應(yīng)該也是繼承于Observable才對，我們看看源碼繼承關(guān)系。

image.png

soga!

Viewbinding是數(shù)據(jù)被訂閱者負(fù)責(zé)分發(fā)數(shù)據(jù)，我們所有的布局文件在kapt工具生成的XXXXViewbinding.java,都是繼承于viewBinding對象。數(shù)據(jù)源我們找到了，那訂閱者在哪里呢？

上面的BaseObservable源碼我們看到了mCallbacks，用來保存訂閱者對象，數(shù)據(jù)變動分發(fā)也是給這些PropertyChangeRegistry。

image.png

數(shù)據(jù)訂閱的傳入主要有3個地方，但是只有ViewDataBinding的有具體的調(diào)用鏈，
我們一路反向查看調(diào)用最后定位到：

    protected boolean updateRegistration(int localFieldId, Object observable,
            CreateWeakListener listenerCreator) {
        if (observable == null) {
            return unregisterFrom(localFieldId);
        }
        WeakListener listener = mLocalFieldObservers[localFieldId];
        if (listener == null) {
            registerTo(localFieldId, observable, listenerCreator);
            return true;
        }
        if (listener.getTarget() == observable) {
            return false;//nothing to do, same object
        }
        unregisterFrom(localFieldId);
        registerTo(localFieldId, observable, listenerCreator);
        return true;
    }

ViewDataBinding內(nèi)部維護(hù)的一個mLocalFieldObservers。
從這里繼續(xù)查看調(diào)用的話，就會看到最終的調(diào)用方其實(shí)是一開始我們看到的kapt自動生成的業(yè)務(wù)XXXXViewDataBinding類的executeBindings的方法。
形成了一個完美的環(huán)路。

也就是說ViewDataBinding既是訂閱者也是被訂閱者，但是它訂閱的是內(nèi)部的各種實(shí)現(xiàn)BaseObserverable接口的基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，而這些數(shù)據(jù)結(jié)構(gòu)在值改變調(diào)用set方法的時候會去觸發(fā)notifyChange進(jìn)而分發(fā)事件到訂閱者，也就是ViewDataBinding上,ViewDataBinding通過executeBindings觸發(fā)初始化訂閱，形成一個完成的訂閱者模型。

訂閱者事件觸發(fā)主要是被訂閱者的set方法出發(fā)以及ViewDataBinding的notifyPropertyChanged2種途徑。

而notifyPropertyChanged是由頁面初始化的時候通過開發(fā)者通過手動給布局中的
data下聲明的variable標(biāo)簽下的變量，進(jìn)行賦值觸發(fā)的。

而任何一種事件觸發(fā)notifyChange之后，會去ViewDataBinding中觸發(fā)executePendingBindings從而觸發(fā)executeBindings。

也就是說觸發(fā)綁定的方式其實(shí)由executePendingBindings執(zhí)行。而我們繼續(xù)查看調(diào)用鏈會發(fā)現(xiàn)executePendingBindings觸發(fā)的點(diǎn)比較多，總結(jié)起來主要是分為2類

• 初始化ViewDataBinding
• 通知數(shù)據(jù)改變

而初始化ViewDataBinding主要是

static {
        if (VERSION.SDK_INT < VERSION_CODES.KITKAT) {
            ROOT_REATTACHED_LISTENER = null;
        } else {
            ROOT_REATTACHED_LISTENER = new OnAttachStateChangeListener() {
                @TargetApi(VERSION_CODES.KITKAT)
                @Override
                public void onViewAttachedToWindow(View v) {
                    // execute the pending bindings.
                    final ViewDataBinding binding = getBinding(v);
                    binding.mRebindRunnable.run();
                    v.removeOnAttachStateChangeListener(this);
                }

                @Override
                public void onViewDetachedFromWindow(View v) {
                }
            };
        }
    }

不難看出android 4.4之后mRoot attach到Window上的時候會去出發(fā)一次，之后將會移除這里的邏輯。

if (USE_CHOREOGRAPHER) {
            mChoreographer = Choreographer.getInstance();
            mFrameCallback = new Choreographer.FrameCallback() {
                @Override
                public void doFrame(long frameTimeNanos) {
                    mRebindRunnable.run();
                }
            };
        } else {
            mFrameCallback = null;
            mUIThreadHandler = new Handler(Looper.myLooper());
        }

private static final boolean USE_CHOREOGRAPHER = SDK_INT >= 16;

每一次界面刷新周期(16.6ms)都會去檢查視圖是否數(shù)據(jù)更新，老版本則是通過Handler去做定時刷新，這么做當(dāng)然沒有在界面刷新回調(diào)之后出發(fā)來的優(yōu)雅，篇幅有限，不做過多解釋。

static class OnStartListener implements LifecycleObserver {
        final WeakReference<ViewDataBinding> mBinding;
        private OnStartListener(ViewDataBinding binding) {
            mBinding = new WeakReference<>(binding);
        }

        @OnLifecycleEvent(Lifecycle.Event.ON_START)
        public void onStart() {
            ViewDataBinding dataBinding = mBinding.get();
            if (dataBinding != null) {
                dataBinding.executePendingBindings();
            }
        }
    }

另一個界面初始化邏輯則是在界面觸發(fā)onStart生命周期的時候。當(dāng)然既然有界面生命周期，自然就會有l(wèi)ifeCycleOwner設(shè)置。

public void setLifecycleOwner(@Nullable LifecycleOwner lifecycleOwner) {
        if (lifecycleOwner instanceof Fragment) {}
        if (mLifecycleOwner == lifecycleOwner) {
            return;
        }
        if (mLifecycleOwner != null) {
            mLifecycleOwner.getLifecycle().removeObserver(mOnStartListener);
        }
        mLifecycleOwner = lifecycleOwner;
        if (lifecycleOwner != null) {
            if (mOnStartListener == null) {
                mOnStartListener = new OnStartListener(this);
            }
            lifecycleOwner.getLifecycle().addObserver(mOnStartListener);
        }
        for (WeakListener<?> weakListener : mLocalFieldObservers) {
            if (weakListener != null) {
                weakListener.setLifecycleOwner(lifecycleOwner);
            }
        }
    }

這也是為什么我們需要設(shè)置setLifecycleOwner，Databinding的數(shù)據(jù)綁定才會生效，包括綁定view的unbind操作也跟這里息息相關(guān)的，當(dāng)然這里fragment的LifecycleOwner官方提示我們會有風(fēng)險，因?yàn)镕ragment內(nèi)部有2個LifecycleOwner，一個是viewLifecycleOwner,一個是Fragment自身的LifecycleOwner，viewLifecycleOwner是Fragment管理的view的LifecycleOwner它會在Fragment的onDestroy之前的onDestroyView中被銷毀，所以有可能會造成內(nèi)存泄露，所以理論上我們對Fragment的ui操作的LifecycleOwner需要使用viewLifecycleOwner。

這次我是從訂閱者模式逆推DataBinding的實(shí)現(xiàn)邏輯，其實(shí)我們還可以正推分析從DataBindingUtil的infaterLayout和setContentView來分析。