常见的模块化模式

没有一种适用于所有项目的 模块化 策略。由于 Gradle 的灵活特性，在组织项目方面几乎没有限制。此页面概述了在开发多模块 Android 应用时可以采用的某些通用规则和常见模式。

高内聚和低耦合原则

描述模块化代码库的一种方法是使用耦合和内聚属性。耦合衡量模块之间相互依赖的程度。在这种情况下，内聚衡量单个模块的元素在功能上相关的程度。通常，您应该努力实现低耦合和高内聚。

  • 低耦合意味着模块应该尽可能独立于彼此，以便对一个模块的更改对其他模块的影响为零或最小。模块不应该了解其他模块的内部工作原理。
  • 高内聚意味着模块应该包含充当系统的代码集合。它们应该具有明确定义的职责，并保持在某些领域知识的边界内。考虑一个电子书应用程序示例。将书籍和支付相关的代码混合到同一个模块中可能是不合适的，因为它们是两个不同的功能域。

模块类型

您组织模块的方式主要取决于您的应用架构。以下是您在遵循我们的 推荐的应用架构 时可以在应用中引入的一些常见模块类型。

数据模块

数据模块通常包含存储库、数据源和模型类。数据模块的三个主要职责是

  1. 封装特定域的所有数据和业务逻辑：每个数据模块应负责处理表示特定域的数据。只要它们相关，它就可以处理许多类型的数据。
  2. 将存储库公开为外部 API：数据模块的公共 API 应该是存储库，因为它们负责向应用的其余部分公开数据。
  3. 隐藏所有实现细节和数据源：数据源只能由同一模块中的存储库访问。它们对外部隐藏。您可以通过使用 Kotlin 的 private 或 internal 可见性关键字来强制执行此操作。
图 1. 数据模块示例及其内容。

功能模块

功能是应用功能的一个独立部分，通常对应于一个屏幕或一系列密切相关的屏幕，例如注册或结账流程。如果您的应用具有底部栏导航，则每个目标都可能是功能。

图 2. 此应用程序的每个选项卡都可以定义为一个功能。

功能与应用中的屏幕或目标相关联。因此，它们很可能具有关联的 UI 和ViewModel来处理其逻辑和状态。单个功能不必局限于单个视图或导航目标。功能模块依赖于数据模块。

图 3. 功能模块示例及其内容。

应用模块

应用模块是应用程序的入口点。它们依赖于功能模块，通常提供根导航。由于构建变体，单个应用模块可以编译成多个不同的二进制文件。

图 4. *演示版* 和 *完整版* 产品风格模块依赖关系图。

如果您的应用针对多种设备类型（例如汽车、可穿戴设备或电视），请为每种设备类型定义一个应用模块。这有助于分离平台特定的依赖项。

图 5. 可穿戴应用依赖关系图。

通用模块

通用模块，也称为核心模块，包含其他模块经常使用的代码。它们减少了冗余，并且不代表应用架构中的任何特定层。以下是通用模块的示例

  • UI 模块：如果您的应用使用自定义 UI 元素或精心设计的品牌，则应考虑将您的窗口小部件集合封装到一个模块中，以便所有功能都可以重用。这有助于使您的 UI 在不同功能之间保持一致。例如，如果您的主题是集中的，那么当重新设计品牌时，您可以避免痛苦的重构。
  • 分析模块：跟踪通常由业务需求决定，而很少考虑软件架构。分析跟踪器通常用于许多不相关的组件中。如果您的情况也是如此，那么拥有一个专门的分析模块可能是一个好主意。
  • 网络模块：当许多模块需要网络连接时，您可能需要考虑拥有一个专门用于提供 http 客户端的模块。当您的客户端需要自定义配置时，它特别有用。
  • 实用程序模块：实用程序，也称为帮助程序，通常是应用程序中重复使用的少量代码。实用程序的示例包括测试帮助程序、货币格式化函数、电子邮件验证器或自定义运算符。

测试模块

测试模块 是仅用于测试目的的 Android 模块。这些模块包含测试代码、测试资源和测试依赖项，这些依赖项仅在运行测试时需要，在应用程序运行时不需要。创建测试模块是为了将特定于测试的代码与主应用程序分离，使模块代码更易于管理和维护。

测试模块的使用场景

