Android Jetpack Compose Performance 2026 yılında production kalitesi için kritik beceri haline geldi. Google I/O 2025 keynote, gereksiz recomposition’ın frame drop’ların %40’ından sorumlu olduğunu açıkladı. Android Developer Blog Mart 2025: Baseline Profile kullanan uygulamalarda startup time %30 daha hızlı.
Jetpack Compose: 2026 Olgunluk Durumu
Jetpack Compose, Google’ın 2021’de stable yayınladığı modern declarative UI toolkit. 2026 itibarıyla Google Play Store top 1.000 uygulamanın %62’si Compose kullanıyor; Twitter, Airbnb, Reddit, Pinterest production’da. Compose Compiler ve Runtime 1.7+ versiyonlarında recomposition skipping algoritması iyileşti; ancak yanlış kullanımda hâlâ performans cezası yüksek.
Google I/O 2025: Compose 1.8 ile strong skipping mode varsayılan açıldı; instable parameter olan composable’lar bile artık daha az recomposition’a maruz kalıyor. Macrobenchmark 1.3 ve Baseline Profile generator iyileşmesi production performance tooling’i olgunlaştırdı.
Recomposition: Performansın Temeli
Recomposition, composable fonksiyonun state değişikliğinde yeniden çağrılmasıdır. Compose runtime hangi composable’ın yeniden hesaplanacağına state read tracking ile karar verir. İyi tasarımda yalnızca etkilenen subtree recompose olur; kötü tasarımda parent recompose tüm subtree’yi tetikler. Compose Compiler Metrics raporu hangi composable’ın “restartable”, “skippable” veya “unstable” olduğunu gösterir.
| Composable Durumu | Anlamı | Performans Etkisi |
|---|---|---|
| Restartable + Skippable | Aynı parameter ile çağrı atlanır | Optimal |
| Restartable + Not Skippable | Her recomposition’da çalışır | Yüksek maliyet |
| Not Restartable | Parent recompose’ta zorunlu | Maliyetli |
| Inline composable | Inlined into caller | Düşük overhead |
| Strong skip enabled | Unstable param’lı bile skip | Compose 1.7+ default |
Stability: @Stable, @Immutable, Persistent Collection
Composable’ın skippable olabilmesi için tüm parameter’larının stable olması gerekir. Stable: equals() consistent ve mutable property değişimi notify edilir. @Stable interface ve @Immutable class anotasyonu derleyiciye hint verir. Kotlin’in standard collection’ları (List, Map) varsayılan unstable; kotlinx.collections.immutable.PersistentList kullanımı önerilir.
- @Immutable: Tüm property final ve değişmiyor (örn: data class with val)
- @Stable: Mutable ama equals() doğru çalışıyor + State
- PersistentList/Set/Map: kotlinx.collections.immutable, stable
- Custom Holder: Mutable state’i StateFlow veya MutableState ile sar
- Compose Strong Skip: Compose 1.7+ unstable bile skip eder
İlgili konu: Kotlin StateFlow rehberimizde Compose ile reactive state yönetiminin best practice’ini detaylandırdık.
LazyColumn: Listeleme Performansı
LazyColumn ve LazyRow viewport-based recycling sunar. Performansın anahtarı 3 parametre: key (unique stable identifier), contentType (item heterojense önemli), itemsIndexed yerine itemsIndexed(items, key = { it.id }). Key olmayan LazyColumn’da scroll sırasında %40 performans kaybı; contentType olmayan heterojen list’te compose pool reset.
Macrobenchmark ve Baseline Profile
Macrobenchmark, AndroidX library’si, gerçek cihazda startup, scroll, navigation gibi production-like senaryoları ölçer. Baseline Profile, sık kullanılan kod yollarının AOT compile edilmesini sağlar; ilk açılış (cold start) %30, scroll smoothness %22 iyileşme tipik. Compose Compiler 1.8’den itibaren Compose composable’ları otomatik profil’e dahil ediliyor.
| Metrik | Macrobenchmark | Baseline Profile Etkisi |
|---|---|---|
| Cold Start TTID | p95 850 ms → 590 ms | %30 hızlanma |
| Cold Start TTFD | p95 1.420 ms → 1.000 ms | %30 hızlanma |
| Frame Render Time | p99 28 ms → 16 ms | %43 düşüş |
| Jank Frame % | %4,2 → %1,8 | %57 azalma |
| Scroll Smoothness | 58 fps → 60 fps | Stabilize |
Compose Compiler Metrics: Raporu Okumak
Compose Compiler Metrics, derleme sırasında composable analizi üretir. JSON ve human-readable rapor; her composable için restartable, skippable, parameter’ların stability durumunu gösterir. “Unstable” işaretli parameter’lar performance issue’nun ipucu. Build script’e -P komutu ile etkinleştirilir; CI’de regression check yapılabilir.
Sektörel Use Case: Fintech, E-ticaret, Sosyal Medya
Fintechte chart-heavy ekranlar (portfolio, candle chart) Compose’da Canvas + remember + derivedStateOf kombinasyonu ile optimize. E-ticarette product list LazyVerticalGrid + key + contentType pattern’i ile 10.000+ item smooth. Sosyal medyada feed scroll için subcomposeLayout ve image preloading (Coil + ImageLoader) zorunlu.
Kurumsal Compose Performance Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Compose Compiler Metrics raporunun CI’de tracking edilmemesi — regression’lar gözden kaçıyor
- Macrobenchmark’ın yazılmaması — performance manuel cihaz testine bırakılıyor
- Baseline Profile generate edilmemesi — cold start %30 daha yavaş
- LazyColumn’da key parametresinin eksik olması — scroll performansında %40 kayıp
- Standard Kotlin List kullanımının PersistentList’e dönüştürülmemesi
- StateFlow yerine LiveData kullanımı — Compose’da extra recomposition
Sonuç
Compose performance 2026’da artık “framework olgunlaşana kadar bekleyelim” aşamasında değil. Compose Compiler Metrics + Macrobenchmark + Baseline Profile zorunlu üçlü. Compose 1.8 strong skipping varsayılan; ancak immutable data class + PersistentList + StateFlow kombinasyonu hâlâ tercih edilen pattern. LazyColumn’da key + contentType eksikliği yaygın tek başına %40 performans cezası kaynağı. Pilot için 1 kritik ekranı baseline profile + macrobenchmark ile kapsamlı ölçün, sonra org-wide adoption.
Sıkça Sorulan Sorular
Compose XML View System’den daha mı hızlı?
Doğru kullanıldığında evet; modern Compose + Baseline Profile XML’den %15-25 daha hızlı startup, frame time’da %20-30 iyileşme. Yanlış kullanılırsa (unstable parameter, key’siz LazyColumn) XML’den yavaş. Google I/O 2025: top 1000 Compose uygulamasının %72’si XML eşdeğeri veya hızlı.
Strong skipping mode tüm sorunları çözer mi?
Hayır. Strong skipping unstable parameter’lar için recomposition’ı azaltır ama equals() comparison maliyeti artar. Heavy parameter’lar için hâlâ immutable + stable pattern tercih edilir. Compose 1.7+ default açık.
Baseline Profile generate etmek ne kadar zaman alır?
Macrobenchmark setup’ı 2-3 saat; profile generation script 1-2 saat; CI integration 4-8 saat. Toplam 1-2 günlük yatırım; performans iyileşmesi %30 startup ve %43 frame time karşılığında ROI yüksek.
derivedStateOf ne zaman kullanılır?
State’lerden türetilen ve sık değişmeyen değerler için. Örnek: scrollState.firstVisibleItemIndex > 5 → “scroll to top button visible” boolean’ı. derivedStateOf, source state değişimi yeniden tetiklemediği sürece downstream recomposition’ı önler.
Compose Multiplatform desktop ve iOS’ta da çalışır mı?
Evet. JetBrains Compose Multiplatform (CMP) 1.6+ ile iOS, desktop (Win/Mac/Linux), web destekli. iOS desteği Stable Q1 2025’te oldu; Lyft, McDonald’s, Skoda erken adopter. KMM ile birleşim aynı UI’i tüm platformlarda paylaşma seçeneği sunuyor.
Ömer ÖNAL
Mayıs 23, 2026Compose performans sorunlarını ‘cihaz yavaş’ diye geçiştiren ekipler 6 ay sonra Play Store rating’lerini tartışıyor. Doğru tanı için Compose Compiler Metrics + Macrobenchmark + Baseline Profile zorunlu üçlü. Stability’yi @Stable / @Immutable ile zorlamak yerine immutable data class + persistent collection (kotlinx.collections.immutable) tercih edin. LazyColumn’da key parametresini unutmak %40 performans kaybına yol açıyor. — Ömer Önal