Hot Start w aplikacjach mobilnych: co to jest, czynniki i jak przyspieszyć

Czym jest Hot Start w aplikacjach mobilnych

Hot Start — to scenariusz uruchamiania aplikacji, w którym jej proces już istnieje w pamięci RAM urządzenia. Użytkownik minimalizuje aplikację, a następnie do niej wraca — system nie tworzy nowego procesu, lecz wznawia istniejący. W tym scenariuszu nie jest wymagane ładowanie OS, inicjalizacja klasy Application i tworzenie procesu, co radykalnie skraca czas do pojawienia się UI na ekranie. Według Android Documentation (2025), Hot Start zajmuje zaledwie 200–500 ms, podczas gdy Cold Start może osiągnąć 5 sekund i więcej. Różnica w szybkości jest szczególnie widoczna na urządzeniach z ograniczoną pamięcią, gdzie system częściej wyładowuje aplikacje działające w tle.

Główna cecha Hot Start — minimalny zestaw wywoływanych metod lifecycle. W Android są to Activity.onCreate i Activity.onStart, w iOS — applicationDidBecomeActive. W przeciwieństwie do Cold Start, gdzie kolejno wywoływane są Application.onCreate, ContentProvider.onCreate, Activity.onCreate i wiele inicjalizacji bibliotek, Hot Start pomija wszystkie te etapy. Deweloper musi rozumieć, który kod jest wykonywany właśnie podczas gorącego uruchamiania — często ciężkie inicjalizacje SDK, analityki i kontenerów DI powtarzają się zarówno w Cold, jak i Hot Start, mimo że przy gorącym starcie nie są już potrzebne.

Cold Start, Warm Start i Hot Start: porównanie

Trzy scenariusze uruchamiania aplikacji różnią się głębokością inicjalizacji. Cold Start (zimny start) występuje, gdy aplikacja jest uruchamiana po raz pierwszy po instalacji, restarcie urządzenia lub wyładowaniu z pamięci. System tworzy nowy proces Linux, ładuje klasy Application, tworzy instancje ContentProvider, wykonuje inicjalizację bibliotek i dopiero wtedy renderuje Activity. Cały proces zajmuje 2–10 sekund w zależności od złożoności aplikacji i charakterystyki urządzenia.

Warm Start (ciepły start) — scenariusz pośredni. Proces aplikacji żyje w pamięci, ale Activity zostało zniszczone i musi być odtworzone. Dzieje się tak na przykład przy obrocie ekranu lub przy powrocie z innej aplikacji, gdy Activity zostało wyładowane z powodu braku pamięci, ale proces pozostał. Warm Start obejmuje wywołanie Activity.onCreate i Activity.onStart, ale nie obejmuje Application.onCreate i inicjalizacji ContentProvider. Czas Warm Start — od 500 ms do 2 sekund. Hot Start — najszybszy z trzech: Activity już istnieje w back stack, proces żyje, a system po prostu wywołuje Activity.onRestart, onStart i onResume. Czas Hot Start — 200–500 ms. Różnica od Warm Start polega na tym, że Activity nie jest tworzone od nowa — jest przywracane z istniejącej instancji.

Android Lifecycle podczas Hot Start

W Android Hot Start jest inicjowany, gdy użytkownik wraca do aplikacji przez ekran Recents lub kliknięciem ikony w stanie zminimalizowanym. System sprawdza, czy proces żyje, a jeśli tak — wywołuje kolejno Activity.onRestart, onStart i onResume. Metoda onCreate podczas Hot Start nie jest wywoływana, ponieważ instancja Activity już istnieje w pamięci. To ważna różnica w stosunku do Warm Start, gdzie onCreate jest jednak wywoływane z powodu zniszczenia Activity. Według Google I/O 2019, typowy czas Hot Start w Android wynosi 200–400 ms, a każde spowolnienie na tym etapie bezpośrednio zwiększa perceived launch time.

Deweloperzy często nie zauważają, że kod inicjalizacji UI, subskrypcja LiveData lub konfiguracja RecyclerView są wykonywane nie tylko w onCreate, ale także w onStart lub onResume. Podczas Hot Start te bloki kodu są wykonywane ponownie, mimo że UI został już skonfigurowany. Zaleca się rozdzielanie jednorazowej inicjalizacji (w onCreate z sprawdzeniem savedInstanceState) i logiki wznawialnej (onStart/onResume). Na przykład ciężkie operacje — konfiguracja adapterów, ładowanie list — lepiej przenieść do bloku, który nie jest wykonywany przy onRestart, lub sprawdzać savedInstanceState.

Przykład śledzenia typu uruchomienia

Poniższy kod w Kotlin demonstruje prosty sposób określenia scenariusza startu i pomiaru czasu. Zmienna launchTimeStamp rejestruje moment rozpoczęcia uruchamiania, a isColdStart pozwala rozdzielić logikę dla zimnego i gorącego startu.

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()
            // jednorazowa inicjalizacja
        } else {
            isColdStart = false
            // Hot Start — Activity zostaje przywrócone
        }
    }

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

iOS Lifecycle podczas gorącego uruchamiania

W iOS Hot Start odpowiada powrotowi aplikacji z tła przez sceneDidBecomeActive (UIKit) lub onAppear (SwiftUI). System operacyjny nie odtwarza procesu, jeśli aplikacja była w stanie Suspended lub Background. Podczas gorącego uruchamiania wywoływane jest applicationDidBecomeActive w AppDelegate, ale nie jest wywoływane applicationDidFinishLaunching — to analogia do Androida, gdzie Application.onCreate jest pomijane. iOS bardziej agresywnie wyładowuje aplikacje z pamięci: jeśli urządzeniu brakuje RAM, system może wyładować aplikację działającą w tle, a wtedy następne uruchomienie będzie Cold Start. Według Apple Developer Documentation, średni czas Hot Start w iOS wynosi 300–600 ms.