以下示例展示了实现测试模块特别有益的情况

  • 共享测试代码：如果您的项目中有多个模块，并且某些测试代码适用于多个模块，则可以创建一个测试模块来共享代码。这有助于减少重复，并使您的测试代码更易于维护。共享测试代码可以包括实用程序类或函数（例如自定义断言或匹配器），以及测试数据（例如模拟的 JSON 响应）。

  • 更清晰的构建配置：测试模块允许您拥有更清晰的构建配置，因为它们可以拥有自己的build.gradle文件。您不必用仅与测试相关的配置来弄乱应用模块的build.gradle文件。

  • 集成测试：测试模块可用于存储用于测试应用不同部分之间交互的集成测试，包括用户界面、业务逻辑、网络请求和数据库查询。

  • 大型应用程序：对于具有复杂代码库和多个模块的大型应用程序，测试模块特别有用。在这种情况下，测试模块可以帮助改进代码组织和可维护性。

图 6. 测试模块可用于隔离原本相互依赖的模块。

模块间通信

模块很少完全独立存在，并且经常依赖于其他模块并与之通信。即使模块协同工作并频繁交换信息，也务必保持低耦合。有时，两个模块之间的直接通信要么不可取（例如，在架构约束的情况下），要么是不可能的，例如循环依赖。

图 7. 由于循环依赖，模块之间无法进行直接的双向通信。需要一个中介模块来协调两个其他独立模块之间的数据流。

为了克服这个问题，您可以使用第三个模块在另外两个模块之间进行中介。中介模块可以侦听来自这两个模块的消息，并根据需要转发它们。在我们的示例应用中，结账屏幕需要知道要购买哪本书，即使事件起源于属于不同功能的单独屏幕。在这种情况下，中介是拥有导航图的模块（通常是应用模块）。在示例中，我们使用导航将数据从主页功能传递到结账功能，使用导航组件。

navController.navigate("checkout/$bookId")

结账目标接收书籍 ID 作为参数，它使用该参数来获取有关书籍的信息。您可以使用保存状态句柄在目标功能的ViewModel中检索导航参数。

class CheckoutViewModel(savedStateHandle: SavedStateHandle, …) : ViewModel() {

   val uiState: StateFlow<CheckoutUiState> =
      savedStateHandle.getStateFlow<String>("bookId", "").map { bookId ->
          // produce UI state calling bookRepository.getBook(bookId)
      }
      …
}

您不应该将对象作为导航参数传递。相反，请使用功能可以用来从数据层访问和加载所需资源的简单 ID。这样，您可以保持低耦合，并且不会违反单一数据源原则。

在下面的示例中，两个功能模块都依赖于相同的数据模块。这使得能够最大程度地减少中介模块需要转发的的数据量，并保持模块之间的低耦合。模块不应传递对象，而应交换基本 ID 并从共享数据模块加载资源。

图 8. 两个功能模块依赖于共享数据模块。

依赖倒置

依赖倒置是指您组织代码的方式，使抽象与具体实现分离。

  • 抽象：定义应用中组件或模块如何相互交互的契约。抽象模块定义系统 API，并包含接口和模型。
  • 具体实现：依赖于抽象模块并实现抽象行为的模块。

依赖于抽象模块中定义的行为的模块应该只依赖于抽象本身，而不是具体的实现。

图 9. 高级模块不直接依赖于低级模块，而是高级模块和实现模块都依赖于抽象模块。

示例

假设一个功能模块需要数据库才能工作。功能模块并不关心数据库是如何实现的，无论是本地 Room 数据库还是远程 Firestore 实例。它只需要存储和读取应用程序数据。

为了实现这一点，功能模块依赖于抽象模块，而不是依赖于特定的数据库实现。此抽象定义了应用的数据库 API。换句话说，它设置了与数据库交互的规则。这允许功能模块使用任何数据库，而无需了解其底层实现细节。

具体实现模块提供抽象模块中定义的 API 的实际实现。为此，实现模块也依赖于抽象模块。

依赖注入

到目前为止，您可能想知道功能模块是如何与实现模块连接的。答案是依赖注入。功能模块不会直接创建所需的数据库实例。相反，它指定了它需要的依赖项。然后，这些依赖项会在外部提供，通常在应用模块中提供。

releaseImplementation(project(":database:impl:firestore"))

debugImplementation(project(":database:impl:room"))

androidTestImplementation(project(":database:impl:mock"))

好处

