因为习惯了MVC的开发模式，所以对这种对XML“瞎改”的做法相当的不习惯，更不要说理解MVVM到底是什么玩意了；现在定下心来看看MVVM代码的实现过程，还是觉得这是一个很了不起的架构。
我将在本文对MVC、MVP、MVVM三种结构进行对比说明，并在最后附上MVVM架构的代码例子，帮助大家了解这一框架的精髓

MVC

MVC

MVC全名是Model-View-Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑
Model：应用程序中用于处理应用程序数据逻辑的部分，它主要负责网络请求，数据库处理，I/O等的操作。
View：应用程序中处理数据显示的部分。在Android开发中，它一般对应着xml布局文件
Controller：应用程序中处理用户交互的部分，接受用户的输入并调用Model和View去完成用户的需求。在Android开发中一般由Activity或Fragment来承担
MVC架构肯定是有优点的，要不然这玩意不会有存在的意义。它通过Controller来掌控全局，同时将View展示和Model的变化分离开。但是对于Android开发来说，一旦一个页面的业务繁多复杂的话，Controller里的代码就会越来越臃肿，这是因为Activity或Fragment不仅仅要负责业务逻辑，同时还要加载应用的布局和初始化使用界面，也就是说Activity或Fragment杂糅了Controller和View的功能，这不能算作一个真正意义上的MVC。因此在这种情况下，MVP架构呼之欲出

MVP

MVP

