Cold Start — soğuk başlatma ve Android'de optimizasyon

Cold Start Nedir

Cold Start (soğuk başlatma), bir Android uygulamasının en başlangıç durumundan başlatıldığı bir senaryodur: işletim sistemi yeni bir süreç oluşturur (Zygote'dan fork), bellek ayırır, DEX kodunu ART'ye yükler, sınıfları başlatır ve bir Application örneği oluşturur, ardından ilk Activity'yi oluşturur. Uygulama başlatılmadan önce, Background Dexopt kullanılıyorsa önbelleğe alınmış sınıf görüntüleri dışında, cihaz belleğinde uygulama hakkında hiçbir veri yoktur.

Cold Start Ne Zaman Oluşur

Soğuk başlatma üç durumda oluşur: uygulama yüklemesinden sonraki ilk başlatmada, cihaz yeniden başlatıldıktan sonraki başlatmada ve sistem belleğin yetersizliği nedeniyle süreci kaldırdıktan sonraki başlatmada. 2–4 GB RAM'e sahip cihazlarda, sistem arka plan süreçlerini oldukça agresif bir şekilde kaldırır, bu nedenle Cold Start, kullanıcı birkaç saatlik hareketsizlikten sonra uygulamaya her döndüğünde oluşabilir. Android 12+'da, sistem donmuş bir süreci (freeze / cached) tutabilir, ancak aktif bellek tasarrufu (OOM-killer) ile süreç sonlandırılacaktır.

Cold Start Neden Kritik Bir Metriktir

Google'a (Find My Device raporu, 2023) göre, kullanıcıların %65'i 3 saniye içinde açılmazsa uygulamayı kapatır. Kullanıcıların günde onlarca kez geri döndüğü sosyal ağlar ve mesajlaşma uygulamaları için Cold Start, kullanıcıyı elde tutmayı doğrudan etkiler. Google Play Console'da Cold Start metriği, Android Vitals bölümünün bir parçasıdır ve ANR ve performans göstergelerinden biri olarak görüntülenir. “Kötü” Cold Start eşiğini (cihazların %25'inde 5 saniyeden fazla) aşan bir uygulama, konsolda bir uyarı alır ve arama sonuçlarında düşürülebilir.

Cold Start vs Warm Start vs Hot Start

Android, her biri farklı süreye, UX etkisine ve optimizasyon yaklaşımlarına sahip üç tür uygulama başlatma arasında ayrım yapar. Farkı anlamak, doğru profil oluşturma stratejisini seçmek için gereklidir.

Warm Start, uygulama süreci zaten arka planda mevcut olduğunda ancak Activity yok edildiğinde oluşur (örneğin, kullanıcı uzun bir aradan sonra geri döndü ve sistem Activity belleğini boşalttı). Hot Start — kullanıcı uygulamayı küçülttüğünde ve hemen tekrar açtığında oluşur: Activity duraklatılmıştır ve geri yükleme minimum süre alır. Kullanıcı için Cold Start en belirgin başlatma türüdür ve optimizasyonu UX'te en büyük iyileştirmeyi sağlar.

Türler Arası Geçiş

