Cold Start — mahiyyəti, soyuq başlanğıc və Android-də optimallaşdırma

Cold Start nədir

Cold Start (soyuq başlanğıc) — bu, Android tətbiqinin ən ilkin vəziyyətdən işə salındığı ssenaridir: əməliyyat sistemi yeni proses yaradır (Zygote-dən fork), yaddaş ayırır, DEX kodunu ART-ə yükləyir, sinifləri işə salır və Application, sonra isə ilk Activity nümunəsini yaradır. Tətbiq başlamazdan əvvəl cihazın yaddaşında onun haqqında heç bir məlumat yoxdur, Background Dexopt istifadə olunarsa, siniflərin keşlənmiş şəkilləri istisna olmaqla.

Cold Start nə zaman baş verir

Soyuq başlanğıc üç halda baş verir: tətbiq quraşdırıldıqdan sonra ilk işə salınmada, cihaz yenidən başladıldıqdan sonra işə salınmada və sistem yaddaş çatışmazlığı səbəbindən prosesi boşaltdıqdan sonra işə salınmada. 2–4 GB RAM olan cihazlarda sistem fon proseslərini kifayət qədər aqressiv şəkildə boşaldır, buna görə də Cold Start bir neçə saatlıq boş dayanmadan sonra tətbiqə hər qayıdışda baş verə bilər. Android 12+ sistem donmuş prosesi (freeze / cached) saxlaya bilər, lakin aktiv yaddaş qənəti zamanı (OOM-killer) proses məhv ediləcək.

Nüçün Cold Start kritik metrikadır

Google (Find My Device report, 2023) məlumatlarına görə, istifadəçilərin 65%-i tətbiq 3 saniyə ərzində açılmazsa onu bağlayır. Sosial şəbəkələr və messencerlər üçün, istifadəçinin gündə onlarla dəfə qayıtdığı yerlərdə, Cold Start birbaşa retention-a təsir edir. Google Play Console-da Cold Start metrikası Android Vitals bölməsinə daxildir və ANR və performans göstəricilərindən biri kimi göstərilir. „Pis” Cold Start həddini aşan tətbiqlər (cihazların 25%-də 5 saniyədən çox) konsolda xəbərdarlıq alır və axtarışda aşağı düşə bilər.

Cold Start vs Warm Start vs Hot Start

Android tətbiqin işə salınmasının üç növünü fərqləndirir, hər birinin fərqli müddəti, UX-ə təsiri və optimallaşdırma yanaşması var. Fərqi başa düşmək düzgün profil strategiyası seçmək üçün zəruridir.

Warm Start o zaman baş verir ki, tətbiq prosesi artıq fonda mövcuddur, lakin Activity məhv edilib (məsələn, istifadəçi uzun fasilədən sonra qayıdıb və sistem Activity yaddaşını boşaldıb). Hot Start — istifadəçi tətbiqi minimuma endirib dərhal yenidən açdıqda: Activity dayandırılıb və bərpa minimal vaxt aparır. İstifadəçi üçün Cold Start ən nəzərə çarpan başlanğıc növüdür və məhz onun optimallaşdırılması UX-də ən böyük artımı verir.

Növlər arasında keçid

Cold Start Warm Start-a çevrilə bilər, tətbiq ən azı bir dəfə işə salındıqdan sonra — ART siniflərin kompilyasiya olunmuş şəkillərini (Image in Boot Profile) keşləyir və DEX-in təkrar yüklənməsi daha sürətli baş verir. Buna görə də ilk Cold Start-dan sonra ikinci işəsalma adətən 20–40% daha sürətli olur. Tətbiq Baseline Profiles istifadə edɐrsə, profillər ilk işəsalmada yüklənir və ikinci başlanğıc daha da sürətli ola bilər: Baseline Profiles dərc edən Google Play, Android 12+ cihazlarında Cold Start-ı 30% sürətləndirdi.

Soyuq başlanğıc fazaları

Cold Start ciddi şəkildə müəyyən edilmiş fazalardan ibarətdir, hər biri müstəqil ölçülə və optimallaşdırıla bilər. Fazaları bilmək tətbiqin vaxtı hansı mərhələdə itirdiyini müəyyən etməyə kömək edir. Google dörd əsas faza ayırır: prosesin yaradılması, Application-ın işə salınması, Activity-nin yaradılması və ilk kadr.

Faza 1: Prosesin yaradılması (fork)

