Hot Start i mobila appar: vad är det, faktorer och hur man snabbar upp

Vad är Hot Start i mobila appar

Hot Start — är ett startscenario där appens process redan finns i enhetens RAM-minne. Användaren minimerar appen, återvänder sedan — och systemet skapar inte en ny process utan återupptar en befintlig. I detta scenario krävs inte inläsning av OS, initiering av Application-klassen och skapande av process, vilket dramatiskt minskar tiden tills UI visas på skärmen. Enligt Android Documentation (2025) tar Hot Start endast 200–500 ms, medan Cold Start kan nå 5 sekunder eller mer. Skillnaden i hastighet är särskilt märkbar på enheter med begränsat minne, där systemet oftare tar bort bakgrundsappar.

Huvuddraget för Hot Start — minimal uppsättning anropade lifecycle-metoder. I Android är dessa Activity.onCreate och Activity.onStart, i iOS — applicationDidBecomeActive. Till skillnad från Cold Start, där Application.onCreate, ContentProvider.onCreate, Activity.onCreate och många biblioteksinitieringar anropas i följd, hoppar Hot Start över alla dessa steg. Utvecklaren måste förstå vilken kod som exakt körs vid varmstart — ofta upprepas tunga initieringar av SDK:er, analys och DI-behållare både vid Cold och Hot Start, trots att de inte längre behövs vid varmstart.

Cold Start, Warm Start och Hot Start: jämförelse

De tre startscenarierna skiljer sig i initieringsdjup. Cold Start (kallstart) inträffar när appen startas första gången efter installation, omstart av enheten eller borttagning från minnet. Systemet skapar en ny Linux-process, laddar Application-klasser, skapar ContentProvider-instanser, utför biblioteksinitiering och först därefter visas Activity. Hela processen tar 2–10 sekunder beroende på appens komplexitet och enhetens egenskaper.

Warm Start (ljumstart) — ett mellanliggande scenario. Appens process lever i minnet, men Activity har förstörts och måste återskapas. Detta händer till exempel vid skärmrotation eller vid återkomst från en annan app, när Activity togs bort på grund av minnesbrist men processen finns kvar. Warm Start omfattar anrop av Activity.onCreate och Activity.onStart, men inte Application.onCreate och ContentProvider-initiering. Tiden för Warm Start — från 500 ms till 2 sekunder. Hot Start — den snabbaste av de tre: Activity finns redan i back stack, processen lever och systemet anropar helt enkelt Activity.onRestart, onStart och onResume. Tiden för Hot Start — 200–500 ms. Skillnaden från Warm Start är att Activity inte skapas på nytt — det återställs från en befintlig instans.

Android Lifecycle vid Hot Start

I Android initieras Hot Start när användaren återvänder till appen via Recents-skärmen eller genom att klicka på ikonen i minimerat tillstånd. Systemet kontrollerar om processen lever, och om så är fallet — anropar det i följd Activity.onRestart, onStart och onResume. Metoden onCreate anropas inte vid Hot Start, eftersom Activity-instansen redan finns i minnet. Detta är en viktig skillnad från Warm Start, där onCreate fortfarande anropas på grund av att Activity förstörts. Enligt Google I/O 2019 är den typiska Hot Start-tiden i Android 200–400 ms, och varje försening i denna fas ökar direkt perceived launch time.

Utvecklare märker ofta inte att koden för UI-initiering, prenumeration på LiveData eller konfiguration av RecyclerView körs inte bara i onCreate utan även i onStart eller onResume. Vid Hot Start körs dessa kodblock igen, trots att UI redan har konfigurerats. Det rekommenderas att separera engångsinitiering (i onCreate med kontroll av savedInstanceState) och återupptagbar logik (onStart/onResume). Till exempel tunga operationer — konfiguration av adaptrar, inläsning av listor — är det bättre att flytta till ett block som inte körs vid onRestart, eller kontrollera savedInstanceState.

Exempel på spårning av starttyp

Följande kod i Kotlin demonstrerar ett enkelt sätt att bestämma startscenario och mäta tid. Variabeln launchTimeStamp registrerar ögonblicket för startens början, och isColdStart gör det möjligt att separera logiken för kall och varm start.

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()
            // engångsinitiering
        } else {
            isColdStart = false
            // Hot Start — Activity återställs
        }
    }

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

iOS Lifecycle vid varmstart

I iOS motsvarar Hot Start återkomsten av appen från bakgrunden via sceneDidBecomeActive (UIKit) eller onAppear (SwiftUI). Operativsystemet återskapar inte processen om appen var i tillståndet Suspended eller Background. Vid varmstart anropas applicationDidBecomeActive i AppDelegate, men applicationDidFinishLaunching anropas inte — detta är analogt med Android, där Application.onCreate hoppas över. iOS tar bort appar från minnet mer aggressivt: om enheten inte har tillräckligt med RAM kan systemet ta bort bakgrundsappen, och nästa start blir Cold Start. Enligt Apple Developer Documentation är den genomsnittliga Hot Start-tiden i iOS 300–600 ms.

