Android的三种开发模式
⼀、概述
和MVC框架模式⼀样，Model模型处理数据代码不变在Android的App开发中，很多⼈经常会头疼于App的架构如何设计： MVC、MVP和MVVM都是为了解决界⾯呈现和逻辑代码分离⽽出现的模式。经典的MVC模式是M-V-X模式的⽼祖宗，MVP和MVVM都是在MVC的基础上演化⽽来。
M-Model : 业务逻辑和实体模型(biz/bean) V-View : 布局⽂件(XML)。
C-Controllor : 控制器(Activity) MVC全名是Model View Controller，如图，是模型(model)－视图(view)－控制器(controller)的缩写，⼀种软件设计典范，⽤⼀种业务逻辑、数据、界⾯显⽰分离的⽅法组织代码，在改进和个性化定制界⾯及⽤户交互的同时，不需要重新编写业务逻辑。
其中M层处理数据，业务逻辑等；V层处理界⾯的显⽰结果；C层起到桥梁的作⽤，来控制V层和M层通信以此来达到分离视图显⽰和业务逻辑层。
2.Android中的MVC
Android中界⾯部分也采⽤了当前⽐较流⾏的MVC框架，在Android中：
视图层(View) ⼀般采⽤XML⽂件进⾏界⾯的描述，这些XML可以理解为AndroidApp的View。使⽤的时候可以⾮常⽅便的引⼊。同时便于后期界⾯的修改。逻辑中与界⾯对应的id不变化则代码不⽤修改，⼤⼤增强了代码的可维护性。
控制层(Controller) Android的控制层的重任通常落在了众多的Activity的肩上。这句话也就暗含了不要在Activity中写代码，要通过Activity交割Model业务逻辑层处理，这样做的另外⼀个原因是Android中的Actiivity的响应时间是5s，如果耗时的操作放在这⾥，程序就很容易被回收掉。
模型层(Model) 我们针对业务模型，建⽴的数据结构和相关的类，就可以理解为AndroidApp的Model，Model是与View⽆关，⽽与业务相关的）
。对数据库的操作、对⽹络等的操作都应该在Model⾥⾯处理，当然对业务计算等操作也是必须放在的该层的。就是应⽤程序中⼆进制的数据。
MVC缺点 ：MVC虽然将界⾯呈现和逻辑代码分离了，但是在实际的Android开发中并没有完全起到想要的作⽤。View对应的XML⽂件实际能做的事情很少，很多界⾯显⽰由Controllor对应的Activity给做了，这样使得Activity变成了⼀个类似View和Controllor之间的⼀个东西。如果是⼩型项⽬，MVC是没任何问题的。因为项⽬⽐较⼩嘛，开发周期⽐较短，Controllor臃肿点也可以理解。假设项⽬越来越来，尤其是再加上⽐较复杂的逻辑，这时候⼀个Activity⼏千⾏代码就⽐较蛋疼了，再加点迷之缩进，那酸爽~~啧啧。
所以MVC⽐较适⽤于快速开发的⼩型项⽬。
在Android开发中，Activity并不是⼀个标准的MVC模式中的Controller，它的⾸要职责是加载应⽤的布局和初始化⽤户 界⾯，并接受并处理来⾃⽤户的操作请求，进⽽作出响应。随着界⾯及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞⼤臃肿。
三、Android中的MVP
什么是MVP ？
MVP从更早的MVC框架演变过来，与MVC有⼀定的相似性：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显⽰。
M-Model : 业务逻辑和实体模型(biz/bean) V-View : 布局⽂件(XML)和Activity P-Presenter : 完成View和Model的交互
MVP框架由3部分组成：View负责显⽰，Presenter负责逻辑处理，Model提供数据。在MVP模式⾥通常包含3个要素（加上View interface是4个）：
View：负责绘制UI元素、与⽤户进⾏交互(在Android中体现为Activity)
Model：负责存储、检索、操纵数据(有时也实现⼀个Model interface⽤来降低耦合)
Presenter：作为View与Model交互的中间纽带，处理与⽤户交互的负责逻辑。
*View interface：需要View实现的接⼝，View通过View interface与Presenter进⾏交互，降低耦合，⽅便进⾏单元测试 Tips：*View interface 的必要性 回想⼀下你在开发Android应⽤时是如何对代码逻辑进⾏单元测试的？是否每次都要将应⽤部署到Android模拟器或真机上，然后通过模拟⽤ 户操作进⾏测试？然⽽由于Android平台的特性，每次部署都耗费了⼤量的时间，这直接导致开发效率的降低。⽽在MVP模式中，处理复杂逻辑的Presenter是通过interface与View(Activity)进⾏交互的，这说明我们可以通过⾃定义类实现这个interface来模拟Activity的⾏为对Presenter进⾏单元测试，省去了⼤量的部署及测试的时间。
MVC与MVP两种模式的主要区别： （最主要区别）View与Model并不直接交互，⽽是通过与Presenter交互来与Model间接交互。⽽在MVC中View可以与Model直接交互 通常View与Presenter是⼀对⼀的，但复杂的View可能绑定多个Presenter来处理逻辑。⽽Controller是基于⾏为的，并且可以被多个View共享，Controller可以负责决定显⽰哪个View Presenter与View的交互是通过接⼝来进⾏的，更有利于添加单元测试。
相较于MVC MVP的优点：
在MVP中，Model(IUserModel的实现类)的改动不会影响Activity(View)，两者也互不⼲涉，⽽在MVC中会； 在MVP中，IUserView这个接⼝可以实现⽅便地对Presenter的测试； 在MVP中，UserPresenter可以⽤于多个视图，但是在MVC中的Activity就不⾏。
因此我们可以发现MVP的优点如下：
1、模型与视图完全分离，我们可以修改视图⽽不影响模型；
2、可以更⾼效地使⽤模型，因为所有的交互都发⽣在⼀个地⽅——Presenter内部；
3、我们可以将⼀个Presenter⽤于多个视图，⽽不需要改变Presenter的逻辑。这个特性⾮常的有⽤，因为视图的变化总是⽐模型的变化频繁；
4、如果我们把逻辑放在Presenter中，那么我们就可以脱离⽤户接⼝来测试这些逻辑（单元测试）。 具体到Android App中，⼀般可以将App 根据程序的结构进⾏纵向划分，根据MVP可以将App分别为模型层(M)，UI层(V)和逻辑层(P)。 具体到Android App中，⼀般可以将App根据程序的结构进⾏纵向划分，根据MVP可以将App分别为模型层(M)，UI层(V)和逻辑层(P)。 UI层⼀般包括Activity，Fragment，Adapter等直接和UI相关的类，UI层的Activity在启动之后实例化相应的Presenter，App的控制权后移，由UI转移到Presenter，两者之间的通信通过BroadCast、Handler或者接⼝完成，只传递事件和结果。 举个简单
的例⼦，UI层通知逻辑层（Presenter）⽤户点击了⼀个Button，逻辑层（Presenter）⾃⼰决定应该⽤什么⾏为进⾏响应，该哪个模型（Model）去做这件事，最后逻辑层（Presenter）将完成的结果更新到UI层。
尽管MVC设计的⾮常nice，但代码臃肿的问题仍然没有得到很好的解决，这个时候MVP就要登场了。可以看到MVP相对于MVC改动是⾮常⼤的。Activity直接当做View使⽤，代替MVC中C的是P-Presenter。对⽐MVC和MVP的模型图可以发现变化最⼤的是View和Model不在直接通信，所有交互的⼯作都通过Presenter来解决。既然两者都通过Presenter来通信，为了复⽤和可拓展性，MVP模式基于接⼝设计也就很好理解了。两者都通过Presenter来通信，好很多的好处，例如提⾼代码复⽤性啦、增加可拓展性啦、降低耦合度啦、代码逻辑更加清晰啦。但是、本来两个能直接通信的东西现在要通过第三⽅来通信，那势必会增加很多类。没错，MVP模式虽然很好，但是增加了很多的接⼝和实现类。代码逻辑虽然清晰，但是代码量要庞⼤⼀些。当刚接⼿⼀个烂尾的MVP模式，如果事先没了解过MVP，会不会⼀脸的懵逼。所以MVP⽐较适⽤于中⼩型的项⽬，⼤型项⽬慎⽤。
四、Android中的MVVM
M-Model : 实体模型(biz/bean) V-View : 布局⽂件(XML) VM-ViewModel : binder所在之处，对外暴露出公共属性，View和Model的绑定器MVVM可以算是MVP的升级版，其中的VM是ViewModel的缩写，Vie
mvc的controllerwModel可以理解成是View的数据模型和Presenter的合体，ViewModel 和View之间的交互通过Data Binding完成，⽽Data Binding可以实现双向的交互，这就使得视图和控制层之间的耦合程度进⼀步降低，关注点分离更为彻底，同时减轻了Activity的压⼒。 有的读者该说了，你作⽤这不是和MVC⼀样嘛！是的，对应的⽂件看起来确实是⼀样的，但是作⽤不同。MVVM和MVP⼀样，View和Model不允许直接交互。只能通过ViewModel。MVVM神奇的地⽅在于通过ViewModel隔离了UI层和业务逻辑层，降低程序的耦合度。⽽且，布局⽂件⾥可以进⾏视图逻辑！并且Model发⽣变化，View也随着发⽣变化。布局⽂件⾥居然还能写逻辑！
MVC->MVP->MVVM演进过程 ：
MVC -> MVP -> MVVM 这⼏个软件设计模式是⼀步步演化发展的，MVVM 是从 MVP 的进⼀步发展与规范，MVP 隔离了MVC中的 M 与 V 的直接联系后，靠 Presenter 来中转，所以使⽤ MVP 时 P 是直接调⽤ View 的接⼝来实现对视图的操作的，这个 View 接⼝的东西⼀般来说是showData、showLoading等等。M 与 V已经隔离了，⽅便测试了，但代码还不够优雅简洁，所以 MVVM 就弥补了这些缺陷。在 MVVM 中就
出现的 Data Binding 这个概念，意思就是 View 接⼝的 showData 这些实现⽅法可以不写了，通过 Binding 来实现。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。