Jetpack Compose 1.7 Production Mimarisi

Jetpack Compose 1.7, Android native UI’ın 2026’daki resmi ve baskın paradigmasıdır. Google’ın 2024 yılında XML layout sistemini “legacy” olarak işaretlemesinden sonra, yeni Android uygulamalarının %78’i tamamen Compose ile yazılıyor (Google I/O 2025 verisi). Ancak production seviyesinde Compose kullanımı, basit `@Composable` fonksiyonlar yazmaktan çok daha derindir; recomposition optimizasyonu, stable parameters, derivedStateOf kullanımı ve baseline profiles olmadan Compose uygulamaları XML eşdeğerlerinden %40 daha yavaş çalışabilir (Android Developers Performance Guide, 2026). Konuyla ilişkili olarak Jetpack Compose Multiplatform 2026: Android ve iOS Rehber rehberimiz detaylı incelemeyi içerir.

Bu yazıda, Compose 1.7’nin getirdiği shared element transitions, lazy layouts iyileştirmeleri ve Strong Skipping Mode’u production pattern olarak inceliyoruz. Türkiye’de Trendyol, Getir ve Hepsiburada gibi yüksek trafikli uygulamaların Compose’a geçiş kararları, frame timing metrikleri ve “jank rate” optimizasyonu üzerinden somut sayılarla anlatılıyor.

Jetpack Compose 1.7 Production Mimarisi

Compose 1.7, Mayıs 2024’te stabil sürüm olarak yayınlandı ve 2026’da Android Studio Iguana ile birlikte default UI toolkit’i konumuna geçti. Önceki sürümlerden farklı olarak, 1.7 ile gelen Strong Skipping Mode, instable parameter’lı composable’ların bile recomposition’dan kaçınmasını sağlıyor. Bu, eski 1.5 ve 1.6 sürümlerinde production’da en büyük performans yarası olan “unnecessary recomposition” sorununu %62 oranında azaltıyor (JetBrains Compose State 2025 raporu).

Production’da Compose mimarisi üç katmanda kurulur. UI katmanı sadece composable fonksiyonlardan oluşur ve hiçbir business logic taşımaz. State holder katmanı, ViewModel ya da Jetpack Compose’un kendi rememberSaveable’ı üzerinden state’i yönetir. Repository katmanı ise Room, Retrofit ve DataStore üzerinden veri akışını sağlar. Bu üç katmanın net ayrılması, ekip büyüdüğünde test edilebilirliği %3,5 kat artırıyor.

Recomposition Optimizasyonu ve Stable Annotations

Production Compose’un en kritik kavramı recomposition’dur. Bir composable’ın gereksiz yere yeniden çalıştırılması, 60 FPS hedefini 45 FPS’e düşürebilir. Compose Compiler 1.7, otomatik olarak class’ları “stable” ya da “unstable” diye işaretler. Ancak custom data class’lar ve özellikle List gibi koleksiyonlar varsayılan olarak unstable kabul edilir; bu da listeyi her ekranda yeniden compose etmeye yol açar.

Çözüm üç katmanlıdır. Birincisi, @Stable ya da @Immutable anotasyonlarını custom class’lara eklemek. İkincisi, ImmutableList ve PersistentList (kotlinx.collections.immutable) kullanmak. Üçüncüsü, derivedStateOf ile yalnızca türetilmiş değerin değiştiği durumlarda recomposition tetiklemek.

@Immutable
data class CartItem(
    val productId: String,
    val title: String,
    val price: BigDecimal,
    val quantity: Int
)

@Composable
fun CartScreen(items: ImmutableList) {
    val total by remember(items) {
        derivedStateOf { items.sumOf { it.price * it.quantity.toBigDecimal() } }
    }
    LazyColumn { items(items, key = { it.productId }) { CartRow(it) } }
}

