Büyüyen Android Uygulamalarında Kod Tabanı Evrimi: Mimari Yapılanma, Compose Pratikleri ve Kalite Metrikleri

Google'ın resmî uygulama mimarisi rehberi iki zorunlu katman tarif ediyor: UI katmanı ve data katmanı; domain katmanı ise isteğe bağlı. UI katmanında ViewModel ekran durumunu tek bir değişmez UiState nesnesi olarak sunar, Composable yalnızca bu durumu çizer ve kullanıcı olaylarını yukarı iletir. Buna tek yönlü veri akışı (UDF) denir. Data katmanında repository'ler veri kaynaklarını saklar ve dışarıya Flow ya da suspend fonksiyonlar açar.

Büyüyen projelerde sorun, bu sınırların zamanla delinmesidir. Tipik belirti: bir Composable içinde doğrudan Retrofit servisi ya da Room DAO çağrılması, veya ViewModel'in Android Context taşıması. Google'ın güncel önerileri bunu açıkça söylüyor: Composable ya da ViewModel veri kaynağıyla doğrudan konuşmamalı, ViewModel'e Context ya da Application verilmemeli, durum tek bir StateFlow olarak sunulmalı. Domain katmanını her projeye zorla eklemek de ayrı bir anti-pattern; yalnızca birden fazla ViewModel'in paylaştığı ya da karmaşık iş kuralları varsa use case sınıfları anlam kazanır.

Somut bir eşik: bir ViewModel 400 satırı ya da 8-10 bağımlılığı aşıyorsa, genelde iki ekranın sorumluluğunu taşıyordur ve bölünmeyi hak eder.

Son 12 ayda Android araç zinciri büyük bir sürüm atladı. Navigation 3, Kasım 2025'te 1.0 ile stabil oldu, Nisan 2026'da 1.1 ile scene'ler arası shared element geçişlerini, 23 Eylül 2026'da 1.2 ile Result API'yi ve KMP deep link desteğini getirdi. Compose kütüphaneleri 7 Ekim 2026 itibarıyla 1.12.1, Material 3 ise 1.4.0 sürümünde. Kotlin 2.4.0 Haziran 2026'da çıktı, en güncel sürüm 8 Ekim'de yayımlanan 2.4.21. AGP 9 ile yerleşik Kotlin desteği ve yeni DSL varsayılan oldu, eski varyant API'si gizlendi; Eylül 2026'da çıkan AGP 9.4, AGP 10'da yeni Variant API'nin zorunlu olacağını hatırlatıyor. Google Play tarafında çökme için yüzde 1,09 ve ANR için yüzde 0,47 eşikleri sürüyor; aşırı partial wake lock için yüzde 5'lik session eşiği de görünürlüğü etkileyebiliyor. Şubat 2027'den itibaren bellek ve kod optimizasyonu eşikleri de bu listeye girecek. Agent tarafında Android Studio, Eylül 2026'da ACP üzerinden Claude Agent, Codex ve Antigravity'yi bağlayan Bring Your Own Agent önizlemesini açtı; Android CLI ise Ekim'de 20'den fazla resmî SKILL.md skill'i ve uzak cihaz akışı ekledi.

Tek bir app modülünde 200 bin satır kod olduğunda iki şey olur: her değişiklik tüm modülü yeniden derletir ve herkes her şeye erişebilir. Modülerleştirme her iki sorunu birlikte çözer. Google'ın Now in Android örnek projesi yaygın bir şablon sunuyor: feature modülleri (ör. feature:profile), paylaşılan core modülleri (core:data, core:designsystem, core:network) ve bunları birleştiren app modülü.

Büyük ekiplerde bir adım daha atılıyor: her feature için api ve impl modülleri. Diğer feature'lar yalnızca api modülüne bağımlı olur, böylece impl içindeki değişiklik yalnızca o modülü yeniden derletir. Ortak Gradle yapılandırmasını tekrar tekrar yazmak yerine build-logic altında convention plugin'ler kullanılır; 40 modüllü bir projede bu, yüzlerce satır kopya build dosyasını ortadan kaldırır. AGP 9 ile bu altyapının bakımı da değişti: yerleşik Kotlin varsayılan, eski android DSL sınıfları gizlendi ve AGP 10'da yeni Variant API zorunlu olacak. Convention plugin'leriniz hâlâ eski applicationVariants API'sine dayanıyorsa, AGP yükseltmesinin asıl maliyeti orada çıkar.

Anti-pattern: modülleri teknik katmana göre bölmek (tüm ViewModel'ler bir modülde, tüm repository'ler başka birinde). Bu yapı derleme izolasyonu sağlamaz ve her feature değişikliği birden fazla modüle dokunur.

Compose performans sorunlarının çoğu, değişmeyen verinin ekranı yeniden oluşturmasından (recomposition) kaynaklanır. Compose, parametreleri değişmeyen Composable'ları atlayabilir; bunun için parametrelerin kararlı (stable) olduğunu bilmesi gerekir. Kotlin 2.0.20 ile varsayılan gelen strong skipping modu burada büyük fark yarattı: artık kararsız parametreli Composable'lar da atlanabiliyor, kararsız parametreler referans eşitliğiyle karşılaştırılıyor ve Composable içindeki lambda'lar otomatik olarak remember ile hatırlanıyor.

Yine de tuzaklar bitmedi. Her recomposition'da yeni bir List oluşturup aşağı geçirmek, referans eşitliğini bozduğu için atlamayı engeller. Çözüm, durumu ViewModel'de bir kez üretip aynı örneği korumak ya da kotlinx.collections.immutable koleksiyonlarını kullanmaktır. Hızlı değişen değerleri (kaydırma konumu gibi) mümkün olan en geç aşamada, ör. Modifier.offset'in lambda sürümünde okumak, recomposition'ı layout ya da çizim aşamasına iter.

