个人浅谈：Android MVC/MVP/MVVM理解

Android 开发的模式从MVC/MVP/MVVM，一路发展过来，讲讲个人的理解。

MVC是最开始的模式，MVC=Model+View+Controller

其中:

• Model：数据模型层，主要负责数据的获取
• View：视图层，页面的显示
• Controller：控制器，业务逻辑的核心控制

        其实看到这个名称解释，就有一个问题产生了，Android想要显示一个界面，一般要有两个东西：Activity/Fragment和布局文件，那么如果在Activity/Fragment 中处理业务逻辑，自定义控件事件的处理，View显示内容的处理，那么V-C两部分就混在一起了，既有View显示部分，又有Controller的部分，耦合度太高了。

       上面这一段几乎是所有讲MVC的都会说的，MVC的问题以及引出MVP，但是稍微思考下就知道，这个是针对N久之前的Android版本，那时候能写出个能跑的APP已经不容易，哪有那么多考虑耦合的问题，能在Activity中把逻辑写清楚已经不易了。

网上很多图都是写单线的View-->Controller--->Model，这个针对的是用户点击等主动操作，但是这个流程反过来也是成立的，比如说接受一个蓝牙状态的广播，根据蓝牙状态控制界面显示蓝牙的icon，是开启，连接中，连接上的图标，这就是Model-->Controller-->View。

       稍微有点经验的工程师都知道，在一个类里面写大量的业务逻辑是很危险的，可读性和维护容易度都在下降，尤其是在Activity或者是Fragment中写大量的业务逻辑，一般来说会写若干的工具类，来把逻辑移出，减少一个类的代码量和耦合，这样自然而然就引出了MVP的概念。

      在MVC中 Activity/Fragment既要当View又要当Controller，MVP就把他拆分了，让它专注于做View的事情，响应View的点击，显示，数据展示等业务，更加专注于视图相关的操作，它负责的事情少了，但是整体的业务不会变，那么它减少的那个部分业务归谁管理呢，这就是Presenter，他来负责处理View和Model的关系，即连接数据源和View（Activty/Fragment）。这样View就完全被独立出来了，只是被动接受Presenter的命令，这样避免了View 有过多的逻辑处理，更加简单。Presenter持有了Model。Model 只用于处理跟数据获取相关的逻辑

        耦合度进一步降低，重用性提高

 

    MVVM是Model（数据层）、ViewController/View（展示层）、ViewModel（数据模型）组成。

    MVVM架构模式在Android主要就是针对MVP进一步封装，通过谷歌提供的ViewModel，LiveData，databinding组合的Jetpack框架，实现更加清晰化代码。通过对ViewModel层的封装：封装业务逻辑处理，封装网络处理、封装数据缓存等，让逻辑处理分离出来，并且不需要处理Model数据，使得Controller层或者View层结构简单，条理清晰。

        乍一看，MVVM和MVP其实就是一回事，View层和Model层都是有的，连接两层的中间部分，在MVP中叫做Presenter，在MVVM中叫做ViewModel。我刚开始看到这两个概念的时候以为就是一回事，其实用了谷歌的JetPack框架以后，感觉还是多少有点区别，ViewModel更像是连接数据和View中间层，但是他本身不包含任何View的对象，仅做业务逻辑，View层更像是加入了观察者模式一样，View的显示被动的跟着ViewModel业务处理的结果做展示，而在MVP中，View的一举一动，其实都是Presenter在响应和控制，主动的去做。

       举一个事件的例子：在MVP中，点击事件，View的点击首先由View层获取，然后调用Presenter层处理，或者直接View处理不再往Presenter下发。在MVVM中View的点击事件首先是在ViewModel中响应，但是具体的改编数据往Model层执行，还是说跳转页面由View层的Activity/Fragment处理。这么比较发现MVP模式存在一个问题，本层就把一个业务逻辑全处理了，这样看耦合度还是高。

      总结：

              MVC，MVP，MVVM在Android上来看其实都是多少都有点硬套的嫌疑，毕竟MVC诞生于PC时代，那时候还没有Android，而写过IOS的小伙伴，都知道IOS开发用MVC其实就很好。网上搜MVC，MVP，MVVM在前端，IOS等其他地方也是很多实践的理论和框架，各有各的说法。

        我个人看法，遵循一个主原则 数据源--->业务逻辑处理--->展示或者是展示--->业务逻辑--->数据源，框架在好，无非就是一个解耦的变种，本质都是MVC，就像冯诺依曼提出的电脑必须的五个组件一样，再怎么倒腾也是必须得有这五个基本组件，跳不出这个圈子。

        Android的四个组件，看MVC，MVP，MVVM无非就是来回倒腾Activity的定位，不断的把它往View层划分靠拢，在往View层靠拢的时候，尽可能的剥离业务和减少它做负责的业务逻辑而已。