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