Android MVVM 应用架构

type

status

date

slug

summary

简介

此篇内容以 Android App 开发为基础，相关术语的讨论仅仅围绕 Android 开发展开。

例如：什么是设计模式？

设计模式（design pattern）：设计模式是一种形式化的最佳实践，可用于解决设计应用程序或系统时的常见问题。

设计模式（design pattern）：是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。

同一个名词在不同的地方会看到不同的解释，每个人都有自己的理解，并没有高下对错之分，同样的 MVC、MVP、MVVM 这些架构软件行业没有一个统一标准的定义（MVC 模式当初以论文形式提出），

但我们可以基于文档、代码的形式来交流 MVC、MVP、MVVM 相关的经验和见解。

架构有很多说法，例如开源系统(MySQL、Nginx)架构、公司架构实现(支付宝、微信)，那架构与框架的区别是什么呢？

框架：面向特定领域的、可复用的“半成品”软件，它实现了该领域的共性基础部分，并提供了一些定义良好的可变点以保证灵活性和可扩展性。是领域内、特定语言和技术的架构应用解决方案。

总结：架构关注的是“结构”，框架关注的是“规范”。

例如：

Timber 是一个小型可扩展的框架库（对代码的复用），它使用了观察者模式（对设计的复用）

DataBinding 是帮助我们实现 MVVM 架构的框架。

对于我们 Android 开发来说，软件功能基于页面（Activity、Fragment)展开，我们遵守 Google 给我们定出的规则，已经能⽤⽐较稳定的代码写软件了，日常开发不需要关注架构。

但如果多人协作的商业项⽬没有架构：

所以多人协作的商业项⽬为保证开发效率与质量，架构是必不可少的，良好的架构还可以帮助您：

随着 Android 应用大小不断增加，您定义的架构务必要能允许应用扩缩、提升应用的稳健性并且方便对应用进行测试。应用架构定义了应用的各个部分之间的界限以及每个部分应承担的职责。为了满足上述需求，您应该按照某些特定原则设计应用架构。

要遵循的最重要的原则是分离关注点。一种常见的错误是在一个 Activity 或 Fragment 中编写所有代码。这些基于界面的类应仅包含处理界面和操作系统交互的逻辑。您应使这些类尽可能保持精简，这样可以避免许多与组件生命周期相关的问题，并提高这些类的可测试性。

请注意，您并非拥有 Activity 和 Fragment 的实现；它们只是表示 Android 操作系统与应用之间关系的粘合类。操作系统可能会根据用户互动或因内存不足等系统条件随时销毁它们。为了提供令人满意的用户体验和更易于管理的应用维护体验，最好尽量减少对它们的依赖。

另一个重要原则是您应该通过数据模型驱动界面（最好是持久性模型）。数据模型代表应用的数据。它们独立于应用中的界面元素和其他组件。这意味着它们与界面和应用组件的生命周期没有关联，但仍会在操作系统决定从内存中移除应用的进程时被销毁。

持久性模型是理想之选，原因如下：

如果您的应用机构以数据模型类为基础，您的应用会更便于测试、更稳定可靠。

三种最流行的设计模式是 MVC、MVP 和 MVVM。MVC 代表模型、视图和控制器，而 MVP 代表模型、视图和呈现器，MVVM 代表模型、视图和视图模型。

ㅤ	MVC	MVP	MVVM
ㅤ	View：XML布局文件	View: 对应于 Activity 和 XML，负责 View 的绘制以及与用户的交互	View: 对应于 Activity 和 XML，负责 View 的绘制以及与用户的交互
ㅤ	Model：实体模型（数据的获取、存储、数据状态变化）	Model: 实体模型	Model: 实体模型，数据获取的职责
ㅤ	Controller：对应于Activity，处理数据、业务和UI	Presenter: 负责完成View与Model间的交互和业务逻辑	ViewModel: 负责完成 View 与 Model 间的交互，负责业务逻辑。
ㅤ	• 关注点分离（更集中） • 使测试和管理代码变得更加容易 • 促进应用程序各层的解耦	• 面向接口编程 • 易于复用 • 更好的代码组织和可重用性	• 数据驱动 • 低耦合 • 可复用 • 团队协作