1.MVC框架模式

MVC的全名是Model View Controller。
即-模型(model) - 视频(view) -控制器(controller),它通过业务逻辑,数据,界面显示分离的手段来组织代码.
MVC框架模式最早由Trygve Reenskaug 于1978年在Smalltalk-80系统上首次提出，我们来看下当时Reenskaug为解析MVC模式所绘制的一个例图：

mvc

同时，Reenskaug也给出了自己对MVC的介绍：
Model： Model可以是一个独立的对象，也可以是一系列对象的集合体；
View： View是Model中一些重要数据在视觉上的体现；
Controller： Controller用于连接User和System，比如当Controller接受到用户的输出时，会将其转换成合适的事件消息，并将该事件消息传递给一个或多个View；

比较经典的MVC框架模式

如下图

mvc经典

Model(模型层):

程序需要操作的数据或信息(系统中的业务逻辑部分),比如数据的存储、网络请求等，同时Model与View也存在一定的耦合，通过某种事件机制（如观察者模式）通知View状态改变或更新；Model还会接收来自Controller的事件，Model也会允许View查询相关数据以显示自身状态。

View（视图层）：

直接面向于最终用户的视图层，并提供给用户操作界面，是Model的具体表情形式，是程序的外壳。该层只负责展示数据，主要是由各种GUI组成，同时响应用户的交互行为并触发Controller的逻辑，View还会通过在Model中注册事件监听Model的改变以此来刷新自身并展示给用户（如监听Model中的Bitmap图像，当Bitmap加载或清除时，对应View展示不同的图像）。

Controller（控制层）：

Controller由View根据用户行为触发，并响应来自View的交互，然后根据View的事件逻辑修改对应的Model，Controller并不关心View如何展示数据或状态，而是通过修改Model并由Model的事件机制来触发View的刷新。
下图展示了MVC在安卓应用程序中由哪些组件担当。

Android中MVC组件

使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式，而Controller存在的目的则是确保M改变，V应该同步更新。
Android应用程序中，MVC是如何实现？都充当什么角色？
1.View接受用户的交互请求。
2.View将请求转交给Controller。
3.Controller（用户做的动作比如：更新数据，删除某条信息等）操作Model进行数据更新（根据用户指示，执行底层的数据动作等等），
4.数据更新后，Model通知View数据变化，
5.View显示更新之后的数据。

MVC的优缺点和适用场景

优点：
1.耦合性低，MVC本质是分层解耦，将View层与Model层很好的分离，减少模块代码之间的相互影响。
2.可扩展性好，由于耦合降低，添加需求，扩展代码就可以减少修改之前的代码。降低bug的出现率。
3.模块职责划分明确，主要划分M，V，C三个模块，利用代码维护。
缺点：
1.View层和Model层是相互可知的，两层之间存在耦合。
2.Android开发，XML做为View层控制能力是有限的，千万了Activity做为Contrller层又要做View层，接收用户操作请求的同时又不可避免的做些如让View隐藏展示的操作，Activity类的职责不断增加，会越来越臃肿。
适用场景：
适用于功能较少、业务逻辑简单、界面不复杂的小型项目。

２.MVP框架模式

MVP全称 Model View Presenter ，它是MVC的一个演化版本，常用MVP结构如下图。

MVP框架模式图

Model（数据获取）：

Model角色主要提供数据的存取功能，Presenter层需要通过Model层存取、获取数据，Model就像一个数据仓库，更直白的说Model是封装了数据DAO、网络获取数据的角色，或者是两种数据获取方式的集合。

View（用户界面）：

View通常指Activity，Fragment或者某个View控件，它含有一个Presenter成员变量，通常View实现一个逻辑接口，将View上的操作转交给Presenter来实现，Presenter将调用View逻辑接口将结果返回给View元素。

Presenter（交互中间人）：

Presenter主要作为View和Model的桥梁，它从Model层检索数据后，返回给View，使得View和Model之间没有耦合，也将业务逻辑从View层上抽离出来。
MVP并没有一个标准的模式它有很多实现方式，但我们只要保证：通过Preseter将View和Model解耦合，降低类型复杂度、各个模块可以独立测试、独立变化，这就是正确的方向。
个人觉得MVP最重要的实现方式是：分享View层和Model层，使它们通过接口进行通信，降低耦合；理想的MVP模式可以实现一份逻辑代码搭配不同的显示界面，因为它们之间不依赖具体的实现，而是依赖于抽象。也可以是同一个界面搭配不同的数据获取方式。
Android程序中，MVP框架是如何实现的？都充当什么角色？
1.View接受用户的交互请求。
2.View通过Presenter暴露的接口将请求转交给Presenter来进行处理。
3.Presenter通过Model暴露的接口对Model进行操作和更新。
4.Model改变后，将改变信息发送到Presenter。
5.Presenter通过View暴露接口对View进行视图更新。

MVP优缺点及适用场景