Android sistemi (ActivityManagerService) Zygote prosesindən fork vasitəsilə yeni proses yaradır. Zygote — bu, Android-ın ümumi sinifləri ilə əvvəlcədən yüklənmiş prosesdir. Fork 30–80 ms ərzində yerinə yetirilir — bu, tətbiqin nəzarət edə bilmədiyi vaxtdır. Fork-dan sonra ActivityThread işə salınır — tətbiqin əsas dövrünün nümunəsi. Bu mərhələdə hçmçinin ClassLoader vasitəsilə siniflərin yüklənməsi baş verir və ART ilk bayt-kodu şərh etməyə başlayır. Tətbiq çox sayda statik işəsalma istifadə edɐrsə, bu faza uzanı bilər.

Faza 2: Application.onCreate

ActivityThread başladıqdan dərhal sonra Application.onCreate çağrılır. Burada tərtibatçı ən çox səhv edir — hər şeyi dərhal işə salır: Crashlytics, Firebase, şəbəkə müştəriləri, verilənlər bazaları, Dagger komponentləri, DI konteynerləri. Hər belə işəsalma əsas yivdə bloklanmış vaxtdır. Application.onCreate 500 ms çəkirsə, bu yarım saniyə ərzində istifadəçi ağ (və ya qara) ekran görür. Bu fazanın optimal müddəti orta cihazda 200 ms-dən azdır.

Faza 3: Activity.onCreate

Application işə salındıqdan sonra Activity (MainActivity və ya Launcher Activity) nümunəsi yaradılır. Activity.onCreate çağrılır, burada setContentView, fraqmentlərin işə salınması, ViewModel qurulumu, LiveData/Flow-a abunə baş verir. onCreate əsas yivdə sinxron şəkildə verilənlərin yüklənməsini (SharedPreferences, SQLite, API) yerinə yetirirsə, faza uzanır. Məqsəd onCreate-i orta cihazda 200–400 ms-ə yerləşdirməkdir.

Faza 4: İlk kadr (TTFD)

OnCreate tamamlandıqdan sonra ilkin çəkim başlayır: ölçü, layout, draw. Bu an TTFD (Time To First Draw) adlanır. Tətbiq splash ekrandan istifadə edɐrsə (Android 12+-da SplashScreen API və ya theme vasitəsilə), çəkim daha sürətli baş verə bilər, lakin istifadəçi yenə də splash yox olana qədər gözləyəcək. Cold Start üçün ideal TTFD 1.5 saniyədən azdır.

Cold Start necə ölçülür

Cold Startın ölçülməsi xüsusi alətlər tələb edir, çünki adi loglama (Log.d) yalnız Application yaradıldıqdan sonra işə başlayır, fork və siniflərin yüklənmə vaxtı isə çatılmaz qalır. Google üç metod tövsiyə edir: ADB əmrləri, Android Vitals və xüsusi perf makroları.

ADB vasitəsilə ölçmə

Ən sadə və təkrarlana bilən üsul adb shell am start -S -W əmridir. -S bayrağı işə salmadan əvvəl tətbiqi məcburi dayandırır (Cold Start-ı təmin edir). Əmr üç metrika çıxarır: ThisTime (Activity başlanğıc vaxtı), TotalTime (prosesin başlanğıcı daxil olmaqla ümumi vaxt) və WaitTime (Activity Manager-in bütün gecikmələri daxil olmaqla vaxt). Təmiz ölçmə üçün 5–7 ölçüm edin və medianı götürün — tək ölçümlər səs-küyə məruz qalır (CPU throttling, fon yükü).

# Məcburi Cold Start ölçmə ilə
$ adb shell am start -S -W \
    com.example.app/.MainActivity

# Əmr nəticəsi:
# ThisTime: 1842 ms
# TotalTime: 1842 ms
# WaitTime: 1855 ms

Android Vitals (Google Play Console)

Google Play Console tətbiqin quraşdırıldığı bütün cihazlardan anonim metrikalar toplayır. Android Vitals → Launch time bölməsində Cold Start-ın cihaz modeli və Android versiyası üzrə median paylanması göstərilir. Bu, test cihazlarında deyil, istifadəçilərin cihazlarında real göstəriciləri görməyin yeganə yoludur. Redmi 9A-da (2 GB RAM) Cold Start 5 saniyədən çox, Pixel 8-də isə 1.2 saniyədirsə, problem yaddaş miqdarı və sinif sayındadır. Google həmçinin 25-ci persentil əsasında istifadəçi tərəfindən qəbul edilən gecikməni (user-perceptible delay) göstərir.

Macrobenchmark