MVP全名是Model-View-Presenter。MVP是从经典的MVC模式演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。
作为一种新的模式，MVP与MVC有着一个重大的区别：MVP中的View并不直接使用Model，它们之间的通信是通过Presenter(MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller

Model：应用程序中用于处理应用程序数据逻辑的部分，它主要负责网络请求，数据库处理，I/O等的操作。
View：应用程序中处理数据显示的部分。在Android开发中，它一般对应着xml布局文件、Activity、Fragment
Presenter：整个MVP体系的控制中心，作为View与Model交互的中间纽带，处理View与Model间的交互和业务逻辑。

在Android开发中，MVP的具体实现流程是当Presenter接收到View的请求，便从Model层获取数据，将数据进行处理。处理好的数据再通过View层的接口回调给Activity或Fragment。这样MVP能够让Activity或Fragment成为真正的View，只做与UI相关的事而不处理其他业务流程。
综上所述，MVP的优点如下：

模型与视图完全分离，我们可以修改视图而不影响模型；
项目代码结构清晰，一看就知道什么类干什么事情；
我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化更频繁
协同工作（例如在设计师没出图之前可以先写一些业务逻辑代码）

MVP也有不足之处：

接口过多，一定程度影响了编码效率。
一定程度上导致Presenter的代码量过大。

为了降低Presenter中业务繁多的问题，Google又推出了MVVM，试图通过数据驱动来减少Presenter的代码量

MVVM

MVVM

MVVM是Model-View-ViewModel的简写。它本质上就是MVC的改进版。MVVM就是将其中View的状态和行为抽象化，让我们将视图UI和业务逻辑分开。当然这些事 ViewModel已经帮我们做了，它可以取出Model的数据同时帮忙处理View中由于需要展示内容而涉及的业务逻辑
Model：应用程序中用于处理应用程序数据逻辑的部分，它主要负责网络请求，数据库处理，I/O等的操作。
View：应用程序中处理数据显示的部分。在Android开发中，它一般对应着xml布局文件、Activity、Fragment。
这里需要补充的是

View层负责处理UI相关的工作，我们只在XML、Activity和Fragment写View层的功能而不进行业务的处理，也就是说我们不在View层写业务逻辑和业务数据相关的代码。

ViewModel ：创建关联，将Model和View绑定起来。这样，一旦Model发生更改，ViewModel就会立即反馈给View从而自动刷新界面。
这里需要补充的是

ViewModel只负责业务逻辑，不做任何和UI相关的事情。更新UI通过数据绑定实现，尽量在ViewModel里面做

来看下MVVM架构在Android上的架构实现

MVVM架构在Android上的架构实现

综上所述，MVVM的优点如下：

数据驱动
在MVVM中，数据和业务逻辑处于一个独立的ViewModel中，ViewModel只要关注数据和业务逻辑，不需要和UI或者控件打交道。由数据自动去驱动UI去自动更新UI，UI的改变又同时自动反馈到数据，数据成为主导因素，这样使得在业务逻辑处理只要关心数据，方便而且简单很多。
低耦合度
MVVM模式中，数据是独立于UI的，ViewModel只负责处理和提供数据，UI想怎么处理数据都由UI自己决定，ViewModel不涉及任何和UI相关的事也不持有UI控件的引用
团队协作
MVVM的分工是非常明显的，由于View和ViewModel之间是松散耦合的。一个是处理业务和数据，一个是专门的UI处理，所以完全可以由两个人分工来做，一个做UI（xml 和 Activity）一个写ViewModel，效率更高。
可复用性
一个ViewModel可以复用到多个View中。同样的一份数据，用不同的UI去做展示，对于版本迭代频繁的UI改动，只要更换View层就行
单元测试
ViewModel里面是数据和业务逻辑，View中关注的是UI，这样做测试是很方便的，完全没有彼此依赖，不管是UI的单元测试还是业务逻辑的单元测试，都是低耦合的。

MVVM的缺点：

更加大的学习成本。目前这种架构的实现方式比较不完善，常见的就是通过DataBinding来完成。
数据绑定使得调试变得困难。当你看到界面异常，有可能是你View的代码有Bug，也可能是Model的代码有问题。数据绑定使得一个位置的Bug被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
数据双向绑定不利于代码重用。客户端开发最常用的重用是View，但是数据双向绑定技术让你的一个View都绑定了一个model，不同模块的model都不同

既然说到DataBinding，那我们就简单了解下它吧

DataBinding

DataBinding早在2015年的Google I/O大会上就被推出了，从名字就可以得知它是一个实现数据和UI绑定的框架。它是构建MVVM架构的一个关键工具，它支持数据和UI双向绑定。
什么是双向绑定？通常情况下，数据的流向是单方面的，只能从业务逻辑处理后流向UI，这就是单向绑定。而双向绑定模式下，数据流向是双向的。业务逻辑中的数据改变时，UI上的数据能够得到刷新；而当用户通过UI交互编辑了数据后，数据也能自动更新到相应的数据源上。
在实际Android开发中，针对Activity或Fragment的布局，在编译阶段会生成一个ViewDataBinding类的对象，该对象持有Activity或Fragment中要展示的数据以及布局中的各个view的引用。当程序运行之后，它将数据分解到各个View上，在UI线程上更新数据、监控数据的变化。这样一来，要展示的数据以及布局就被紧紧的绑定在了一起。

示例代码

终于到了紧张刺激的时刻了，让我们一起看看MVVM架构的代码是如何实现的吧。
先看看项目结构。我这里使用的是DataBinding+Dagger2，所以自上而下的分别是dagger2的包以及DataBinding的包。DataBinding除了m，v，vm以外，还简单封装了一下BaseActivity与BaseAdapter，并将事件Model接口单独放在EventListener中，同时将网络请求放到NetRequest里面

项目结构

下面来具体看代码吧
先看看Application，这个没啥，定义了OkHttpClient请求对象。注意因为是kotlin，所以client对象转成Java之后作用于不再是public而是变成private，dagger2不能赋值给private对象，所以要在其上方加@JvmField注解

class MyApplication : Application() {
    @JvmField
    @Inject
    var client: OkHttpClient? = null

    override fun onCreate() {
        super.onCreate()

        DaggerAppComponent.builder().appModule(AppModule(this)).build().injectApp(this)
    }
}

网络请求部分，写了一个单例。getRequestInfo()就是后续请求的Observable

class NetRequest private constructor() {

  companion object {
      @Volatile private var INSTANCE: NetRequest? = null

      fun getInstance(): NetRequest {
          return INSTANCE ?: synchronized(NetRequest::class) {
              INSTANCE ?: NetRequest()
          }
      }
  }

  fun getRequestInfo() : Observable<String> {
      return Observable.create<String> {
          val builder = Request.Builder()
          val request = builder.url("http://www.mocky.io/v2/5afe76b83200007400222e7b").build()
          val call = (Utils.getApp() as MyApplication).client!!.newCall(request)
          val response = call.execute()
          if (response.isSuccessful) {
              it.onNext(response.body()!!.string())
          }
          else {
              it.onError(Exception("出现异常"))
          }
      }.subscribeOn(Schedulers.io()).observeOn(AndroidSchedulers.mainThread())
  }
}

事件部分，后续给Activity实现

interface EventListener {
    fun onClickListener(view: View, value: String)
}

先来看看m

class SearchBeans : BaseObservable() {
    var value: String? = null
        @Bindable
        get() = field
        set(value) {
            field = value
            notifyPropertyChanged(BR.value)
        }

    var position: Int? = null
        @Bindable
        get() = field
        set(value) {
            field = value
            notifyPropertyChanged(BR.position)
        }
}

在ViewModel里面进行网络请求，得到结果之后通过EventBus传递到Activity中。ViewModel的理解因人而异，我之前还看到过把ViewModel跟Model混在一起的写法，我觉得都是不对的。甚至还见过把网络请求又写在Activity中的代码，这个都是违背了MVVM本质了。我没有将请求部分放置在Model中，这是因为独立的网络类可以方便我后续的管理

class SearchViewModel {
    fun getRemoteValue() {
        NetRequest.getInstance().getRequestInfo().subscribe({
            val type = object : TypeToken<List<SearchBeans>>() {}.type
            val value = Gson().fromJson<List<SearchBeans>>(it, type)
            EventBus.getDefault().post(value)
        }, {

        }, {

        })
    }
}

剩下重头戏View部分了，来看看xml部分。先来看看Activity的布局，里面有一个RecyclerView，它的Model是一个Adapter，还有一个自定义属性app:adapter

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto">
    <data>
        <variable
            name="adapter"
            type="com.renyu.architecturedemo.mvvm.SearchAdapter">

        </variable>
    </data>
    <LinearLayout
        android:orientation="vertical" android:layout_width="match_parent"
        android:layout_height="match_parent">

        <android.support.v7.widget.RecyclerView
            android:id="@+id/rv_search"
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            app:adapter="@{adapter}">

        </android.support.v7.widget.RecyclerView>
    </LinearLayout>
</layout>

自定义属性我是放在Utils工具类里面，在这里对RecyclerView进行adapter的绑定

class Utils {
    companion object {
        @JvmStatic
        @BindingAdapter("adapter")
        fun setAdapter(recyclerView: RecyclerView, adapter: SearchAdapter) {
            recyclerView.layoutManager = LinearLayoutManager(recyclerView.context)
            recyclerView.setHasFixedSize(true)
            recyclerView.adapter = adapter
        }
    }
}

来看看Activity的实现，BaseActivity在onCreate()中将View和Model进行绑定

abstract class BaseActivity<T : ViewDataBinding, M : Any, VM : Any> : AppCompatActivity() {

    abstract fun initViews(): Int
    abstract fun variableId(): Int
    abstract fun model(): M
    abstract fun viewModel() : VM
    abstract fun initParams()
    abstract fun loadData()

    var viewDataBinding: T? = null
    var viewModel: VM? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        viewDataBinding = DataBindingUtil.setContentView(this, initViews())
        viewDataBinding?.setVariable(variableId(), model())

        viewModel = viewModel()

        initParams()
        loadData()
    }
}