Uygulama en az bir kez başlatıldıktan sonra Cold Start, Warm Start haline gelebilir — ART derlenmiş sınıf görüntülerini (Boot Profile'da Image) önbelleğe alır ve sonraki DEX yüklemesi daha hızlı olur. Bu nedenle, ilk Cold Start'tan sonraki ikinci başlatma genellikle %20–40 daha hızlıdır. Uygulama Baseline Profiles kullanıyorsa, profiller ilk başlatmada yüklenir ve ikinci başlatma daha da hızlı olabilir: Baseline Profiles yayınlayan Google Play, Android 12+ cihazlarda Cold Start'i %30 hızlandırdı.

Soğuk Başlatma Aşamaları

Cold Start, her biri bağımsız olarak ölçülebilen ve optimize edilebilen kesin olarak tanımlanmış aşamalardan oluşur. Aşamaları bilmek, uygulamanın hangi aşamada zaman kaybettiğini belirlemeye yardımcı olur. Google dört ana aşama belirler: süreç oluşturma, Application başlatma, Activity oluşturma ve ilk kare.

Aşama 1: Süreç Oluşturma (fork)

Android sistemi (ActivityManagerService), Zygote sürecinden fork yaparak yeni bir süreç oluşturur. Zygote, ortak Android sınıflarıyla önceden yüklenmiş bir süreçtir. Fork 30–80 ms sürer — bu süre uygulamanın kontrolü dışındadır. Fork'tan sonra, ActivityThread başlatılır — uygulamanın ana döngü örneği. Bu aşamada, ClassLoader aracılığıyla sınıf yükleme de gerçekleşir ve ART ilk bayt kodunu yorumlamaya başlar. Uygulama çok sayıda statik başlatıcı kullanıyorsa, bu aşama uzayabilir.

Aşama 2: Application.onCreate

ActivityThread başladıktan hemen sonra Application.onCreate çağrılır. Geliştiricilerin en sık hata yaptığı yer burasıdır — her şeyi bir kerede başlatmak: Crashlytics, Firebase, ağ istemcileri, veritabanları, Dagger bileşenleri, DI kapsayıcıları. Bu başlatmaların her biri ana iş parçacığında bloke edilen süredir. Application.onCreate 500 ms sürerse, kullanıcı yarım saniye boyunca beyaz (veya siyah) bir ekran görür. Orta segment bir cihazda bu aşamanın optimal süresi 200 ms'den azdır.

Aşama 3: Activity.onCreate

Application başlatmasından sonra, bir Activity örneği oluşturulur (MainActivity veya Launcher Activity). Activity.onCreate çağrılır ve burada setContentView, fragment başlatma, ViewModel kurulumu ve LiveData/Flow aboneliği gerçekleşir. onCreate ana iş parçacığında verileri (SharedPreferences, SQLite, API) senkron olarak yüklerse, aşama uzar. Amaç, orta segment bir cihazda onCreate'i 200–400 ms içinde tutmaktır.

Aşama 4: İlk Kare (TTFD)

OnCreate tamamlandıktan sonra ilk işleme başlar: ölçü, düzen, çizim. Bu ana TTFD (Time To First Draw) denir. Uygulama bir açılış ekranı (Android 12+'da SplashScreen API veya tema aracılığıyla) kullanıyorsa, işleme daha hızlı gerçekleşebilir, ancak kullanıcı yine de splash kaybolana kadar bekleyecektir. Cold Start için ideal TTFD 1,5 saniyeden azdır.

Cold Start Nasıl Ölçülür

Cold Start ölçümü özel araçlar gerektirir, çünkü normal günlük kaydı (Log.d) yalnızca Application oluşturulduktan sonra çalışmaya başlar ve fork zamanlaması ile sınıf yüklemesi erişilemez durumda kalır. Google üç yöntem önerir: ADB komutları, Android Vitals ve özel performans makroları.

ADB ile Ölçüm

En basit ve tekrarlanabilir yöntem adb shell am start -S -W komutudur. -S bayrağı, başlatmadan önce uygulamayı zorla durdurur (Cold Start sağlar). Komut üç metrik çıktısı verir: ThisTime (Activity başlangıç süresi), TotalTime (süreç başlatma dahil toplam süre) ve WaitTime (Activity Manager'ın tüm gecikmeleri dahil süre). Temiz ölçümler için 5–7 okuma yapın ve medyanı kullanın — tek okumalar gürültüye (CPU kısma, arka plan yükü) tabidir.

# Ölçümle zorunlu Cold Start
$ adb shell am start -S -W \
    com.example.app/.MainActivity

# Komut çıktısı:
# ThisTime: 1842 ms
# TotalTime: 1842 ms
# WaitTime: 1855 ms

Android Vitals (Google Play Console)

Google Play Console, uygulamanın yüklü olduğu tüm cihazlardan anonim metrikler toplar. Android Vitals → Launch time bölümünde, cihaz modeline ve Android sürümüne göre Cold Start medyan dağılımı görüntülenir. Bu, test cihazlarında değil, kullanıcıların cihazlarında gerçek metrikleri görmenin tek yoludur. Redmi 9A'da (2 GB RAM) Cold Start 5 saniyeyi ve Pixel 8'de 1,2 saniyeyi aşarsa, sorun bellek boyutu ve sınıf sayısıdır. Google ayrıca 25. yüzdelik dilime dayalı kullanıcı tarafından algılanabilir gecikmeyi de gösterir.

Macrobenchmark

Google Jetpack Macrobenchmark (androidx.benchmark kütüphanesi), araçlı uygulama başlatma testleri yazmayı sağlar. Test uygulamayı yükler, soğuk bir durumdan başlatır ve ilk kareye kadar olan süreyi ölçer. Macrobenchmark otomatik olarak 20 çalıştırma yapar, aykırı değerleri atar ve kararlı yüzdelik dilimler gösterir. CI/CD için, temel çizgiyi ve mevcut başlatmayı karşılaştırabilirsiniz — süre artarsa, CI hattı başarısız olabilir.

Cold Start Nasıl Optimize Edilir

Cold Start optimizasyonu, uygulamanın birden çok düzeyini etkileyen sistematik bir çalışmadır: kod, kaynaklar, derleme yapılandırması ve başlatma mimarisi. Google, en pahalı kısımdan — Application.onCreate — başlamayı ve daha küçük ayrıntılara doğru ilerlemeyi önerir.

Tembel Başlatma (Lazy Init)

Başlangıçta gerekmeyen tüm başlatmaları Application.onCreate dışına, ilk kullanım noktasına taşıyın. Firebase, Crashlytics, analiz SDK'sı, push bildirimleri, DI bileşenleri — her şey ilk ekran işlendikten sonra başlatılabilir. Kotlin'de Lazy (by lazy) kullanın veya açık bir initialize(context) çağrısıyla ContentProvider başlatması kullanın. Google'a (Android Performance, 2023) göre, tembel başlatma, 5+ SDK kullanan uygulamalar için Cold Start'i %40–60 azaltır.

Baseline Profiles

Baseline Profiles, uygulama başlangıcında kullanılan kritik sınıfların ve yöntemlerin AOT derlemesidir. Baseline Profiles olmadan, ART DEX kodunu yorumlar veya JIT aracılığıyla derler, bu da zaman alır. Profillerle ART, uygulama yüklemesi sırasında belirtilen yöntemleri yerel koda (AOT) derler. Google, Baseline Profiles'in Android 9+'da Cold Start'i %15–40 ve Android 12+ ART optimizasyonlarıyla %60'a kadar hızlandırdığını belirtir. Profil oluşturmak için androidx.benchmark:benchmark-baseline-profile-gradle-plugin eklentisini kullanın.

App Startup Library

androidx.startup kütüphanesi, bileşen başlatmasını düzenlemeye ve tek bir ContentProvider'da yürütmeye olanak tanır. Farklı kütüphanelerden birden çok ContentProvider (her biri soğuk başlatmaya 1–2 ms ekler) yerine, App Startup bunları bir bağımlılık grafiğinde birleştirir ve gerektiğinde kesin olarak başlatır. Başlangıçta, yalnızca ilk ekran için gerekli olan @Initializer ile işaretlenmiş bileşenler yürütülür. Diğerleri için needEarlyInit = false bayrağı ayarlanır — ilk işlemeden sonra başlatılırlar.

// App Startup Initializer — başlatmadan sonra başlatma
class AnalyticsInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        Analytics.init(context)
    }
    override fun dependencies() = listOf<Class<out Initializer<*>>>()
}

// AndroidManifest.xml'de isteğe bağlı olarak işaretle
// <meta-data android:name="AnalyticsInitializer"
//     android:value="false" />

DEX Boyutunu Küçültme

DEX dosyasının boyutu, ART yükleme süresini doğrudan etkiler. Şaşırtma ve ölü kod kaldırma için R8/ProGuard kullanın (MinifyEnabled = true). Manifest'te android:extractNativeLibs="false" özelliğini etkinleştirin, böylece APK yükleme sırasında .so dosyalarını açmaz. 10'dan fazla referans takibi olan projeler için, yalnızca ilk ekrana startup-priority ekleyin. DEX'teki her ek yöntem, yüklemeye 0,5–2 ms ekler ve 50k'den fazla yöntemi olan uygulamalar için (primary dex ile multidex) — 300 ms'ye kadar.

Android Vitals'da Cold Start

Google Play Console'daki Android Vitals (Launch time bölümü), kullanıcının anonim tanılamayı kabul etmesi koşuluyla, uygulamanın yüklü olduğu tüm cihazlardan veri toplar. Metrikler, Cold Start süresine bağlı olarak üç kategoriye ayrılır: “iyi”, “orta”, “kötü”.

Google Eşik Değerleri

Google, “kötü” Cold Start'i herhangi bir cihazda 5 saniyeyi aşan süre olarak tanımlar. Ancak pratikte, amiral gemisi cihazlar (Snapdragon 8 Gen) için iyi süre 1,5 saniyeden az, orta segment için — 2,5 saniyeden az, bütçe cihazları için — 4 saniyeden azdır. Android Vitals, her cihaz modeli için medyanı gösterir ve hangi cihazlarda uygulamanın yavaş başladığını anlamaya olanak tanır. Samsung A-series veya Xiaomi Redmi cihazlarda Cold Start kötüyse, neden çoğunlukla yavaş flash bellek ve düşük RAM'dir (Baseline Profiles ile hızlanma tam da bu cihazlarda en büyük etkiyi verir).

Google Play Metriği Nasıl Kullanır

Konsolda görüntülenmenin yanı sıra, Cold Start metriği Google Play Search'te uygulama kalite derecelendirmesini etkiler. “Kötü” başlatma yüzdesi yüksek olan uygulamalar, yükleme sayfasında “Performans Uyarısı” etiketi alır ve bu da dönüşümü azaltır. Google'a (Android Performance Playbook, 2024) göre, Cold Start sorunlarını çözen uygulamalar, yükleme dönüşümünü ortalama %5 artırdı ve kullanıcıyı elde tutmayı (D1) %3–7 iyileştirdi.

Firebase Performance ile Entegrasyon

Daha ayrıntılı izleme için Firebase Performance Monitoring kullanın. Oturum düzeyinde Cold Start'i izler, uygulama sürümüne ve Android sürümüne göre ayırır. Android Vitals'ın aksine, Firebase aşamaya göre harcanan zamanın iz diyagramını gösterir. Örneğin, sürüm 3.2.0'da Application.onCreate'in 800 ms sürdüğünü (yeni bir push bildirim kütüphanesi nedeniyle), sürüm 3.2.1'de ise — 200 ms (düzeltmeden sonra) olduğunu görebilirsiniz.

Optimizasyon İçin Kod Örnekleri

Aşağıda, Cold Start'i doğrudan hızlandıran iki pratik örnek verilmiştir: başlatma sonrası SDK başlatmasını taşıma ve SplashScreen API kullanma.

Application.onCreate'dan Başlatmayı Taşıma

Tipik bir hata, tüm SDK'ları Application.onCreate'da başlatmaktır. Aşağıda, kritik olmayan başlatmanın ilk kare çizildikten sonra başlatılan bir coroutine'e nasıl taşınacağı gösterilmiştir. Önemli: Firebase, Crashlytics ve Crash Reporting SDK'ları başlangıçta başlatılmalıdır — diğer bileşenlerin başlatılması sırasında çökmeleri yakaladıkları için ertelenemezler. Geri kalanı için ilk Activity'de lifecycleScope kullanın.

// ❌ Kötü — tüm başlatma Application.onCreate'da
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this) // kritik
        Analytics.init(this) // daha sonra olabilir
        Database.init(this) // daha sonra olabilir
        ImageLoader.init(this) // daha sonra olabilir
    }
}

