MVC

MVC简单来说就是将整个应用氛围Model、View和Controller三个部分

视图(View)：管理作为位图展示到屏幕上的图形和文字输出。
控制器(Controller):翻译用户的输入并依照用户的输入操作模型和视图。
模型(Model)：管理应用的行为和数据，响应数据请求(经常来自视图)和更新状态的指令(经常来自控制器)。

MVC架构

从上图可以看出来View层需要Controller发起时间通知View然后View从Model获取数据，这在APP中是较难实现的，我们的时间往往是由Activity或View发起并主导的，如果将时间的发起与控制权交由Controller处理的话经常会出现一些意想不到的问题，如内存泄露等，这就导致了MVC的变种MVP的出现，Android本身的设计还是符合MVC架构的，但是Android中纯粹作为iew的XML视图功能太弱，这样Activity就从当了View和Controller两个角色，直接导致Activity里的代码量大爆炸。所以更贴切的说法是，这个MVC结构最终其实只是一个Model-View(Activity:View&Controller)的结构

MVP

MVP架构是MVC的一个变种，很多架构都自称遵循MVC架构模式，但是他们实际上却实现了MVP模式。
MVC和MVP之间的区别其实并不明显，我认为两者之间的最大区别就是View层可以发起事件。

MVP架构

在MVP中，Presenter可以理解为松散的控制器，其中包含了视图UI业务逻辑，所有从视图发出的时间都会通过代理给Presenter进行处理，同时，Presenter也通过视图暴露的接口进行通信。

APP中的应用

在MVC中，控制器负责以不同的视图相应客户端请求的不同动作，然而不同于MVC模式，MVP中视图将所有的动作交给Presnter进行处理，MVC中所有的动作都对应着一个控制器的方法调用，Web应用中没一个动作都是对某一个URL进行的操作，控制器根据访问的陆游和方法(GET等)对数据进行操作，最终选择正确的视图

MVC中控制器返回的视图没有直接绑定到模板上，它仅仅被控制器渲染并没有完全无状态的，其中不包含任何的逻辑，但是MVP中视图必须要将对应的事件代理给Presenter执行，否则事件就无法被响应。

上述内容取自what are MVP and MVC and what is the difference? Stack Overflow 中的Model-View-Controller部分。

从这里可以看出，Presenter层的出现帮助我们减轻了Activity的压力，结构上也较为清晰，但是View层将存在较多与Presenter沟通的代码这是我们较为不希望看到的结果，MVVM架构在这种情况下被提了出来。

MVVM

MVVM架构模式是微软在2005年诞生的，第一次进入Android人员视野是从Google2015退出DataBinding组件开始，后续Google不断的退出了ViewModels、LivewData、Android Loader、Lifecyycles等适用于MVVM架构的组件，有次可见Google已经"钦定"MVVM是Android开发未来的第一架构了。

MVVM架构

从Model-View-ViewModel这个名字来看，它由三个部分组成，也就是Model，View和ViewModel，其中视图模型(ViewModel)其实就是PM模式中的暂时模型，在MVVM中叫做视图模型。
除了我们非常熟悉的Model、View和ViewModel这三个部分，在MVVM的实现中，还引入了隐式的一个Binnder层，而声名式的数据和命令的绑定在MVVM模式中就是通过它完成的。

Binder层

MVVM架构将Presenter改名为ViewModel，基本上与MVP模式完全一致，唯一的区别是，它采用双向绑定(data-binding)View的变动，自动反映在ViewModel,反之亦然，折旧导致了我们如果要完整的采用MVVM必须熟练的掌握DataBinding等基础组件，这就给我们将MVVM引入项目带来了困难。

AndroidFlux

AndroidFlux是Facebook的Flux架构的Android实现。Flux是Facebook在14年提出的一种Web前端架构，主要
用来处理复杂的UI逻辑的一致性问题(当时是为了解决Web页面的消息通知问题)。经过实践之后发现，这种架构可以很好的应用在Android平台，相当于其他的MVC/MVP/MVVM等模式，拥有良好的文档和更具体的设计，比较适合于快速开发实现。Flux模式最大的特点是单向的数据流，它的UI状态更新模式继承了MVC模式的设计思想。Flux并不是具体的框架，二十一套处理UI问题的模式，AndroidFlux同样不是具体的框架，二十一套处理UI问题的模式，AndroidFlux同样不是具体的框架，你不予要导入或集成任何新的代码就可以使用，而你需要做的事情是了解这套思想、遵循这种开发模式。

AndroidFlux架构

AndroidFlux的架构设计很容易让我们想到函数式响应编程，而且AndroidFlux一直在强调它自己本身并非某种具体框架二十一种UI或者说数据流的走向，这个很想我们熟知的RxJava设计思路，所有事件UI都可以当做为一个数据流并加以处理。

AndroidFlux的数据流动

只有一个Dispatcher在AndroidFlux应用中Dispatcher是中心枢纽，管理所有的数据流，它实际上管理的是Store注册的一系列回调接口，本身没有其他逻辑--它仅仅是用来把Action发送到各个Store的一套简单的机制。每个Store都会把自己注册到这里，并提供自己的回调方法。当ActionCreato给Dispatcher传递一个Action的时候，应用中所有的Store都会通过回调接口收到通知。
随着App的增长，Dispatcher会变得更加重要，它可以通过调整回调方法的触发次序来管理Store之间的依赖关系。Store可以声明等待其他Store更新完毕再更新自己。

Stores

Store包含应用的状态(State)和逻辑(Logic)。它扮演的角色和MV模式中的Model没类似，但是它会管理多个对象的状态--它不是像ORM-Model一样的单独的数据集。
忧郁AndroidFlux是一串的语法、结构贵方，他并没有什么组件来协助我们开发，所以使用AndroidFlux的难度交稿，暂时不考虑在中、小型团队中的应用，仅仅作为一个知识扩展。