真正实现部分，看看这里是不是只对UI进行处理了？viewModel?.getRemoteValue()去获取远程数据，通过EventBus获取得到的结果。这里实现了EventListener接口并将其传给Adapter

class SearchActivity : BaseActivity<ActivitySearchBinding, SearchAdapter, SearchViewModel>(), EventListener {

  private val beans: ArrayList<SearchBeans> by lazy {
      ArrayList<SearchBeans>()
  }

  private val adapter: SearchAdapter by lazy {
      SearchAdapter(beans, this)
  }

  override fun onClickListener(view: View, value: String) {
      val intent = Intent(this, DetailActivity::class.java)
      intent.putExtra("key", value)
      startActivity(intent)
  }

  override fun initViews() = R.layout.activity_search

  override fun variableId() = BR.adapter

  override fun model() = adapter

  override fun viewModel() = SearchViewModel()

  override fun onCreate(savedInstanceState: Bundle?) {
      super.onCreate(savedInstanceState)
      EventBus.getDefault().register(this)
  }

  override fun initParams() {

  }

  override fun loadData() {
      viewDataBinding?.rvSearch?.post {
          viewModel?.getRemoteValue()
      }
  }

  override fun onDestroy() {
      super.onDestroy()
      EventBus.getDefault().unregister(this)
  }

