Warm Start: mohiyati, issiq ishga tushirish va optimallashtirish Android'da

Warm Start nima

Warm Start (issiq ishga tushirish) — bu Cold Start va Hot Start o'rtasidagi holat: ilova jarayoni xotirada mavjud (ba'zan Linux fon keshlarida), lekin Activity faol emas va qaytadan yaratiladi. Android tizimi RAM yetishmaganda Activity'ni stekdan tushirishi mumkin, jarayonni tirik qoldirib. Foydalanuvchi ilovaga qaytganda, Warm Start boshlanadi: Activity'ning yangi namunasi yaratiladi, hayotiy sikl metodlari onCreate → onStart → onResume bajariladi, lekin Application.onCreate va sinflarni yuklash o'tkazib yuboriladi.

Warm Start sabablari

Android tizimi Activity'ni tushirish to'g'risida jarayonning ustuvorligi (importance rank) asosida qaror qiladi. Fonda joylashgan Activity (PROCESS_STATE_IMPORTANT_FOREGROUND yoki PROCESS_STATE_TOP_SLEEPING darajasi) ilova yig'ilgandan keyin 5–30 daqiqa ichida yo'q qilinishi mumkin, mavjud RAM'ga qarab. 3 GB RAM'li qurilmalarda Activity 10 daqiqadan keyin tushirilishi mumkin, 8 GB'li qurilmalarda — bir necha soatdan keyin. Muhim: Warm Start'da onSaveInstanceState Activity yo'q qilinishidan oldin chaqiriladi va ishlab chiquvchi UI holatini saqlashi mumkin.

Foydalanuvchi idroki

Foydalanuvchi Warm va Cold Start o'rtasidagi farqni ko'rmaydi — u shunchaki ilova belgisini bosadi va kutadi. Biroq Warm Start'da oq ekran (blank window) paydo bo'lishi mumkin, agar ilova boshlang'ich oyna uchun o'z mavzusini sozlamagan bo'lsa. Google manifestda (Theme.AppCompat.Light yoki Theme.Material3.DayNight) Activity uchun maxsus mavzu o'rnatishni tavsiya qiladi, bu Warm Start'da oq/qora ekran miltillashining oldini oladi. Android 12+ da SplashScreen API ham bu effektni yashiradi.

Warm Start vs Cold Start vs Hot Start

Uch turdagi ishga tushirish o'rtasidagi farqni tushunish profiling va optimallashtirish strategiyasini to'g'ri tanlash uchun zarur. Har bir tur o'z davomiyligiga, o'z muammoli joylariga va o'z o'lchov vositalariga ega.

Amalda Warm Start barcha ishga tushirishlarning 30% dan 60% gachasini tashkil qiladi, foydalanuvchi odatlari va qurilma RAM hajmiga qarab. Ko'p ilovalarni ochiq tutadigan foydalanuvchilar (multitasker) Warm Start bilan tez-tez uchrashadilar. Ijtimoiy tarmoqlar va messenjerlar uchun Warm Start eng keng tarqalgan stsenariy, chunki ilova doim fonda. Bank ilovalari uchun, aksincha, Cold Start ustunlik qiladi (jarayonni majburiy tozalash xavfsizlik nuqtai nazaridan).

Issiq ishga tushirish fazalari

Warm Start uch fazadan iborat bo'lib, ularning har biri o'lchanishi va optimallashtirilishi mumkin. Cold Start'dan farqli o'laroq, bu yerda fork va sinflarni yuklash fazasi mavjud emas, lekin holatni tiklash (restore) fazasi mavjud bo'lib, u qimmatga tushishi mumkin.

Faza 1: Boshlang'ich oyna (window background)

Tizim ilovada boshlang'ich oyna uchun mavzu bor yoki yo'qligini tekshiradi. Agar mavzu o'rnatilmagan bo'lsa, oq (yoki qora) ekran ko'rsatiladi. Agar mavzu o'rnatilgan bo'lsa, mavzudan background ko'rsatiladi. Bu faza 10–30 ms davom etadi, lekin mavzu haqiqiy UI bilan mos kelmasa, vizual ravishda seziladi. Birinchi ekran foniga mos rangdagi maxsus windowBackground bilan Theme.Material3.DayNight dan foydalaning — bu bir zumda yuklash effektini yaratadi.

