Hot Start în aplicațiile mobile: ce este, factori și cum să accelerezi

Ce este Hot Start în aplicațiile mobile

Hot Start — este scenariul de pornire a aplicației în care procesul său există deja în memoria RAM a dispozitivului. Utilizatorul minimizează aplicația, apoi revine — iar sistemul nu creează un proces nou, ci reia unul existent. În acest scenariu nu este necesară încărcarea OS, inițializarea clasei Application și crearea procesului, ceea ce reduce radical timpul până la apariția UI pe ecran. Conform Android Documentation (2025), Hot Start durează doar 200–500 ms, în timp ce Cold Start poate atinge 5 secunde și mai mult. Diferența de viteză este deosebit de vizibilă pe dispozitivele cu memorie limitată, unde sistemul descarcă mai frecvent aplicațiile de fundal.

Caracteristica principală a Hot Start — setul minim de metode lifecycle apelate. În Android acestea sunt Activity.onCreate și Activity.onStart, în iOS — applicationDidBecomeActive. Spre deosebire de Cold Start, unde sunt apelate succesiv Application.onCreate, ContentProvider.onCreate, Activity.onCreate și numeroase inițializări de biblioteci, Hot Start sare peste toate aceste etape. Dezvoltatorul trebuie să înțeleagă ce cod se execută exact la pornirea la cald — adesea inițializările grele ale SDK-urilor, analiticii și containerelor DI se repetă atât la Cold, cât și la Hot Start, deși la pornirea la cald nu mai sunt necesare.

Cold Start, Warm Start și Hot Start: comparație

Cele trei scenarii de pornire a aplicației diferă prin profunzimea inițializării. Cold Start (pornire la rece) are loc când aplicația este lansată pentru prima dată după instalare, repornirea dispozitivului sau descărcarea din memorie. Sistemul creează un nou proces Linux, încarcă clasele Application, creează instanțe ContentProvider, execută inițializarea bibliotecilor și abia apoi afișează Activity. Întregul proces durează 2–10 secunde în funcție de complexitatea aplicației și caracteristicile dispozitivului.

Warm Start (pornire la călduț) — scenariu intermediar. Procesul aplicației este viu în memorie, dar Activity a fost distrusă și trebuie recreată. Aceasta se întâmplă, de exemplu, la rotirea ecranului sau la revenirea dintr-o altă aplicație, când Activity a fost descărcată din cauza lipsei de memorie, dar procesul a rămas. Warm Start include apelarea Activity.onCreate și Activity.onStart, dar nu include Application.onCreate și inițializarea ContentProvider. Timpul Warm Start — de la 500 ms la 2 secunde. Hot Start — cel mai rapid dintre trei: Activity există deja în back stack, procesul este viu, iar sistemul apelează pur și simplu Activity.onRestart, onStart și onResume. Timpul Hot Start — 200–500 ms. Diferența față de Warm Start constă în faptul că Activity nu este creată din nou — este restaurată dintr-o instanță existentă.

Android Lifecycle la Hot Start

În Android Hot Start este inițiat când utilizatorul revine în aplicație prin ecranul Recents sau prin atingerea pictogramei în stare minimizată. Sistemul verifică dacă procesul este viu și, dacă da — apelează succesiv Activity.onRestart, onStart și onResume. Metoda onCreate nu este apelată la Hot Start, deoarece instanța Activity există deja în memorie. Aceasta este o diferență importantă față de Warm Start, unde onCreate este totuși apelat din cauza distrugerii Activity. Conform Google I/O 2019, timpul tipic al Hot Start în Android este de 200–400 ms, iar orice încetinire în această etapă crește direct perceived launch time.

Dezvoltatorii adesea nu observă că codul de inițializare UI, abonarea la LiveData sau configurarea RecyclerView se execută nu doar în onCreate, ci și în onStart sau onResume. La Hot Start aceste blocuri de cod se execută din nou, deși UI a fost deja configurat. Se recomandă separarea inițializării unice (în onCreate cu verificarea savedInstanceState) și a logicii reluabile (onStart/onResume). De exemplu, operațiile grele — configurarea adaptoarelor, încărcarea listelor — este mai bine să fie mutate într-un bloc care nu se execută la onRestart, sau să se verifice savedInstanceState.

Exemplu de urmărire a tipului de pornire

Următorul cod în Kotlin demonstrează o modalitate simplă de a determina scenariul de pornire și de a măsura timpul. Variabila launchTimeStamp fixează momentul începerii pornirii, iar isColdStart permite separarea logicii pentru pornire la rece și la cald.

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()
            // inițializare unică
        } else {
            isColdStart = false
            // Hot Start — Activity este restaurată
        }
    }

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

iOS Lifecycle la pornirea la cald

În iOS Hot Start corespunde revenirii aplicației din fundal prin sceneDidBecomeActive (UIKit) sau onAppear (SwiftUI). Sistemul de operare nu recrează procesul dacă aplicația a fost în starea Suspended sau Background. La pornirea la cald este apelat applicationDidBecomeActive în AppDelegate, dar nu este apelat applicationDidFinishLaunching — aceasta este o analogie cu Android, unde Application.onCreate este omis. iOS descarcă mai agresiv aplicațiile din memorie: dacă dispozitivul nu are suficient RAM, sistemul poate descărca aplicația de fundal, iar următoarea pornire va fi Cold Start. Conform Apple Developer Documentation, timpul mediu al Hot Start în iOS este de 300–600 ms.

