《Android构建MVVM》系列(一) 之 MVVM架构快速入门

前言

本文属于Android 构建MVVM系列开篇，共六个篇章，详见目录树
该系列文章旨在为Android的开发者入门MVVM架构，掌握其基本开发模式
辅以讲解Android Architecture Components,使得更好的实现MVVM

目录树

1. Android 构建MVVM系列(一) 之 MVVM架构快速入门
   
   • 前言
   • 分层思想
   • 什么MVC/MVP ？
   • MVVM是什么，与MVC/MVP有何区别 ？
   • Android Architecture Components(架构组件)
   • 一个MVVM的Demo
   • 结语
2. Android 构建MVVM系列(二) 之 架构组件 LiveData
3. Android 构建MVVM系列(三) 之 架构组件 ViewModel
4. Android 构建MVVM系列(四) 之 架构组件 Room
5. Android 构建MVVM系列(五) 之 构建更好的 Demo
6. Android 构建MVVM系列(六) 之 总结与展望

正文

---

1F 分层思想

分层是一种思想，同时也是一种架构模式。它的特点是专职，即某一层的职责是相同的、确定的；比如我们平时所谓的Dao、Controller层…他们都有明确的职责。

分层思想具体表现为，通过抽象某一类的逻辑构成一个水平功能面，进而对上层提供API；多个层面相互依赖、配合提供整体解决方案。层与层之间的依赖关系是自上而下的，即上层依赖下层，下层不能依赖上层，最底层的组件没有依赖。
初学者往往搞不明白为什么明明可以直接编码业务逻辑，还要去做所谓的分层架构呢？
其实对仅仅实现需求来说，用不用分层架构没有关系的，不分层照样可以实现；那么为什么我们还要徒增烦恼呢？有句话说的好：“存在即合理”，也就是说既然我们的前辈研究出了所谓的分层架构，并且沿用至今；那么就一定有它的优点，一定是解决了某一领域的痛点而诞生的。
当你的项目随着需求的增加和不断调整，不可避免的就要去改动已有的代码，如果项目规模不大还好，如果是个老古董项目，可能某个类里面上万行的代码，没有注释，没有采用分层架构，相信我，你会哭的。



分层架构虽说不能完完全全的解决项目程序复杂度高的问题，但是通过分层，将大的问题抽象分解成了小的功能面，局部化在每一层中，这样就有效的降低了单个问题的规模和复杂度；另外层与层之间也可以通过简单的调整插入新的层面，用以满足不断变化的需求，同一层面来说也可近乎0成本的水平扩展；并且易于Debug、测试。

2F 什么是MVC/MVP ？

先来说说MVC吧，其实MVX模式都是分层思想的一种具体实现，上文提到的分层思想实际上是一种抽象层面的分层，着重表现在抽象和解耦。

MVC实际上是一种分层思想的践行者和改进者，在GUI编程中，MVC已经有几十年的历史了。
顾名思义M(Model)即数据模型层，Model层很有意思，对于服务端编程来说我们把MVC中的M极有可能是包括了业务处理(Service)和实体类的，对于客户端编程来说MVC中的M可能就仅仅是数据模型，当然以上的说法只是于我个人而言的体会，不代表广义立场。
V(View)即视图层/表现层，主要负责数据的展示和用户的交互，C(Controller)即控制层，主要负责一些数据传递、请求转发、业务处理的委派。
以上是标准意义上的MVC，对于Android来说：
Model：数据模型(实体类、持久化、IO)
View：布局文件
Controller：对应于Activity、Fragment，包含一些业务逻辑的处理
这里我们会发现，Android的MVC事实上V层的职责一部分被C层承担了，比如一些交互我们必须写到Activity/Fragment中，这样就会导致C层既包含UI操作，又有网络请求、业务处理等；导致C层过于臃肿，不利于项目后期的维护和扩展。



所以，MVP就应运而生了，MVP实际上是由MVC进化而来，它比较好的解决了MVC时代遗留的问题，MVP中的各层含义：
Model：数据模型(实体类、持久化、IO)
View：Activity/Fragment和布局文件
Presenter：负责完成View和Model之间的交互和业务逻辑
其核心是：设计一个抽象的V层接口，并由具体的View实现该接口，P层内部维护一个该接口的实例引用，一般在构造函数中传递进来复制(即View层初始化P层实例时)，彼时P层即可通过调用该接口来完成对View层的操作,V层也因持有P层实例，可以进行业务逻辑处理委派。

3F MVVM是什么，与MVC/MVP有何区别 ？

MVVM是对MVP/MVC的一种改进，既解决了MVC时代的职责不明的问题，也很好的解决了MVP模式中需要编写过多繁琐的接口，以及V层和P层互相依赖所产生的一些隐式问题。

在MVVM中，各层含义如下
Model：数据模型(实体类、持久化、IO)
View：Activity/Fragment和布局文件
ViewModel：业务逻辑的处理、数据的转换、连接M层和V层的桥梁
看上去似乎和MVP中各层的职责是类似的，并没有显著的不同和改进；那么我们为何要使用MVVM架构呢？

引用美团技术团队的一段解释

1. 双向绑定、数据驱动
   在常规的开发模式中，数据变化需要更新UI的时候，需要先获取UI控件的引用，然后再更新UI。获取用户的输入和操作也需要通过UI控件的引用。在MVVM中，这些都是通过数据驱动来自动完成的，数据变化后会自动更新UI，UI的改变也能自动反馈到数据层，数据成为主导因素。这样MVVM层在业务逻辑处理中只要关心数据，不需要直接和UI打交道，在业务处理过程中简单方便很多。
2. 高度解耦
   MVVM模式中，数据是独立于UI的。
   数据和业务逻辑处于一个独立的ViewModel中，ViewModel只需要关注数据和业务逻辑，不需要和UI或者控件打交道。UI想怎么处理数据都由UI自己决定，ViewModel不涉及任何和UI相关的事，也不持有UI控件的引用。即便是控件改变了（比如：TextView换成EditText），ViewModel也几乎不需要更改任何代码。它非常完美的解耦了View层和ViewModel，解决了上面我们所说的MVP的痛点。
3. 可复用、易测试、方便协同开发
   一个ViewModel可以复用到多个View中。同样的一份数据，可以提供给不同的UI去做展示。对于版本迭代中频繁的UI改动，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二选择。
   MVVM的分工是非常明显的，由于View和ViewModel之间是松散耦合的：一个是处理业务和数据、一个是专门的UI处理。所以，完全由两个人分工来做，一个做UI（XML和Activity）一个写ViewModel，效率更高
   ViewModel层做的事是数据处理和业务逻辑，View层中关注的是UI，两者完全没有依赖。不管是UI的单元测试还是业务逻辑的单元测试，都是低耦合的。在MVVM中数据是直接绑定到UI控件上的（部分数据是可以直接反映出UI上的内容），那么我们就可以直接通过修改绑定的数据源来间接做一些Android UI上的测试。

4F Android Architecture Components(架构组件)

实现MVVM的方式和工具有很多，既可以使用Google在2015年推出的DataBinding库，亦或是其他。也可以选择Google IO 2017 推出的Android Architecture Components即架构组件，这也是本文所采用的解决方案。

<