Android应用模块化开发指南
包含多个Gradle模块的项目称为多模块项目。本文包含多模块应用项目的最佳实践和推荐模式。
代码规模变大带来的问题
可扩缩性、可读性和整体代码质量会随着时间的推移而降低,代码维护者未采取积极的措施来保持易于维护的结构。模块化是一种行之有效的代码库构建方法,可帮助改善可维护性并避免此类问题。
什么是模块化?
将代码库组织为多个松散耦合的独立部分的做法。每个部分都是一个模块。每个模块都是独立的,并且都有明确的用途。通过将问题划分为更小、更易于解决的子问题,您可以降低设计和维护大型系统的复杂性。
示例多模块代码库的依赖关系图
模块化优势
模块化具有众多优势,但核心都是提高代码库的可维护性和整体质量。
优势 | 摘要 |
可重用性 | 模块化可支持在同一基础上共享代码并构建多个应用。模块实际上就是构建块。应用应为其各项功能的总和,而这些功能按单独的模块进行划分。特定模块提供的功能不一定会在特定应用中启用。例如,:feature:news 可以是完整版本变种和 Wear 应用的一部分,但不是演示版本变种的一部分。 |
严格控制可见性 | 借助模块,您可以轻松控制向代码库的其他部分公开哪些内容。您可以将除公共接口以外的所有内容标记为 internal 或 private,以防止在模块外部使用这些内容。 |
自定义分发 | Play Feature Delivery 使用了 app bundle 的多种高级功能,让您可以按条件或按需分发应用的某些功能。 |
可伸缩性 | 在紧密耦合的代码库中,单项更改可能会触发看似不相关的代码部分的级联更改。适当模块化的项目将遵循分离关注点原则,因此可限制耦合。这样一来,贡献者将拥有更大的自主权。 |
所有权 | 除了实现自主权外,模块还可用于实现问责制原则。模块可以由专门的所有者来负责维护代码、修复 bug、添加测试以及查看更改。 |
封装 | 封装意味着代码的每个部分都应尽可能少地了解其他部分。隔离的代码更易于阅读和理解。 |
可测试性 | 可测试性是指可以轻松测试代码。可测试代码是指可以轻松单独测试组件的代码。 |
构建时间 | 某些 Gradle 功能(如增量构建、构建缓存或并行构建)可以利用模块化来提高 build 性能。 |
常见误区
代码库的粒度是指其模块化程度。粒度不是越大越好,也不是越小越好。过于精细化的设计会增加开销负担,而过于粗略又会降低模块化的优势。
应用示例
Now InAndroid
模块化遵循的原则—高内聚低耦合
表征模块化代码库的一种方式是使用耦合和内聚属性。耦合用于衡量模块相互依赖的程度。
- • 低耦合是指模块应尽可能相互独立,这样一来,对一个模块所做的更改将对其他模块产生零影响或极小的影响。模块相互之间不应了解对方的内部运行原理。
- • 高内聚是指多个模块的代码集合应当像一个系统一样运行。它们应具有明确定义的职责,并始终位于特定领域知识范围以内。假设有一个电子书应用示例。在同一个模块中融合图书相关代码和付款相关代码是不合适的,因为图书和付款是两个不同的功能领域。
模块类型
在遵循应用架构指南的前提下,应用中应该引入的一些通用模块类型。
数据模块
数据模块通常包含存储库、数据源和模型类。包含三职责:
- 1. 封装特定领域的所有数据和业务逻辑:每个数据模块都应负责处理表示特定领域的数据。它可以处理许多类型的数据,只要这些数据相关即可。
- 2. 将存储库公开为外部 API:数据模块的公共 API 应为存储库,因为它们负责向应用的其余部分公开数据。
- 3. 对外部隐藏所有实现细节和数据源:只能由同一模块中的存储库访问数据源。它们对外部始终处于隐藏状态。您可以使用 Kotlin 的 private 或 internal 可见性关键字来实现此操作。
示例数据模块及其内容
功能模块
功能是应用功能的独立部分,通常对应于一个屏幕或一系列密切相关的屏幕,例如注册或结账流程。如果您的应用具有底部导航栏,则每个目标位置都可能是一项功能。
此应用的每个标签页均可定义为功能
功能与应用中的屏幕或目标位置相关联。因此,它们可能具有相关联的界面和 ViewModel,用于处理其逻辑和状态。一项功能并不一定仅限于单一视图或导航目标位置。功能模块依赖于数据模块。
功能模块及其内容示例
应用模块
应用模块是应用的入口点。它们依赖于功能模块,并且通常提供根导航。由于支持 build 变体,因此单个应用模块可以编译为许多不同的二进制文件。
“演示版”和“完整版”产品变种模块依赖关系图
如果您的应用以多种设备类型(例如汽车、穿戴式设备或电视)为目标平台,您可以考虑为每个设备类型定义一个应用模块。这有助于分离特定于平台的依赖项。
Wear 应用依赖关系图
通用模块
通用模块(也称为核心模块)包含其他模块经常使用的代码。它们可减少冗余,并且不代表应用架构中的任何特定层。下面列出了通用模块的一些示例:
- • 界面模块:如果您使用自定义界面元素或在应用中精心设计品牌元素,则应考虑将 widget 集合封装到一个模块中,以便重复使用所有功能。这有助于确保您的界面在不同功能之间保持一致。例如,如果您采用集中式主题,则在更换品牌名称时可以避免痛苦的重构过程。
- • 分析模块:跟踪通常取决于业务需求,而几乎不用考虑软件架构。分析跟踪器经常应用于许多不相关的组件。如果是这种情况,最好创建一个专用分析模块。
- • 网络模块:当许多模块需要网络连接时,您可以考虑创建一个专用于提供 http 客户端的模块。当客户端需要自定义配置,该模块尤为实用。
- • 实用程序模块:实用程序(也称为辅助程序)通常是在应用中重复使用的小段代码。实用程序的示例包括测试辅助程序、货币格式设置函数、电子邮件验证程序和自定义运算符。
模块间通信
很少有模块是完全隔离的。模块之间通常相互依赖并相互通信。即使多个模块协同运行并频繁交换信息,也务必要保持低耦合。有时,与架构约束一样,两个模块之间进行直接通信是不可取的方式。此外,在使用循环依赖项等情况下,两个模块直接进行通信也是不可行的。
使用循环依赖项时,在模块之间进行直接双向通信是不可行的。需要通过一个中间模块来协调两个其他独立模块之间的数据流
使用循环依赖项时,在模块之间进行直接双向通信是不可行的。需要通过一个中间模块来协调两个其他独立模块之间的数据流
为了克服此问题,您可以在两个模块之间使用第三个中间模块。中间模块可以监听来自这两个模块的消息,并根据需要转发消息。在我们的示例应用中,即使事件源自属于不同功能的单独屏幕,结账屏幕也需要知道要购买哪本图书。在这种情况下,拥有导航图的模块将充当中间模块(通常是应用模块)。在此示例中,我们使用导航组件将数据从主屏幕功能传递至结账功能。
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 并从共享数据模块加载资源,而不是传递对象。
两个功能模块依赖于一个共享数据模块
常见最佳实践
没有最好的架构,但通常建议遵循代码的可读性、可维护性和可测试性。
- • 版本目录是 Gradle 在同步期间生成的类型安全的依赖项列表。您可以在其中集中声明所有依赖项,并且可供项目中的所有模块使用。
- • 使用惯例插件在模块之间共享 build 逻辑。
保持配置一致
每个模块都会引入配置开销。如果模块数量达到特定阈值,保持一致的配置将成为一项挑战。
尽可能少公开信息
应尽量减少模块的公共接口,并且仅公开基本信息。不应向外部泄露任何实现细节。请尽可能缩小范围。使用 Kotlin 的 private 或 internal 可见性范围将模块声明设为私有模块。在模块中声明依赖项时,请优先使用 implementation 而不是 api。后者会向模块的使用方公开传递依赖项。使用实现可以缩短构建时间,因为这样可以减少需要重新构建的模块数量。
首选 Kotlin 和 Java 模块
AS支持应用模块(APK)、库模块(AAR)及Kotlin/Java模块(JAR),APK、AAR模块包含了资源会产生较多的开销,因此您应当优先尽可能多地使用 Kotlin 或 Java 库。
推荐阅读
- • kotlin依赖注入框架之koin(一)
- • kotlin依赖注入框架之koin(二)
- • kotlin依赖注入框架之koin(三)
欢迎关注我的公众号“虎哥Droid”,原创技术文章第一时间推送。