Hot Start у мобільних додатках: що це, фактори та як прискорити

Що таке Hot Start у мобільних додатках

Hot Start — це сценарій запуску додатку, при якому його процес вже існує в оперативній пам'яті пристрою. Користувач згортає додаток, потім повертається — і система не створює новий процес, а відновлює існуючий. У цьому сценарії не потрібне завантаження ОС, ініціалізація класу Application та створення процесу, що кардинально скорочує час до появи UI на екрані. За даними Android Documentation (2025), Hot Start займає всього 200–500 мс, тоді як 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 мс до 2 секунд. Hot Start — найшвидший із трьох: Activity вже існує в back stack, процес живий, і система просто викликає Activity.onRestart, onStart та onResume. Час Hot Start — 200–500 мс. Відмінність від Warm Start у тому, що Activity не створюється заново — вона відновлюється з існуючого екземпляра.

Android Lifecycle при Hot Start

В Android Hot Start ініціюється, коли користувач повертається в додаток через Recents screen або натисканням на іконку при згорнутому стані. Система перевіряє, чи живий процес, і якщо так — викликає послідовно Activity.onRestart, onStart та onResume. Метод onCreate при Hot Start не викликається, оскільки екземпляр Activity вже існує в пам'яті. Це важлива відмінність від Warm Start, де onCreate все ж викликається через знищення Activity. За даними Google I/O 2019, типовий час Hot Start в Android становить 200–400 мс, і будь-яке уповільнення на цьому етапі безпосередньо збільшує 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 мс.

Ключова відмінність 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 мс втрачають до 20% користувачів при повторному поверненні.

Друга категорія — фрагменти та View, що відновлюються з savedInstanceState. Якщо фрагменти містять важкі ViewPager2, WebView або складні ієрархії з глибокою вкладеністю, їх відновлення займає ресурси CPU. За даними Google I/O 2023, кожна вкладена ViewGroup додає в середньому 2–5 мс до часу рендерингу при 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 мс після відмальовки першого кадру. Це не впливає на 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()
        }
    }
}