Warm Start: özü, sıcak başlatma ve Android'de optimizasyon

Warm Start Nedir

Warm Start, Cold Start ve Hot Start arasındaki bir durumdur: uygulama süreci bellekte bulunur (bazen Linux arka plan önbelleğinde), ancak Activity etkin değildir ve yeniden oluşturulacaktır. Android'in RAM'i azaldığında, süreci canlı bırakarak Activity'yi yığından kaldırabilir. Kullanıcı uygulamaya döndüğünde, Warm Start gerçekleşir: yeni bir Activity örneği oluşturulur, yaşam döngüsü yöntemleri onCreate → onStart → onResume yürütülür, ancak Application.onCreate ve sınıf yükleme atlanır.

Warm Start'ın Nedenleri

Android, süreç önceliğine (önem sırası) göre Activity'yi kaldırmaya karar verir. Arka plandaki bir Activity (PROCESS_STATE_IMPORTANT_FOREGROUND veya PROCESS_STATE_TOP_SLEEPING seviyesi), mevcut RAM'e bağlı olarak uygulama simge durumuna küçültüldükten 5–30 dakika sonra yok edilebilir. 3 GB RAM'li cihazlarda, Activity 10 dakika içinde kaldırılabilir; 8 GB RAM'li cihazlarda, birkaç saat sonra. Önemli: Warm Start sırasında onSaveInstanceState, Activity yok edilmeden önce çağrılır ve geliştirici UI durumunu kaydedebilir.

Kullanıcı Algısı

Kullanıcı Warm ve Cold Start arasındaki farkı görmez — sadece uygulama simgesine dokunur ve bekler. Ancak Warm Start sırasında, uygulama özel bir başlangıç penceresi teması ayarlamamışsa beyaz bir ekran görünebilir. Google, Warm Start sırasında beyaz/siyah ekran titremesini önlemek için manifestoda başlangıç Activity'si için özel bir tema (Theme.AppCompat.Light veya Theme.Material3.DayNight) ayarlamanızı önerir. Android 12+'da SplashScreen API de bu efekti gizler.

Warm Start vs Cold Start vs Hot Start

Üç başlatma türü arasındaki farkı anlamak, doğru profil oluşturma ve optimizasyon stratejisini seçmek için çok önemlidir. Her türün kendi süresi, darboğazları ve ölçüm araçları vardır.

Pratikte, Warm Start, kullanıcı alışkanlıklarına ve cihaz RAM'ine bağlı olarak tüm uygulama başlatmalarının %30 ila %60'ını oluşturur. Birçok uygulamayı açık tutan kullanıcılar (çoklu görev), Warm Start ile daha sık karşılaşır. Sosyal ağlar ve mesajlaşma uygulamaları için Warm Start en yaygın senaryodur çünkü uygulama her zaman arka plandadır. Bankacılık uygulamalarında ise tam tersine Cold Start baskındır (güvenlik nedenleriyle zorunlu süreç temizliği).

Sıcak Başlatmanın Aşamaları

Warm Start, her biri ölçülebilir ve optimize edilebilir üç aşamadan oluşur. Cold Start'ın aksine, fork aşaması veya sınıf yükleme yoktur, ancak maliyetli olabilen bir durum geri yükleme aşaması vardır.

Aşama 1: Başlangıç Penceresi (pencere arka planı)

Sistem, uygulamanın başlangıç penceresi için bir teması olup olmadığını kontrol eder. Tema ayarlanmamışsa, beyaz (veya sisteme bağlı olarak siyah) bir ekran görüntülenir. Tema ayarlanmışsa, tema arka planı gösterilir. Bu aşama 10–30 ms sürer, ancak tema uygulamanın gerçek UI'sıyla eşleşmezse görsel olarak fark edilir. Rengi ilk ekranın arka planıyla eşleşen özel bir windowBackground ile Theme.Material3.DayNight kullanın — bu anlık yükleme efekti oluşturur.

Aşama 2: Activity Oluşturma (geri yükleme)

Sistem, Activity yok edilmeden önce onSaveInstanceState'da kaydedilen Bundle savedInstanceState'ı ileterek onCreate'i çağırır. Uygulama durumu (alan metni, kaydırma konumu, ViewModel verileri) doğru şekilde kaydettiyse, geri yükleme hızlı gerçekleşir. Aksi takdirde, Activity sıfırdan başlar ve kullanıcı veriler yüklenirken bir yükleyici görür. Kilit nokta: ViewModel nesneleri, yalnızca süreç yok edilmediyse Warm Start'tan sağ çıkar — Warm Start sırasında ViewModel bellekte kalır.

Aşama 3: İlk Kare (TTFD)

onCreate'ten sonra onStart → onResume yürütülür ve sistem ilk çizimi tetikler. Warm Start için TTFD (Time To First Draw), orta sınıf bir cihazda 300 ms'nin altında olmalıdır. İlk ekran, ağır Views içeren karmaşık bir RecyclerView içeriyorsa veya ağdan resim yüklüyorsa, TTFD eşiği aşabilir. İlk kareden sonra yumuşak içerik yüklemesi için Placeholder ve Shimmer kullanın.

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

