关于Android架构模式
为什么我们要使用架构模式呢？
首先我们说一下我们知道的Android有哪些呢？
MVC MVP MVVM 三种架构模式
我们使用架构模式基本上都是为了降低耦合性 使Android工程师在开发的时候只需要关注一点就可以,提高了工作的效率。
如果说你认为使用架构模式就会让你的代码量变少的话,那你就大错特错了,使用架构模式并不是说让你的代码量变少,有时候还会比之前得代码要多。架构模式是为了帮助我们在逻辑上边的更简单,很好的定义单一原则,下次修改的时候就可以直接找到某一个模块进行修改就可以，大大的提高了我们工作的效率。方便定位问题以及后续需求变更时不至于需要去改一大堆东西。
MVC
MVC （Model-View-Controller）我们最常见的架构 也是很容易理解的
视图层(View)
对应于XML布局文件
控制层(Controller)
Android的控制层是由Activity来承担的，Activity本来主要是作为初始化页面，展示数据的操作，但是因为XML视图功能太弱，所以Activity既要负责视图的显示又要加入控制逻辑，承担的功能过多。
模型层(Model)
我们针对业务模型，建立的数据结构和相关的类，它主要负责网络请求，数据库处理，I/O的操作。
image.png
在Android 开发当中我们都知道Activity并不是控制层(Controller) 但是在这个模式中Activity却被我们当做控制层使用,本来它的首要职责是加载应用的布局和初始化用户界面，接受并处理来自用户的操作请求，进而作出响应。在MVC模式下随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。
MVP
MVP 是 Model-View-Presenter
Model：业务逻辑和实体模型，用来操作实际的数据，包含 Bean 和 Model 的抽
象接口 来降低耦合。
View：就是 Android 中的视图，需要建立一个 View 的抽象接口 View Interface。
通过实 现 View 的接口来实现 View 与 Presenter 的交互，从而降低耦合。对应于
Activity， 负责 View 的绘制与用户交互；
Presenter：View 和 Model 的中间枢纽，处理和用户交互的逻辑。
image.png
Activity/Fragment 只充当视图层，不做任何的业务逻辑，将业务逻辑全部放在
业务层，由 Presenter 和 Model 进行交互，避免 Model 直接操作 View。以达到
解耦的效果。
MVP的优点:
1.模型与视图完全分离，我们可以修改视图而不影响模型；
2.项目代码结构（文件夹）清晰，一看就知道什么类干什么事情；
3.我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑，这个特性非常的有用，因为视图的变化总是比模型的变化频繁
4.协同工作（例如在设计师没出图之前可以先写一些业务逻辑代码或者其他人接手代码改起来比较容易）;
5.代码灵活性
MVP的缺点：
Presenter层与View层是通过接口进行交互的，View层可能会有大量的接口，因为有可能好几个Activity都是去实现同一个View接口，那么所有用到的Activity都要去实现所有的方法(不管你是否用到)，而且如果后面有些方法要删改，Presenter和Activity都要改动，比较麻烦；
MVP 使用特点是面向接口编程（View/Presenter/Model 都定义一套接口）。
MVVM
MVP中我们说过随着业务逻辑的增加，UI的改变多的情况下，会有非常多的跟UI相关的 Case，这样就会造成View的接口会很庞大。
而MVVM就解决了这个问题，通过双向绑定的机制，实现数据和UI内容，只要想改其中一方，另一方都能够及时更新的一种设计理念，这样就省去了很多在View层中写很多 Case 的情况，只需要改变数据就行。
Model：
Model层就是职责数据的存储、读取网络数据、操作数据库数据以及I/O，一般会有一个ViewModel对象来调用获取这一部分的数据。
View：
我感觉这里的View才是真正的View，为什么这么说？View层做的仅仅和UI相关的工作，我们只在XML、Activity、Fragment写View层的代码。
View层不做任何业务逻辑、不涉及操作数据、不处理数据、UI和数据严格的分开。
ViewModel：
ViewModel 只做和业务逻辑和业务数据相关的事，不做任何和UI、控件相关的事，ViewModel 层不会持有任何控件的引用，更不会在ViewModel中通过UI控件的引用去做更新UI的事情。
ViewModel就是专注于业务的逻辑处理，操作的也都是对数据进行操作，这些个数据源绑定在相应的控件上会自动去更改UI，开发者不需要关心更新UI的事情。
image
MVVM 的缺点是数据绑定使得 Bug 很难被调试。
你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。
数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
不管是用哪种设计模式，只要运用得当，都可以达到想要的结果。如果非要说怎么选的话，建议如下：
1.如果项目简单，没什么复杂性，未来改动也不大的话，选择常用的 MVC 就可以了，注意将每个模块封装好，方便调用即可。
2.对于偏向展示型的 APP，绝大多数业务逻辑都在后端，APP 主要功能就是展示数据，交互等，建议使用 MVVM。
3.对于工具类或者需要写很多业务逻辑 APP，使用MVP或者MVVM都可。
