Mobil tətbiqlərdə Hot Start: bu nədir, amillər və necə sürətləndirmək olar

Mobil tətbiqlərdə Hot Start nədir

Hot Start — tətbiqin prosesi artıq cihazın operativ yaddaşında mövcud olan işə salma ssenarisidir. İstifadəçi tətbiqi kiçildir, sonra qayıdır — və sistem yeni proses yaratmır, mövcud olanı bərpa edir. Bu ssenaridə OS-nin yüklənməsi, Application sinfinin inisializasiyası və prosesin yaradılması tələb olunmur ki, bu da UI-nin ekranda görünmə vaxtını kəskin şəkildə azaldır. Android Documentation (2025) görə, Hot Start cəmi 200–500 ms çəkir, Cold Start isə 5 saniyə və daha çox ola bilər. Sürət fərqi xüsusilə məhdud yaddaşa malik cihazlarda nəzərə çarpır, burada sistem fon tətbiqlərini daha tez-tez boşaldır.

Hot Start-in əsas xüsusiyyəti — çağırılan lifecycle metodlarının minimal dəstidir. Android-də bunlar Activity.onCreate və Activity.onStart, iOS-da — applicationDidBecomeActive-dir. Application.onCreate, ContentProvider.onCreate, Activity.onCreate və kitabxanaların çoxsaylı inisializasiyalarının ardıcıl çağırıldığı Cold Start-dan fərqli olaraq, Hot Start bütün bu mərhələləri keçir. Tərtibatçı anlamalıdır ki, hansı kod məhz isti başlanğıc zamanı icra olunur — tez-tez SDK, analitika və DI konteynerlərinin ağır inisializasiyaları həm Cold, həm də Hot Start-da təkrarlanır, baxmayaraq ki, isti başlanğıcda onlar artıq lazım deyil.

Cold Start, Warm Start və Hot Start: müqayisə

Üç işə salma ssenarisi inisializasiya dərinliyinə görə fərqlənir. Cold Start (soyuq başlanğıc) tətbiq ilk dəfə quraşdırmadan sonra, cihazın yenidən başladılmasından və ya yaddaşdan boşaldıldıqdan sonra işə salındıqda baş verir. Sistem yeni Linux prosesi yaradır, Application siniflərini yükləyir, ContentProvider nümunələri yaradır, kitabxanaların inisializasiyasını həyata keçirir və yalnız bundan sonra Activity-ni göstərir. Bütün proses tətbiqin mürəkkəbliyindən və cihazın xüsusiyyətlərindən asılı olaraq 2–10 saniyə çəkir.

Warm Start (isti başlanğıc) — aralıq ssenari. Tətbiqin prosesi yaddaşda canlıdır, lakin Activity məhv edilib və yenidən yaradılmalıdır. Bu, məsələn, ekranın fırlanması və ya başqa tətbiqdən qayıtdıqda, Activity yaddaş çatışmazlığı səbəbindən boşaldıldıqda, lakin proses qaldıqda baş verir. Warm Start Activity.onCreate və Activity.onStart çağırışını əhatə edir, lakin Application.onCreate və ContentProvider inisializasiyasını əhatə etmir. Warm Start vaxtı — 500 ms-dən 2 saniyəyə qədər. Hot Start — üçün ən sürətlisi: Activity artıq back stack-də mövcuddur, proses canlıdır və sistem sadəcə Activity.onRestart, onStart və onResume çağırır. Hot Start vaxtı — 200–500 ms. Warm Start-dan fərqi ondadır ki, Activity yenidən yaradılmır — mövcud nümunədən bərpa olunur.

Hot Start zamanı Android Lifecycle

Android-də Hot Start istifadəçi Recents ekranı vasitəsilə və ya kiçildilmiş vəziyyətdə ikona klikləyərək tətbiqə qayıtdıqda başladılır. Sistem prosesin canlı olub-olmadığını yoxlayır və əgər varsa — ardıcıl olaraq Activity.onRestart, onStart və onResume çağırır. Hot Start zamanı onCreate metodu çağırılmır, çünki Activity nümunəsi artıq yaddaşda mövcuddur. Bu, onCreate-in hələ də Activity-nin məhv edilməsi səbəbindən çağırıldığı Warm Start-dan mühüm fərqdir. Google I/O 2019 məlumatına görə, Android-də tipik Hot Start vaxtı 200–400 ms təşkil edir və bu mərhələdə hər hansı ləngimə birbaşa perceived launch time-i artırır.