Warm Start'ı ölçmek Cold Start'tan daha karmaşıktır çünkü sürecin canlı olduğu ancak Activity'nin yok edildiği durumu simüle etmeniz gerekir. -S bayrağıyla standart ADB komutu çalışmaz — süreci öldürür. Warm Start için farklı yaklaşımlar kullanın.

-S olmadan ADB shell am start

Önce, uygulamayı adb shell monkey ile başlatın veya simgeye dokunun, ardından simge durumuna küçültün (adb shell input keyevent 3 keyevent HOME). Sistemin Activity'yi kaldırması için 5–10 saniye bekleyin, ardından adb shell am start -W (-S olmadan) çalıştırın. Komut, Cold Start'tan daha kısa bir başlatma süresi döndürecektir. Tekrarlanabilirlik için bir betik kullanın: başlat → bekle → ana sayfa → bekle → başlat.

# ADB ile Warm Start Simülasyonu
$ adb shell am start -W \
    com.example.app/.MainActivity

# Çıktı (Warm Start):
# ThisTime: 412 ms
# TotalTime: 412 ms
# WaitTime: 423 ms

Warm Start için Macrobenchmark

androidx.benchmark.macro kitaplığı, Warm Start ölçümünü destekler. Testte startupMode = StartupMode.WARM ayarlayın — kitaplık uygulamayı başlatacak, simge durumuna küçültecek, bekleyecek (yapılandırılabilir gecikme) ve ardından yeniden başlatmayı ölçecektir. Macrobenchmark 10–20 yineleme yapar ve yüzdelik dilimleri hesaplar. CI/CD'de bir eşik belirleyebilirsiniz: P50 Warm Start 600 ms'yi aşarsa test başarısız olur. Bu, her işlemede gerilemeleri izlemenizi sağlar.

Firebase Performance Monitoring

Firebase, son uygulama kapatma süresine göre Cold ve Warm Start'ı otomatik olarak ayırt eder. Uygulama son 30 dakika içinde açıldıysa, Firebase başlatmayı Warm olarak sınıflandırır. Firebase konsolunda, her başlatma türü için ayrı grafikler görecek ve optimizasyonların etkinliğini değerlendirebileceksiniz. Örneğin, ViewModel'de durum koruma uyguladıktan sonra Warm Start süresinde %30 azalma görebilirsiniz.

Warm Start Nasıl Optimize Edilir

Warm Start optimizasyonu iki alana odaklanır: Activity.onCreate'i hızlandırmak ve doğru durum geri yükleme. Application.onCreate ve sınıf yükleme zaten tamamlandığından, ana darboğaz ilk ekranın UI kodudur.

Zamansız Durum Geri Yükleme

Kaydedilen durum (savedInstanceState), seri durumdan çıkarma gerektiren veriler (Bitmap, String, JSON) içeriyorsa, bunu bir arka plan iş parçacığında yapın. onCreate'te Bundle'dan doğrudan okumak yerine, bir coroutine başlatın ve bir shimmer ekranı gösterin. Pratikte, orta sınıf bir cihazda Bundle seri durumdan çıkarma 20–100 ms sürer — küçük görünür, ancak Warm Start için bu toplam sürenin %10–50'sidir. Jetpack'in Saved State Module'ünü kullanın; bu modül, ViewModel durumunu Bundle'da veya veritabanında otomatik olarak kaydeder ve geri yükler.

setContentView Optimizasyonu

XML düzeni şişirme, Warm Start'ın en pahalı aşamalarından biridir. İlk ekran, AppBar, CollapsingToolbar, NestedScrollView artı üç RecyclerView ile karmaşık bir CoordinatorLayout kullanıyorsa, şişirme süresi 300 ms'ye ulaşabilir. Çözümler: düz bir hiyerarşi için ConstraintLayout kullanın, başlangıçta görünmeyen bölümler için ViewStub uygulayın (bottom sheet, dialog), AsyncLayoutInflater aracılığıyla ağır parçalar için zamansız şişirmeyi etkinleştirin. Jetpack Compose'da şişirme gerekmez, ancak Warm Start sırasında Compose ağacı derlemesi benzer bir süre alabilir.

Veri Önbellekleme

Warm Start sırasında, uygulamanın önceki oturumda yüklediği veriler zaten önbellekte olabilir: Room veritabanı, SharedPreferences, ViewModel'de bellek içi önbellek. İlk ekranınız sunucudan bir liste gösteriyorsa, başlangıçta önbelleği kontrol edin ve verileri arka planda güncelleyin. cache-then-network stratejisini kullanın: önce önbelleğe alınmış verileri gösterin (anında), ardından sunucudan güncelleyin (zamansız olarak). Bu, algılanan Warm Start süresini 100–200 ms'ye düşürür.

// Warm Start için Önbellekleme ile ViewModel
class FeedViewModel : ViewModel() {
    private val cache = MutableStateFlow<List<Item>>(emptyList())

