应用架构指南

常见的最佳做法

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

虽然以下建议不是强制性的，但在大多数情况下，遵循这些建议会使您的代码库更强大、可测试性更高且更易维护：

不要将数据存储在应用组件中。

请避免将应用的入口点（如 Activity、Service 和广播接收器）指定为数据源。相反，您应只将其与其他组件协调，以检索与该入口点相关的数据子集。每个应用组件存在的时间都很短暂，具体取决于用户与其设备的交互情况以及系统当前的整体运行状况。

减少对 Android 类的依赖。

您的应用组件应该是唯一依赖于 Android 框架 SDK API （例如 Context 或 Toast）的类。将应用中的其他类与这些类分离开来有助于改善可测试性，并减少应用中的耦合。

在应用的各个模块之间设定明确定义的职责界限。

例如，请勿在代码库中将从网络加载数据的代码散布到多个类或软件包中。同样，也不要将不相关的职责（如数据缓存和数据绑定）定义到同一个类中。遵循推荐的应用架构可以帮助您解决此问题。

尽量少公开每个模块中的代码。

例如，请勿试图创建从模块提供内部实现细节的快捷方式。短期内，您可能会省点时间，但随着代码库的不断发展，您可能会反复陷入技术上的麻烦。

专注于应用的独特核心，以使其从其他应用中脱颖而出。

不要一次又一次地编写相同的样板代码，这是在做无用功。 相反，您应将时间和精力集中放在能让应用与众不同的方面上，并让 Jetpack 库以及建议的其他库处理重复的样板。

考虑如何使应用的每个部分可独立测试。

例如，如果使用明确定义的 API 从网络获取数据，将会更容易测试在本地数据库中保留该数据的模块。如果您将这两个模块的逻辑混放在一处，或将网络代码分散在整个代码库中，那么即便能够进行有效测试，难度也会大很多。

保留尽可能多的相关数据和最新数据。

这样，即使用户的设备处于离线模式，他们也可以使用您应用的功能。请记住，并非所有用户都能享受到稳定的高速连接 - 即使有时可以使用，在比较拥挤的地方网络信号也可能不佳。