Tərtibatçılar tez-tez UI inisializasiyası, LiveData-ya abunəlik və ya RecyclerView qurulması kodunun təkcə onCreate-də deyil, həm də onStart və ya onResume-də icra olunduğunu görmürlər. Hot Start zamanı bu kod blokları UI artıq qurulmuş olsa da, yenidən icra olunur. Birdəfəlik inisializasiyanı (savedInstanceState yoxlanılması ilə onCreate-də) və bərpa olunan məntiqi (onStart/onResume) ayırmaq tövsiyə olunur. Məsələn, ağır əməliyyatlar — adapterlərin qurulması, siyahıların yüklənməsi — onRestart zamanı icra olunmayan bloka köçürülməli və ya savedInstanceState yoxlanılmalıdır.

Başlanğıc tipini izləmə nümunəsi

Aşağıdakı Kotlin kodu başlanğıc ssenarisini təyin etmək və vaxtı ölçmək üçün sadə üsul göstərir. launchTimeStamp dəyişəni başlanğıc anını qeyd edir, isColdStart isə soyuq və isti başlanğıc üçün məntiqi ayırmağa imkan verir.

class MainActivity : AppCompatActivity() {

    private var launchTimeStamp = 0L
    private var isColdStart = true

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        if (savedInstanceState == null) {
            isColdStart = true
            launchTimeStamp = System.currentTimeMillis()
            // birdəfəlik inisializasiya
        } else {
            isColdStart = false
            // Hot Start — Activity bərpa olunur
        }
    }

    override fun onResume() {
        super.onResume()
        if (isColdStart) {
            val launchTime =
                System.currentTimeMillis() - launchTimeStamp
            Log.d("LaunchTime", "Cold Start: $launchTime ms")
        }
    }
}

İsti başlanğıc zamanı iOS Lifecycle

iOS-da Hot Start sceneDidBecomeActive (UIKit) və ya onAppear (SwiftUI) vasitəsilə tətbiqin fondan qayıtmasına uyğundur. Əməliyyat sistemi tətbiq Suspended və ya Background vəziyyətində idisə prosesi yenidən yaratmır. İsti başlanğıc zamanı AppDelegate-də applicationDidBecomeActive çağırılır, lakin applicationDidFinishLaunching çağırılmır — bu, Application.onCreate-in buraxıldığı Android analoqudur. iOS yaddaşdan tətbiqləri daha aqressiv şəkildə boşaldır: cihazda RAM çatışmazlığı olarsa, sistem fon tətbiqini boşalda bilər və növbəti başlanğıc Cold Start olacaq. Apple Developer Documentation məlumatına görə, iOS-da orta Hot Start vaxtı 300–600 ms-dir.

iOS-un əsas fərqi — Android anlayışında Warm Start-ın birbaşa analoqunun olmamasıdır. iOS-da tətbiq kiçildilərkən sceneDidEnterBackground çağırılır, qayıdarkən isə — sceneWillEnterForeground və sceneDidBecomeActive. Sistem səhnəni boşaldır, lakin prosesi canlı qoyursa, növbəti başlanğıc səhnə baxımından Cold, proses baxımından isə Hot olacaq. Tərtibatçı inisializasiya kodunu yerləşdirərkən bunu nəzərə almalıdır: NotificationCenter-ə abunəlik, UI yeniləməsi və vəziyyətlərin sıfırlanması məhz sceneDidBecomeActive-də olmalıdır, təkcə viewDidLoad-də deyil.

iOS-da Hot Start emalı nümunəsi

Bu Swift kodu isti başlanğıcların sayını izləməyi və məntiqi ayırmağı göstərir. foregroundCount sayğacı fondan hər qayıdışda artır.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

    func sceneDidBecomeActive(
        _ scene: UIScene
    ) {
        foregroundCount += 1

        if foregroundCount == 1 {
            // Cold Start — tam inisializasiya
            setupSDKs()
        } else {
            // Hot Start — yalnız UI yeniləməsi
            refreshUI()
        }
    }

    private func refreshUI() {
        // ekranda məlumat yeniləməsi
    }
}

Hot Start sürətinə təsir edən amillər

Hot Start sürətinə bir neçə amil kateqoriyası təsir edir. Birincisi — onStart və onResume lifecycle metodlarında işin həcmi. Əgər tərtibatçı bu metodlara şəbəkədən məlumat yükləmə, JSON parse etmə, adapter inisializasiyası və ya ağır hesablamalar yerləşdiribsə, hər bir belə blok başlanğıc vaxtına onlarla və yüzlərlə millisaniyə əlavə edir. Android Vitals alətinin məlumatına görə, Hot Start müddəti 800 ms-dən çox olan tətbiqlər təkrar qayıdışda istifadəçilərin 20%-ə qədərini itirir.

