Warm Start: mahiyyəti, isti başlatma və optimallaşdırma Android-də

Warm Start nədir

Warm Start (isti başlatma) — bu Cold Start və Hot Start arasındakı haldır: proqram prosesi yaddaşda mövcuddur (bəzən Linux keş yaddaşında), lakin Activity aktiv deyil və yenidən yaradılacaq. Android sistemi operativ yaddaş çatışmazlığı zamanı Activity-ni yığından çıxararaq prosesi canlı saxlaya bilər. İstifadəçi proqrama qayıtdıqda Warm Start başlayır: yeni Activity nüsxəsi yaradılır, həyat dövriyyəsi metodları onCreate → onStart → onResume icra olunur, lakin Application.onCreate və siniflərin yüklənməsi ötürülür.

Warm Start-ın səbəbləri

Android sistemi Activity-nin boşaldılması qərarını prosesin prioriteti (importance rank) əsasında qəbul edir. Fondakı Activity (PROCESS_STATE_IMPORTANT_FOREGROUND və ya PROCESS_STATE_TOP_SLEEPING səviyyəsi) proqram kiçiltdikdən sonra 5–30 dəqiqə ərzində, mövcud RAM-dan asılı olaraq məhv edilə bilər. 3 GB RAM-lı cihazlarda Activity 10 dəqiqədən sonra, 8 GB RAM-lı cihazlarda isə bir neçə saatdan sonra boşaldıla bilər. Vacib: Warm Start zamanı onSaveInstanceState Activity məhv edilməzdən əvvəl çağırılır və tərtibatçı UI vəziyyətini saxlaya bilər.

İstifadəçi tərəfindən qavranılması

İstifadəçi Warm və Cold Start arasındakı fərqi görmür — sadəcə proqramın ikonasına klik edir və gözləyir. Lakin Warm Start zamanı ağ ekran (blank window) görünə bilər, əgər proqram başlatma pəncərəsi üçün öz temini qurmayıbsa. Google başlatma Activity üçün manifestdə fərdi tem (Theme.AppCompat.Light və ya Theme.Material3.DayNight) təyin etməyi tövsiyə edir ki, Warm Start zamanı ağ/qara ekranın yanıb-sönməsindən qaçınılsın. Android 12+-da SplashScreen API də bu effekti gizlədir.

Warm Start vs Cold Start vs Hot Start

Üç başlatma növü arasındakı fərqi anlamaq profilinq və optimallaşdırma strategiyasını düzgün seçmək üçün vacibdir. Hər növün öz müddəti, öz dar boğazları və ölçmə alətləri var.

Təcrübədə Warm Start istifadəçinin vərdişlərindən və cihazın RAM həcmindən asılı olaraq bütün başlatmaların 30%-dən 60%-ə qədərini təşkil edir. Çoxlu proqramı açıq saxlayan istifadəçilər (multitasker) daha tez-tez Warm Start-la qarşılaşırlar. Sosial řəbəkələr və mesajlaşma proqramları üçün Warm Start ən çox yayılmış ssenaridir, çünki proqram hər zaman fondadır. Bank proqramları üçün isə əksinə, Cold Start üstünlük təşkil edir (təhlükəsizlik səbəbindən prosesin məcburi təmizlənməsi).

İsti başlatmanın fazaları

Warm Start hər biri ölçülə və optimallaşdırıla bilən üç fazadan ibarətdir. Cold Start-dan fərqli olaraq, burada fork və sinif yükləmə fazası yoxdur, lakin bahalı ola biləcək bərpa (restore) fazası var.

Faza 1: Başlatma pəncərəsi (window background)

