Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Un projet comportant plusieurs modules Gradle est appelé "projet multimodule". Ce guide comprend les bonnes pratiques et les modèles recommandés pour développer des applications multimodules Android.
Le problème du codebase croissant
Dans un codebase en croissance constante, l'évolutivité, la lisibilité et la qualité globale du code diminuent souvent au fil du temps. Ce phénomène s'explique par l'augmentation de la taille du codebase sans que ses responsables de maintenance ne prennent des mesures actives pour appliquer une structure facile à entretenir. La modularisation est un moyen de structurer votre codebase de manière à améliorer son entretien et à éviter ces problèmes.
Qu'est-ce que la modularisation ?
La modularisation est une pratique qui consiste à organiser un codebase en parties faiblement couplées et autonomes. Chaque partie est un module. Chaque module est indépendant et remplit un objectif clair. En divisant un problème en sous-problèmes plus petits et plus faciles à résoudre, vous réduisez la complexité de la conception et de la maintenance d'un système volumineux.
Figure 1. Graphique de dépendance d'un exemple de codebase multimodule
Avantages de la modularisation
Les avantages de la modularisation sont nombreux, bien qu'ils soient chacun axés sur l'amélioration de l'entretien et de la qualité globale d'un codebase. Le tableau ci-dessous récapitule les principaux avantages.
Avantage
Résumé
Réutilisation
La modularisation permet de partager du code et de créer plusieurs applications à partir de la même base. Les modules sont des composants fondamentaux. Les applications doivent être une somme de leurs fonctionnalités, sous forme de modules distincts. Les fonctionnalités fournies par un module donné peuvent être activées ou non dans une application spécifique. Par exemple, :feature:news peut faire partie du type de version complet et de l'application Wear, mais ne peut pas faire partie du type de version de démonstration.
Contrôle strict de la visibilité
Les modules vous permettent de contrôler facilement ce que vous exposez à d'autres parties de votre codebase. Tous les éléments, à l'exception de votre interface publique, peuvent être marqués comme internal ou private afin d'éviter qu'ils ne soient utilisés en dehors du module.
Diffusion personnalisable
Play Feature Delivery utilise les fonctionnalités avancées des app bundles, ce qui vous permet de proposer certaines fonctionnalités de votre application de manière conditionnelle ou à la demande.
Les avantages de la modularisation ne sont atteignables qu'avec un codebase modularisé.
Les avantages suivants peuvent être obtenus avec d'autres techniques, mais la modularisation peut vous aider à les appliquer davantage encore.
Avantage
Résumé
Évolutivité
Dans un codebase à couplage fort, une seule modification peut déclencher une série de modifications dans des parties du code qui ne semblent pas liées. Un projet correctement modularisé respectera le principe de séparation des préoccupations et limitera donc le couplage. Les contributeurs bénéficieront ainsi d'une plus grande autonomie.
Propriété
En plus d'activer l'autonomie, les modules peuvent également être utilisés pour renforcer la responsabilité. Un module peut avoir un propriétaire dédié chargé d'entretenir le code, de corriger les bugs, d'ajouter des tests et d'examiner les modifications.
Encapsulation
L'encapsulation signifie que chaque partie de votre code ne doit contenir que le minimum de connaissances possible sur les autres éléments. Le code isolé est plus facile à lire et à comprendre.
Testabilité
La testabilité définit la facilité de test de votre code. Une base de code testable est une base de code qui permet de tester facilement des composants de façon isolée.
Durée de la compilation
Certaines fonctionnalités de Gradle, comme la compilation incrémentielle, le cache de compilation ou la compilation parallèle, peuvent exploiter la modularité pour améliorer les performances de compilation.
Écueils les plus courants
La précision de votre codebase est la mesure dans laquelle elle se compose de modules. Un codebase plus précis comporte davantage de modules plus petits. Lorsque vous concevez un codebase modularisé, vous devez choisir un niveau de précision. Pour ce faire, tenez compte de la taille de votre codebase et de sa complexité relative. Si vous privilégiez la précision, l'aperçu général peut être surchargé ; si vous la négligez, vous réduisez les avantages de la modularisation.
Quelques écueils courants :
Précision trop fine : chaque module entraîne une surcharge de l'aperçu général, ce qui se traduit par une complexité de compilation accrue et un code récurrent. Une configuration de compilation complexe complique la cohérence des configurations entre les modules. Une quantité excessive de code récurrent entraîne un codebase fastidieux et difficile à entretenir. Si l'aperçu général nuit à l'amélioration de l'évolutivité, vous devriez envisager de regrouper certains modules.
Précision trop faible : à l'inverse, si vos modules deviennent trop volumineux, vous risquez de vous retrouver avec un bloc énorme et de ne pas profiter des avantages de la modularité. Par exemple, dans un petit projet, vous pouvez placer la couche de données dans un seul module. Toutefois, au fur et à mesure de sa croissance, il peut être nécessaire de scinder des dépôts et des sources de données en modules autonomes.
Précision trop complexe : il n'est pas toujours logique de modulariser votre projet. Un facteur déterminant est la taille du codebase. Si votre projet ne devrait pas dépasser un certain seuil, vous ne bénéficierez pas de l'évolutivité et des gains de durée de compilation.
La modularisation est-elle la solution idéale pour moi ?
Si vous voulez bénéficier de la réutilisation, d'un contrôle strict de la visibilité ou de l'utilisation de Play Feature Delivery, une modularisation est nécessaire. Si ce n'est pas le cas, mais que vous souhaitez tout de même bénéficier d'une évolutivité, d'une propriété, d'un encapsulation ou d'une durée de compilation améliorées, envisagez une modularisation.
Exemples
Now in Android : application Android entièrement fonctionnelle avec modularisation.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/17 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)"]]