Diferența cheie a iOS — absența unui analog direct al Warm Start în înțelegerea Android. În iOS la minimizarea aplicației este apelat sceneDidEnterBackground, iar la revenire — sceneWillEnterForeground și sceneDidBecomeActive. Dacă sistemul descarcă scena, dar lasă procesul viu, următoarea pornire va fi Cold din punctul de vedere al scenei, dar Hot din punctul de vedere al procesului. Dezvoltatorul trebuie să țină cont de aceasta la plasarea codului de inițializare: abonarea la NotificationCenter, actualizarea UI și resetarea stărilor trebuie să fie exact în sceneDidBecomeActive, nu doar în viewDidLoad.

Exemplu de gestionare a Hot Start în iOS

Acest cod în Swift arată cum să urmărești numărul de porniri la cald și să separi logica. Contorul foregroundCount crește la fiecare revenire din fundal.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

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

        if foregroundCount == 1 {
            // Cold Start — inițializare completă
            setupSDKs()
        } else {
            // Hot Start — doar actualizare UI
            refreshUI()
        }
    }

    private func refreshUI() {
        // actualizare date pe ecran
    }
}

Factori care influențează viteza Hot Start

Viteza Hot Start este influențată de mai multe categorii de factori. Prima — volumul de lucru în metodele lifecycle onStart și onResume. Dacă dezvoltatorul a plasat în aceste metode încărcarea datelor din rețea, parsarea JSON, inițializarea adaptoarelor sau calcule grele, fiecare astfel de bloc adaugă zeci și sute de milisecunde la timpul de pornire. Conform datelor instrumentului Android Vitals, aplicațiile cu durata Hot Start mai mare de 800 ms pierd până la 20% din utilizatori la revenirea repetată.

A doua categorie — fragmentele și View-urile restaurate din savedInstanceState. Dacă fragmentele conțin ViewPager2 grele, WebView sau ierarhii complexe cu imbricare profundă, restaurarea lor consumă resurse CPU. Conform Google I/O 2023, fiecare ViewGroup imbricat adaugă în medie 2–5 ms la timpul de randare la Hot Start. A treia categorie — SDK-uri terțe: bibliotecile de analitică, crash-reporting, A/B-testare și încărcătoarele DEX pot executa inițializarea la fiecare revenire din fundal. Se recomandă verificarea care SDK-uri execută cod exact în onStart/onResume și amânarea sarcinilor necritice pe un thread de fundal.

Metode de optimizare a pornirii la cald

Optimizarea Hot Start se rezumă la minimizarea lucrului în metodele lifecycle de reluare. Prima metodă — inițializare leneșă: tot codul care nu este necesar pentru primul cadru UI trebuie executat după apelarea onResume cu întârziere prin Handler.postDelayed sau Coroutine.launch(Dispatchers.IO). A doua metodă — cache-ul stării View: la minimizarea aplicației salvați datele în cache în memorie, pentru ca la Hot Start să nu le reîncărcați din BD sau rețea. A treia metodă — utilizarea SavedStateHandle în Android și StateRestorationPolicy în iOS pentru minimizarea volumului de date restaurate.

Încărcare leneșă după Hot Start

În acest exemplu Handler.postDelayed amână inițializarea analiticii cu 500 ms după randarea primului cadru. Aceasta nu afectează perceived launch time, deoarece utilizatorul vede deja interfața.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // inițializare după primul cadru
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Utilizarea bibliotecii App Startup

AndroidX App Startup permite gestionarea ordinii de inițializare a componentelor la pornire. Toate ContentProvider-urile sunt inițializate automat la Cold Start, dar puteți dezactiva inițializarea automată pentru componentele care nu sunt necesare la Hot Start.

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

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

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

Instrumente de monitorizare a timpului de pornire

Pentru măsurarea timpului Hot Start există atât instrumente încorporate ale platformelor, cât și soluții terțe. În Android instrumentul cheie este Android Vitals în Google Play Console — colectează automat metrici ale timpului de pornire pentru toate scenariile (Cold, Warm, Hot) cu defalcare pe modele de dispozitive și versiuni OS. Suplimentar, puteți folosi Macrobenchmark din AndroidX — o bibliotecă pentru testarea automatizată a performanței de pornire. În iOS echivalentul este MetricKit, care colectează date despre timpul de pornire, frecvența cadrelor și utilizarea memoriei.

Pentru profilarea detaliată a pornirii la cald sunt potrivite Firebase Performance Monitoring (urmărește custom traces) și New Relic cu dashboard-uri ale timpului de pornire. De partea dezvoltatorului pentru măsurare manuală se folosește reportFullyDrawn în Android — API care raportează sistemului momentul exact când UI este randat și gata de interacțiune. În iOS echivalentul este endActivity în MetricKit. Combinând aceste instrumente, puteți identifica care SDK sau bloc de cod încetinește Hot Start exact pe anumite dispozitive.

Exemplu Macrobenchmark pentru Hot Start

Cod în Kotlin folosind biblioteca Macrobenchmark pentru măsurarea Cold și Hot Start. Testul lansează Activity și măsoară timpul până la starea complete.

@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()
        }
    }
}