分离 API 和其实现的好处如下

  • 可互换性：通过清晰分离 API 和实现模块，您可以为同一个 API 开发多个实现，并在它们之间切换，而无需更改使用该 API 的代码。这在您希望在不同上下文中提供不同功能或行为的场景中特别有用。例如，用于测试的模拟实现与用于生产的真实实现。
  • 解耦：分离意味着使用抽象的模块不依赖于任何特定的技术。如果您稍后选择将数据库从 Room 更改为 Firestore，则会更容易，因为更改只会发生在执行此工作的特定模块（实现模块）中，并且不会影响使用数据库 API 的其他模块。
  • 可测试性：分离 API 和其实现可以极大地促进测试。您可以针对 API 契约编写测试用例。您还可以使用不同的实现来测试各种场景和边缘情况，包括模拟实现。
  • 改进构建性能：当您将 API 和其实现分离到不同的模块时，实现模块中的更改不会强制构建系统重新编译依赖于 API 模块的模块。这会导致更快的构建时间和更高的生产力，尤其是在构建时间可能很长的大型项目中。

何时分离

在以下情况下，分离 API 和其实现是有益的

  • 多种功能：如果您可以通过多种方式实现系统的一部分，则清晰的 API 允许不同实现的互换性。例如，您可能有一个使用 OpenGL 或 Vulkan 的渲染系统，或者一个与 Play 或您自己的内部计费 API 合作的计费系统。
  • 多个应用程序：如果您正在为不同平台开发多个具有共享功能的应用程序，则可以定义通用 API 并为每个平台开发特定的实现。
  • 独立团队：分离允许不同的开发人员或团队同时处理代码库的不同部分。开发人员应专注于理解 API 契约并正确使用它们。他们不需要担心其他模块的实现细节。
  • 大型代码库：当代码库很大或很复杂时，将 API 与实现分离会使代码更易于管理。它允许您将代码库分解成更细粒度、更易于理解和维护的单元。

如何实现？

要实现依赖倒置，请按照以下步骤操作

  1. 创建抽象模块：此模块应包含定义功能行为的 API（接口和模型）。
  2. 创建实现模块：实现模块应依赖于 API 模块并实现抽象的行为。
    Instead of high level modules depending on low level modules directly, high level and implementation modules depend on the abstraction module.
    图 10. 实现模块依赖于抽象模块。
  3. 使高级模块依赖于抽象模块：不要直接依赖于特定实现，而是使模块依赖于抽象模块。高级模块不需要了解实现细节，它们只需要契约（API）。
    High level modules depend on abstractions, not implementation.
    图 11. 高级模块依赖于抽象，而不是实现。
  4. 提供实现模块：最后，您需要为依赖项提供实际的实现。具体的实现取决于您的项目设置，但应用模块通常是执行此操作的理想位置。要提供实现，请将其指定为所选构建变体或测试源集的依赖项。
    App module provides actual implementation.
    图 12. 应用模块提供实际的实现。

一般最佳实践

如开头所述，开发多模块应用没有唯一正确的方法。就像存在许多软件架构一样，也存在许多模块化应用的方式。但是，以下一般建议可以帮助您使代码更易读、更易维护和更易测试。

保持配置一致

每个模块都会引入配置开销。如果模块数量达到一定阈值，管理一致的配置就会成为一项挑战。例如，模块使用相同版本的依赖项非常重要。如果您需要更新大量模块仅仅是为了提升依赖项版本，这不仅需要付出努力，而且还存在潜在错误的风险。为了解决这个问题，您可以使用 Gradle 的其中一个工具来集中配置。

  • 版本目录是由 Gradle 在同步期间生成的依赖项类型安全列表。它是声明所有依赖项的中心位置，并且项目中的所有模块都可以访问它。
  • 使用约定插件在模块之间共享构建逻辑。

尽可能少地公开

模块的公共接口应该最小，并且只公开基本要素。它不应该泄露任何实现细节到外部。将所有内容的范围限制到尽可能小的程度。使用 Kotlin 的private或internal可见性范围使声明成为模块私有。在模块中声明依赖项时，优先使用implementation而不是api。后者将传递依赖项公开给模块的使用者。使用 implementation 可以提高构建时间，因为它减少了需要重新构建的模块数量。

优先使用 Kotlin & Java 模块

Android Studio 支持三种基本类型的模块

  • 应用模块是应用程序的入口点。它们可以包含源代码、资源、资产和AndroidManifest.xml。应用模块的输出是 Android 应用包 (AAB) 或 Android 应用软件包 (APK)。
  • 库模块与应用模块具有相同的内容。它们被其他 Android 模块用作依赖项。库模块的输出是 Android 归档 (AAR)，其结构与应用模块相同，但它们被编译成 Android 归档 (AAR) 文件，该文件稍后可被其他模块用作依赖项。库模块可以封装和重用许多应用模块中的相同逻辑和资源。
  • Kotlin 和 Java 库不包含任何 Android 资源、资产或清单文件。

由于 Android 模块会带来开销，因此最好尽可能使用 Kotlin 或 Java 类型。