Bu pattern, Trendyol’un sepet ekranında frame timing P99 değerini 38ms’ten 14ms’e indirdi (Android Dev Summit Türkiye 2025 sunumu). LazyColumn’da key parametresinin verilmesi de animasyon stabilitesi ve recomposition skip için kritik; key vermeden yapılan listeler scroll sırasında %35 daha fazla CPU tüketir.

Baseline Profiles ile Cold Start Optimizasyonu

Baseline Profiles, Compose uygulamalarının cold start performansını iyileştiren en kritik araçtır. Macrobenchmark library’si üzerinden recorded olan kritik kullanıcı yollarını AOT (Ahead-Of-Time) compile eden bu sistem, Compose uygulamalarında cold start’ı %30-45 hızlandırır (Android Developers Performance Documentation, 2026).

Aşağıdaki tablo, baseline profile öncesi ve sonrası cold start sürelerini gerçek production uygulamalarından gösteriyor:

Baseline profile oluşturma sürecinde, en kritik kullanıcı yolları (örneğin uygulama açılışı → ana ekran → ürün listesi → ürün detayı) Macrobenchmark testleri içinde tanımlanır. Bu testler `./gradlew :benchmark:connectedReleaseAndroidTest` ile çalıştırılır ve `baseline-prof.txt` dosyası üretilir. Bu dosya `app/src/main/baseline-prof.txt` altına konulduktan sonra release build’de otomatik olarak AOT compile sırasında kullanılır.

State Management: Compose State + ViewModel Pattern

Compose 1.7 ile state management’ta üç ana pattern geçerli. Lokal state için remember ve rememberSaveable yeterlidir; ekran döndürmesinden sağ çıkması gereken küçük state’ler için rememberSaveable tercih edilir. Ekran seviyesi state için ViewModel kullanılır; bu pattern Android’in mimari önerisidir ve process death sonrası state restoration sağlar. Cross-screen state için ise Hilt ile injected singleton repository ve StateFlow tercih edilir.

• remember + mutableStateOf: Tek composable scope’unda kalan UI state için. Örnek: bir butonun expanded/collapsed durumu, text field’ın aktif değeri.
• rememberSaveable: Configuration change’lerden sağ çıkması gereken küçük state. Saver protokolü ile custom class’lar da saklanabilir.
• ViewModel + StateFlow: Ekran seviyesi business state. collectAsStateWithLifecycle() ile lifecycle-aware collect yapılır.
• Hilt + Repository: Cross-screen state ve dependency injection. Singleton scope’da paylaşılan veri için.

collectAsState yerine collectAsStateWithLifecycle() kullanmak production’da kritik; standart collectAsState, ekran background’a gittiğinde bile aktif kalır ve gereksiz CPU/network kullanır. Lifecycle-aware versiyon, Lifecycle.State.STARTED altına düştüğünde collection’ı askıya alır. Bu tek değişiklik, Hepsiburada’nın background battery drain metriklerini %22 iyileştirdi (Hepsiburada Mobil Tech Blog, 2025).

Compose Navigation 2.8 ve Type-Safe Routes

Compose Navigation 2.8 (2025 Q4 sürümü), 2026’da string-based route tanımını tamamen deprecate etti. Yeni Type-Safe Navigation API’si, kotlinx.serialization üzerine inşa edilmiş ve compile-time’da route doğruluğunu garanti ediyor. Bu, production’da en yaygın bug kaynaklarından biri olan “yanlış string route” hatalarını sıfıra indiriyor.

@Serializable
data class ProductDetail(val productId: String, val variantId: String? = null)

@Serializable
object Home

NavHost(navController, startDestination = Home) {
    composable { HomeScreen(onProductClick = { id -> navController.navigate(ProductDetail(id)) }) }
    composable { backStackEntry ->
        val args = backStackEntry.toRoute()
        ProductDetailScreen(productId = args.productId)
    }
}

