此页面由 Cloud Translation API 翻译。
Android Developers
Design & Plan
App architecture
Android 应用模块化指南
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
包含多个 Gradle 模块的项目称为多模块项目。本指南包含有关开发多模块 Android 应用的最佳实践和推荐模式。
注意：本页面假定您对推荐的应用架构有基本的了解。
代码库不断变大的问题
在不断变大的代码库中，可扩缩性、可读性和整体代码质量通常会随着时间的推移而降低。这是因为代码库在不断变大，而其维护者未采取积极措施来保持易于维护的结构。模块化是一种行之有效的代码库构建方法，可帮助改善可维护性并避免此类问题。
什么是模块化？
模块化是按多个松散耦合的独立部分整理代码库的做法。每个部分都是一个模块。每个模块都是独立的，并且都有明确的用途。通过将问题划分为更小、更易于解决的子问题，您可以降低设计和维护大型系统的复杂性。
图 1：多模块代码库示例的依赖关系图
模块化的优势
模块化具有众多优势，但核心都是提高代码库的可维护性和整体质量。下表总结了模块化的主要优势。
优势
摘要
可重用性
模块化可支持在同一基础上共享代码并构建多个应用。模块实际上就是构建块。应用应为其各项功能的总和，而这些功能按单独的模块进行划分。特定模块提供的功能不一定会在特定的应用中实现。例如，:feature:news 可以是完整版本变种和 Wear 应用的一部分，但不是演示版本变种的一部分。
严格控制可见性
借助模块，您可以轻松控制向代码库的其他部分公开哪些内容。您可以将除公共接口以外的所有内容标记为 internal 或 private，以防止在模块外部使用这些内容。
自定义分发
Play Feature Delivery 使用了 app bundle 的多种高级功能，让您可以按条件或按需分发应用的某些功能。
只有通过模块化代码库才能实现模块化的优势。
采用其他方法也可实现以下优势，但模块化可以帮助您进一步强化这些优势。
优势
摘要
可伸缩性
在紧密耦合的代码库中，单项更改可能会触发看似不相关的代码部分的级联更改。适当模块化的项目将遵循关注点分离原则，因此可限制耦合。这样一来，贡献者将拥有更大的自主权。
所有权
除了实现自主权外，模块还可用于实现问责制原则。可以由一个专门的所有者来负责为模块维护代码、修复 bug、添加测试以及查看更改。
封装
封装意味着代码的每个部分都应尽可能少地了解其他部分。隔离的代码更易于阅读和理解。
可测试性
可测试性是指测试代码的轻松程度。可测试的代码库是指可以轻松单独测试组件的代码库。
构建时间
某些 Gradle 功能（如增量构建、构建缓存或并行构建）可以利用模块化来提升构建性能。
常见误区
代码库的粒度是指其模块化程度。更细粒度的代码库包含更多、更小的模块。在设计模块化代码库时，您应当决定粒度级别。为此，请考虑代码库的大小及其相对复杂度。过于精细化的设计会增加开销负担，而过于粗略又会降低模块化的优势。
下面列出了一些常见误区：
过于精细：每个模块都会产生一定的开销，包括增加构建复杂度以及引入样板代码。复杂的 build 配置会导致难以在模块之间保持配置一致。过多的样板代码会导致代码库冗长累赘，难以维护。如果开销抵消了可伸缩性方面的改进，则应考虑整合某些模块。
过于粗略：相反，如果模块过大，最终可能会产生另一个单体式模块，失去模块化的优势。例如，在小项目中，将数据层放到单一模块中是没有问题的。但随着模块变大，您可能需要将代码库和数据源拆分为独立的模块。
过于复杂：构建模块化项目并非总是明智的做法。代码库的大小是一项决定因素。如果您预计项目不会变大到超过某个特定阈值，则不必考虑可伸缩性和构建时间。
我是否适合采用模块化方法？
如果您需要实现可重用性、严格控制可见性或使用 Play Feature Delivery，则有必要采用模块化方法。如果您尚未采用模块化方法，但希望改善可扩缩性、所有权、封装或构建时间，那么模块化是一种值得考虑的方法。
示例
Now in Android - 功能完备的模块化 Android 应用。
多模块架构示例
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-08-17。
[null,null,["最后更新时间 (UTC)：2025-08-17。"],[],[],null,["# Guide to Android app modularization\n\nA project with multiple Gradle modules is known as a multi-module project. This\nguide encompasses best practices and recommended patterns for developing\nmulti-module Android apps.\n| **Note:** This page assumes a basic familiarity with the [recommended app\n| architecture](/topic/architecture).\n\nThe growing codebase problem\n----------------------------\n\nIn an ever-growing codebase, scalability, readability, and overall code quality\noften decrease through time. This comes as a result of the codebase increasing\nin size without its maintainers taking active measures to enforce a structure\nthat is easily maintainable. Modularization is a means of structuring your\ncodebase in a way that improves maintainability and helps avoid these problems.\n\nWhat is modularization?\n-----------------------\n\nModularization is a practice of organizing a codebase into loosely coupled and\nself contained parts. Each part is a module. Each module is independent and\nserves a clear purpose. By dividing a problem into smaller and easier to solve\nsubproblems, you reduce the complexity of designing and maintaining a large\nsystem.\n**Figure 1**: Dependency graph of a sample multi-module codebase\n\nBenefits of modularization\n--------------------------\n\nThe benefits of modularization are many, though they each center upon improving\nthe maintainability and overall quality of a codebase. The following table\nsummarizes the key benefits.\n\n| Benefit | Summary |\n|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Reusability | Modularization enables opportunities for code sharing and building multiple apps from the same foundation. Modules are effectively building blocks. Apps should be a sum of their features where the features are organized as separate modules. The functionality that a certain module provides may or may not be enabled in a particular app. For example, a `:feature:news` can be a part of the full version flavor and wear app but not part of the demo version flavor. |\n| Strict visibility control | Modules enable you to easily control what you expose to other parts of your codebase. You can mark everything but your public interface as `internal` or `private` to prevent it from being used outside the module. |\n| Customizable delivery | [Play Feature Delivery](/guide/playcore/feature-delivery) uses the advanced capabilities of app bundles, allowing you to deliver certain features of your app conditionally or on demand. |\n\nThe benefits of modularization are only achievable with a modularized codebase.\nThe following benefits might be achieved with other techniques but\nmodularization can help you enforce them even more.\n\n| Benefit | Summary |\n|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Scalability | In a tightly coupled codebase a single change can trigger a cascade of alterations in seemingly unrelated parts of code. A properly modularized project will embrace the [separation of concerns](https://en.wikipedia.org/wiki/Separation_of_concerns) principle and therefore limit the coupling. This empowers the contributors through greater autonomy. |\n| Ownership | In addition to enabling autonomy, modules can also be used to enforce accountability. A module can have a dedicated owner who is responsible for maintaining the code, fixing bugs, adding tests, and reviewing changes. |\n| Encapsulation | Encapsulation means that each part of your code should have the smallest possible amount of knowledge about other parts. Isolated code is easier to read and understand. |\n| Testability | Testability characterizes how easy it is to [test](/training/testing) your code. A testable codebase is one where components can be easily tested in isolation. |\n| Build time | Some Gradle functionalities such as incremental build, build cache or parallel build, can leverage modularity to [improve build performance](/studio/build/optimize-your-build). |\n\nCommon pitfalls\n---------------\n\nThe granularity of your codebase is the extent to which it is composed of\nmodules. A more granular codebase has more, smaller modules. When designing a\nmodularized codebase, you should decide on a level of granularity. To do so,\ntake into account the size of your codebase and its relative complexity. Going\ntoo fine-grained will make the overhead a burden, and going too coarse will\nlessen the benefits of modularization.\n\nSome common pitfalls are as follows:\n\n- **Too fine-grained** : Every module brings a certain amount of overhead in the form of increased build complexity and [boilerplate code](https://en.wikipedia.org/wiki/Boilerplate_code). A complex build configuration makes it difficult to [keep configurations consistent](/topic/modularization/patterns#consistent-configuration) across modules. Too much boilerplate code results in a cumbersome codebase that is difficult to maintain. If overhead counteracts scalability improvements, you should consider consolidating some modules.\n- **Too coarse-grained**: Conversely, if your modules are growing too large you might end up with yet another monolith and miss the benefits that modularity has to offer. For example, in a small project it's ok to put the data layer inside a single module. But as it grows, it might be necessary to separate repositories and data sources into standalone modules.\n- **Too complex**: It doesn't always make sense to modularize your project. A dominating factor is the size of the codebase. If you don't expect your project to grow beyond a certain threshold, the scalability and build time gains won't apply.\n\nIs modularization the right technique for me?\n---------------------------------------------\n\nIf you need the benefits of reusability, strict visibility control or to use the\n[Play Feature Delivery](/guide/playcore/feature-delivery), then modularization is a necessity for you. If you\ndon't, but still want to benefit from improved scalability, ownership,\nencapsulation, or build times, then modularization is something worth\nconsidering.\n\nSamples\n-------\n\n- [Now in Android](https://github.com/android/nowinandroid) - fully functional Android app featuring modularization.\n- [Multi module architecture sample](https://github.com/android/architecture-samples/tree/multimodule)"]]