Kluczowa różnica w iOS — brak bezpośredniego odpowiednika Warm Start w rozumieniu Androida. W iOS przy minimalizowaniu aplikacji wywoływane jest sceneDidEnterBackground, a przy powrocie — sceneWillEnterForeground i sceneDidBecomeActive. Jeśli system wyładowuje scenę, ale pozostawia proces żywy, następne uruchomienie będzie Cold z punktu widzenia sceny, ale Hot z punktu widzenia procesu. Deweloper musi to uwzględniać przy umieszczaniu kodu inicjalizacji: subskrypcja NotificationCenter, aktualizacja UI i resetowanie stanów powinny być właśnie w sceneDidBecomeActive, a nie tylko w viewDidLoad.

Przykład obsługi Hot Start w iOS

Ten kod w Swift pokazuje, jak śledzić liczbę gorących uruchomień i rozdzielać logikę. Licznik foregroundCount zwiększa się przy każdym powrocie z tła.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

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

        if foregroundCount == 1 {
            // Cold Start — pełna inicjalizacja
            setupSDKs()
        } else {
            // Hot Start — tylko aktualizacja UI
            refreshUI()
        }
    }

    private func refreshUI() {
        // aktualizacja danych na ekranie
    }
}

Czynniki wpływające na szybkość Hot Start

Na szybkość Hot Start wpływa kilka kategorii czynników. Pierwsza — ilość pracy w metodach lifecycle onStart i onResume. Jeśli deweloper umieścił w tych metodach ładowanie danych z sieci, parsowanie JSON, inicjalizację adapterów lub ciężkie obliczenia, każdy taki blok dodaje dziesiątki i setki milisekund do czasu uruchamiania. Według danych z narzędzia Android Vitals, aplikacje z czasem Hot Start powyżej 800 ms tracą do 20% użytkowników przy ponownym powrocie.

Druga kategoria — fragmenty i View przywracane z savedInstanceState. Jeśli fragmenty zawierają ciężkie ViewPager2, WebView lub złożone hierarchie z głębokim zagnieżdżeniem, ich przywracanie zajmuje zasoby CPU. Według Google I/O 2023, każdy zagnieżdżony ViewGroup dodaje średnio 2–5 ms do czasu renderowania podczas Hot Start. Trzecia kategoria — zewnętrzne SDK: biblioteki analityki, crash-reporting, A/B-testowania i DEX-loadery mogą wykonywać inicjalizację przy każdym powrocie z tła. Zaleca się sprawdzanie, które SDK uruchamiają kod właśnie w onStart/onResume, i odkładanie niekrytycznych zadań na wątek tła.

Metody optymalizacji gorącego uruchamiania

Optymalizacja Hot Start sprowadza się do minimalizacji pracy w metodach lifecycle wznowienia. Pierwsza metoda — leniwa inicjalizacja: cały kod, który nie jest potrzebny do pierwszej klatki UI, powinien być wykonywany po wywołaniu onResume z opóźnieniem przez Handler.postDelayed lub Coroutine.launch(Dispatchers.IO). Druga metoda — buforowanie stanu View: przy minimalizowaniu aplikacji zapisuj dane w pamięci podręcznej in-memory, aby podczas Hot Start nie ładować ich ponownie z bazy danych lub sieci. Trzecia metoda — używanie SavedStateHandle w Android i StateRestorationPolicy w iOS w celu minimalizacji ilości przywracanych danych.

Leniwe ładowanie po Hot Start

W tym przykładzie Handler.postDelayed opóźnia inicjalizację analityki o 500 ms po renderowaniu pierwszej klatki. Nie wpływa to na perceived launch time, ponieważ użytkownik już widzi interfejs.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // inicjalizacja po pierwszej klatce
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Korzystanie z biblioteki App Startup

AndroidX App Startup pozwala zarządzać kolejnością inicjalizacji komponentów podczas uruchamiania. Wszystkie ContentProvider są inicjalizowane automatycznie podczas Cold Start, ale możesz wyłączyć automatyczną inicjalizację dla komponentów niepotrzebnych podczas 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<*>>()
}

Narzędzia monitorowania czasu uruchamiania

Do pomiaru czasu Hot Start istnieją zarówno wbudowane narzędzia platform, jak i rozwiązania zewnętrzne. W Android kluczowym narzędziem jest Android Vitals w Google Play Console — automatycznie zbiera metryki czasu uruchamiania dla wszystkich scenariuszy (Cold, Warm, Hot) z podziałem na modele urządzeń i wersje OS. Dodatkowo można użyć Macrobenchmark z AndroidX — biblioteki do zautomatyzowanego testowania wydajności startu. W iOS odpowiednikiem jest MetricKit, który zbiera dane o czasie uruchamiania, częstotliwości klatek i użyciu pamięci.

Do szczegółowego profilowania gorącego startu nadają się Firebase Performance Monitoring (śledzi custom traces) i New Relic z dashboardami czasu uruchamiania. Po stronie dewelopera do ręcznego pomiaru używa się reportFullyDrawn w Android — API, które informuje system o dokładnym momencie, gdy UI jest narysowany i gotowy do interakcji. W iOS odpowiednikiem jest endActivity w MetricKit. Łącząc te narzędzia, można zidentyfikować, które SDK lub blok kodu spowalnia Hot Start właśnie na konkretnych urządzeniach.

Przykład Macrobenchmark dla Hot Start

Kod w Kotlin z użyciem biblioteki Macrobenchmark do pomiaru Cold i Hot Start. Test uruchamia Activity i mierzy czas do osiągnięcia stanu 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()
        }
    }
}