Type-safe navigation, deep link senaryolarında da büyük kazanım sağlıyor. Önceki versiyonlarda deep link parsing manuel olarak yapılıyor ve hatalı URL’lerde crash oluyordu; 2.8 ile birlikte deep link’ler de kotlinx.serialization üzerinden parse ediliyor.

Strong Skipping Mode ve Compose Compiler 2.0

Compose Compiler 2.0 (Kotlin 2.0 ile birlikte 2025’te yayınlandı) Strong Skipping Mode’u default olarak getirdi. Bu mode’da, unstable parameter’lı bir composable bile, parameter referansları değişmediği sürece skip ediliyor. Sonuç olarak, eskiden manuel olarak @Stable işaretlememiz gereken birçok class artık otomatik olarak optimize ediliyor.

Strong Skipping’in en büyük faydası lambda parameter’larda görülüyor. Compose’da en yaygın anti-pattern, her recomposition’da yeni bir lambda instance oluşturulması ve bu yüzden child composable’ların skip edilememesiydi. Strong Skipping ile lambda’lar otomatik olarak `remember` ediliyor, yani manuel `remember { { … } }` pattern’i artık gerekmiyor.

Android Developer Relations ekibinden Chris Banes, 2025 Android Dev Summit konuşmasında şu tespiti yapmıştı: “Strong Skipping ile birlikte, çoğu Compose uygulamasında manuel optimizasyon ihtiyacı %70 azaldı. Artık tek odaklanmanız gereken stable data class’lar ve doğru key kullanımı.” Türkiye’de bu pattern’i en agresif şekilde uygulayan ekip Getir Compose ekibi oldu ve uygulama boyutunu da %12 küçülttüler.

Modifier Performance ve composed{} Tuzakları

Modifier zincirlerinin sırası ve composed { } kullanımı, Compose performansını doğrudan etkiler. Production’da en yaygın hata, custom modifier’ları composed { } içinde yazmaktır; her recomposition’da yeni modifier instance oluşur ve down-stream child composable’lar skip edilemez.

• Modifier.Node API kullan: Compose 1.7 ile gelen yeni API, composed { }’a göre %4x daha hızlı.
• Modifier sırasını optimize et: .padding() önce, .clickable() sonra; aksi halde click area padding’i içermez.
• Aynı modifier’ı remember et: Modifier extension function’ları her composable çağrısında yeniden yaratılır.
• graphicsLayer kullan: Animasyonlar için Modifier.scale yerine Modifier.graphicsLayer { scaleX = …; scaleY = … } %40 daha verimli.

Modifier.Node API’sine geçiş, özellikle custom drawing yapan composable’larda kritik. Eski composed{} API’si her composable’da yeni state allocate ederken, Node API singleton tabanlı çalışır ve composable graph’ı boyunca state’i paylaşır. Trendyol’un product card composable’ı, Node API’sine geçtikten sonra scroll smoothness’ı 58 FPS’ten 60 FPS’e sabitlendi.

Compose Multiplatform Entegrasyonu

JetBrains’in Compose Multiplatform (CMP) 1.7’si, 2026’da iOS desteğiyle de stabil hale geldi. Android Compose 1.7 kodu, %85 oranında CMP’ye taşınabiliyor (JetBrains CMP Migration Report 2025). Bu, Türkiye’deki startup’lar için ciddi bir cazibe yaratıyor; tek Compose kod tabanından iOS ve Android’e deploy etme imkanı.

Ancak production’da CMP’ye geçiş kararı verilirken üç kritik soru sorulmalı. Birincisi, native iOS UI patterns’a ne kadar bağımlısınız? Eğer uygulamanız Apple Human Interface Guidelines’a sıkı sıkıya bağlıysa, native SwiftUI tercih edilmeli. İkincisi, native API’lere erişim ihtiyacınız ne kadar yüksek? Compose Multiplatform’da iOS-specific API’ler için expect/actual pattern’i kullanılması gerekiyor. Üçüncüsü, ekip bilgisi nasıl dağılmış? CMP’de Kotlin/Native bilgisi şart, bu da iOS developer’lardan ek learning curve gerektirir.

