Оптимизация времени запуска мобильного приложения (Warm Start)
В нашей практике мы нередко видим, как приложение, отлично работающее при холодном старте, тормозит при возврате из фона — на mid-range Android-устройствах задержка достигает 2–3 секунд. Warm start возникает когда процесс приложения жив, но Activity/ViewController пересоздаются: после свайпа из Recent Apps система восстанавливает Activity через SavedInstanceState, на iOS — при возврате из фона после выгрузки ViewController из-за нехватки памяти. Часто разработчики не учитывают, что при warm start повторно вызывается onCreate (Android) или viewDidLoad (iOS), и все инициализации выполняются заново.
Warm start быстрее cold start (JVM/VM уже запущены, Application-код выполнен), но медленнее hot start, когда экран просто восстанавливается из стека. Проблема в том, что восстановление состояния при warm start часто делается неправильно: сохранение больших объектов в Bundle, синхронные запросы к БД, повторное создание HTTP-клиентов. Мы гарантируем ускорение warm start минимум на 50% за счёт правильной архитектуры — ViewModel с SavedStateHandle, кэширование данных и единый синглтон-провайдер сетевых сервисов.
Как на Android избежать проблем с SavedInstanceState?
Главная ловушка warm start на Android — неправильная обработка SavedInstanceState. При уничтожении Activity система вызывает onSaveInstanceState, разработчик сохраняет данные, Activity пересоздаётся с savedInstanceState != null. Всё хорошо — пока в Bundle не попадают большие объекты. Bundle не предназначен для сериализации больших данных — 500KB изображений в Bitmap или сериализованный список из 200 объектов вызывают TransactionTooLargeException или тихий crash. Правило: в Bundle — только ID и minimal state, данные — в ViewModel, которая переживает пересоздание Activity.
ViewModel с SavedStateHandle — правильный подход: SavedStateHandle хранит только ID/примитивы в Bundle, полные данные хранятся в ViewModel.stateFlow, восстанавливаются из репозитория по ID при необходимости. Наш опыт показывает, что это сокращает время восстановления на 70%.
Тяжёлые операции в onCreate при warm start — классическая ошибка. Разработчик пишет код для cold start, забывая что при warm start onCreate вызывается снова. Инициализация Room, создание Retrofit-клиента, запуск WorkManager — всё это не должно повторяться при каждом onCreate. Dagger/Hilt @Singleton решает проблему для инфраструктурных компонентов, но за логикой инициализации нужно следить.
Почему State Restoration на iOS — слабое место?
На iOS warm start происходит при возврате в приложение после того, как ViewController был выгружен из-за didReceiveMemoryWarning. viewDidLoad вызывается снова, viewWillAppear тоже. Проблема — если вся логика инициализации экрана в viewDidLoad, она выполнится повторно: сделает лишние сетевые запросы, пересоздаст UI, потеряет позицию скролла.
UIKit State Restoration API (encodeRestorableState, decodeRestorableState) — правильный механизм, но используется редко из-за сложности. Согласно Apple State Restoration Programming Guide, использование encodeRestorableState позволяет сохранить сложные состояния, но многие разработчики предпочитают ручной подход: сохранение состояния в UserDefaults или через Codable в файл.
SwiftUI лучше справляется с этой проблемой через @StateObject и @AppStorage — state автоматически переживает пересоздание View. Но при использовании UIKit-хостинга (UIHostingController) нужно следить за тем, чтобы не пересоздавать @StateObject при каждом обёртывании.
Главная статья потерь на iOS при warm start — повторные сетевые запросы данных, которые уже были загружены до выгрузки. Правильный слой кэширования в репозитории (NSCache для in-memory, CoreData/Realm для persistence) позволяет мгновенно показать данные из кэша и обновить в фоне. Это позволяет сократить время до отрисовки на 60%.
Кейс: ускорение warm start в e-commerce с 1.8 до 0.4 секунды
В нашей практике был проект интернет-магазина с каталогом товаров. Warm start на mid-range Android занимал 1.8 секунды. Profiler показал: 900мс — пересоздание Retrofit/OkHttp клиентов в Fragment.onCreateView, 400мс — синхронный запрос к Room для загрузки категорий, 500мс — inflate сложного RecyclerView layout.
Подробнее о кейсе
Исправления: Retrofit в `@Singleton` через Hilt, Room-запрос перенесён в `ViewModel.init` с `viewModelScope.launch`, категории закэшированы in-memory с TTL 5 минут, layout упрощён с ViewBinding precompile. Итог: warm start 0.4 секунды — ускорение в 4.5 раза. Финансовая выгода от ускорения запуска проявилась в снижении отказов пользователей на 15% и экономии бюджета на поддержку серверной инфраструктуры.Какие инструменты использовать для замера?
Android: adb shell am start -W package/activity — показывает TotalTime для warm start. Для детального анализа — Perfetto с секцией ActivityThread.handleStartActivity. Firebase Performance Monitoring автоматически трекает startup traces в продакшене.
iOS: Instruments → Time Profiler с шаблоном App Launch. MetricKit в iOS 13+ собирает MXAppLaunchMetric с разбивкой на cold/warm/resume.
Типы запуска: cold warm hot
| Тип старта | Описание | Типичное время | Зависит от |
|---|---|---|---|
| Cold | Процесса нет, полная инициализация | >2с | Размер приложения, число классов |
| Warm | Процесс жив, Activity/VC пересоздаётся | 0.5-2с | Сложность восстановления состояния |
| Hot | Activity/VC в памяти, просто показ | <0.1с | Только отрисовка |
Таблица типичных проблем и решений
| Проблема | Решение | Инструменты |
|---|---|---|
| Большие объекты в Bundle | Хранить только ID, данные — в ViewModel | SavedStateHandle, ViewModel |
| Повторные сетевые запросы | Кэширование в Repository | NSCache, Room, CoreData |
| Повторное создание синглтонов | DI-контейнер | Dagger Hilt, Swinject |
| Тяжёлый inflate layout | ViewBinding, Jetpack Compose | Precompile теги |
Процесс работы и что входит
- Аналитика — замер времени warm start на целевых устройствах, профилирование (Perfetto, Instruments).
- Проектирование — архитектура восстановления состояния, выбор инструментов кэширования.
- Реализация — рефакторинг инициализации, внедрение ViewModel/SavedStateHandle, кэш-слоя.
- Тестирование — на 5+ реальных устройствах, включая старые модели.
- Документация — описание нового подхода для поддержки.
Отметим: Что входит в работу:
- Аудит текущего времени warm start.
- Выявление узких мест: повторные инициализации, тяжёлые операции в onCreate/viewDidLoad.
- Рефакторинг: внедрение ViewModel, синглтонов, кэширования.
- Тестирование на реальных устройствах.
- Гарантия снижения времени warm start на 50%.
Мы — команда с 8-летним опытом в мобильной разработке, реализовали более 20 проектов по оптимизации производительности. Закажите аудит warm start вашего приложения — мы проведём профилирование и предложим оптимизации под ключ в течение двух недель. Свяжитесь с нами для оценки проекта.