Teşhis için Layout Inspector'daki recomposition sayaçları ve Compose compiler'ın ürettiği stabilite raporları birlikte kullanılmalı.

Navigation 3, Kasım 2025'te 1.0 sürümüyle stabil oldu ve Compose için sıfırdan tasarlandı. Nisan 2026'da 1.1 scene'ler arası shared element geçişlerini, Eylül 2026'da 1.2 Result API'sini, KMP deep link desteğini ve öngörülü geri hareketi için yardımcıları ekledi. Google'ın mimari önerileri de artık tek activity ve Navigation 3'ü açıkça tavsiye ediyor. En büyük fark, geri yığının (back stack) artık kütüphanenin değil sizin elinizde olması: ekranları temsil eden anahtarlardan oluşan bir listeyi kendiniz tutuyorsunuz, NavDisplay bu listeyi gözlemleyip ilgili ekranı çiziyor. Navigation 2'deki NavController'ın iç durumu yüzünden zorlaşan “tek doğruluk kaynağı” sorunu böylece ortadan kalkıyor.

Büyüyen uygulamalar için iki kazanç öne çıkıyor. Birincisi test edilebilirlik: geri yığın düz bir Kotlin listesi olduğu için navigasyon mantığını birim testlerle doğrulamak kolaylaşıyor. İkincisi Scenes API: tablet ve katlanabilir cihazlarda liste-detay gibi çok bölmeli düzenleri aynı navigasyon yapısıyla kurabiliyorsunuz.

Geçiş için gerçekçi bir yaklaşım, her şeyi bir anda taşımak yerine yeni feature modüllerini Navigation 3 ile yazmak ve eski grafiği kademeli küçültmek. Anti-pattern: tür güvenli anahtarlar yerine string rotalarla devam edip argümanları elle ayrıştırmak.

Kalite tartışmasını görüşe değil sayıya bağlamanın en kolay yolu, Google Play'in kendi eşikleri. Android vitals'ta kullanıcının fark ettiği çökme oranı için genel kötü davranış eşiği yüzde 1,09, ANR oranı için yüzde 0,47; tek bir telefon modelinde ise her ikisi için yüzde 8. Play bu değerleri son 28 günün ortalamasıyla değerlendiriyor ve eşiği aşan uygulamaların mağaza görünürlüğü etkilenebiliyor. Listeye pil de girdi: arka planda 24 saatte toplam 2 saati aşan partial wake lock “aşırı” sayılıyor ve bu durum session'ların yüzde 5'inden fazlasında görülürse görünürlük etkilenebiliyor. Google ayrıca Şubat 2027'den itibaren bellek kullanımı, bitmap belleği ve kod optimizasyonu eşiklerinin de görünürlüğe yansıyabileceğini duyurdu.

Bu metriklerin yanına iki performans metriği eklemek gerekir: soğuk başlangıç süresi ve yavaş ya da donmuş kare oranı. Macrobenchmark ile CI'da başlangıç ve kaydırma testleri koşup sonuçları her sürümde karşılaştırmak, regresyonu kullanıcıdan önce yakalar. Baseline Profiles, uygulamanın kritik yollarını önceden derleyerek ilk açılışta yorumlanan kod miktarını azaltır; Google ilk açılıştan itibaren yaklaşık yüzde 30 kod çalıştırma hızlanması raporluyor, Startup Profiles ise başlangıca yaklaşık yüzde 15 daha ekleyebiliyor.

Pratik öneri: her metrik için bir bütçe belirleyin, ör. orta segment test cihazında soğuk açılış 1,5 saniyenin altında, ve bütçeyi aşan PR'ı otomatik işaretleyin.

Mimari kurallar bir wiki sayfasında yaşadığı sürece, büyüyen ekipte ilk yoğun sprintte delinir. AI kod asistanları üretim hızını artırdıkça bu daha da belirgin hâle geliyor: model, çalışan ama katman sınırını ihlal eden kodu kolayca üretebiliyor. Bu yüzden kuralların CI'da çalışan kontrollere dönüşmesi gerekir. Meta'nın Instagram Direct ekibinin Eylül 2026'da Google ile paylaştığı vaka bunu sayıya döküyor: sınırları mimarinin kendisine gömen, durumu yalnızca UiState ile alan Compose-first yapıya geçilen ekranlarda UI kodu yüzde 50 küçüldü, tipik bir Agent session'ınun token maliyeti yüzde 33 düştü. Ekibin vardığı sonuç, skill ve guardrail'lerin token harcadığı ve atlatılabildiği, doğru yolu kolay kılan mimarinin ise kalıcı olduğu.

Üç katmanlı bir koruma işe yarıyor. Birincisi statik analiz: detekt ve Android Lint, Compose'a özgü kural setleriyle birlikte. İkincisi mimari testler: Konsist gibi araçlarla “feature modülleri birbirinin impl modülüne bağımlı olamaz” ya da “ViewModel sınıfları Context almaz” gibi kuralları birim test olarak yazmak. Üçüncüsü modül bağımlılık grafiğinin kendisini denetlemek; döngüsel ya da yasak bağımlılık eklenince build kırılmalı.

Build sağlığı da kalite metriğidir. Gradle configuration cache ve build cache açık olmalı, temiz ve artımlı derleme süreleri haftalık izlenmeli. Artımlı derlemesi 2 dakikayı geçen bir proje, geliştiricinin gün içinde onlarca kez beklemesi demek.