// ✅ İyi — Firebase başlangıçta, gerisi after inflate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this)
    }
}

// İlk kareden sonra MainActivity'de:
lifecycleScope.launchWhenResumed {
    initializeNonCriticalSdks()
}

SplashScreen API

Android 12+'da, süreç başladığında hemen bir sistem splash'i (koyu/açık arka planda uygulama simgesi) gösteren resmi SplashScreen API'yi kullanın. Bu, başlatma süresini kullanıcıdan gizler — beyaz bir ekran yerine bir splash görür. Eski cihazlar için theme-based splash (stillerde Theme.SplashScreen) kullanın. Önemli: splash 300 ms'den uzun sürmemelidir — uygulama o zamana kadar hazır değilse, “kalıcı” bir iskelet (shimmer) çizin ve yükleme ilerlemesini gösterin.

// SplashScreen API — Android 12+
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        val splashScreen = installSplashScreen()
        splashScreen.setKeepOnScreenCondition {
            isReady.value == false
        }
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

// Tema tabanlı splash (Android 5-11)
// themes.xml'de:
// <style name="Theme.App.Starting" parent="Theme.SplashScreen">
//   <item name="windowSplashScreenBackground">@color/white</item>
//   <item name="windowSplashScreenAnimatedIcon">@mipmap/ic_launcher</item>
// </style>