Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Gradle ofrece la posibilidad de crear proyectos de varios módulos. En esta guía, se incluyen las prácticas y los patrones recomendados para desarrollar apps para Android con varios módulos.
El problema de la base de código creciente
En una base de código en constante crecimiento, la escalabilidad, la legibilidad y la calidad general del código suelen disminuir con el tiempo. Esto se debe a que el tamaño de la base de código aumenta sin que los encargados de su mantenimiento tomen medidas activas para aplicar una estructura que se pueda mantener fácilmente. La modularización es una forma de estructurar la base de código de una manera que mejore el mantenimiento y ayude a evitar estos problemas.
¿Qué es la modularización?
La modularización es una práctica para organizar una base de código en partes con acoplamiento bajo y elementos independientes. Cada parte es un módulo. Cada módulo es independiente y tiene un propósito claro. Si divides un problema en subproblemas más pequeños y fáciles de resolver, se reduce la complejidad de diseñar y mantener un sistema grande.
Figura 1: Gráfico de dependencia de un ejemplo de base de código de varios módulos.
Beneficios de la modularización
Los beneficios de la modularización son muchos, aunque cada uno se centra en mejorar la capacidad de mantenimiento y la calidad general de una base de código. En la siguiente tabla, se resumen los beneficios clave.
Beneficio
Resumen
Capacidad de reutilización
La modularización ofrece oportunidades para compartir código y compilar varias apps desde la misma base. Los módulos son componentes fundamentales. Una app deben ser una suma de sus funciones cuando estas se organizan como módulos separados. La funcionalidad que proporciona un módulo determinado puede o no estar habilitada en una app en particular. Por ejemplo, un :feature:news puede ser parte de la versión final y la app de Wear, pero no de la versión de demostración.
Control de visibilidad estricto
Los módulos te permiten controlar fácilmente lo que expones a otras partes de tu base de código. Puedes marcar todo excepto la interfaz pública como internal o private para evitar que se use fuera del módulo.
Entrega personalizable
Play Feature Delivery usa las funciones avanzadas de los paquetes de aplicaciones, lo que te permite ofrecer ciertas funciones de tu app de manera condicional o a pedido.
Los beneficios de la modularización solo se logran con una base de código modular.
Los siguientes beneficios se pueden lograr con otras técnicas, pero la modularización puede ayudarte a aplicarlos aún más.
Beneficio
Resumen
Escalabilidad
En una base de código de acoplamiento alto, un solo cambio puede desencadenar una cascada de alteraciones en partes de código aparentemente no relacionadas. Un proyecto modularizado adecuadamente adoptará el principio de separación de problemas y, por lo tanto, limitará el acoplamiento. De esta manera, los colaboradores tendrán mayor autonomía.
Propiedad
Además de habilitar la autonomía, los módulos también se pueden usar para aplicar la responsabilidad. Un módulo puede tener un propietario dedicado que sea responsable de mantener el código, corregir errores, agregar pruebas y revisar los cambios.
Encapsulamiento
El encapsulamiento significa que cada parte de tu código debería tener el menor conocimiento posible sobre otras partes. El código aislado es más fácil de leer y entender.
Capacidad de realizar pruebas
La capacidad de realizar pruebas determina qué tan fácil es probar tu código. Una base de código que se puede probar es aquella en la que los componentes se pueden probar fácilmente de forma aislada.
Tiempo de compilación
Algunas funcionalidades de Gradle, como la compilación incremental, la caché de compilación o la compilación en paralelo, pueden aprovechar la modularidad para mejorar el rendimiento de la compilación.
Errores comunes
El nivel de detalle de tu base de código es la medida en la que está compuesta por módulos. Una base de código más detallada tiene más módulos de menor tamaño. Cuando diseñas una base de código modular, debes decidir un nivel de detalle. Para hacerlo, ten en cuenta el tamaño de la base de código y su complejidad relativa. Usar un nivel de detalle demasiado alto hará que la sobrecarga se convierta en un problema, y hacerlo demasiado general reducirá los beneficios de la modularización.
Estos son algunos de los errores más comunes:
Muy detallada: Cada módulo genera cierta sobrecarga en forma de mayor complejidad de compilación y código estándar. Una configuración de compilación compleja dificulta la consistencia de las configuraciones entre los módulos. El exceso de código estándar da como resultado una base de código engorrosa que es difícil de mantener. Si la sobrecarga contrarresta las mejoras de escalabilidad, deberías considerar consolidar algunos módulos.
Demasiado detallado: Por el contrario, si los módulos son demasiado grandes, es posible que obtengas otra aplicación monolítica y pierdas los beneficios que ofrece la modularidad. Por ejemplo, en un proyecto pequeño, está bien colocar la capa de datos dentro de un solo módulo. Pero a medida que crece, puede ser necesario separar los repositorios y las fuentes de datos en módulos independientes.
Demasiado complejo: No siempre tiene sentido modularizar tu proyecto. Un factor dominante es el tamaño de la base de código. Si no esperas que tu proyecto crezca más allá de un cierto límite, no se aplicarán las ganancias de escalabilidad ni de tiempo de compilación.
¿La técnica de modularización es adecuada para mí?
Si necesitas los beneficios de la reutilización, un control de visibilidad estricto o usar Play Feature Delivery, la modularización es necesaria para ti. Si no los necesitas, pero aún deseas beneficiarte de una mejor escalabilidad, propiedad, encapsulamiento o tiempos de compilación, vale la pena considerar la modularización.
Ejemplos
Now in Android: Una app para Android completamente funcional con modularización.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-08-17 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-08-17 (UTC)"],[],[],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)"]]