İkinci kateqoriya — savedInstanceState-dən bərpa edilən fraqmentlər və View-lər. Fraqmentlərdə ağır ViewPager2, WebView və ya dərin yerləşdirmə ilə mürəkkəb iyerarxiyalar varsa, onların bərpası CPU resurslarını tutur. Google I/O 2023 məlumatına görə, hər yerləşdirilmiş ViewGroup Hot Start zamanı render vaxtına orta hesabla 2–5 ms əlavə edir. Üçüncü kateqoriya — üçüncü tərəf SDK-ları: analitika, crash-reporting, A/B-test kitabxanaları və DEX yükləyiciləri fondan hər qayıdışda inisializasiya icra edə bilər. Hansı SDK-ların məhz onStart/onResume-də kod işə saldığını yoxlamaq və kritik olmayan tapşırıqları fon thread-inə təxirə salmaq tövsiyə olunur.

İsti başlanğıcın optimallaşdırma metodları

Hot Start optimallaşdırması bərpa lifecycle metodlarında işin minimuma endirilməsinə əsaslanır. Birinci metod — tənbəl inisializasiya: UI-nin ilk kadrı üçün lazım olmayan bütün kod onResume çağırışından sonra Handler.postDelayed və ya Coroutine.launch(Dispatchers.IO) vasitəsilə gecikmə ilə icra edilməlidir. İkinci metod — View vəziyyətinin keşləşdirilməsi: tətbiq kiçildilərkən məlumatları in-memory keşdə saxlayın ki, Hot Start zamanı onları verilənlər bazasından və ya şəbəkədən yenidən yükləmək lazım olmasın. Üçüncü metod — Android-də SavedStateHandle və iOS-da StateRestorationPolicy istifadə edərək bərpa olunan məlumatların həcmini minimuma endirmək.

Hot Start-dan sonra tənbəl yükləmə

Bu nümunədə Handler.postDelayed analitikanın inisializasiyasını ilk kadr renderindən 500 ms sonra təxirə salır. Bu, perceived launch time-a təsir etmir, çünki istifadəçi artıq interfeysi görür.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // ilk kadrdan sonra inisializasiya
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

App Startup kitabxanasından istifadə

AndroidX App Startup başlanğıc zamanı komponentlərin inisializasiya sırasını idarə etməyə imkan verir. Bütün ContentProvider Cold Start zamanı avtomatik inisializasiya olunur, lakin siz Hot Start zamanı lazım olmayan komponentlər üçün avtomatik inisializasiyanı söndürə bilərsiniz.

@Initializer(Application::class)
class SdkInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        SdkOne.init(context)
        SdkTwo.init(context)
    }

    override fun dependencies() = emptyList<Class<*>>()
}

Başlanğıc vaxtının monitorinqi alətləri

Hot Start vaxtını ölçmək üçün həm platformaların daxili alətləri, həm də üçüncü tərəf həlləri mövcuddur. Android-də əsas alət Google Play Console-da Android Vitals-dir — o, bütün ssenarilər (Cold, Warm, Hot) üçün başlanğıc vaxtı metrikalarını cihaz modelləri və OS versiyaları üzrə bölgü ilə avtomatik toplayır. Əlavə olaraq AndroidX-dən Macrobenchmark — başlanğıc performansının avtomatlaşdırılmış testi üçün kitabxanadan istifadə edilə bilər. iOS-da ekvivalent MetricKit-dir, o, başlanğıc vaxtı, kadr tezliyi və yaddaş istifadəsi haqqında məlumat toplayır.

İsti başlanğıcın ətraflı profilləşdirilməsi üçün Firebase Performance Monitoring (custom traces izləyir) və New Relic başlanğıc vaxtı dashboardları ilə uyğundur. Tərtibatçı tərəfindən əl ilə ölçmə üçün Android-də reportFullyDrawn — UI-nin çəkildiyi və qarşılıqlı əlaqəyə hazır olduğu dəqiq anı sistemə bildirən API istifadə olunur. iOS-da ekvivalent MetricKit-də endActivity-dir. Bu alətləri birləşdirərək, Hot Start-ı məhz konkret cihazlarda hansı SDK və ya kod blokunun ləngitdiyini müəyyən etmək olar.

Hot Start üçün Macrobenchmark nümunəsi

Macrobenchmark kitabxanasından istifadə edən Kotlin kodu Cold və Hot Start ölçmək üçün. Test Activity-ni işə salır və complete vəziyyətinə qədər vaxtı ölçür.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun hotStart() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 10,
            startupMode = StartupMode.HOT
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}