  @Subscribe(threadMode = ThreadMode.MAIN)
  fun onEventMainThread(bean: List<SearchBeans>) {
      beans.addAll(bean)
      adapter.notifyDataSetChanged()
  }
}

来看看Adapter部分。这里面也是对EventListener以及每一行Item对应的对象SearchBeans的声明

<?xml version="1.0" encoding="utf-8"?>
<layout>
    <data>
        <variable
            name="beans"
            type="com.renyu.architecturedemo.mvvm.model.SearchBeans">

        </variable>

        <variable
            name="eventListener"
            type="com.renyu.architecturedemo.mvvm.impl.EventListener">

        </variable>
    </data>
    <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
        android:orientation="vertical" android:layout_width="match_parent"
        android:layout_height="wrap_content">
        <TextView
            android:layout_width="match_parent"
            android:layout_height="50dip"
            android:gravity="center"
            android:onClick="@{(view) -> eventListener.onClickListener(view, beans.value)}"
            android:text="@{beans.value}"/>
        <View
            android:layout_width="match_parent"
            android:layout_height="0.5dip"
            android:background="@color/colorAccent">

        </View>
    </LinearLayout>
</layout>

BaseAdapter里面完成了View跟Model的绑定，这个还包含对EventListener的绑定

abstract class BaseAdapter<T: ViewDataBinding, D>(val beans: ArrayList<D>, private val eventListener: EventListener) : RecyclerView.Adapter<BaseAdapter.BaseViewHolder>() {

    abstract fun initViews(): Int
    abstract fun dataVariableId(): Int
    abstract fun eventListenerVariableId(): Int

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): BaseViewHolder {
        val viewDataBinding = DataBindingUtil.inflate<T>(LayoutInflater.from(parent.context), initViews(), parent, false)
        return BaseViewHolder(viewDataBinding)
    }

    override fun getItemCount(): Int = beans.size

    override fun onBindViewHolder(holder: BaseViewHolder, position: Int) {
        holder.viewDataBinding?.setVariable(dataVariableId(), beans[holder.layoutPosition])
        holder.viewDataBinding?.setVariable(eventListenerVariableId(), eventListener)
        holder.viewDataBinding?.executePendingBindings()
    }

    class BaseViewHolder : RecyclerView.ViewHolder {

        var viewDataBinding: ViewDataBinding? = null

        constructor(viewDataBinding: ViewDataBinding) : super(viewDataBinding.root) {
            this.viewDataBinding = viewDataBinding
        }
    }
}

真正实现部分倒没多少代码

class SearchAdapter(beans: ArrayList<SearchBeans>, eventListener: EventListener) : BaseAdapter<AdapterSearchBinding, SearchBeans>(beans, eventListener) {
    override fun dataVariableId(): Int {
        return BR.beans
    }

    override fun eventListenerVariableId(): Int {
        return BR.eventListener
    }

    override fun initViews() = R.layout.adapter_search
}

剩下就完成了，看看有没有毛病

最终效果

总结一下，以上三种框架没有一个能说一定是最好的，关键还是看你自己的选择。说老实话，就为了一个列表，我看MVC比MVVM和MVP实现起来都轻松。但是如果你写一个大首页的话，最好还是采取MVVM或者MVP，为了方便自己后续修改调试，也方便将来给你擦屁股的那个朋友