Faza 2: Activity yaratish (tiklash)

Tizim onCreate ni Activity yo'q qilinishidan oldin onSaveInstanceState'da saqlangan Bundle savedInstanceState bilan chaqiradi. Agar ilova holatni to'g'ri saqlagan bo'lsa (maydon matni, skroll pozitsiyasi, ViewModel ma'lumotlari), tiklash tez amalga oshiriladi. Agar yo'q bo'lsa — Activity bo'sh varaqdan boshlanadi va foydalanuvchi ma'lumotlar yuklanmaguncha loaderni ko'radi. Asosiy nuqta: ViewModel ob'ektlari Warm Start'dan faqat jarayon yo'q qilinmagan taqdirda omon qoladi — Warm Start'da ViewModel xotirada saqlanadi.

Faza 3: Birinchi kadr (TTFD)

onCreate'dan keyin onStart → onResume bajariladi va tizim birinchi chizishni chaqiradi. TTFD (Time To First Draw) Warm Start uchun o'rtacha qurilmada 300 ms dan kam bo'lishi kerak. Agar birinchi ekran og'ir View'lar bilan murakkab RecyclerView yoki tarmoq orqali tasvirlarni yuklashni o'z ichiga olsa, TTFD chegaradan oshib ketishi mumkin. Birinchi kadrdan keyin kontentni silliq yuklash uchun Placeholder va Shimmer dan foydalaning.

Warm Start'ni qanday o'lchash

Warm Start'ni o'lchash Cold Start'ga qaraganda murakkabroq, chunki «jarayon tirik, Activity yo'q qilingan» holatini simulyatsiya qilish kerak. Standart ADB buyrug'i -S bayrog'i bilan mos kelmaydi — u jarayonni o'ldiradi. Warm Start uchun boshqa usullardan foydalaning.

ADB shell am start -S siz

Avval ilovani adb shell monkey orqali yoki belgini bosish orqali ishga tushiring, so'ngra uni yig'ing (adb shell input keyevent 3 keyevent HOME). 5–10 soniya kuting, tizim Activity'ni tushirishi uchun va adb shell am start -W ( -S siz) ni ishga tushiring. Buyruq Cold Start'dan qisqaroq bo'lgan ishga tushirish vaqtini qaytaradi. Takrorlanuvchanlik uchun skriptdan foydalaning: ishga tushirish → kutish → home → kutish → ishga tushirish.

# Warm Start'ni ADB orqali simulyatsiya qilish
$ adb shell am start -W \
    com.example.app/.MainActivity

# Chiqish (Warm Start):
# ThisTime: 412 ms
# TotalTime: 412 ms
# WaitTime: 423 ms

Macrobenchmark Warm Start uchun

androidx.benchmark.macro kutubxonasi Warm Start'ni o'lchashni qo'llab-quvvatlaydi. Buning uchun testda startupMode = StartupMode.WARM ni o'rnating — kutubxona ilovani ishga tushiradi, uni yig'adi, kutadi (sozlanishi mumkin bo'lgan kechikish) va keyin qayta ishga tushirishni o'lchaydi. Macrobenchmark 10–20 marta bajaradi va persentillarni hisoblaydi. CI/CD da chegarani sozlash mumkin: agar P50 Warm Start 600 ms dan oshsa — test muvaffaqiyatsizlikka uchraydi. Bu har bir commit'da regressiyalarni kuzatish imkonini beradi.

Firebase Performance Monitoring

Firebase avtomatik ravishda Cold va Warm Start'ni ilovaning oldingi yopilish vaqtiga qarab farqlaydi. Agar ilova oxirgi 30 daqiqa ichida ochilgan bo'lsa, Firebase ishga tushirishni Warm deb tasniflaydi. Firebase konsolida har bir ishga tushirish turi uchun alohida grafiklarni ko'rasiz, bu optimallashtirish samaradorligini baholash imkonini beradi. Masalan, ViewModel'da holatni saqlashni joriy qilgandan so'ng Warm Start'ni 30% gacha kamaytirishni ko'rish mumkin.