Google Jetpack Macrobenchmark (androidx.benchmark kitabxanası) tətbiqin işə salınması üçün instrumentasiya olunmuş testlər yazmağa imkan verir. Test tətbiqi quraşdırır, onu soyuq vəziyyətdə işə salır və ilk kadra qədər olan vaxtı ölçür. Macrobenchmark avtomatik olaraq 20 qaçış edir, kənar göstəriciləri atır və sabit persentillər göstərir. CI/CD üçün baseline və cari işəsalmanı müqayisə etmək olar — vaxt artıbsa, CI pipeline xəta verə bilər.

Cold Start necə optimallaşdırılır

Cold Start optimallaşdırması tətbiqin bir neçə səviyyəsinə təsir edən sistemli işdir: kod, resurslar, yığma konfiqurasiyası və işəsalma arxitekturası. Google ən bahalısından — Application.onCreate — başlamağı və xırda şeylərə keçməyi tövsiyə edir.

Tənbel işəsalma (Lazy Init)

Başlanğıcda tələb olunmayan bütün işəsalmaları Application.onCreate-dan ilk istifadə nöqtəsinə köçürün. Firebase, Crashlytics, analytics SDK, push-notifications, DI komponentləri — bütün bunlar ilk ekran çəkildikdən sonra işə salına bilər. Kotlin-də Lazy (by lazy) və ya açıq initialize(context) çağrısı ilə ContentProvider işəsalmasi istifadə edin. Google (Android Performance, 2023) məlumatlarına görə, tənbel işəsalma 5+ SDK istifadə edən tətbiqlər üçün Cold Start-ı 40–60% qısaltır.

Baseline Profiles

Baseline Profiles — bu, tətbiqin başlanğıcında istifadə olunan kritik siniflərin və metodların AOT kompilyasiyasıdır. Baseline Profiles olmadan ART DEX kodunu şərh edir və ya JIT ilə kompilyasiya edir, bu vaxt aparır. Profillərlə ART göstərilən metodları tətbiq quraşdırılarkən yerli koda (AOT) kompilyasiya edir. Google, Baseline Profiles-ın Android 9+-da Cold Start-ı 15–40%, Android 12+ ART optimallaşdırmaları ilə isə 60%-ə qədər sürətləndirdiyini bildirir. Profillər yaratmaq üçün androidx.benchmark:benchmark-baseline-profile-gradle-plugin plagini istifadə edin.

App Startup Library

androidx.startup kitabxanası komponentlərin işə salınmasını tərtib etməyə və onu bir ContentProvider-də yerinɩ yetirməyə imkan verir. Müxtəlif kitabxanalardan bir neçə ContentProvider (hər biri soyuq başlanğıca 1–2 ms əlavə edir) əvəzinə App Startup onları asılılıq qrafikində birləşdirir və yalnız zəruri olduqda işə salır. Başlanğıcda yalnız ilk ekran üçün zəruri olaraq qeyd edilmiş @Initializer komponentləri yerinə yetirilir. Qalanları üçün needEarlyInit = false bayrağı qoyulur — onlar ilk çəkimdən sonra işə düşür.

// App Startup Initializer — başlanğıcdan sonra işəsalma
class AnalyticsInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        Analytics.init(context)
    }
    override fun dependencies() = listOf<Class<out Initializer<*>>>()
}

// AndroidManifest.xml-də isteğə bağlı olaraq qeyd edirik
// <meta-data android:name="AnalyticsInitializer"
//     android:value="false" />

DEX ölçüsünün azaldılması

DEX faylının ölçüsü birbaşa onun ART tərəfindən yüklənmə müddətinə təsir edir. Kodun gizlədilməsi və ölü kodun silinməsi üçün R8/ProGuard istifadə edin (MinifyEnabled = true). APK quraşdırma zamanı .so fayllarını açmaması üçün manifestdə android:extractNativeLibs="false" aktivləşdirin. 10 Reference Tracking olan layihələr üçün startup-priority yalnız ilk ekran üçün əlavə edin. DEX-dəki hər əlavə metod yüklənməyə 0.5–2 ms əlavə edir, 50k+ metodu olan tətbiqlər üçün isə (multidex ilə primary dex) — 300 ms-ə qədər.

Android Vitals-da Cold Start

Android Vitals Google Play Console-da (Launch time section) tətbiqin quraşdırıldığı bütün cihazlardan məlumat toplayır, istifadəçinin anonim diaqnostikaya razılığı şərtilə. Metrikalar Cold Start vaxtından asılı olaraq üç kateqoriyaya bölünür: „good” (yaxşı), „moderate” (orta), „bad” (pis).