优点：
1.通过P层的转接避免业务逻辑放置在View，有效的降低View的复杂性。
2.View层和Model完全解耦，他们之间互不干扰，带来了良好的可拓展性，可测试性，保证了系统的灵活性和整洁性。
3.Activity、Fragment等仅做为View层，不会再出现MVC那种Activity又做View层又做Controller层的窘境，View层和Model层大大提高利用性。
4.我们可以将Presenter用于多个视图，而不需要改变Presenter的逻辑。这个也是理想的MVP模式。
5.由于各层分工明确，便于单元测试。
缺点：
1.MVP是以UI为驱动的模式，更新UI是需要保证能获取到控件的引用，同时更新UI也要考虑当前是否是UI线程。
2.复杂的业务也会导致P层太大，代码臃肿的问题依然不能解决。
3.MVP通过接口进行交互，接口粒度不太好设计和控制，粒度太小，就会存在大量接口，粒度太大，解耦效果就不好。
4.MVP数据都是被动地通过UI控件做展示，但是由于数据的时变性，我们更希望数据能由被动变为主动，使数据更有活性，由数据来驱动UI。
5.Activity需要实现各种跟UI相关的接口，同时要在Activity中编写大量的事件，然后在事件处理中调用presenter的业务处理方法，View和Presenter只是互相持有引用并互相做回调,代码不美观。
适用场景：适用于界面复杂、利用性高、功能中等、业务逻辑中等或是简单的项目。实际上MVP的思想很适合用于复杂的界面上，我们完全可以在项目中某一部分上使用MVP模式去实现。
官方例子：https://github.com/android/architecture-samples

Android中使用MVP需要注意的点：

1.更新UI时要考虑当前执行的线程是否在UI线程，也要考虑Activity的生命周期，判断好Activity是否已经被销毁。
2.P层如果需要执行耗时操，P层持有Activity、Fragment的强引用，在耗时结束操作结束前Activity已经被摧毁了，但由于P层一直持有Activity、Fragment的对象，导致Activity、Fragment无法被回收引起内存泄露，这里建议用弱引用和Activity、Fragment的destory()生命周期来处理。

3.MVVM框架模式

说到Android MVVM，大家都知道有DataBinding框架，但是其实不是相同的，MVVM是一种架构模式，而DataBinding是一个实现数据和UI绑定的框架，是构建MVVM模式的一个工具。
MVVM 全称Model View ViewModel，你可以把MVVM看做是MVP的一个改进版本，常用的MVVM结构图如下：

MVVM框架模式

Model：

Model主要是封装数据存储或操作一些逻辑，还会提供一系列的实体类用于UI绑定，ViewModel则会在修改这些数据后将数据改变告诉View层并更新UI。实例中，数据的获取、存储、状态变化都是Model层的任务。Model包括实体模型（Bean)、Retrofit的Service、获取网络数据接口，本地存储接口，数据变化监听等。Model提供数据获取接口供ViewModel调用，经数据转换和操作并最终映射绑定到View层某个UI元素的属性上

View：

View用于处理界面的逻辑且不参与业务逻辑相关的操作，只负责显示由ViewModel提供的数据，View层不做任何业务逻辑、不涉及数据操作、不处理数据，UI和数据严格的分开，对应于Activity和XML。

ViewModel：

ViewModel层做的事情刚好和View层相反，ViewModel只做和业务逻辑相关的事情，不做任何和UI有关的事情。ViewModel不会持有任何控件层的引用，更不会在ViewModel层中通过UI控件去更新UI。就是专注于业务逻辑的处理，做的事情也都只是对数据的操作（这些数据都与控件绑定，会自动更新UI）。同时DataBinding框架已经支持双向绑定。可以通过双向绑定获取View层反馈给ViewModel层的数据，并对数据进行操作。
MVVM的目标和思想与MVP类似，利用数据绑定（Databinding），打造了一个更加灵活的架构。
MVVM模式中，数据是独立于UI的，数据和业务逻辑处于一个独立的ViewModel中，ViewModel只需要关注数据和业务逻辑，不需要和UI或者控件打交道。UI想怎么显示数据都由UI自己决定，ViewModel不涉及任何UI相关的事，也不持有UI控件的引用，既然是控件变了（如：TextView换成EditText）,ViewModel也几乎不需要更改什么代码。它完美的解耦了View层和Model层，解决了MVP的痛点。
Android程序中，MVVM框架是如何实现的？都充当什么角色？
1.View接受用户交互请求。
2.View将请求转交给ViewModel。
3.ViewModel操作Model数据更新。
4.Model更新完数据，通知ViewModel数据发生变化。
5.ViewModel更新View数据。
其中更新view已经由Databinding完成。

MVVM的优缺点及适用场景

优点：
1.低耦合，数据和业务逻辑都是处理一个独立的ViewModel中，ViewModel只需要关注数据和业务逻辑，不需要View层打交道。
2.可重用性，你可以把一些视图逻辑放在一个ViewModel里面，让很多View重用这段视图逻辑。
3.可分开独立开发，MVVM的分工非常明显。由于View和ViewModle之间是松散耦合的，一个处理业务和数据，一个专门处理UI，所以，完全可以由两个人分工来做，一个做UI，一个写ViewModel（待验证）
4.由于各层分工明确。便于单元测试（待验证）
5.相对于MVP而言，MVVM不需要手动处理大量的View和Model相关操作，完美的解耦了View层和ViewModel。
6.不需要findViewById也不需要butterknife.
7.View和Model的双向绑定是支持生命周期检测的，不会担心页面销毁了还有回调发生，这个由lifeCycle完成
8.不会像MVC一样导致Activity中代码量巨大，也不会像MVP一样出现大量的View和Presenter接口。项目结构更加低耦合
缺点：
1.数据绑定使得bug很难被调试。
2.对于过大的项目，数据绑定要花费更多的内存。
3.过于简单的界面，有点大才小用了。
适用场景：
MVVM是不适用于简单的界面和极度复杂的界面，在界面简单的情况下，MVVM反而将我们的逻辑复杂化了，而界面元素过多，相对应的ViewModel的构建和维护成本就会变的很高，不利于项目的发展。