Sistem proqramın başlatma pəncərəsi üçün teminin olub-olmadığını yoxlayır. Tem qurulmayıbsa, ağ (və ya sistemdən asılı olaraq qara) ekran göstərilir. Tem qurulubsa, temdən fon göstərilir. Bu faza 10–30 ms çəkir, lakin tem proqramın real UI-sinə uyğun gəlməzsə, vizual olaraq hiss olunur. Rəngi ilk ekranın fonu ilə uyğun gələn fərdi windowBackground ilə Theme.Material3.DayNight istifadə edin — bu ani yüklənmə effekti yaradır.

Faza 2: Activity yaradılması (restore)

Sistem Activity məhv edilməzdən əvvəl onSaveInstanceState-də saxlanılmış Bundle savedInstanceState-i ötürərək onCreate-i çağırır. Əgər proqram vəziyyəti düzgün saxlayıbsa (sahə mətni, sürüşdürmə mövqeyi, ViewModel məlumatları), bərpa tez baş verir. Əks halda — Activity təmiz vərəqdən başlayır və istifadəçi məlumat yüklənənə qədər loader görür. Önəmli məqam: ViewModel obyektləri Warm Start-ı yalnız proses məhv olunmayıbsa yaşayır — Warm Start zamanı ViewModel yaddaşda qalır.

Faza 3: İlk kadr (TTFD)

OnCreate-dən sonra onStart → onResume icra olunur və sistem ilk çərçivəni göstərir. Orta cihazda Warm Start üçün TTFD (Time To First Draw) 300 ms-dən az olmalıdır. Əgər ilk ekranda ağır View-ləri olan mürəkkəb RecyclerView varsa və ya şəbəkədən şəkillər yükləyirsə, TTFD həddi aşa bilər. İlk kadrdan sonra məzmunun hamar yüklənməsi üçün Placeholder və Shimmer istifadə edin.

Warm Start-ı necə ölçmək olar

Warm Start-i ölçmək Cold Start-dan çətindir, çünki „proses canlı, Activity məhv edilib” vəziyyətini simulyasiya etmək lazımdır. -S bayrağı ilə standart ADB əmri uyğun deyil — prosesi öldürür. Warm Start üçün başqa yanaşmalardan istifadə edin.

ADB shell am start -S olmadan

Əvvəlcə proqramı adb shell monkey və ya ikona toxunmaqla başladın, sonra onu kiçildin (adb shell input keyevent 3 keyevent HOME). Sistemin Activity-ni boşaltması üçün 5–10 saniyə gözləyin və adb shell am start -W ( -S olmadan) işə salın. Əmir, Cold Start-dan daha qısa olacaq başlatma vaxtını qaytaracaq. Təkrarlanma qabiliyyəti üçün skriptdən istifadə edin: başlat → gözlə → home → gözlə → başlat.

# Warm Start-ın ADB ilə simulyasiyası
$ adb shell am start -W \
    com.example.app/.MainActivity

# Nəticə (Warm Start):
# ThisTime: 412 ms
# TotalTime: 412 ms
# WaitTime: 423 ms

Warm Start üçün Macrobenchmark

androidx.benchmark.macro kitabxanası Warm Start ölçülməsini dəstəkləyir. Bunun üçün testdə startupMode = StartupMode.WARM təyin edin — kitabxana proqramı başladacaq, kiçildəcək, gözləyəcək (configurable delay) və sonra təkrar başlatmanı ölçəcək. Macrobenchmark 10–20 dəfə icra edir və persentilləri hesablayır. CI/CD-də hədd təyin etmək olar: əgər P50 Warm Start 600 ms-i keçərsə — test uğursuz olur. Bu, hər commit-də reqressiyaları izləməyə imkan verir.

Firebase Performance Monitoring

Firebase avtomatik olaraq Cold və Warm Start-ı proqramın son bağlanmasından keçən vaxta əsasən fərqləndirir. Əgər proqram son 30 dəqiqə ərzində açıq olubsa, Firebase başlatmanı Warm kimi təsnif edir. Firebase konsolunda hər başlatma növü üçün ayrı-ayrı qrafiklər görəcəksiniz ki, bu da optimallaşdırmanın effektivliyini qiymətləndirməyə imkan verir. Məsələn, ViewModel-də vəziyyətin saxlanmasını tətbiq etdikdən sonra Warm Start-ın 30% azaldığını görmək olar.