    init {
        // Önce önbellek, sonra ağ
        viewModelScope.launch {
            cache.emit(db.getItems()) // Warm Start: veriler zaten DB'de
            cache.emit(api.fetchItems()) // Arka plan güncellemesi
        }
    }
}

Warm Start Sırasında Durum Koruma

Doğru durum koruma, iyi bir Warm Start'ı kötü olandan ayıran temel faktördür. Kullanıcı, uygulamaya döndüğünde kaydırma konumu, alanlardaki metin ve seçili sekmeler dahil olmak üzere bıraktığı şeyin aynısını görmeyi bekler.

onSaveInstanceState

Sistem, Activity yok edilirken onSaveInstanceState'yı çağırır, ancak süreç öldürülmeden ÖNCE. Bundle'da yalnızca basit veri türleri (String, Int, Parcelable, Serializable) kaydedilir. Karmaşık veriler için ViewModel'de SavedStateHandle kullanın — Warm Start sırasında alanları otomatik olarak kaydeder ve geri yükler. onSaveInstanceState'nın aksine, SavedStateHandle, süreç Warm Start'tan sağ çıksa bile çalışır (ViewModel yok edilmez). Örnek: EditText'teki metin için SavedStateHandle.getLiveData(“text”) kullanın — metin otomatik olarak kaydedilecek ve geri yüklenecektir.

ViewModel ve Warm Start

Warm Start sırasında süreç öldürülmediyse, ViewModel bellekte kalır ve onCleared çağrılmaz. Bu, önceki oturumda yüklenen tüm verilerin anında kullanılabilir olduğu anlamına gelir. Ancak, süreç öldürüldüyse (cihaz 30 dakikadan fazla derin uykuda), ViewModel yok edilir ve SavedStateHandle ile yeniden oluşturulur. Warm Start sırasında doğru ViewModel davranışı için, herhangi bir senaryoda geri yüklenmesi gereken alanlarla SavedStateHandle kullanın. Fark: @HiltViewModel ile ViewModel, SavedStateHandle'ı otomatik olarak destekler.

RecyclerView Kaydırma Konumunu Kaydetme

Warm Start'ın en yaygın sorunlarından biri — kaydırma konumunu kaybetmek. Kullanıcı 50. öğeye kaydırdı, uygulamayı simge durumuna küçülttü, geri döndü — ve listenin başını görüyor. Çözüm: layoutManager.onSaveInstanceState kaydedin (ilk görünür öğenin konumunu ve ofsetini kaydeder) ve onRestoreInstanceState içinde geri yükleyin. Ayrıca, Warm Start sırasında konumu hızlı bir şekilde geri yüklemek için son görünür konumu bir tarih/saat anahtarıyla SharedPreferences'te kaydedebilirsiniz.

// RecyclerView Kaydırma Konumunu Kaydetme
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putParcelable(
        "rv_state", binding.recyclerView
            .layoutManager?.onSaveInstanceState()
    )
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    savedInstanceState?.getParcelable<Parcelable>("rv_state")
        ?.let { binding.recyclerView.layoutManager?.onRestoreInstanceState(it) }
}

Warm Start İçin Kod Örnekleri

Warm Start optimizasyonunun iki pratik örneği: ViewModel'de SavedStateHandle kullanımı ve başlangıçtan sonra karmaşık verilerin zamansız geri yüklenmesi.

SavedStateHandle ile ViewModel

SavedStateHandle, alanları otomatik olarak Bundle'a kaydeder ve Warm Start sırasında geri yükler. Kullanıcı profili alanı (String, JSON), gereksiz sunucu istekleri olmadan geri yüklenecektir. Süreç öldürüldüyse, SavedStateHandle Bundle'dan son kaydedilen durumu yükler.

class ProfileViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    val profile: StateFlow<Profile?>
        get() = savedStateHandle
            .getStateFlow("profile", null)

    fun loadProfile(id: String) {
        viewModelScope.launch {
            savedStateHandle["profile"] =
                api.getProfile(id)
        }
    }
}

// Warm Start: profile null değil, yükleyicisiz UI
// Yüklemeden sonra: profile SavedStateHandle'da güncellenir

Ağır Ekranlar İçin AsyncLayoutInflater

İlk ekran karmaşık bir düzen içeriyorsa (harita, gradyan, birden çok liste), arka planda ağır öğeleri şişirmek için AsyncLayoutInflater kullanın. Düzen şişirilirken, shimmer efektli bir yer tutucu gösterin. Bu, her milisaniyenin önemli olduğu Warm Start için özellikle önemlidir. AsyncLayoutInflater bir arka plan iş parçacığında çalışır ve hazır View'ı ana iş parçacığındaki bir geri çağırmaya iletir.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Anlık işleme için Placeholder düzeni
        setContentView(R.layout.placeholder_shimmer)

        // Ağır düzenin zamansız yüklenmesi
        AsyncLayoutInflater(this).inflate(
            R.layout.activity_main_complex,
            findViewById(R.id.container)
        ) { view, resId, parent ->
            parent?.removeAllViews()
            parent?.addView(view)
        }
    }
}