Compose ekranınız takılıyorsa sebep neredeyse hiçbir zaman framework değil. Üç şeyden biri: composition içinde yapılan pahalı hesaplama, kimliği her karede değişen bir parametre yüzünden atlanamayan recomposition, ya da Baseline Profile konulmadığı için ödenen soğuk açılış bedeli. Bu yazı güncel sürüm gerçeğini (Compose BOM 2026.09.00, güçlü atlama, Baseline Profile), Google'ın yayımladığı gerçek yüzdeleri ve Türkiye'deki Android projelerinde takvimi belirleyen Play kuralını anlatıyor.
Tek tek sürüm sabitlemeyin, BOM sabitleyin
Compose Bill of Materials, tek bir sürüm numarasını tüm Compose bileşenlerine eşliyor; böylece ui, foundation, material3 ve runtime sürümlerini elle eşleştirmiyorsunuz. Güncel BOM 2026.09.00 ve şuna çözümleniyor (bkz. Android Developers, "Compose to BOM mapping"):
| Bileşen | BOM 2026.09.00 karşılığı |
|---|---|
androidx.compose.ui:ui | 1.12.1 |
androidx.compose.foundation:foundation | 1.12.1 |
androidx.compose.runtime:runtime | 1.12.1 |
androidx.compose.material3:material3 | 1.4.0 |
Son satırdaki sürüm farkına dikkat: Material3 çekirdek kütüphanelerden ayrı bir hatta ilerliyor. Bileşenleri tek tek sabitleyen ekipler tam bu yüzden, masum görünen bir yükseltmeden sonra bağımlılık çözümleme çakışmasıyla karşılaşıyor. BOM'u sabitleyin; tek bir bileşeni ancak somut bir gerekçeniz varsa ve o gerekçeyi koda yorum olarak yazarak ezin.
Güçlü atlama, eski "stability" tavsiyelerinin çoğunu geçersiz kıldı
Kotlin 2.0.20'den beri güçlü atlama (strong skipping) varsayılan olarak açık. Getirdiği değişiklik şu: yeniden başlatılabilir tüm composable'lar, parametreleri kararsız olsa bile atlanabilir hâle geliyor. Kararsız parametreler örnek eşitliğiyle (===), kararlı parametreler equals() ile karşılaştırılıyor.
İkinci ve daha az bilinen etkisi: composable içindeki tüm lambda'lar otomatik olarak memoize ediliyor. Derleyici lambda'yı bir remember çağrısına sarıyor:
// Yazdığınız
val lambda = { use(unstableObject) }
// Güçlü atlama açıkken derleyicinin ürettiği
val lambda = remember(unstableObject) {
{ use(unstableObject) }
}
Dokümanın verdiği ölçüm, test edilen uygulamalarda APK boyutuna etkisinin yaklaşık 4 kB olduğu. Yani "lambda'ları elle remember'a sarın" tavsiyesi artık gereksiz; hâlâ bunu yapan kod tabanları gürültü üretiyor.
Bunun size bıraktığı iş, veri sınıflarınızı gözden geçirmek. Kararsız bir tip (örneğin List yerine ImmutableList kullanılmayan bir alan) her seferinde yeni bir örnek olarak üretiliyorsa, === karşılaştırması false dönüyor ve atlama gerçekleşmiyor. Sorun derleyicide değil, her map çağrısında yeni liste üreten repository katmanınızda.
Baseline Profile: Google'ın yayımladığı iki rakam
Baseline Profile, uygulamanızın kritik kod yollarını ilk açılışta yorumlayıcı yerine önceden derlenmiş hâlde çalıştırıyor. Resmî dokümanın verdiği rakamlar:
- İlk çalıştırmadan itibaren kod yürütmesinde yaklaşık %30 hızlanma.
- Startup profilleri eklendiğinde açılış için ek ~%15.
- AGP 8.2 ve sonrasında R8 profil kurallarını yeniden yazdığında ek ~%15 performans ve ~%30 daha geniş metot kapsamı.
Buradaki tuzak yapılandırmada. Profil üretilirken uygulama obfuscate edilmemiş olmalı (isMinifyEnabled = false); sürüm derlemesinde ise obfuscate edilmiş olmalı (isMinifyEnabled = true). R8, obfuscate edilmemiş profil kurallarını sürüm koduna göre yeniden yazıyor. Bu ikiliyi yanlış kuran ekiplerde profil sessizce etkisiz kalıyor: hata yok, uyarı yok, kazanç da yok.
Gereksinimler: Android 7 (API 24) ve üstü, AGP 8.0+ (kütüphaneler için 8.3+), Macrobenchmark 1.5.0+, Profile Installer 1.4.1+.
Play'in 31 Ağustos 2026 tarihi Compose kararınızı da etkiliyor
Google Play'in hedef API seviyesi gereksinimine göre yeni uygulamalar ve güncellemeler 31 Ağustos 2026'dan itibaren Android 16 (API 36) veya üstünü hedeflemek zorunda. Play Console üzerinden 1 Kasım 2026'ya kadar uzatma alınabiliyor. Mevcut uygulamalardan API 34 ve altını hedefleyenler ise yeni Android sürümlü cihazlarda yeni kullanıcılara görünmüyor.
Bu, XML tabanlı eski bir uygulamayı taşımak için doğal bir kırılma anı. Hedef API'yi yükseltirken zaten AGP, Kotlin ve bağımlılık sürümlerini çıkacaksınız; Compose'a geçiş için ikinci bir yükseltme dalgası açmak yerine aynı pencereye sıkıştırmak daha ucuz.
Aynı yükseltmede kontrol edilmesi gereken bir başka kural: POST_NOTIFICATIONS. Android 13 (API 33) ile çalışma zamanı izni hâline geldi ve yeni kurulan uygulamalarda bildirimler varsayılan olarak kapalı. API 32 ve altını hedefleyen uygulamalarda sistem izin diyaloğunu ilk açılışta kendisi gösteriyordu; 33 ve üstünü hedefleyince zamanlamayı siz seçiyorsunuz. İlk açılışta sorarsanız ret oranınız yükseliyor, çünkü kullanıcı henüz neden bildirim isteyeceğinizi bilmiyor.
Compose'a geçerken en pahalı hata, tüm ekranları birden dönüştürmek. ComposeView ile mevcut XML hiyerarşisinin içine ekran ekran girin; önce liste ve detay gibi yüksek trafikli, mantığı sade ekranları taşıyın. Karmaşık form ve kamera ekranlarını en sona bırakın.
Yanlış yerde aranan üç performans sorunu
1. Composition içinde ağır hesaplama. Sıralama, filtreleme, tarih biçimlendirme gibi işler composable gövdesinde çalışıyorsa her recomposition'da tekrarlanıyor. Bunları remember ile türetilmiş duruma taşıyın veya ViewModel katmanında hesaplayın.
2. Yanlış anahtarla LazyColumn. key vermezseniz liste değiştiğinde Compose öğeleri konuma göre eşleştiriyor; araya bir kayıt girdiğinde altındaki her şey yeniden oluşuyor. Kararlı bir kimlik verin.
3. Ölçümü emülatörde yapmak. Soğuk açılış ve jank ölçümleri ancak sürüm derlemesiyle, gerçek ve orta segment bir cihazda anlamlı. Geliştirici makinesindeki emülatörde hiçbir Baseline Profile kazancı görünmez.
Sırada ne var
Üç satırlık bir kontrol listesi. Birincisi: build.gradle.kts dosyanızda Compose bileşenlerini tek tek mi sabitliyorsunuz? Öyleyse BOM'a geçin.
İkincisi: sürüm derlemenizde Baseline Profile üretiliyor mu ve isMinifyEnabled ikilisi doğru kurulmuş mu? Üçüncüsü: Play Console'da hedef API seviyeniz kaç?
Android tarafında kapsam ve ekip kurgusu için mobil uygulama geliştirme firması seçimi, framework kararı için React Native ve Flutter karşılaştırması yazılarına bakabilirsiniz. Hizmet kapsamımız mobil uygulama geliştirme sayfasında; kaba bir efor bandı için proje fiyat hesaplama aracını kullanabilirsiniz.
Sürüm eşlemesi, güçlü atlama davranışı, Baseline Profile yüzdeleri ve bildirim izni kuralı 25 Eylül 2026'da developer.android.com üzerindeki ilgili resmî sayfalardan doğrulanmıştır. Hedef API seviyesi tarihleri Google Play gereksinim sayfasındandır. Kod örneği resmî dokümandaki dönüşümü göstermektedir.