Warm Start'ni optimallashtirish

Warm Start'ni optimallashtirish ikki yo'nalishga qaratilgan: Activity.onCreate'ni tezlashtirish va holatni to'g'ri tiklash. Application.onCreate va sinflarni yuklash allaqachon bajarilganligi sababli, asosiy muammo — birinchi ekran UI kodi.

Holatni asinxron tiklash

Agar saqlangan holat (savedInstanceState) deserializatsiya qilinishi kerak bo'lgan ma'lumotlarni (Bitmap, String, JSON) o'z ichiga olsa, buni fon oqimida bajaring. Bundle'dan to'g'ridan-to'g'ri onCreate'da o'qish o'rniga, coroutine ishga tushiring va shimmer ekranini ko'rsating. Amalda, Bundle'ni deserializatsiya qilish o'rtacha qurilmada 20–100 ms davom etadi — oz ko'rinadi, lekin Warm Start uchun bu umumiy vaqtning 10–50% ini tashkil qiladi. ViewModel holatini avtomatik ravishda Bundle yoki ma'lumotlar bazasida saqlaydigan va tiklaydigan Jetpack kutubxonasining Saved State Module dan foydalaning.

setContentView'ni optimallashtirish

XML maketini kengaytirish (layout inflation) — Warm Start'ning eng qimmat bosqichlaridan biri. Agar birinchi ekran AppBar, CollapsingToolbar, NestedScrollView va uchta RecyclerView bilan murakkab CoordinatorLayout'dan foydalansa, inflation vaqti 300 ms ga yetishi mumkin. Yechimlar: tekis iyerarxiya uchun ConstraintLayout dan foydalaning, boshlang'ichda ko'rinmaydigan bo'limlar uchun ViewStub'ni qo'llang (bottom sheet, dialog), og'ir fragmentlar uchun asinxron kengaytirishni AsyncLayoutInflater orqali yoqing. Jetpack Compose'da inflation kerak emas, lekin Compose daraxtini Warm Start'da kompilyatsiya qilish shuncha vaqt olishi mumkin.

Ma'lumotlarni keshlashtirish

Warm Start'da ilova oldingi seansda yuklagan ma'lumotlar keshda bo'lishi mumkin: Room ma'lumotlar bazasi, SharedPreferences, ViewModel'da in-memory kesh. Agar birinchi ekran serverni ro'yxatini ko'rsatsa, boshlang'ichda keshni tekshiring va ma'lumotlarni fonda yangilang. cache-then-network strategiyasidan foydalaning: avval keshlangan ma'lumotlarni ko'rsating (bir zumda), so'ngra serverdan yangilang (asinxron). Bu Warm Start'ning idrok etilgan vaqtini 100–200 ms gacha qisqartiradi.

// ViewModel Warm Start uchun keshlashtirish bilan
class FeedViewModel : ViewModel() {
    private val cache = MutableStateFlow<List<Item>>(emptyList())

    init {
        // Avval kesh, keyin tarmoq
        viewModelScope.launch {
            cache.emit(db.getItems()) // Warm Start: ma'lumotlar bazada allaqachon
            cache.emit(api.fetchItems()) // Fonda yangilash
        }
    }
}

Holatni saqlash Warm Start'da

Holatni to'g'ri saqlash — yaxshi Warm Start'ni yomondan ajratib turadigan asosiy omil. Foydalanuvchi ilovaga qaytib, xuddi tark etgan narsani ko'rishni kutadi — shu jumladan skroll pozitsiyasi, maydonlardagi matn, tanlangan yorliqlar.

onSaveInstanceState

