当开发人员在真实的移动应用程序上工作时，该应用程序的性质是动态的，并将根据用户的需求扩展其功能，那么就不可能在活动或片段中编写核心逻辑。为了构造项目的代码并给予模块化设计(分离的代码部分)，应用体系结构模式来分离关注点。开发人员使用的最受欢迎的android架构如下：
- MVC(模型-视图-控制器)
- MVP(模型—视图—演示者)
- MVVM(模型—视图— ViewModel)
所有这些模式的主要思想是以适当的方式组织项目，以便所有代码都包含在单元测试中。而且，在软件的维护，添加和删除功能方面非常有帮助，开发人员可以跟踪各种关键的逻辑部分。
模型-视图-控制器(MVC)模式
MVC模式是最古老的android应用程序体系结构，它仅建议将代码分为3个不同的层：
- 型号：用于存储数据的层。它负责处理域逻辑(实际业务规则)以及与数据库和网络层的通信。
- 查看： UI(用户界面)层。它提供了存储在模型中的数据的可视化。
- 控制器：包含核心逻辑的层。它会通知用户的行为，并根据需要更新模型。
在MVC模式中，视图和控制器都取决于模型。控制器会更新应用程序数据，View会获取数据。在这种模式下，模型可以独立于UI进行测试，因为它是分开的。有多种方法可以应用MVC模式。活动和片段都可以充当控制器，在其中它们负责数据处理和更新视图。另一种方法是将活动和片段用作“视图”，并且控制器以及模型应该是一个单独的类，该类不能扩展任何Android类。如果视图遵守单一职责原则，那么它们的作用只是为每个用户事件更新Controller，并仅显示来自Model的数据，而无需实现任何业务逻辑。在这种情况下，UI测试应该足以涵盖View的功能。
好处：
- MVC模式增强了代码的可测试性，并且由于它高度支持关注点分离，因此使其更易于实现新功能。
- 由于Model和Controller不扩展或不使用任何Android类，因此可以进行单元测试。
- 如果View遵守单一职责原则，则可以通过UI测试来检查View的功能(更新控制器并显示来自模型的数据，而无需实现域逻辑)
缺点：
- 即使正确应用了MVC，代码层也相互依赖。
- 没有用于处理UI逻辑的参数，即如何显示数据。
模型—视图—演示器(MVP)模式
MVP模式是Android应用程序体系结构的第二次迭代。这种模式已被广泛接受，并仍建议新的开发人员使用。每个组件的目的都很容易学习：
- 型号：用于存储数据的层。它负责处理域逻辑(实际业务规则)以及与数据库和网络层的通信。
- 查看： UI(用户界面)层。它提供数据的可视化并跟踪用户的操作，以便通知Presenter。
- 演示者：从模型中获取数据并应用UI逻辑来决定要显示的内容。它管理视图的状态，并根据用户从视图中输入的通知执行操作。
在MVP架构中，View和Presenter是紧密相关的，并且相互引用。为了使代码易读且易于理解，使用Contract接口类定义Presenter和View关系。视图是抽象的，并具有一个接口，以使Presenter能够进行单元测试。
好处：
- android组件中没有概念关系
- 由于应用程序的模型，视图和演示者层是分离的，因此易于代码维护和测试。
缺点：
- 如果开发者不履行单一责任 破坏代码的原理，然后Presenter层倾向于扩展为一个巨大的全知类。
模型-视图-视图模型(MVVM)模式
android体系结构的第三次迭代是MVVV模式。在发布Android体系结构组件时，Android团队推荐了这种体系结构模式。以下是单独的代码层：
- 模型：该层负责数据源的抽象。 Model和ViewModel一起工作以获取和保存数据。
- 视图：该层的目的是向ViewModel通知用户的操作。
- ViewModel：它公开了与View相关的那些数据流。
MVVM和MVP模式非常相似，因为它们都可以有效地抽象化View层的状态和行为。在MVVM中，视图可以将自身绑定到ViewModel公开的数据流。
在MVVM模式中，视图将各种操作通知给ViewModel。视图有对ViewModel的引用，而ViewModel没有有关视图的信息。 View与ViewModel和MVVM之间存在多对一关系，支持两者之间的双向数据绑定。
比较MVC，MVP和MVVM架构模式
|
Pattern |
Dependency on Android API |
XML Complexity |
Unit Testability |
Follow Modular and single responsibility principle |
|---|---|---|---|---|
| MVC | High | Low | Difficult | No |
| MVP | Low | Low | Good | Yes |
| MVVM | Low or No dependency | Medium to High | Best | Yes |
建筑优势
- 开发人员可以设计可以接受将来更改的应用程序。
- 为应用程序提供模块化设计，以确保良好的质量测试和代码维护。
建筑的缺点
- 以架构模式编写整个项目代码是一个耗时的过程。
- 开发人员团队需要严格的纪律，因为一项错误的更改可能会破坏体系结构的完整性。