1、架构设计目的
经过设计使程序模块化，作到模块内部的高聚合和模块之间的低耦合，这样作的好处是使得程序在开发的过程当中，开发人员只须要专一于一点，提升程序开发的效率，而且更容易进行后续的测试以及定位问题。前端
对于不一样量级的工程，具体架构的实现方式必然是不一样的，因此对于移动端来讲，逐渐演变出MCV、MVP、MVVM三种结构模式。android
2、MVC架构模式
一、工做模块
- View（视图）:界面渲染
- Controller（控制器）: 业务逻辑处理
- Model（模型）:数据提供
二、工做流程
- View将请求转交给Controller
- Controller操做Model进行数据更新
- 数据更新以后，Model通知View数据变化
- View显示更新以后的数据
三、架构缺陷
MVC看似各施其职，互不干涉，可是互联网发展了不少年了，随着业务不断的迭代，复杂度不断的提升，MVC模式的缺陷也被愈来愈多的开发者们所诟病。git
在Android早期开发中使用的是都是MVC架构，这是一种非标准的MVC架构，Controller和View并无解耦，由于Activity或Fragment既承担Controller的角色，又承担了View的角色。由于UI的更新几乎都是在Activity或Fragment中进行，一旦工程的量级上来，就会致使Controller层变得及其臃肿且难以维护。github
因为 Controller 和 View 的揉合，回调嵌套太多，代码逻辑不清晰，难以理解且不利于后期维护，各层次模块之间职责不清晰等等。数据库
3、MVP架构模式
在2016年，Google 推出了 MVP 架构，MVP是从经典的MVC模式演变而来。在尝试使用的过程当中发现这种架构模式能解决如今所面临过的不少问题。编程
一、工做模块
- View（视图）: 界面渲染
- Presenter（调度器）: 业务逻辑处理
- Model（模型）: 数据提供
二、工做流程
- View将请求转交给Presenter
- Presenter操做Model进行数据请求
- 数据更新以后，Model通知Presenter数据发生变化
- Presenter更新View的数据
三、设计优点
明显能够看到，MVP和MVC最大的不一样之处是View与Model彻底隔离，这就意味着，在Android开中，就能够明确的把Activity看成View处理,而不须要多承担Controller的做用，Controller和View彻底解耦。若是Model或View中的一方发生变化，只要交互接口不变，另外一方就不必对上述变化作出改变，使得Model层的业务逻辑具备很好的灵活性和可重用性，耦合性下降。对于后期维护来讲，特别是项目愈来愈庞大时，能够很快的梳理出项目结构，很方便的进行管理。设计模式
下面经过几段实例代码来体现一下MVP模式的事件流服务器
首先要定义几个事件接口来做为view和presenter之间的契约。架构
在MVP模式中，View层只负责数据的渲染和展现，因此对于事件的监听，咱们统一经过接口的形式交给Presenter进行接管，数据更新的时候，咱们又经过接口的形式将数据回调给View层进行更新。模块化
Presenter层则会驱动Model拿到最新的数据，咱们也能够经过泛型封装去简化掉Model层，由于咱们主要的目的是将Controller和View进行解耦，经过Presenter做为中间桥梁进行通讯。当数据更新时，Presenter又会将数据经过接口通知给View，构建了一条简单的MVP模式的数据链路。
四、架构缺陷
尽管这样，MVP模式仍是有不足之处。由于Presenter层与View层是经过接口进行交互的，若是好几个Activity都是去实现同一个View接口，这就致使View层可能会有大量的接口，那么无论你是否用到，全部用到的Activity都要去实现该接口的全部方法；若是对Activity去进行实现单一View接口维护的话，每个View都要去建立对应的Presenter和View接口。会致使出现大量的类，你的工程体系将会变得很庞大，以下图：
另外，对于一些业务比较复杂的界面，你的Presenter须要去实现不少的接口，这样会致使Presenter层太大，逻辑比较复杂，代码臃肿的依然是个问题。
4、MVVM架构模式
MVVM架构模式目前普遍的用于移动端和前端的开发，大名鼎鼎的Vue响应式编程用的就是这种设计，其双向绑定更是将观察者模式完美得体现。
一、工做模块:
- View（视图）: 界面渲染
- ViewModel（调度器）: 业务逻辑处理
- Model（模型）: 数据提供
二、工做流程:
- 在View中来绑定事件和响应事件，进行事件的触发
- ViewModel操做Model的去获取数据
- Model去请求数据
- 服务器或数据库将数据返回到Model层中
- ViewModel在回调中收到返回的实体类对象
- 实体类更新，驱动UI更新
三、设计优点
在MVVM中，数据是核心，因为VIewModel与View之间的双向绑定，操做了ViewModel中的数据，就会同步到DOM，咱们透过DOM事件监控用户对DOM的改动，也会同步到ViewModel，很好作到数据的一致性。不只如此，由于双向绑定的存在，View的功能进一步强化，Controller的功能大都移动到了View上处理，大大的简化Controller，业务复杂、代码臃肿的问题获得了解决。
四、架构缺陷
了解MVVM以后，咱们会发现双向绑定确实简化了控制层，可以适用于复杂的业务场景，保证了数据的一致性的同时，也大大的增长了Model层。若是长期持有，不释放内存就形成了花费更多的内存，处理不当，就会致使内存溢出或内存泄露的问题出现。
移动端开发最经常使用的重用是View，可是数据双向绑定技术，让你在一个View都绑定了一个Model，不一样模块的Model都不一样，就会致使不利于代码重用。
5、总结
从 MVC 架构模式到 MVVM， 这几个软件设计模式是一步步演化发展的，从分离展现层到展现模型层，通过这么长时间的发展和演变，MVC 架构模式出现了各式各样的变种，并切在不一样的平台上有着本身的表现，下面是对三种架构模式的统一对比：
| 模式 |
优点 |
缺陷 |
| MVC |
模块独立，组件重用 |
一、Controller和View耦合度高 二、逻辑回调和嵌套复杂 |
| MVP |
一、Controller和View彻底解耦 二、方便大型项目管理 |
一、接口泛化、难以维护 二、Presenter层代码臃肿 |
| MVVM |
双向绑定，简化业务代码 |
|
有些Android开发工程师认为为了双向绑定而使用MVVM模式显得很生硬，对于大型项目的协同开发，“MVP+组件化”开发则有着自然的优点，更有人说Google的AAC架构更好用。对此我不作评价，由于没有最好的，只有适合的。每一个平台自己每每对应用层有着本身的设计。场景不一样，选择不一样，可是目的都是同样的，都是为了解决复杂度，提供高性能、高可用、可扩展的应用。