Part 01
架构的概念
在移动端开发中，一般将代码分为三个部分：UI逻辑，业务逻辑和数据操作逻辑。
Android的架构就是希望达到这样的目的：
1.降低代码之间的耦合率，使团队可以清晰的划分各自的任务，提高开发效率；
2.使代码逻辑清晰，提高代码的可读性与可维护性；
3.减少重复代码，提高开发的效率，避免重复造轮子。
为了达到以上的目的，涌现出了许多的架构。谷歌官方也推出了自己的架构组件，用成熟的框架来减少样板代码，提高开发效率，犹如SpringMVC的风范，这就是MVVM的框架实现。下面我们来简单认识一下这几种架构。
Part 02
MVC
MVC架构应该是每个Android第一次进行开发时所使用的架构。View层负责页面的显示，与用户的交互，获取用户的操作。Controller负责接收用户的操作并处理业务逻辑。Model层则负责数据处理，网络请求及可能涉及到的本地数据库操作等。MVC的本质就是按照UI逻辑、业务逻辑、数据逻辑不同的职责分三大模块，彼此分工。
在Android开发中，View一般由xml文件表现。但是由于xml的能力不足，我们对于ui处理的逻辑被放在了activity中。同时关于controller的业务逻辑代码，一部分也放在了activity中，与model层的交互便在此中进行。
由此带来了MVC架构的问题与弊端，在activity中会同时包含我们的ui和业务逻辑代码。随着项目的变大和页面的复杂，在activity中的代码会变得越来越多，越来越复杂，难以维护。同时view直接持有controller和model实例，不同职责的代码进行耦合，导致代码耦合性高，模块分工不清晰。各功能模块之间互相粘连，当想更新或者处理一些bug的时候会非常困难。
同时MVC架构的好处便是我们不需要写大量的隔离代码用来解藕。当我们面对一些简单的页面和需求快速响应的需求时，它可以帮助我们快速完成。
从中我们也能看到MVC下一步需要进化改进的方向：
1.加强view与model之间的解藕，使它们减少互相持有。
2.减轻controller的冗杂程度，减重以提高可维护性和可读性。
由此我们来介绍下一种架构。
Part 03
MVP
MVP全名是Model-View-Presenter。与mvc模式相比，它具有更好的可扩展性和可维护性，代码间的耦合程度更低。View层负责页面的显示，与用户的交互，获取用户的操作。Model层则负责数据处理，网络请求及可能涉及到的本地数据库操作等。它们的职责都没有变化，不同的地方在于Presenter：它负责业务逻辑，起着连接View和Model桥梁的作用。
为了解决mvc中代码耦合程度高的问题，我们将业务逻辑都抽离出来放入Presenter中，这样我们的Model和View实现了完全的隔离，实现了单向依赖。在View和Psenter之间使用接口来通信，这样我们可以按照功能或者需求来划分各自的模块，同时进行开发。同样在我们有需要时，我们也可以更换单独某个模块而不影响同一页面中其他模块的运行，这是mvc所不具有的。
看上去mvp已经实现了我们的需求，但它也有自己的问题。因为在我们的实际开发过程中，每个页面或多或少都会有所差异即没有两个完全相同的页面，这也就导致了我们每个activity都需要一个自己的Presenter及配套的接口，这使得我们需要写大量的代码对其进行解藕，当面对小型的项目时这反而影响了我们的开发效率，同时controller臃肿的问题依然存在，解藕的程度还是不够深。由此我们来介绍下一种架构。
Part 04
MVVM
MVVM，全名为Model-View-ViewModel。View层负责页面的显示，与用户的交互，获取用户的操作。Model层则负责数据处理，网络请求及可能涉及到的本地数据库操作等。它们的职责依然没有变化。ViewModel：负责存储view的数据映像以及业务逻辑。
MVVM模式中的重点就是viewmodel，它通过绑定的方式将view与model一一对应，将数据的变化直接显示在我们的view上，彻底抛弃掉了MVP的Presenter中的ui逻辑操作。我们也不再需要单独编写接口进行通信。之前的业务逻辑也放在了viewmodel之中。这样的方式使得我们的视图与业务完全解藕，view专注于ui操作，viewmodel专注于业务操作，这就是数据驱动的思想。
要想实现这样的效果我们还需要一个简单容易上手的框架来帮助我们进行view与viewmodel之间的绑定和减轻viewmodel中业务逻辑操作过于复杂的部分。由此谷歌官方推出了mvvm框架和与之一起使用的jetpack架构组件库，包括了：DataBinding，LiveData，ViewModel，Navigation，Lifecycle。
MVVM与MVC、MVP最大的差异便是MVVM是由数据驱动，专注于页面开发的架构模式，更像谷歌官方推出的专注于移动端开发的架构。不同于其余两种，MVVM的开发需要页面的存在，这也导致了它的使用被限制在了页面开发当中，我们无法在插板洗衣机上进行开发。因为没有数据对象与页面可言。
Part 05
总结
通过以上介绍我们可以发现，没有完美无缺的框架，只有场景中最合适的框架。每一个框架的诞生都是伴随着我们对某个特殊场景或者某些场景下的特殊问题的需求。例如Android中的问题便是ui与业务逻辑的解藕。但当我们面对一些小型项目，快速需求或者没有页面显示的需要时，MVVM显然也不是我们的最优解。我们需要学习的是对需求的拆分与理解，选择最合适我们项目的框架。
