​ 寻找mvvm相关资料已经找了很长时间了，简书，掘金，CSDN看了很多各路大神洋洋洒洒几千字的文章，但最终都没有找到我所想要的架构设计，大多数文章先在介绍MVVM的起源，然后介绍关于DataBinding框架的一些使用方法。

​ Shit！我要看这些干嘛！因为既然想到MVVM模式，那肯定是经过标准安卓设计模式（且这么说，否则没有用到设计的某些程序，都自称自己是MVC），再经过MVP模式，最终会选择MVVM这个模式。So，DataBinding这个框架我已经默认你会了，不过确实不难，用熟了会很爽。

​ 为什么要使用MVVM？有人说，我不喜欢MVVM，因为把逻辑写在XML里面让人看的不够清晰，但是看到这样的代码你会说不清晰？

      <TextView android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="@{user.name}"/>
       
      <TextView android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:text="@{user.nick}"/>

​ 这样的代码明显比你那个findViewById再setText强的太多，User在变，TextView跟着再变，感觉这里的逻辑就是那么顺理成章。有些人说我有ButterKnife不需要findviewById了，但是ButterKnife的效率貌似不高（查阅了相关资料，没有去做实验），但是DataBinding可不一样，Google自家开发的框架，AndroidStdio原生支持，XML语法高亮，方法跳转等等，更为重要的是DataBinding是一次性生成布局的树状结构，对于XML中添加Id的控件，即可以直接以final成员的方式访问，不会重复findViewById，傻傻的从根节点寻找。hi！儿子，你是某某Id的view吗？不是啊，那你问问你儿子看。。。

​ 那怎样的设计会比较完美呢？在做的这个项目，结合老大哥留下的代码我也做了很多尝试，MVPVM，这应该是他的尝试，这个名词在翟一凡的博客中好像也看到过，我在原有代码的基础上进行了自己的改造，M层处理数据的来源，V层是架在Fragment上，处理界面的变化，P层处理网络请求，去调M层的数据，VM这个层是好layout绑定在一起，我当时的设计是这样的，一个界面一个VM，即使这个界面上面是一个Banner图，中间是几个选择菜单，底下是一个纵向的列表，我是一个界面一个VM的形式写的，在Presenter和ViewModule这两个层可以不导入android包中的任何一个类，与其他Activity交互也都是在View中进行的，s写的也是十分的舒服，项目上线后，我又在思考这个设计的问题，因为模式而模式，导致了0复用，类太多，一个界面下面至少有xxxContract，xxxPresenter，xxxViewModule，xxxFragemnt，显然这不是我所看到的。后来在github上面找到一个示例 archi，start的人还蛮多的。这个示例介绍上面提到的安卓的三种设计，主界面是列表，次界面是详情。大多数App都有这个设计吧，原谅我蹩脚的截图，排版排不好，将就一下。

​ 然后是这个是类的结构，分了m，v，vm三个包。

​ 在这个设计里面，V层的接口写在VM中，然后每个View对应一个VM，其实现在想来，应该是这样设计的，MVVM，视图和模型绑定，那么每个视图绑定一个一个VM进行绑定，VM这个层完全可以取代掉Presenter这个层，也不需要Contract，因为Contract的存在就是关联P和V，这样处理的好处就是，各个View之间可以解耦，举个例子，可能存在多个界面用到Banner，但是ViewModule不需要动，变化的只是其中的数据而已，再说点击Banner的跳转事件，以前是写在View层的，因为我的VM中是不含有Context的，但是从archi这个示例看来，他点击列表中的Item跳转事件都直接写在VM中，那么我们的banner完全也可以把点击跳转写在VM中，这下好了，只需要关心数据，剩下的都交给他吧。

​ 近两年Android涌现出好多新的框架，新的东西带来新的挑战，学习的曲线是陡峭的，但是学会之后开发效率也是可以提高数倍！