Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Project yang memiliki beberapa modul Gradle dikenal sebagai project multi-modul. Panduan
ini mencakup praktik terbaik dan pola yang direkomendasikan untuk mengembangkan
aplikasi Android multi-modul.
Masalah codebase yang terus berkembang
Pada codebase yang terus berkembang, skalabilitas, keterbacaan, dan kualitas kode secara keseluruhan
sering kali berkurang seiring waktu. Hal ini terjadi karena ukuran codebase bertambah
tetapi pengelolanya tidak melakukan tindakan aktif untuk menerapkan struktur
yang mudah dikelola. Modularisasi adalah cara untuk membuat struktur codebase
Anda dengan cara yang meningkatkan kemudahan pengelolaan dan membantu menghindari masalah ini.
Apa yang dimaksud dengan modularisasi?
Modularisasi adalah praktik mengatur codebase ke dalam bagian-bagian yang dikaitkan secara longgar dan
berdiri sendiri. Setiap bagian merupakan modul. Setiap modul bersifat independen dan
memiliki tujuan yang jelas. Dengan membagi masalah menjadi lebih kecil dan lebih mudah untuk menyelesaikan
sub-masalah, Anda akan mengurangi kerumitan dalam mendesain dan mempertahankan sistem
yang besar.
Gambar 1: Grafik dependensi sampel codebase multi-modul
Manfaat modularisasi
Manfaat modularisasi sangat banyak, meskipun masing-masing berfokus pada peningkatan
pengelolaan dan kualitas codebase secara keseluruhan. Tabel berikut
merangkum manfaat utama.
Keunggulan
Ringkasan
Penggunaan kembali
Modularisasi memungkinkan peluang untuk berbagi kode dan mem-build beberapa aplikasi dari fondasi yang sama. Modul merupakan elemen penyusun yang efektif. Aplikasi seharusnya merupakan kumpulan dari sejumlah fitur yang fiturnya diatur sebagai modul terpisah. Fungsi yang disediakan modul tertentu mungkin diaktifkan atau tidak diaktifkan dalam aplikasi tertentu. Misalnya, :feature:news dapat menjadi bagian dari ragam dan aplikasi Wear versi lengkap, tetapi bukan bagian dari ragam versi demo.
Kontrol visibilitas yang ketat
Modul memungkinkan Anda mengontrol apa yang diekspos ke bagian lain codebase Anda dengan mudah. Anda dapat menandai semuanya kecuali antarmuka publik sebagai internal atau private agar tidak digunakan di luar modul.
Pengiriman yang dapat disesuaikan
Play Feature Delivery menggunakan kemampuan app bundle tingkat lanjut, sehingga Anda dapat mengirimkan fitur tertentu dari aplikasi Anda secara bersyarat atau on demand.
Manfaat modularisasi hanya dapat dicapai dengan codebase modular.
Manfaat berikut mungkin dapat dicapai dengan teknik lain, tetapi
modularisasi dapat membantu Anda menerapkannya lebih jauh lagi.
Keunggulan
Ringkasan
Skalabilitas
Dalam codebase yang terkait erat, satu perubahan dapat memicu penurunan perubahan di bagian kode yang tampaknya tidak berkaitan. Project yang dimodularisasi dengan benar akan mendukung prinsip pemisahan masalah dan akan membatasi pengaitan. Hal ini memberdayakan kontributor melalui otonomi yang lebih besar.
Kepemilikan
Selain mengaktifkan otonomi, modul juga dapat digunakan untuk menerapkan akuntabilitas. Modul dapat memiliki pemilik khusus yang bertanggung jawab untuk mengelola kode, memperbaiki bug, menambahkan pengujian, dan meninjau perubahan.
Enkapsulasi
Enkapsulasi berarti setiap bagian kode Anda harus memiliki sesedikit mungkin pengetahuan tentang bagian lain. Kode terisolasi lebih mudah dibaca dan dipahami.
Kemampuan pengujian
Kemampuan pengujian menunjukkan seberapa mudah pengujian kode Anda. Codebase yang dapat diuji adalah codebase tempat komponen dapat dengan mudah diuji secara terpisah.
Waktu build
Beberapa fungsi Gradle seperti build inkremental, cache build, atau build paralel, dapat memanfaatkan modularitas untuk meningkatkan performa build.
Kesalahan umum
Tingkat perincian codebase Anda adalah sejauh mana terdiri dari
modul. Codebase yang lebih terperinci memiliki lebih banyak modul yang lebih kecil. Saat mendesain
codebase modular, Anda harus memutuskan tingkat perincian. Untuk melakukannya,
perhitungkan ukuran codebase dan kompleksitas relatifnya. Penerapan
yang terlalu detail akan menimbulkan beban overhead, dan penerapan yang terlalu samar akan
mengurangi manfaat modularisasi.
Beberapa kesalahan umum adalah sebagai berikut:
Terlalu detail: Setiap modul menghasilkan jumlah overhead tertentu dalam
bentuk peningkatan kompleksitas build dan kode boilerplate. Konfigurasi
build yang kompleks mempersulit untuk
menjaga konfigurasi tetap konsisten di seluruh modul. Terlalu banyak kode boilerplate
mengakibatkan codebase rumit yang sulit dikelola. Jika overhead
melawan peningkatan skalabilitas, Anda harus mempertimbangkan untuk menggabungkan beberapa
modul.
Terlalu samar: Sebaliknya, jika modul Anda tumbuh terlalu besar, Anda
mungkin akan mendapatkan monolit lain dan melewatkan manfaat yang
ditawarkan modularitas. Misalnya, dalam project kecil, Anda dapat menempatkan lapisan data
di dalam satu modul. Namun seiring pertumbuhannya, repositori dan sumber data
mungkin perlu dipisahkan menjadi modul yang berdiri sendiri.
Terlalu rumit: Memodularisasi project Anda tidak selalu masuk akal. Faktor
yang mendominasi adalah ukuran codebase. Jika Anda tidak mengharapkan
project berkembang melebihi batas tertentu, skalabilitas dan waktu build
tidak akan berlaku.
Apakah modularisasi adalah teknik yang tepat untuk saya?
Jika Anda memerlukan manfaat penggunaan kembali, kontrol visibilitas yang ketat, atau penggunaan
Play Feature Delivery, modularisasi adalah kebutuhan bagi Anda. Jika tidak,
tetapi masih ingin mendapatkan manfaat dari skalabilitas, kepemilikan,
enkapsulasi, atau waktu build yang lebih baik, modularisasi adalah hal yang penting
dipertimbangkan.
Contoh
Now in Android - aplikasi Android yang berfungsi sepenuhnya dan memiliki
modularisasi.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-08-17 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)"]]