Tizim onSaveInstanceState'ni Activity yo'q qilinganda chaqiradi, lekin jarayon o'ldirilishidan OLDIN. Bundle'da faqat oddiy ma'lumotlar (String, Int, Parcelable, Serializable) saqlanadi. Murakkab ma'lumotlar uchun ViewModel'da SavedStateHandle dan foydalaning — u Warm Start'da avtomatik ravishda maydonlarni saqlaydi va tiklaydi. onSaveInstanceState'dan farqli o'laroq, SavedStateHandle hatto jarayon Warm Start'dan omon qolgan taqdirda ham ishlaydi (ViewModel yo'q qilinmaydi). Misol: EditText'dagi matn uchun SavedStateHandle.getLiveData("text") dan foydalaning — matn avtomatik saqlanadi va tiklanadi.

ViewModel va Warm Start

Agar Warm Start'da jarayon o'ldirilmagan bo'lsa, ViewModel xotirada qoladi va onCleared chaqirilmaydi. Bu avvalgi seansda yuklangan barcha ma'lumotlar bir zumda mavjud degani. Ammo jarayon o'ldirilgan bo'lsa (qurilma 30 daqiqadan ko'proq deep sleep'da), ViewModel yo'q qilinadi va SavedStateHandle bilan qaytadan yaratiladi. Warm Start'da ViewModel'ning to'g'ri ishlashi uchun har qanday stsenariyda tiklanishi kerak bo'lgan maydonlar bilan SavedStateHandle dan foydalaning. Farqi: @HiltViewModel bilan ViewModel avtomatik ravishda SavedStateHandle'ni qo'llab-quvvatlaydi.

RecyclerView skrollini saqlash

Warm Start'ning eng keng tarqalgan muammolaridan biri — skroll pozitsiyasini yo'qotish. Foydalanuvchi lentani 50-elementgacha aylantirgan, ilovani yig'gan, qaytgan — va ro'yxat boshini ko'radi. Yechim: layoutManager.onSaveInstanceState ni saqlang (birinchi ko'rinadigan elementning pozitsiyasi va offsetini saqlaydi) va uni onRestoreInstanceState da tiklang. Shuningdek, oxirgi ko'rinadigan pozitsiyani sana/vaqt kaliti bilan SharedPreferences'da saqlash mumkin, bu Warm Start'da pozitsiyani tezda tiklash imkonini beradi.

// RecyclerView skroll pozitsiyasini saqlash
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) }
}

Kod namunalari Warm Start uchun

Warm Start'ni optimallashtirishning ikkita amaliy misoli: ViewModel'da SavedStateHandle dan foydalanish va ishga tushirishdan keyin murakkab ma'lumotlarni asinxron tiklash.

ViewModel SavedStateHandle bilan

SavedStateHandle avtomatik ravishda maydonlarni Bundle'da saqlaydi va Warm Start'da tiklaydi. Foydalanuvchi profili maydoni (String, JSON) serverga qo'shimcha so'rovlarsiz tiklanadi. Agar jarayon o'ldirilgan bo'lsa, SavedStateHandle Bundle'dan oxirgi saqlangan holatni yuklaydi.

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 emas, UI loader siz
// Yuklashdan keyin: profile SavedStateHandle'da yangilanadi

AsyncLayoutInflater og'ir ekran uchun

Agar birinchi ekran murakkab maketni (xarita, gradient, bir nechta ro'yxatlar) o'z ichiga olsa, AsyncLayoutInflater dan og'ir elementlarni fonda kengaytirish uchun foydalaning. Maket kengaytirilayotganda, shimmer effektli placeholder ko'rsating. Bu Warm Start uchun ayniqsa muhim, chunki har bir millisoniya qadrlanadi. AsyncLayoutInflater fon oqimida ishlaydi va tayyor View'ni asosiy oqimdagi callback'ga yetkazadi.

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

        // Bir zumda chizish uchun placeholder maket
        setContentView(R.layout.placeholder_shimmer)

        // Og'ir maketni asinxron yuklash
        AsyncLayoutInflater(this).inflate(
            R.layout.activity_main_complex,
            findViewById(R.id.container)
        ) { view, resId, parent ->
            parent?.removeAllViews()
            parent?.addView(view)
        }
    }
}