Оптимизация времени запуска мобильного приложения (Warm Start)
Warm start — приложение уже было запущено, процесс жив в памяти, но Activity/ViewController пересоздаётся. На Android это типичная ситуация после свайпа из Recent Apps и повторного открытия, или после того как система убила Activity из-за нехватки памяти, оставив процесс. На iOS — возврат в приложение после длительного пребывания в фоне, когда ViewController был выгружен из памяти.
Warm start медленнее hot start (когда процесс и Activity живы), но быстрее cold start — JVM/Dart VM/JS runtime уже запущены, Application-код уже выполнен. Проблема в том, что восстановление состояния при warm start часто делается неправильно.
Android: SavedInstanceState и ViewModel
Главная ловушка 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 при необходимости.
Тяжёлые операции в onCreate при warm start — классическая ошибка. Разработчик пишет код для cold start, забывая что при warm start onCreate вызывается снова. Инициализация Room, создание Retrofit-клиента, запуск WorkManager — всё это не должно повторяться при каждом onCreate. Dagger/Hilt @Singleton решает проблему для инфраструктурных компонентов, но за логикой инициализации нужно следить.
iOS: жизненный цикл и State Restoration
На iOS warm start происходит при возврате в приложение после того, как ViewController был выгружен из-за didReceiveMemoryWarning. viewDidLoad вызывается снова, viewWillAppear тоже. Проблема — если вся логика инициализации экрана в viewDidLoad, она выполнится повторно: сделает лишние сетевые запросы, пересоздаст UI, потеряет позицию скролла.
UIKit State Restoration API (encodeRestorableState, decodeRestorableState) — правильный механизм, но используется редко из-за сложности. Чаще встречается ручной подход: сохранение состояния в UserDefaults или через Codable в файл.
SwiftUI лучше справляется с этой проблемой через @StateObject и @AppStorage — state автоматически переживает пересоздание View. Но при использовании UIKit-хостинга (UIHostingController) нужно следить за тем, чтобы не пересоздавать @StateObject при каждом обёртывании.
Главная статья потерь на iOS при warm start — повторные сетевые запросы данных, которые уже были загружены до выгрузки. Правильный слой кэширования в репозитории (NSCache для in-memory, CoreData/Realm для persistence) позволяет мгновенно показать данные из кэша и обновить в фоне.
Практический кейс
Приложение e-commerce с каталогом товаров. Warm start на mid-range Android занимал 1.8 секунды. Profiler показал: 900ms — пересоздание Retrofit/OkHttp клиентов в Fragment.onCreateView, 400ms — синхронный запрос к Room для загрузки категорий, 500ms — inflate сложного RecyclerView layout.
Исправления: Retrofit в @Singleton через Hilt, Room-запрос перенесён в ViewModel.init с viewModelScope.launch, категории закэшированы в memory с TTL 5 минут, layout упрощён с ViewBinding precompile. Итог: warm start 0.4 секунды.
Метрики и инструменты
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.
Срок оптимизации — одна-две недели в зависимости от количества экранов и сложности архитектуры.