闲来无事强行看一波MVVM的实现预警篇幅比较长。这块代码实在太多了。本来想一篇写完，发现只说了一小部分。
-
什么是mvvm
MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开
说下个人理解把，MVVM是一种架构思想,其实大体上和MVP是没啥区别的，只不过MVP是野王，在官方给出MVVM这种架构之前，在android界自发形成的一种先进架构思想，演进的过程和android的发展也是有关系的，android刚兴起的时候项目都不是很大，后面android生态慢慢的项目变多变大，官方的MVC架构已经广为诟病了，因为大家都把业务代码以及各种view的操作代码塞进Controller，导致其臃肿不堪，当业务需要继续迭代的时候，效率极低，更别说换一个人来接手项目了，然后各路大牛齐出招最终MVP这个野王因为其优雅的业务实现架构被迅速传播布道，长时间成为各大中小厂的主流架构。
只不过19年Google刷了下存在感,推出了官方的解决方案，Google这些年推出了很多新东西，但不是每一个都能迅速传播流行，MVVM能够有这么大影响力，和他跟MVP对解决业务代码爆炸这个诟病离不开关系的，在加上官方源码在Activity和Fragment底层的支持，MVP还需要手动去管理业务的引用瞬间就不香了。
配合上Databinding的双向数据绑定，只要业务数据实现了BaseObsevable接口，就能够做到数据自动驱动UI，开发者无需到处编写ui逻辑。
-
为什么用mvvm？
前面说到了MVVM的几个优点
1. 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
以前在使用MVVM开发的时候，我时常有这么一个疑问，每次数据改变，采用DataBinding实现的数据驱动UI逻辑代码，会导致全局刷新吗？
会是这样吗？如果是这样的话，那我自己使用代码去更新ui反而效率更高，虽然代码写起来很多，但是起码不会因为全局刷新，导致一些UI闪屏等体验问题。
带着这个问题我们打开一个布局文件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
当然想要使用DataBinding我们就必须在项目对应的gradle文件里加上
android{
buildFeatures {
dataBinding = true
}
}
内部方法有好几个，执行ui操作的代码只有一段。
仔细观察，我们会发现，每一个View的操作都会被一个dirtyFlags包裹，只有当与指定的值&操作不等于0才执行，这就是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);
}
}
也就是只有指定的数据位刷新了，才会进行ui更新，否则不会执行。
就像下面这段代码,会将mDirtyFlag的1号位置为0x1L
然后notifyPropertyChanged这个是重点，下面会讲到。
public void setP(@Nullable com.tomoro.indonesia.base_lib.refresh.RefreshPresenter P) {
this.mP = P;
synchronized(this) {
mDirtyFlags |= 0x1L;
}
notifyPropertyChanged(BR.p);
super.requestRebind();
}
我们回忆一下刚才看到的代码
这个时候如果我们用 0x3L换算成2进制0x11 & 0x1那他的结果肯定 != 0 ,就会触发刷新逻辑，然后上面的代码块是 0x2L换算成2进制0x10 & 0x1 结果是等于0 的,所以不会触发刷新逻辑。
也就是说，DataBinding不会触发全局刷新，每次executeBindings()只会执行脏数据Ui修改。
-
MVVM是如何实现数据绑定
既然数据改变能驱动Ui,我们很容易就能联想到，数据源肯定是被UI订阅了。
所以我们的数据源才需要实现BaseObserver接口，官方的DataBinding包中，做了很多基础实现。
在源码里我们看到很多Observable开头的数据结构包装类。
打开其中一个ObservableByte会发现
BaseObserver子类
image.png
image.png
所以他们都是Observable的子类。
public class BaseObservable implements Observable {
private transient PropertyChangeRegistry mCallbacks;
/***
.....
省略一些不重要的方法以及细节
***/
@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);
}
}
可以看到刚才我们在上面设置P的时候调用的notifyPropertyChanged方法原来来源于这里，也就是说其实ViewBinding就是那个被订阅者，它负责数据分发，那么真相只有一个它应该也是继承于Observable才对，我们看看源码继承关系。
image.png
soga!
Viewbinding是数据被订阅者负责分发数据，我们所有的布局文件在kapt工具生成的XXXXViewbinding.java,都是继承于viewBinding对象。数据源我们找到了，那订阅者在哪里呢？
上面的BaseObservable源码我们看到了mCallbacks，用来保存订阅者对象，数据变动分发也是给这些PropertyChangeRegistry。
数据订阅的传入主要有3个地方，但是只有ViewDataBinding的有具体的调用链，
我们一路反向查看调用最后定位到：
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内部维护的一个mLocalFieldObservers。
从这里继续查看调用的话，就会看到最终的调用方其实是一开始我们看到的kapt自动生成的业务XXXXViewDataBinding类的executeBindings的方法。
形成了一个完美的环路。
也就是说ViewDataBinding既是订阅者也是被订阅者，但是它订阅的是内部的各种实现BaseObserverable接口的基础数据结构，而这些数据结构在值改变调用set方法的时候会去触发notifyChange进而分发事件到订阅者，也就是ViewDataBinding上,ViewDataBinding通过executeBindings触发初始化订阅，形成一个完成的订阅者模型。
订阅者事件触发主要是被订阅者的set方法出发以及ViewDataBinding的notifyPropertyChanged2种途径。
而notifyPropertyChanged是由页面初始化的时候通过开发者通过手动给布局中的
data下声明的variable标签下的变量，进行赋值触发的。
而任何一种事件触发notifyChange之后，会去ViewDataBinding中触发executePendingBindings从而触发executeBindings。
也就是说触发绑定的方式其实由executePendingBindings执行。而我们继续查看调用链会发现executePendingBindings触发的点比较多，总结起来主要是分为2类
- 初始化ViewDataBinding
- 通知数据改变
而初始化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上的时候会去出发一次，之后将会移除这里的逻辑。
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)都会去检查视图是否数据更新，老版本则是通过Handler去做定时刷新，这么做当然没有在界面刷新回调之后出发来的优雅，篇幅有限，不做过多解释。
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();
}
}
}
另一个界面初始化逻辑则是在界面触发onStart生命周期的时候。当然既然有界面生命周期，自然就会有lifeCycleOwner设置。
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);
}
}
}
这也是为什么我们需要设置setLifecycleOwner，Databinding的数据绑定才会生效，包括绑定view的unbind操作也跟这里息息相关的，当然这里fragment的LifecycleOwner官方提示我们会有风险，因为Fragment内部有2个LifecycleOwner，一个是viewLifecycleOwner,一个是Fragment自身的LifecycleOwner，viewLifecycleOwner是Fragment管理的view的LifecycleOwner它会在Fragment的onDestroy之前的onDestroyView中被销毁，所以有可能会造成内存泄露，所以理论上我们对Fragment的ui操作的LifecycleOwner需要使用viewLifecycleOwner。
这次我是从订阅者模式逆推DataBinding的实现逻辑，其实我们还可以正推分析从DataBindingUtil的infaterLayout和setContentView来分析。
