android常见的架构设计原则-参考google文档

常见的架构原则

分离关注点

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

通过模型驱动界面

• 另一个重要原则是您应该通过模型驱动界面（最好是持久性模型）。模型是负责处理应用数据的组件。它们独立于应用中的 View 对象和应用组件，因此不受应用的生命周期以及相关的关注点的影响。

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

• 如果 Android 操作系统销毁应用以释放资源，用户不会丢失数据。
• 当网络连接不稳定或不可用时，应用会继续工作。
  应用所基于的模型类应明确定义数据管理职责，这样将使应用更可测试且更一致。

推荐应用架构

假设我们要构建一个用于显示用户个人资料的界面。我们使用私有后端和 REST API 获取给定个人资料的数据。

请注意，每个组件仅依赖于其下一级的组件。例如，Activity 和 Fragment 仅依赖于视图模型。存储区是唯一依赖于其他多个类的类；在本例中，存储区依赖于持久性数据模型和远程后端数据源。

这种设计打造了一致且愉快的用户体验。无论用户上次使用应用是在几分钟前还是几天之前，现在回到应用时都会立即看到应用在本地保留的用户信息。如果此数据已过时，则应用的存储区模块将开始在后台更新数据。

构建界面

• 界面由 Fragment UserProfileFragment 及其对应的布局文件 user_profile_layout.xml 组成。

• 我们将使用 UserProfileViewModel（基于 ViewModel 架构组件）存储这些信息。

  ViewModel 对象为特定的界面组件（如 Fragment 或 Activity）提供数据，并包含数据处理业务逻辑，以与模型进行通信。例如，ViewModel 可以调用其他组件来加载数据，还可以转发用户请求来修改数据。ViewModel 不了解界面组件，因此不受配置更改（如在旋转设备时重新创建 Activity）的影响

最佳做法

编程是一个创造性的领域，构建 Android 应用也不例外。无论是在多个 Activity 或 Fragment 之间传递数据，检索远程数据并将其保留在本地以在离线模式下使用，还是复杂应用遇到的任何其他常见情况，解决问题的方法都会有很多种。

虽然以下建议不是强制性的，但根据我们的经验，从长远来看，遵循这些建议会使您的代码库更强大、可测试性更高且更易维护：

• 避免将应用的入口点（如 Activity、Service 和广播接收器）指定为数据源。
  相反，您应只将其与其他组件协调，以检索与该入口点相关的数据子集。每个应用组件存在的时间都很短暂，具体取决于用户与其设备的交互情况以及系统当前的整体运行状况。
• 在应用的各个模块之间设定明确定义的职责界限。
  例如，请勿在代码库中将从网络加载数据的代码散布到多个类或软件包中。同样，也不要将不相关的职责（如数据缓存和数据绑定）定义到同一个类中。
• 尽量少公开每个模块中的代码。
  请勿试图创建“就是那一个”快捷方式来呈现一个模块的内部实现细节。短期内，您可能会省点时间，但随着代码库的不断发展，您可能会反复陷入技术上的麻烦。
• 考虑如何使每个模块可独立测试。
  例如，如果使用明确定义的 API 从网络获取数据，将会更容易测试在本地数据库中保留该数据的模块。如果您将这两个模块的逻辑混放在一处，或将网络代码分散在整个代码库中，那么即便能够进行测试，难度也会大很多。
• 专注于应用的独特核心，以使其从其他应用中脱颖而出。
  不要一次又一次地编写相同的样板代码，这是在做无用功。相反，您应将时间和精力集中放在能让应用与众不同的方面上，并让 Android 架构组件以及建议的其他库处理重复的样板。
• 保留尽可能多的相关数据和最新数据。
  这样，即使用户的设备处于离线模式，他们也可以使用您应用的功能。请注意，并非所有用户都能享受到稳定的高速连接。
• 将一个数据源指定为单一可信来源。 每当应用需要访问这部分数据时，这部分数据都应一律源于此单一可信来源。