Warm Start-ı necə optimallaşdırmaq olar

Warm Start optimallaşdırması iki istiqamətə yönəlib: Activity.onCreate-in sürətləndirilməsi və vəziyyətin düzgün bərpası. Application.onCreate və sinif yüklənməsi artıq icra olunduğundan, əsas darboğaz ilk ekranın UI kodudur.

Asinxron vəziyyət bərpası

Əgər saxlanılmış vəziyyət (savedInstanceState) deserializasiya edilməli məlumatları ehtiva edirsə (Bitmap, String, JSON), bunu fon ipində edin. onCreate-də birbaşa Bundle-dən oxumaq əvəzinə, korutin işə salın və shimmer ekranı göstərin. Təcrübədə orta cihazda Bundle deserializasiyası 20–100 ms çəkir — az görünür, lakin Warm Start üçün bu, ümumi vaxtın 10–50%-dir. Bundle və ya verilənlər bazasında ViewModel vəziyyətini avtomatik saxlayan və bərpa edən Jetpack kitabxanasının Saved State Module-indən istifadə edin.

setContentView optimallaşdırılması

XML layout-un genişləndirilməsi (layout inflation) — Warm Start-ın ən bahalı mərhələlərindən biridir. Əgər ilk ekran AppBar, CollapsingToolbar, NestedScrollView və üç RecyclerView ilə mürəkkəb CoordinatorLayout istifadə edirsə, inflation vaxtı 300 ms-ə çata bilər. Həll yolları: yastı iyerarxiya üçün ConstraintLayout istifadə edin, başlanğıcda görünməyən bölümələr (bottom sheet, dialog) üçün ViewStub tətbiq edin, ağır fraqmentlərin asinxron genişləndirilməsini AsyncLayoutInflater vasitəsilə aktivləşdirin. Jetpack Compose-da inflation tələb olunmur, lakin Warm Start-da Compose ağacının kompilyasiyası oxşar vaxt apara bilər.

Məlumatların keşlənməsi

Warm Start zamanı proqramın əvvəlki sessiyada yüklədiyi məlumatlar artıq keşdə ola bilər: Room verilənlər bazası, SharedPreferences, ViewModel-də in-memory keş. Əgər ilk ekran serverdən siyahı göstərirsə, başlatma zamanı keşi yoxlayın və məlumatları fonda yeniləyin. cache-then-network strategiyasından istifadə edin: əvvəlcə keşlənmiş məlumatları göstərin (ani), sonra serverdən yeniləyin (asinxron). Bu, Warm Start-ın qavranılan vaxtını 100–200 ms-ə qədər azaldır.

// Warm Start üçün keşləmə ilə ViewModel
class FeedViewModel : ViewModel() {
    private val cache = MutableStateFlow<List<Item>>(emptyList())

    init {
        // Əvvəlcə keş, sonra şəbəkə
        viewModelScope.launch {
            cache.emit(db.getItems()) // Warm Start: məlumatlar artıq verilənlər bazasında
            cache.emit(api.fetchItems()) // Fonda yenilənmə
        }
    }
}

Warm Start zamanı vəziyyətin saxlanması

Vəziyyətin düzgün saxlanması yaxşı Warm Start-ı pisdən fərqləndirən əsas amildir. İstifadəçi proqrama qayıdıb eyni şeyi görməyi gözləyir — sürüşdürmə mövqeyi, sahələrdəki mətn, seçilmiş əlavələr daxil olmaqla.

onSaveInstanceState

