Hot Start у мобилним апликацијама: шта је то, фактори и како убрзати

Шта је Hot Start у мобилним апликацијама

Hot Start — сценарио покретања апликације при којем њен процес већ постоји у RAM меморији уређаја. Корисник смањује апликацију, затим се враћа — и систем не ствара нови процес, већ наставља постојећи. У овом сценарију није потребно учитавање ОС, иницијализација класе Application и стварање процеса, што драстично смањује време до појаве UI на екрану. Према Android Documentation (2025), Hot Start траје само 200–500 ms, док Cold Start може достићи 5 секунди и више. Разлика у брзини је посебно приметна на уређајима са ограниченом меморијом, где систем чешће истовара позадинске апликације.

Главна карактеристика Hot Start — минимални скуп позваних lifecycle метода. У Android-у су то Activity.onCreate и Activity.onStart, у iOS-у — applicationDidBecomeActive. За разлику од Cold Start, где се редом позивају Application.onCreate, ContentProvider.onCreate, Activity.onCreate и бројне иницијализације библиотека, Hot Start прескаче све ове фазе. Програмер мора да разуме који се код извршава управо при врућем покретању — често се тешке иницијализације SDK-а, аналитике и DI контејнера понављају и на Cold и на Hot Start, иако при врућем старту више нису потребне.

Cold Start, Warm Start и Hot Start: поређење

Три сценарија покретања апликације разликују се по дубини иницијализације. Cold Start (хладни старт) се дешава када се апликација покреће први пут након инсталације, поновног покретања уређаја или истовара из меморије. Систем ствара нови Linux процес, учитава класе Application, ствара инстанце ContentProvider, извршава иницијализацију библиотека и тек онда приказује Activity. Цео процес траје 2–10 секунди у зависности од сложености апликације и карактеристика уређаја.

Warm Start (топли старт) — прелазни сценарио. Процес апликације је жив у меморији, али Activity је уништена и мора се поново створити. То се дешава, на пример, при ротацији екрана или при повратку из друге апликације, када је Activity истоварена због недостатка меморије, али је процес остао. Warm Start укључује позив Activity.onCreate и Activity.onStart, али не укључује Application.onCreate и иницијализацију ContentProvider. Време Warm Start — од 500 ms до 2 секунде. Hot Start — најбржи од три: Activity већ постоји у back stack-у, процес је жив, а систем једноставно позива Activity.onRestart, onStart и onResume. Време Hot Start — 200–500 ms. Разлика од Warm Start је у томе што се Activity не ствара изнова — враћа се из постојеће инстанце.

Android Lifecycle при Hot Start

У Android-у Hot Start се покреће када се корисник враћа у апликацију преко Recents екрана или кликом на икону у смањеном стању. Систем проверава да ли је процес жив, и ако јесте — позива редом Activity.onRestart, onStart и onResume. Метод onCreate се при Hot Start не позива, јер инстанца Activity већ постоји у меморији. Ово је важна разлика од Warm Start, где се onCreate ипак позива због уништења Activity. Према Google I/O 2019, типично време Hot Start у Android-у је 200–400 ms, и свако успоравање у овој фази директно повећава perceived launch time.

Програмери често не примећују да се код иницијализације UI, претплате на LiveData или подешавања RecyclerView извршава не само у onCreate, већ и у onStart или onResume. При Hot Start ови блокови кода се извршавају поново, иако је UI већ подешен. Препоручује се раздвајање једнократне иницијализације (у onCreate са провером savedInstanceState) и логике која се може наставити (onStart/onResume). На пример, тешке операције — подешавање адаптера, учитавање листи — боље је преместити у блок који се не извршава при onRestart, или проверавати savedInstanceState.

Пример праћења типа покретања

Следећи код у Kotlin-у демонстрира једноставан начин одређивања сценарија старта и мерења времена. Променљива launchTimeStamp бележи тренутак почетка покретања, а isColdStart омогућава раздвајање логике за хладно и вруће покретање.

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()
            // једнократна иницијализација
        } else {
            isColdStart = false
            // Hot Start — Activity се враћа
        }
    }

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

iOS Lifecycle при врућем покретању

У iOS-у Hot Start одговара повратку апликације из позадине кроз sceneDidBecomeActive (UIKit) или onAppear (SwiftUI). Оперативни систем не поново ствара процес ако је апликација била у стању Suspended или Background. При врућем покретању позива се applicationDidBecomeActive у AppDelegate, али се не позива applicationDidFinishLaunching — ово је аналогно Android-у, где се Application.onCreate прескаче. iOS агресивније истовара апликације из меморије: ако уређају недостаје RAM, систем може истоварити позадинску апликацију, и тада ће следеће покретање бити Cold Start. Према Apple Developer Documentation, просечно време Hot Start у iOS-у је 300–600 ms.

