Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Birden fazla Gradle modülü içeren projeye çok modüllü proje denir. Bu kılavuz, çok modüllü Android uygulamaları geliştirme ile ilgili en iyi uygulamaları ve önerilen kalıpları kapsar.
Büyüyen kod tabanı sorunu
Sürekli büyüyen bir kod tabanında ölçeklenebilirlik, okunabilirlik ve genel kod kalitesi zamanla azalır. Bu durum, kod tabanının boyutunun artmasına rağmen bakımını yapanların kolayca bakımı yapılabilecek bir yapıyı zorunlu kılmak için aktif önlemler almaması sonucunda ortaya çıkar. Modülerleştirme, kod tabanınızı sürdürülebilirliği artıracak ve bu sorunları önlemeye yardımcı olacak şekilde yapılandırmanın bir yoludur.
Modülerleştirme nedir?
Modülerleştirme, kod tabanını gevşek bağlı ve bağımsız parçalar halinde düzenleme uygulamasıdır. Her bölüm bir modüldür. Her modül bağımsızdır ve net bir amaca hizmet eder. Bir sorunu daha küçük ve çözülmesi daha kolay alt sorunlara bölerek büyük bir sistemi tasarlama ve sürdürme karmaşıklığını azaltırsınız.
Şekil 1: Örnek çok modüllü bir kod tabanının bağımlılık grafiği
Modülerleştirmenin avantajları
Modülerleştirmenin birçok avantajı vardır. Bu avantajların her biri, kod tabanının sürdürülebilirliğini ve genel kalitesini artırmaya odaklanır. Aşağıdaki tabloda temel avantajlar özetlenmektedir.
Avantajı
Özet
Yeniden kullanılabilirlik
Modülerleştirme, kod paylaşımı ve aynı temelden birden fazla uygulama oluşturma fırsatları sunar. Modüller, etkili bir şekilde yapı taşlarıdır. Uygulamalar, özelliklerinin toplamı olmalı ve özellikler ayrı modüller olarak düzenlenmelidir. Belirli bir modülün sağladığı işlev, belirli bir uygulamada etkinleştirilebilir veya etkinleştirilmeyebilir. Örneğin, :feature:news, tam sürüm varyantının ve Wear uygulamasının bir parçası olabilir ancak demo sürüm varyantının bir parçası olmayabilir.
Sıkı görünürlük kontrolü
Modüller, kod tabanınızın diğer bölümlerine neyi göstereceğinizi kolayca kontrol etmenizi sağlar. Genel arayüzünüz hariç her şeyi internal veya private olarak işaretleyerek modülün dışında kullanılmasını engelleyebilirsiniz.
Özelleştirilebilir yayınlama
Play Özellik Dağıtımı, uygulama paketlerinin gelişmiş özelliklerini kullanarak uygulamanızın belirli özelliklerini koşullu olarak veya isteğe bağlı şekilde yayınlamanıza olanak tanır.
Modülerleştirmenin avantajları yalnızca modülerleştirilmiş bir kod tabanıyla elde edilebilir.
Aşağıdaki avantajlar başka tekniklerle de elde edilebilir ancak modülerleştirme, bu avantajları daha da iyi uygulamanıza yardımcı olabilir.
Avantajı
Özet
Ölçeklenebilir
Sıkıca bağlı bir kod tabanında tek bir değişiklik, kodun görünüşte alakasız kısımlarında bir dizi değişikliği tetikleyebilir. Doğru şekilde modülerleştirilmiş bir proje, ilgi alanlarının ayrılması ilkesini benimser ve bu nedenle bağlantıyı sınırlar. Bu sayede katılımcılar daha fazla özerklik kazanır.
Sahiplik
Modüller, özerkliği etkinleştirmenin yanı sıra hesap verebilirliği zorunlu kılmak için de kullanılabilir. Bir modülün, kodu korumak, hataları düzeltmek, test eklemek ve değişiklikleri incelemekten sorumlu özel bir sahibi olabilir.
Kapsülleme
Kapsülleme, kodunuzun her bölümünün diğer bölümler hakkında mümkün olduğunca az bilgiye sahip olması gerektiği anlamına gelir. İzole edilmiş kodun okunması ve anlaşılması daha kolaydır.
Test Edilebilirlik
Test edilebilirlik, kodunuzu test etmenin ne kadar kolay olduğunu gösterir. Test edilebilir bir kod tabanı, bileşenlerin kolayca ayrı ayrı test edilebildiği bir kod tabanıdır.
Derleme zamanı
Artımlı derleme, derleme önbelleği veya paralel derleme gibi bazı Gradle işlevleri, derleme performansını artırmak için modülerlikten yararlanabilir.
Sık karşılaşılan sorunlar
Kod tabanınızın ayrıntı düzeyi, modüllerden oluşma derecesidir. Daha ayrıntılı bir kod tabanında daha fazla ve daha küçük modül bulunur. Modüler bir kod tabanı tasarlarken ayrıntı düzeyine karar vermeniz gerekir. Bunu yapmak için kod tabanınızın boyutunu ve göreceli karmaşıklığını göz önünde bulundurun. Çok ayrıntılı bir yapı, ek yükü ağırlaştırır. Çok kaba bir yapı ise modülerleştirmenin avantajlarını azaltır.
Yaygın hatalardan bazıları şunlardır:
Çok ayrıntılı: Her modül, derleme karmaşıklığının artması ve standart kod şeklinde belirli bir ek yük getirir. Karmaşık bir derleme yapılandırması, modüller arasında yapılandırmaların tutarlı kalmasını zorlaştırır. Çok fazla standart kod
bakımı zor olan hantal bir kod tabanına yol açar. Ek yük, ölçeklenebilirlik iyileştirmelerini engelliyorsa bazı modülleri birleştirmeyi düşünebilirsiniz.
Çok kaba taneli: Bunun aksine, modülleriniz çok büyüyorsa başka bir monolit elde edebilir ve modülerliğin sunduğu avantajları kaçırabilirsiniz. Örneğin, küçük bir projede veri katmanını tek bir modülün içine yerleştirebilirsiniz. Ancak büyüdükçe depoları ve veri kaynaklarını bağımsız modüllere ayırmak gerekebilir.
Çok karmaşık: Projenizi modüler hale getirmek her zaman mantıklı olmayabilir. Baskın faktör, kod tabanının boyutudur. Projenizin belirli bir eşiğin ötesine geçmesini beklemiyorsanız ölçeklenebilirlik ve derleme süresi avantajları geçerli olmaz.
Modülerleştirme benim için doğru teknik mi?
Yeniden kullanılabilirlik, sıkı görünürlük kontrolü veya Play Özellik Dağıtımı'nın avantajlarından yararlanmak istiyorsanız modülerleştirme sizin için bir zorunluluktur. Bu avantajlardan yararlanmak istemiyorsanız ancak yine de ölçeklenebilirlik, sahiplik, kapsülleme veya derleme sürelerinde iyileşme elde etmek istiyorsanız modülerleştirme üzerinde düşünmeniz gereken bir konudur.
Örnekler
Now in Android: Modülerleştirme özelliğine sahip, tam işlevli bir Android uygulaması.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-08-17 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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)"]]
