架构设计的目的
通过设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率，并且更容易进行后续的测试以及定位问题。但设计不能违背目的，对于不同量级的工程，具体架构的实现方式必然是不同的，切忌犯为了设计而设计，为了架构而架构的毛病。
举一个例子
一个Android App如果只有3个Java文件，那只需要做点模块和层次的划分就可以，引入框架或者架构反而提高了工作量，降低了生产力；
但如果当前开发的App最终代码量在10W行以上，本地需要进行复杂操作，同时也需要考虑到与其余的Android开发者以及后台开发人员之间的同步配合，那就需要在架构上进行一些思考！
MVC
MVC (Model-View-Controller)：M是指逻辑模型，V是指视图模型，C则是控制器。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式，而C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新，这与《设计模式》中的观察者模式是完全一样
为何用MVC
从用户的角度出发，用户可以根据自己的需求，选择自己合适的浏览数据的方式。 从开发者的角度，MVC把应用程序的逻辑层与界面是完全分开的，这样，界面设计人员可以直接参与到界面开发，程序员就可以把精力放在逻辑层上。而不是像以前那样，设计人员把所有的材料交给开发人员，由开发人员来实现界面
MVC的通信方式
Android中的MVC
1.视图层（View）：一般采用XML文件进行界面的描述，使用的时候可以非常方便的引入。
2.控制层（Controller）：Android的控制层通常是在Acitvity中实现。
3.模型层（Model）：对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的
MVP设计架构
在App开发过程中，经常出现的问题就是某一部分的代码量过大，虽然做了模块划分和接口隔离，但也很难完全避免。从实践中看到，这更多的出现在UI部分，也就是在Activity里。想象一下，一个2000+行以上基本不带注释的Activity，我的第一反应就是想吐。Activity内容过多的原因其实很好解释，因为Activity本身需要担负与用户之间的操作交互，界面的展示，不是单纯的Controller或View。而且现在大部分的Activity还对整个App起到类似IOS中的【ViewController】的作用，这又带入了大量的逻辑代码，造成Activity的臃肿。为了解决这个问题，让我们引入MVP框架。
MVC的缺点
在Android开发中，Activity并不是一个标准的MVC模式中的Controller，它的首要职责是加载应用的布局和初始化用户 界面，并接受并处理来自用户的操作请求，进而作出响应。随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。
什么是MVP
MVP (Model-View-Presenter)：MVP其实是由MVC演变而来的，其中的M依然是指逻辑模型，V依然是指视图模型，而P（中间桥梁）则代替了C成为了逻辑控制器的角色。
MVC和MVP到底有啥区别
区别就在于MVP中View并不直接使用Model，它们之间的通信是通过Presenter
(MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过
Controller。我们知道在MVC里，View是可以直接访问Model的。从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。
在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，即View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的
MVP的通信方式
MVP的优缺点
1、模型与视图完全分离，我们可以修改视图而不影响模型 2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部
3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑
MVVM的定义
MVVM(Model-View-ViewModel)：MVVM和MVP的区别其实不大，只不过是把presenter层换成了ViewModel层，再有就是View层和ViewModel层是相互绑定的关系，当我们更新ViewModel层的数据的时候，View层会相应的更新UI。
MVVM的通信方式
MVVM优点
• MVVM模式和MVC模式一样，主要目的是分离视图（View）和模型（Model），有几大优点 •
低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
• 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。 •
独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计。 •
可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写
被动的MVC
主动的MVC