Кључна разлика iOS-а — недостатак директног аналога Warm Start у Android смислу. У iOS-у при смањењу апликације позива се sceneDidEnterBackground, а при повратку — sceneWillEnterForeground и sceneDidBecomeActive. Ако систем истовари сцену, али остави процес живим, следеће покретање ће бити Cold са становишта сцене, али Hot са становишта процеса. Програмер мора ово узети у обзир при постављању кода иницијализације: претплата на NotificationCenter, ажурирање UI и ресетовање стања треба да буду управо у sceneDidBecomeActive, а не само у viewDidLoad.

Пример обраде Hot Start у iOS-у

Овај код у Swift-у показује како пратити број врућих покретања и раздвојити логику. Бројач foregroundCount се повећава при сваком повратку из позадине.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

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

        if foregroundCount == 1 {
            // Cold Start — потпуна иницијализација
            setupSDKs()
        } else {
            // Hot Start — само ажурирање UI
            refreshUI()
        }
    }

    private func refreshUI() {
        // ажурирање података на екрану
    }
}

Фактори који утичу на брзину Hot Start

На брзину Hot Start утиче неколико категорија фактора. Прва — обим посла у lifecycle методима onStart и onResume. Ако је програмер у ове методе сместио учитавање података из мреже, парсирање JSON-а, иницијализацију адаптера или тешка израчунавања, сваки такав блок додаје десетине и стотине милисекунди времену покретања. Према подацима алата Android Vitals, апликације са трајањем Hot Start већим од 800 ms губе до 20% корисника при поновном повратку.

Друга категорија — фрагменти и View-ови који се враћају из savedInstanceState. Ако фрагменти садрже тешке ViewPager2, WebView или сложене хијерархије са дубоким угњежђењем, њихово враћање троши CPU ресурсе. Према Google I/O 2023, сваки угњеждени ViewGroup додаје у просеку 2–5 ms времену рендеровања при Hot Start. Трећа категорија — SDK-ови трећих страна: библиотеке аналитике, crash-reporting, A/B-тестирања и DEX учитавачи могу извршавати иницијализацију при сваком повратку из позадине. Препоручује се провера који SDK-ови покрећу код управо у onStart/onResume, и одлагање некритичних задатака на позадинску нит.

Методе оптимизације врућег покретања

Оптимизација Hot Start се своди на минимизацију посла у lifecycle методима наставка. Прва метода — лења иницијализација: сав код који није потребан за први оквир UI треба извршити након позива onResume са кашњењем кроз Handler.postDelayed или Coroutine.launch(Dispatchers.IO). Друга метода — кеширање стања View: при смањењу апликације чувајте податке у in-memory кешу, како их при Hot Start не бисте поново учитавали из базе или мреже. Трећа метода — коришћење SavedStateHandle у Android-у и StateRestorationPolicy у iOS-у за минимизацију обима података који се враћају.

Лења иницијализација после Hot Start

У овом примеру Handler.postDelayed одлаже иницијализацију аналитике за 500 ms након рендеровања првог оквира. То не утиче на perceived launch time, јер корисник већ види интерфејс.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // иницијализација после првог оквира
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Коришћење App Startup библиотеке

AndroidX App Startup омогућава управљање редоследом иницијализације компоненти при покретању. Сви ContentProvider се аутоматски иницијализују при Cold Start, али можете искључити аутоматску иницијализацију за компоненте које нису потребне при 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<*>>()
}

Алати за праћење времена покретања

За мерење времена Hot Start постоје како уграђени алати платформи, тако и решења трећих страна. У Android-у кључни алат је Android Vitals у Google Play Console — аутоматски прикупља метрике времена покретања за све сценарије (Cold, Warm, Hot) са разврставањем по моделима уређаја и верзијама ОС. Додатно се може користити Macrobenchmark из AndroidX — библиотека за аутоматизовано тестирање перформанси покретања. У iOS-у еквивалент је MetricKit, који прикупља податке о времену покретања, фреквенцији оквира и коришћењу меморије.

За детаљно профилисање врућег покретања погодни су Firebase Performance Monitoring (прати custom traces) и New Relic са контролним таблама времена покретања. На страни програмера за ручно мерење користи се reportFullyDrawn у Android-у — API који јавља систему тачан тренутак када је UI нацртан и спреман за интеракцију. У iOS-у еквивалент је endActivity у MetricKit-у. Комбиновањем ових алата може се открити који SDK или блок кода успорава Hot Start управо на одређеним уређајима.

Пример Macrobenchmark за Hot Start

Код у Kotlin-у коришћењем библиотеке Macrobenchmark за мерење Cold и Hot Start. Тест покреће Activity и мери време до 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()
        }
    }
}