Testing Stratejisi: createComposeRule + Maestro

Compose testing 2026’da iki katmanlı bir piramide oturdu. Unit/UI testleri için createComposeRule ile composable seviyesinde test yazılıyor; assertion’lar onNodeWithText, onNodeWithTag gibi semantic API’ler üzerinden. E2E testleri için Maestro tercih ediliyor; YAML tabanlı, flaky’lik oranı %5 altında kalan modern bir araç.

Paparazzi, Cash App ekibinin geliştirdiği screenshot test library’si, Compose composable’larını emulator olmadan render edebiliyor. Bu, CI/CD pipeline’larında test sürelerini %75 azaltıyor. Türkiye’de Hepsiburada ve Trendyol bu pattern’i agresif şekilde kullanıyor; her PR’da otomatik snapshot diff testleri çalışıyor.

Sıkça Sorulan Sorular

Kurumsal Jetpack Compose Dönüşümünde Tipik Sorunlar

Türkiye’de büyük şirketlerin Compose geçişlerinde gözlemlediğim üç ana problem var. Birincisi, ekip eğitimi yetersizliği. XML mindset’inden Compose’un deklaratif paradigmasına geçiş minimum 6-8 hafta tam zamanlı pratik istiyor; bu sürede ekipte 1-2 senior’un mentor olarak ayrılması şart. Ders alınmayan en pahalı hata, “ekibe iki kitap verip işine bak” demek.

İkincisi, recomposition optimizasyonunu sona bırakmak. Compose’da performance, mimaride bir “polish” katmanı değil; en başından stable state design ile başlanmalı. Aksi halde 6 ay sonra production’da jank fark edildiğinde, yapısal refactor maliyeti yeniden yazmakla aynı.

Üçüncüsü, interop pattern’inin yanlış uygulanması. XML ve Compose interop’unda en yaygın hata, RecyclerView içine ComposeView koymak ve her item için yeni bir Compose hierarchy yaratmaktır; bu pattern scroll performansını %60 düşürür. Doğrusu, RecyclerView’ı tamamen LazyColumn ile değiştirmek ya da ComposeView’ları parent seviyede tutmaktır.

Bir banka müşterimde, eski XML uygulamaya 18 ay boyunca Compose ekleme deneyimi yaşadık. İlk altı ay tamamen “interop hataları” düzeltmekle geçti. Sonunda öğrendiğimiz ders şuydu: Compose’a geçişi iki şekilde planlayın; ya tüm ekran Compose, ya tüm ekran XML. Aynı ekran içinde karışım kısa vadeli pragmatik gibi görünse de, uzun vadeli teknik borç fabrikasıdır. — Ömer Önal

Sonuç

Jetpack Compose 1.7, 2026’da Android native UI için tek doğru tercih. Strong Skipping Mode, Compose Compiler 2.0 ve Modifier.Node API gibi gelişmeler sayesinde performance dezavantajları neredeyse tamamen elimine edildi. Production’da başarı için üç temel kural geçerli: state design’ı en başından stable yap, baseline profiles’ı CI/CD’ye entegre et, ve interop pattern’ini “tüm ekran” granülerliğinde uygula. Bu üç kuralı uygulayan ekipler, Compose’un developer velocity faydalarını eksiksiz alıyor; uygulamamayanlar ise XML’den daha yavaş ve daha kırılgan uygulamalarla karşılaşıyor.

Ekibinizin Compose geçiş roadmap’ini, eğitim planını ve mimari kararlarını birlikte tasarlayalım. İletişim sayfasından bana ulaşın, 30 dakikalık ücretsiz keşif görüşmesinde mevcut durumunuzu analiz edip somut bir geçiş planı çıkaralım.