1.MVC框架模式
MVC的全名是模型视图控制器。
即-model-view-controller，它显示由业务逻辑、数据和接口分开的手段来组织代码。
MVC框架模式是Trygve Reenskaug于1978年在Smalltalk-80系统中首次提出的。 让我们看看Reenskaug为分析MVC模式而绘制的图。
mvc
另外，Reenskaug还介绍了MVC :
Model: Model可以是独立对象，也可以是一组对象的集合。
视图：视图是模型中重要数据的视觉表示；
控制器：控制器用于连接用户和系统。 例如，当控制器收到用户的输出时，它将转换为相应的事件消息，并将该事件消息传递给一个或多个视图。
经典MVC框架模式比较
如下图所示
古典音乐
模型层：
在存储数据、网络请求等程序需要操作的数据或信息(系统中的业务逻辑部分)的同时，Model和View也存在一定的耦合，通过观察者模式等某种事件机制，View的状态Model从控制器接收事件，Model允许View查询相关数据并显示其状态。
视图层：
它是直接面向最终用户的视图层，提供给用户操作界面，是Model的具体表情形式，是程序的外壳。 该层只负责显示数据，主要由各种GUI组成。 它还响应用户交互启动控制器逻辑，View通过在Model中注册事件并监听Model更改来更新自身并向用户显示。 例如，监听模型的位图图像，然后在加载或清除位图时，相应的视图显示不同的图像。
控制层：
控制器将根据用户行为启动View，响应来自View的交互，并根据View的事件逻辑更改相应的模型。 控制器不关心View如何显示数据和状态，而是更改模型，并通过模型事件机制启动View刷新。
下图显示了MVC在Android APP应用程序中负责的组件。
安卓的MVC组件
使用MVC的目的是分离m和v的实现代码，以便同一程序使用不同的表示形式。 Controller还旨在确保m发生变化，v同步更新。
在Android APP中，MVC是如何实现的？ 起着什么作用？
1.View接受用户交互请求。
2.View将请求转发到控制器。
3.Controller (用户执行的动作，例如数据更新、某个信息的删除等) )操作Model进行数据更新)按照用户的指示，执行基础数据的动作等)，
4 .数据更新后，模型会通知您视图数据的变化。
5.View显示更新后的数据。
MVC的优缺点及适用场景
好处：
1 .耦合性低，MVC的本质是分层解耦，较好地分离视图层和模型层，减少模块码之间的相互影响。
2 .可扩展性好，耦合降低，通过增加需求，扩展代码可以减少修改前的代码。 降低错误的发生率。
3 .模块角色划分明确，主要分为m、v、c三个模块，利用代码进行维护。
缺点：
1.View层和Model层相互了解，两层之间存在键。
2 .安卓开发，XML作为视图层的控制能力有限。 无论是作为控制层，还是作为视图层，Activity在接受用户的操作请求的同时，都不可避免地会隐藏视图进行展示。 活动类职责增加，日益肥大。
应用场景：
适用于功能少、业务逻辑简单、接口不复杂的小项目。
2.MVP框架模式
MVP的全名是Model View Presenter，这是MVC的进化版，常用的MVP结构如下图所示。
MVP框架模型图
模型(数据获取) :
Model角色主要提供数据访问功能，Presenter层需要通过Model层访问和检索数据。 Model就像一个数据仓库，更坦率地说，Model是数据DAO、封装网络以检索数据的角色或两种数据检索方法的集合。
用户界面(View ) :
View通常是指包含Presenter成员变量的Activity、Fragment或View控件。 View通常实现将View上的操作传递给Presenter实现的逻辑接口，Presenter调用View逻辑接口并将结果返回给View元素。
Presenter (交互式zqdgz ) :
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的构建和维护成本就会变的很高，不利于项目的发展。