Google hədd dəyərləri

Google „bad” Cold Start-ı istənilən cihazda 5 saniyədən çox vaxt kimi müəyyən edir. Lakin praktikada flaqman cihazlar üçün (Snapdragon 8 Gen) yaxşı vaxt 1.5 saniyədən az, orta seqment üçün 2.5 saniyədən az, büdcə cihazlar üçün isə 4 saniyədən az hesab olunur. Android Vitals hər device model üçün median göstərir ki, bu da tətbiqin hansı cihazlarda yavaş işə düşdüyünü anlamağa imkan verir. Cold Start Samsung A-series və ya Xiaomi Redmi cihazlarında pisdirsə, səbəb ən çox zəif flash yaddaş və az miqdarda RAM-dır (Baseline Profiles vasitəsilə sürətlənmə məhz belə cihazlarda ən böyük effekt verir).

Google Play metrikadan necə istifadə edir

Konsolda göstərilməklə yanaşı, Cold Start metrikası Google Play Search-da tətbiqin keyfiyyət reytinqinə təsir edir. Yüksək faizdə „pis” başlanğıcı olan tətbiqlər quraşdırma səhifəsində „Performance warning” etiketi alır ki, bu da konversiyanı aşağı salır. Google (Android Performance Playbook, 2024) məlumatlarına görə, Cold Start problemlərini həll edən tətbiqlər quraşdırma konversiyasını orta hesabla 5% artırır və retention göstəricisini (D1) 3–7% yaxşılaşdırır.

Firebase Performance ilə inteqrasiya

Daha ətraflı monitorinq üçün Firebase Performance Monitoring istifadə edin. O, Cold Start-ı sessiya səviyyəsində izləyir, tətbiq və Android versiyaları üzrə bölür. Android Vitals-dən fərqli olaraq, Firebase fazalar üzrə sərf olunan vaxtın trace diaqramını göstərir. Məsələn, 3.2.0 versiyasında Application.onCreate-in 800 ms (yeni push bildiriş kitabxanası səbəbindən), 3.2.1 versiyasında isə 200 ms (düzəlişdən sonra) olduğunu görmək olar.

Optimallaşdırma üçün kod nümunələri

Aşağıda Cold Start-ı birbaşa sürətləndirən iki praktik nümunə verilmişdir: SDK işəsalmasi-nin başlanğıcdan sonraya köçürülməsi və SplashScreen API-dən istifadə.

Application.onCreate-dən işəsalmasi-nin köçürülməsi

Tipik səhv — bütün SDK-ların Application.onCreate-də işə salınması. Aşağıda qeyri-kritik işəsalmasi-nin ilk kadr çəkildikdən sonra işə düşən korutinaya necə köçürülməsi göstərilmişdir. Vacib: Firebase, Crashlytics və Crash Reporting SDK başlanğıcda işə salınmalıdır — onları təxirə salmaq olmaz, çünki digər komponentlərin işə salınması zamanı kraşları tuturlar. Qalanları üçün ilk Activity-də lifecycleScope istifadə edin.

// ❌ Pis — bütün işəsalma Application.onCreate-də
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this) // kritik
        Analytics.init(this) // sonra ola bilər
        Database.init(this) // sonra ola bilər
        ImageLoader.init(this) // sonra ola bilər
    }
}

// ✅ Yaxşı — Firebase başlanğıcda, qalanı inflate-dən sonra
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Firebase.init(this)
    }
}

// MainActivity-də ilk kadrdan sonra:
lifecycleScope.launchWhenResumed {
    initializeNonCriticalSdks()
}

SplashScreen API

Android 12+-da proses başlayan kimi sistem splash-ı (tün/işıq fonda tətbiq ikonası) göstərən rəsmi SplashScreen API-dən istifadə edin. Bu, işəsalma vaxtını istifadəçidən gizlədir — o, ağ ekran əvəzinə splash görür. Köhnə cihazlar üçün theme-based splash (stilli Theme.SplashScreen) istifadə edin. Vacib: splash 300 ms-dən çox çəkməməlidir — əgər bu müddətdə tətbiq hazır deyilsə, „daimi” skeleton (shimmer) çəkin və yüklənmə prosesini göstərin.

// 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)
    }
}

// Theme-based splash (Android 5-11)
// themes.xml-də:
// <style name="Theme.App.Starting" parent="Theme.SplashScreen">
//   <item name="windowSplashScreenBackground">@color/white</item>
//   <item name="windowSplashScreenAnimatedIcon">@mipmap/ic_launcher</item>
// </style>