Sistem Activity məhv edilərkən onSaveInstanceState çağırır, lakin proses öldürülməzdƏN ƏVVƏL. Bundle-də yalnız sadə məlumatlar (String, Int, Parcelable, Serializable) saxlanılır. Mürəkkəb məlumatlar üçün ViewModel-də SavedStateHandle-dan istifadə edin — Warm Start zamanı sahələri avtomatik saxlayır və bərpa edir. onSaveInstanceState-dən fərqli olaraq, SavedStateHandle hətta proses Warm Start-ı yaşasa belə işləyir (ViewModel məhv edilmir). Nümunə: EditText-də mətn üçün SavedStateHandle.getLiveData(“text”) istifadə edin — mətn avtomatik saxlanılacaq və bərpa olunacaq.

ViewModel və Warm Start

Əgər Warm Start zamanı proses öldürülməyibsə, ViewModel yaddaşda qalır və onCleared çağırılmır. Bu o deməkdir ki, əvvəlki sessiyada yüklənmiş bütün məlumatlar ani şəkildə əlçatandır. Lakin proses öldürülübsə (cihaz dərin yuxu rejimində 30 dəqiqədən çox olub), ViewModel məhv edilir və SavedStateHandle ilə yenidən yaradılır. Warm Start zamanı ViewModel-in düzgün işləməsi üçün istənilən ssenaridə bərpa edilməli sahələrlə SavedStateHandle-dan istifadə edin. Fərq: @HiltViewModel ilə ViewModel SavedStateHandle-ı avtomatik dəstəkləyir.

RecyclerView sürüşdürməsinin saxlanması

Warm Start-ın ən geniş yayılmış problemlərindən biri — sürüşdürmə mövqeyinin itirilməsi. İstifadəçi siyahını 50-ci elementə qədər sürüşdürdü, proqramı kiçiltdi, qayıtdı — və siyahının əvvəlini görür. Həll yolu: layoutManager.onSaveInstanceState-i saxlayın (ilk görünən elementin mövqeyini və offsetini saxlayır) və onu onRestoreInstanceState-də bərpa edin. Həmçinin son görünən mövqeyi tarix/vaxt açarı ilə SharedPreferences-də saxlaya bilərsiniz ki, Warm Start zamanı mövqe tez bərpa olunsun.

// RecyclerView sürüşdürmə mövqeyinin saxlanması
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 üçün kod nümunələri

Warm Start optimallaşdırmasının iki praktik nümunəsi: ViewModel-də SavedStateHandle istifadəsi və başlatmadan sonra mürəkkəb məlumatların asinxron bərpası.

ViewModel ilə SavedStateHandle

SavedStateHandle avtomatik olaraq sahələri Bundle-də saxlayır və onları Warm Start zamanı bərpa edir. İstifadəçi profil sahəsi (String, JSON) serverə əlavə sorğular olmadan bərpa olunacaq. Əgər proses öldürülübsə, SavedStateHandle Bundle-dən son saxlanılmış vəziyyəti yükləyəcək.

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: profil null deyil, UI loader olmadan
// Yüklənmədən sonra: profil SavedStateHandle-də yenilənir

Ağır ekran üçün AsyncLayoutInflater

Əgər ilk ekran mürəkkəb layout (xəritə, qradiyent, bir neçə siyahı) ehtiva edirsə, ağır elementlərin fonda genişləndirilməsi üçün AsyncLayoutInflater istifadə edin. Layout genişlənərkən shimmer effekti ilə placeholder göstərin. Bu, xüsusilə hər millisaniyənin əhəmiyyətli olduğu Warm Start üçün vacibdir. AsyncLayoutInflater fon ipində işləyir və hazır View-i əsas ipdə callback-ə ötürür.

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

        // Ani renderinq üçün Placeholder-maket
        setContentView(R.layout.placeholder_shimmer)

        // Ağır layout-un asinxron yüklənməsi
        AsyncLayoutInflater(this).inflate(
            R.layout.activity_main_complex,
            findViewById(R.id.container)
        ) { view, resId, parent ->
            parent?.removeAllViews()
            parent?.addView(view)
        }
    }
}