Tüm projelere uyan tek bir modülerleştirme stratejisi yoktur. Kaynak: esnek bir yapıya sahip olduğundan, Gradle'ın esnek bazı önemli belgeler vardır. Bu sayfada bazı genel kurallar ve yaygın olarak kullanılan geliştirirken kullanabileceğiniz bazı kalıplar var.
Yüksek tutarlılık ve düşük bağlantı ilkesi
Modüler bir kod tabanını tanımlamanın bir yolu da kuplaj ve cohesion özelliklerini içerir. Bağlantı, modüllerin hangi birbirine bağımlıdır. Bu bağlamda tutarlılık, bir kurumun öğelerinin tek bir modülle ilişkilendirilmesi gerekir. Genel kural olarak, en iyi uygulamaları düşük bağlantı ve yüksek tutarlılık:
- Düşük bağlantı, modüllerin değişiklik gösterir. Böylece, bir modülde yapılan değişikliklerin modül üzerindeki etkisi hiç ya da diğer modüllerin üzerine konuşalım. Modüller, yapay zekanın iç işleyişi hakkında diğer modülleri de inceleyin.
- Yüksek tutarlılık, modüllerin bir dizi koddan oluşması gerektiği anlamına gelir. bir sistem gibi işlev görür. Sorumlulukları açıkça tanımlanmış olmalı ve projenin belirli alan bilgilerinin sınırları içinde olmalıdır. Örnek bir e-kitabı inceleyin bir uygulamadır. Kitap ve ödemeyle ilgili kodları birlikte kullanmak uygun olmayabilir işlevsel alandır. Bu nedenle, aynı modülde
Modül türleri
Modüllerinizi düzenleme şekliniz büyük ölçüde uygulama mimarinize bağlıdır. Şunun altında: aşağıdaki adımları takip ederken uygulamanızda kullanabileceğiniz bazı yaygın modül türleridir: önerilen uygulama mimarimiz.
göz atın.Veri modülleri
Veri modülleri genellikle depo, veri kaynakları ve model sınıfları içerir. İlgili içeriği oluşturmak için kullanılan veri modülünün üç temel sorumluluğu şunlardır:
- Belirli bir alandaki tüm verileri ve iş mantığını kapsülle: Her veri modülünün belirli bir görevi temsil eden verilerin işlenmesinden alan. Birbirleriyle alakalı oldukları sürece birçok veri türünü işleyebilir.
- Depoyu harici bir API olarak kullanıma sunma: Verilerin herkese açık API'si modülün bir depo olması gerektiğini ve uygulamanın geri kalanı.
- Tüm uygulama ayrıntılarını ve veri kaynaklarını dışarıdan gizleyin:
Veri kaynaklarına yalnızca aynı modüldeki depolar tarafından erişilebilir.
Dışarıdan gizli kalırlar. Kotlin'in
private
veyainternal
görünürlük anahtar kelimesi.
![](https://developer.android.google.cn/static/topic/modularization/images/2_data_modules.png?authuser=8&hl=tr)
Özellik modülleri
Özellik, bir uygulamanın işlevselliğinin izole bir parçasıdır. Bu işlev genellikle kaydolma veya ödeme işlemleri gibi birbiriyle yakından alakalı ekranlardan oluşan bir ekran ya da dizi akışı sağlar. Uygulamanızın alt kısmında gezinme çubuğu varsa her bir hedef bir özelliktir.
![](https://developer.android.google.cn/static/topic/modularization/images/2_bottom_bar.png?authuser=8&hl=tr)
Özellikler, uygulamanızdaki ekranlarla veya hedeflerle ilişkilendirilir. Dolayısıyla,
mantıklarını yönetmek için ilişkilendirilmiş bir kullanıcı arayüzü ve ViewModel
belirtin. Tek bir özelliğin tek bir görünüm veya
navigasyon hedefi. Özellik modülleri veri modüllerine bağlıdır.
![](https://developer.android.google.cn/static/topic/modularization/images/2_feature_modules.png?authuser=8&hl=tr)
Uygulama modülleri
Uygulama modülleri, uygulamanın giriş noktalarıdır. Özelliklere göre değişir. modüllerin kullanılabilmesini sağlar ve genellikle kök gezinme sağlar. Tek bir uygulama modülü derlenebilir derleme varyantları sayesinde bir dizi farklı ikili programa bağlanabilir.
![](https://developer.android.google.cn/static/topic/modularization/images/2_demo_full_dep_graph.png?authuser=8&hl=tr)
Uygulamanız otomatik, Wear veya TV gibi birden fazla cihaz türünü hedefliyorsa her biri için bir uygulama modülü tanımlayın. Bu sayede, platforma özgü ve bildirmeyi konuştuk.
![](https://developer.android.google.cn/static/topic/modularization/images/2_wear_dep_graph.png?authuser=8&hl=tr)
Ortak modüller
Temel modüller olarak da bilinen yaygın modüller, diğer modüllerin yaygın olarak kullanılan bir üründür. Gereksizliği azaltırlar ve proje planında belirli bir katmanı kullanır. Aşağıda yaygın modüllere örnekler verilmiştir:
- Kullanıcı arayüzü modülü: Reklam öğenizde özel kullanıcı arayüzü öğeleri veya ayrıntılı marka kullanımı uygulamanız varsa widget koleksiyonunuzu bir modüle yeniden kullanılması gereken tüm özellikler. Böylece, kullanıcı arayüzünüz farklı özellikler. Örneğin temanız merkeziyse Yeniden markalama gerçekleştiğinde sıkıntılı bir yeniden düzenleme sürecidir.
- Analytics modülü: İzleme, çoğu zaman işletme gereksinimlerine göre yazılım mimarisine çok az kafa yorabilir. Analytics izleyiciler genelde alakasız pek çok bileşende kullanılır. Bu sizin için de geçerliyse, ayrı bir analiz modülüne sahip olmak iyi bir fikirdir.
- Ağ modülü: Birçok modül ağ bağlantısı gerektirdiğinde bir http istemcisi sağlamak için özel olarak tasarlanmış bir modül oluşturabilirsiniz. Evet Özellikle istemciniz özel yapılandırmaya ihtiyaç duyduğunda kullanışlıdır.
- Yardımcı program modülü: Yardımcı olarak da bilinen yardımcı programlar genellikle küçük parçalardır uygulamada yeniden kullanılan bir kod grubudur. Yardımcı programlara örnek olarak şunlar verilebilir: test yardımcıları, para birimi biçimlendirme işlevi, e-posta doğrulayıcı veya operatörümüzü kullanabilirsiniz.
Test modülleri
Test modülleri, yalnızca test amaçlı kullanılan Android modülleridir. Modüller, yalnızca test amaçlı kullanılan test kodunu, test kaynaklarını ve testlerin çalıştırılması için gereklidir ve uygulamanın çalışma zamanı boyunca gerekli değildir. Test modülleri, teste özgü kodu ana makineden ayırmak için oluşturulur Bu da modül kodunun yönetilmesini ve bakımını kolaylaştırır.
Test modüllerinin kullanım alanları
Aşağıdaki örneklerde, test modüllerinin uygulandığı durumlar gösterilmektedir çok faydalı olabilir:
Paylaşılan test kodu: Projenizde birden fazla modül varsa ve bunlardan bazıları test kodu birden fazla modül için geçerliyse, test etmek istediğiniz modülünü kullanabilirsiniz. Bu, yinelemeleri azaltmanıza ve testinizi yapmanıza yardımcı olabilir. bakımını kolaylaştırır. Paylaşılan test kodu, yardımcı program sınıflarını veya işlevlerinin yanı sıra simüle edilmiş JSON yanıtları.
Temiz Derleme Yapılandırmaları: Test modüllerini kullanarak kendi
build.gradle
dosyalarına sahip olabilirler. Hayır uygulama modülünüzünbuild.gradle
dosyasını yalnızca testlerle ilgilidir.Entegrasyon Testleri: Test modülleri, entegrasyonu depolamak için kullanılabilir uygulamanızın farklı bölümleri arasındaki etkileşimleri test etmek için kullanılan testler kullanıcı arayüzü, iş mantığı, ağ istekleri ve veritabanı sorguları dahil.
Büyük ölçekli uygulamalar: Test modülleri özellikle karmaşık kod tabanlarına ve birden çok modüle sahip büyük ölçekli uygulamalar. Böyle bir durumda durumlarda, test modülleri kodun düzenini ve sürdürülebilirliğini iyileştirmeye yardımcı olabilir.
![](https://developer.android.google.cn/static/topic/modularization/images/2_test_modules.png?authuser=8&hl=tr)
Modülden modüle iletişime
Modüller nadiren toplam ayrımda bulunur ve genellikle diğer modülleri ve iyi bir fırsattır. Modüller etkinken bile bağlantıyı düşük tutmak önemlidir. ve sık sık bilgi alışverişinde bulunur. Bazen doğrudan olduğu gibi iki modül arasındaki iletişimin mimari kısıtlamaları ekleyin. Bunu yapmak, örneğin döngüsel bir ve bildirmeyi konuştuk.
![](https://developer.android.google.cn/static/topic/modularization/images/2_mediator.png?authuser=8&hl=tr)
Bu sorunun üstesinden gelmek için, uyumlulaştırma arasında geçiş yapıyor. Arabulucu modülü hem ve gerektiği şekilde iletmeniz gerekir. Örnek uygulamamızda ödeme ekranın, etkinliğin kaynağı olsa da hangi kitabı satın alacağını bilmesi gerekir farklı bir özelliğin parçası olan ayrı bir ekran. Bu durumda, aracı, gezinme grafiğine sahip olan modüldür (genellikle bir uygulama modülü). Bu örnekte, verileri ana sayfa özelliğinden ödeme özelliğini kullanmak için Gezinme bileşenini kullanın.
navController.navigate("checkout/$bookId")
Ödeme hedefi, bir kitap kimliğini bağımsız değişken olarak alır ve
ve kitapla ilgili bilgileri getirir. Şu işlemler için kayıt durumu işleyicisini kullanabilirsiniz:
bir hedef özelliğinin ViewModel
içindeki gezinme bağımsız değişkenlerini alma.
class CheckoutViewModel(savedStateHandle: SavedStateHandle, …) : ViewModel() {
val uiState: StateFlow<CheckoutUiState> =
savedStateHandle.getStateFlow<String>("bookId", "").map { bookId ->
// produce UI state calling bookRepository.getBook(bookId)
}
…
}
Nesneleri, gezinme bağımsız değişkenleri olarak iletmemeniz gerekir. Bunun yerine basit kimlikler kullanın . Bu şekilde bağıntıyı düşük tutarak tek doğru kaynağı da ihlal etmemiş olursunuz. gösteriyoruz.
Aşağıdaki örnekte her iki özellik modülü de aynı veri modülüne dayanır. Bu Arabulucu modülünün ihtiyaç duyduğu veri miktarını en aza indirmeyi mümkün kılar ve modüller arasındaki bağı düşük tutuyor. Tüm bu bilgileri modüllerin, temel kimlikler değişimi ile kaynakları bir paylaşılan veri modülü.
![](https://developer.android.google.cn/static/topic/modularization/images/2_shared_data.png?authuser=8&hl=tr)
Bağımlılığı ters çevirme
Bağımlılığı ters çevirme, kodunuzu soyutlamanın tam anlamıyla somut bir uygulamadan ayrıdır.
- Soyutlama: Hesabınızdaki bileşenlerin veya modüllerin birbirleriyle etkileşime girdiğini gösterir. Soyutlama modülleri bir projenin arayüzler ve modeller içerir.
- Beton uygulama: Soyutlama modülüne bağlı modüller ve bir soyutlama davranışını uygulamaktır.
Soyutlama modülünde tanımlanan davranışa dayanan modüller yalnızca soyutlamanın kendisine bağlıdır.
![](https://developer.android.google.cn/static/topic/modularization/images/2_di_concept.png?authuser=8&hl=tr)
Örnek
Çalışması için veritabanına ihtiyaç duyan bir özellik modülü düşünün. Özellik modülü veri tabanının uygulanma şekliyle ilgili olan; yerel oda veritabanı veya uzak Firestore örneğidir. Yalnızca uygulama verilerini saklayıp okuması gerekir.
Bunu başarmak için özellik modülü, yerine soyutlama modülüne kıyaslandığında daha doğru sonuçlar elde eder. Bu soyutlama, uygulamanın veritabanı API'sidir. Diğer bir deyişle, bir web sitesi geliştirmek için Böylece özellik modülünün temel uygulama ayrıntılarını öğrenin.
Somut uygulama modülü, Özetleme modülünde tanımlanan API'ler. Bunu yapabilmemiz için de modülü de soyutlama modülüne bağlıdır.
Bağımlılık yerleştirme
Şimdiye kadar, özellik modülünün Google Etiket Yöneticisi'yle modülünü kullanabilirsiniz. Bu soruya cevap Bağımlılık Yerleştirme şeklindedir. Özellik modülü, gerekli veritabanı örneğini doğrudan oluşturmaz. Bunun yerine hangi bağımlılıklara ihtiyacı olduğunu belirler. Bu bağımlılıklar daha sonra projenin harici olarak, genellikle uygulama modülü içinde bulunur.
releaseImplementation(project(":database:impl:firestore"))
debugImplementation(project(":database:impl:room"))
androidTestImplementation(project(":database:impl:mock"))
Avantajlar
API'lerinizi ve uygulamalarını ayırmanın avantajları şunlardır:
- Değiştirilebilirlik: API ve uygulamanın birbirinden net bir şekilde ayrıldığını gösterir. modüllerinde, aynı API için birden fazla uygulama geliştirebilir ve bunlar arasında API'yı kullanan kodu değiştirmeden. Bu özellik, özellikle de farklı türde bir e-posta bağlamlardaki kapasiteleri veya davranışları ifade eder. Örneğin, gerçek bir üretim uygulamasına kıyasla test amaçlı olarak uygulanmasını sağlar.
- Ayrıştırma: Ayırma, soyutlama kullanan modüllerin herhangi bir teknolojiye bağlı olabilir. Veritabanınızı daha sonra Firestore'a ayırmak daha kolaydır, çünkü değişiklikler yalnızca işlemi yapan belirli modülde (uygulama modülünde) gerçekleştiğinde veritabanınızın API'sini kullanarak diğer modülleri etkileyebilir.
- Test edilebilirlik: API'leri uygulamalarından ayırmak, kolaylaştırır. API sözleşmelerine karşı test durumları yazabilirsiniz. Şunları yapabilirsiniz: çeşitli senaryoları ve uç durumları test etmek için farklı uygulamalar da kullanır. örnek uygulamalar dahil.
- İyileştirilmiş derleme performansı: Bir API ile uygulamadaki değişiklikler, uygulama sürecinin modülün özelliklerine bağlı olarak derleme sistemini, API modülü. Bu da derleme sürelerinin daha hızlı olmasını ve üretkenliğin artmasını sağlar. Özellikle derleme sürelerinin önemli olabileceği büyük projelerde bunun yardımı dokunur.
Ne zaman ayrılmalı?
API'lerinizi şu durumlardan biridir:
- Çeşitli özellikler: Sisteminizin bazı bölümlerini farklı dillerde uygulayabiliyorsanız şekilde, net bir API, farklı öğelerin birbirinin yerine hakkında bilgi edindiniz. Örneğin, OpenGL kullanan bir oluşturma sisteminiz ya da Vulkan, Play veya şirket içi faturalandırmanız ile çalışan bir faturalandırma sistemi API'ye gidin.
- Birden çok uygulama: Google Haritalar'ı kullanarak birden fazla uygulama özellikleri tanımlamak için, ortak API'ler tanımlayabilir ve uygulamalar geliştirebilir.
- Bağımsız ekipler: Bu ayrım, farklı geliştiricilerin veya ekiplerin kod tabanının farklı bölümlerinde aynı anda çalışmanızı sağlar. Geliştiricilerin API sözleşmelerini anlama ve doğru kullanma konusunda bilgi sahibi olacaksınız. Google'ın diğer modüllerin uygulama ayrıntılarıyla ilgilenmek zorunda kalmazsınız.
- Büyük kod tabanı: Kod tabanı büyük veya karmaşık olduğunda, API'yi ayırmak kodu daha yönetilebilir hale getirir. Hedeflerinize ulaşmanız için daha ayrıntılı, anlaşılabilir ve bakımı yapılabilir birimlere ayırmanızı sağlar.
Nasıl uygulanır?
Bağımlılığı ters çevirmeyi uygulamak için aşağıdaki adımları izleyin:
- Özet modülü oluştur: Bu modülde API'ler (arayüzler) özelliğinizin davranışını tanımlayan).
- Uygulama modülleri oluşturun: Uygulama modüllerinde
ve bir soyutlama davranışını uygulayın.
Şekil 10. Uygulama modülleri soyutlama modülüne bağlı. - Üst seviye modülleri soyutlama modüllerine bağımlı hale getir:
bağlı olarak, modüllerinizi
soyutlama modüllerini kullanır. Üst seviye modüllerin uygulamayı bilmesi gerekmez
yalnızca sözleşmeye (API) ihtiyaçları vardır.
Şekil 11. Üst düzey modüller uygulamaya değil soyutlamalara bağlıdır. - Uygulama modülünü sağlama: Son olarak,
nasıl uygulayacağınızı öğreneceksiniz. Özel uygulama, proje yöneticisinin
ancak uygulama modülü bunu yapmak için genellikle iyi bir yerdir.
Uygulamayı sağlamak amacıyla, bunu seçtiğiniz metrik için bir bağımlılık
derleme varyantı veya test kaynağı grubu olabilir.
Şekil 12. Uygulama modülü, gerçek uygulamaları mümkün kılar.
Genel en iyi uygulamalar
Başta da belirttiğimiz gibi, başarılı bir proje için planlama yapmanın çok modüllü bir uygulamadır. Birçok yazılım mimarisi gibi bir uygulamayı modülerleştirmenin birçok yolu var. Bununla birlikte, aşağıdaki genel bilgiler önerileri, kodunuzu daha okunabilir, bakımını yapabilir ve test edilebilir.
Yapılandırmanızın tutarlı olmasını sağlayın
Her modül yapılandırma ek yükü getirir. Modüllerinizin sayısı belirli bir eşiğe ulaştığında tutarlı yapılandırma yönetimi, isteyebilirsiniz. Örneğin, modüllerin aynı bağımlılığı kullanması önemlidir. sürümünü değil. Sadece bir teste giriş yapmak için çok sayıda modülü güncellemeniz bu, yalnızca bir çaba değil, aynı zamanda potansiyel riskler için değildir. Bu sorunu çözmek için gradle'ın araçlarından birini kullanarak yapılandırmanızı merkezileştirin:
- Sürüm katalogları, tür güvenli bir bağımlılık listesidir senkronizasyon sırasında Gradle tarafından oluşturulur. Burası tüm ticari marka bilgilerinizi beyan edebileceğiniz ve projedeki tüm modüllerde kullanılabilir olduğundan emin olmalısınız.
- Modüller arasında derleme mantığını paylaşmak için kural eklentileri kullanın.
Mümkün olduğunca az kullanıma sunun
Bir modülün herkese açık arayüzü minimum düzeyde olmalı ve yalnızca
en iyi uygulamalar. Uygulama ayrıntılarını dışarı sızdırmamalıdır. Kapsam
ele almaya çalışıyoruz. Kotlin private
veya internal
özelliğini kullanın
görünürlük kapsamını ayarlayabilirsiniz. Bildirimde
bağımlılıklarını api
yerine implementation
olarak tercih edin. İkincisi
Modülünüzün tüketicilerine geçişli bağımlılıklar sunar. Kullanım
modüllerin sayısını azalttığı için uygulama, derleme süresini iyileştirebilir
gerekiyor.
Kotlin ve Java modülleri
Android Studio'nun desteklediği üç temel modül türü vardır:
- Uygulama modülleri, uygulamanızın giriş noktalarıdır. Şunları içerebilir:
kaynak kodu, kaynaklar ve öğeler ile bir
AndroidManifest.xml
. Çıktı uygulama modülü bir Android App Bundle (AAB) veya Android Uygulama Paketiyse (APK). - Kitaplık modülleri, uygulama modülleriyle aynı içeriğe sahiptir. Bunlar: diğer Android modülleri tarafından bağımlılık olarak kullanıldığını görüyoruz. Bir kitaplık modülünün çıkışı Android Arşivi (AAR), yapısal olarak uygulama modülleriyle aynıdır, ancak daha sonra diğer kullanıcılar tarafından kullanılabilecek bir Android Arşivi (AAR) dosyasına modüllerini bağımlılık olarak görebiliriz. Kitaplık modülü sayesinde birçok uygulama modülünde aynı mantığı ve kaynakları kapsülleyip yeniden kullanabilirsiniz.
- Kotlin ve Java kitaplıkları herhangi bir Android kaynağı, öğesi veya manifest dosyalarında belirtilen dosyalar.
Android modüllerin ek yük getirmesi tercih edilir; bu nedenle, Olabildiğince çok Kotlin veya Java türünü.