Den viktigaste skillnaden med iOS — avsaknaden av en direkt analogi till Warm Start i Android-bemärkelse. I iOS vid minimering av appen anropas sceneDidEnterBackground, och vid återkomst — sceneWillEnterForeground och sceneDidBecomeActive. Om systemet tar bort scenen men lämnar processen vid liv, blir nästa start Cold ur scenens synvinkel men Hot ur processens synvinkel. Utvecklaren måste ta hänsyn till detta vid placering av initieringskod: prenumeration på NotificationCenter, UI-uppdatering och återställning av tillstånd bör vara precis i sceneDidBecomeActive, inte bara i viewDidLoad.

Exempel på hantering av Hot Start i iOS

Denna kod i Swift visar hur man spårar antalet varmstarter och separerar logik. Räknaren foregroundCount ökar vid varje återkomst från bakgrunden.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

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

        if foregroundCount == 1 {
            // Cold Start — fullständig initiering
            setupSDKs()
        } else {
            // Hot Start — endast UI-uppdatering
            refreshUI()
        }
    }

    private func refreshUI() {
        // datauppdatering på skärmen
    }
}

Faktorer som påverkar Hot Starts hastighet

Hastigheten på Hot Start påverkas av flera kategorier av faktorer. Den första — mängden arbete i lifecycle-metoderna onStart och onResume. Om utvecklaren har placerat i dessa metoder inläsning av data från nätverket, JSON-tolkning, initiering av adaptrar eller tunga beräkningar, lägger varje sådant block till tiotals och hundratals millisekunder till starttiden. Enligt data från verktyget Android Vitals förlorar appar med Hot Start-tid över 800 ms upp till 20% av användarna vid återkommande återkomst.

Den andra kategorin — fragment och Vyer som återställs från savedInstanceState. Om fragment innehåller tunga ViewPager2, WebView eller komplexa hierarkier med djup nästling, förbrukar deras återställning CPU-resurser. Enligt Google I/O 2023 lägger varje nästlad ViewGroup i genomsnitt 2–5 ms till renderingstiden vid Hot Start. Den tredje kategorin — SDK:er från tredje part: analysbibliotek, crash-reporting, A/B-testning och DEX-laddare kan utföra initiering vid varje återkomst från bakgrunden. Det rekommenderas att kontrollera vilka SDK:er som kör kod precis i onStart/onResume, och skjuta upp icke-kritiska uppgifter till en bakgrundstråd.

Optimeringsmetoder för varmstart

Optimering av Hot Start handlar om att minimera arbete i lifecycle-metoderna för återupptagning. Den första metoden — lat initiering: all kod som inte behövs för den första UI-bilden bör köras efter anrop av onResume med fördröjning via Handler.postDelayed eller Coroutine.launch(Dispatchers.IO). Den andra metoden — cachning av View-tillstånd: vid minimering av appen spara data i en cache i minnet, så att du vid Hot Start inte behöver ladda dem igen från databasen eller nätverket. Den tredje metoden — användning av SavedStateHandle i Android och StateRestorationPolicy i iOS för att minimera mängden återställd data.

Lat inläsning efter Hot Start

I detta exempel fördröjer Handler.postDelayed initieringen av analys med 500 ms efter rendering av den första bilden. Detta påverkar inte perceived launch time, eftersom användaren redan ser gränssnittet.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // initiering efter första bilden
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Användning av App Startup-biblioteket

AndroidX App Startup gör det möjligt att hantera ordningen för komponentinitiering vid start. Alla ContentProvider initieras automatiskt vid Cold Start, men du kan stänga av automatisk initiering för komponenter som inte behövs vid 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<*>>()
}

Verktyg för övervakning av starttid

För mätning av Hot Start-tiden finns både inbyggda plattformsverktyg och tredjepartslösningar. I Android är det viktigaste verktyget Android Vitals i Google Play Console — det samlar automatiskt in mätvärden för starttid för alla scenarier (Cold, Warm, Hot) uppdelat efter enhetsmodeller och OS-versioner. Dessutom kan Macrobenchmark från AndroidX användas — ett bibliotek för automatiserad testning av startprestanda. I iOS är motsvarigheten MetricKit, som samlar in data om starttid, bildfrekvens och minnesanvändning.

För detaljerad profilering av varmstart är Firebase Performance Monitoring (spårar custom traces) och New Relic med instrumentpaneler för starttid lämpliga. På utvecklarsidan för manuell mätning används reportFullyDrawn i Android — ett API som rapporterar till systemet det exakta ögonblicket när UI har renderats och är redo för interaktion. I iOS är motsvarigheten endActivity i MetricKit. Genom att kombinera dessa verktyg kan man identifiera vilket SDK eller kodblock som saktar ner Hot Start på specifika enheter.

Exempel på Macrobenchmark för Hot Start

Kod i Kotlin med hjälp av Macrobenchmark-biblioteket för mätning av Cold och Hot Start. Testet startar Activity och mäter tiden till complete-status.

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