Настройка мониторинга скорости запуска приложения (Launch Time Tracking)

Время холодного запуска — первая метрика, которую замечает пользователь. Если ваш cold launch превышает 2 секунды, каждый двадцатый пользователь может закрыть приложение. Apple рекомендует холодный запуск менее 20 секунд, но реальный порог терпения ниже. Без мониторинга вы не узнаете, что P95 достигает 5 секунд. Мониторинг перцентилей (P50, P95) даёт полную картину: среднее значение скрывает хвост, который убивает пользовательский опыт. Настройка алертов на регрессию позволяет не пропустить ухудшение между релизами. Мы настраиваем мониторинг запуска для iOS и Android, используя MetricKit и Firebase Performance — многолетний опыт и десятки реализованных интеграций. С нашей помощью вы сможете в течение двух дней получить прозрачную систему метрик и перестать гадать, что тормозит запуск. Настройка включает интеграцию SDK, создание дашборда и настройку уведомлений в Slack или Telegram. Это позволяет сэкономить до 40% времени на отладку регрессий и повысить конверсию удержания на 5-10%.

Мониторинг скорости запуска: что измеряем и как

Cold launch — приложение не в памяти, процесс создаётся заново. Самый медленный, самый важный для мониторинга. Warm launch (iOS) — приложение было в памяти, но сброшено в background. Процесс жив, но viewDidLoad выполняется заново. Hot launch — возврат из background. Практически мгновенный. Мониторить нужно cold и warm. Hot не показателен.

Почему холодный запуск — главная метрика?

Холодный запуск — первое впечатление пользователя. Если он длится дольше 3 секунд, каждый двадцатый пользователь может закрыть приложение. Apple в рекомендациях по производительности требует холодный запуск менее 20 секунд, но реальный порог терпения — около 2 секунд. Мониторинг P95 показывает худший сценарий, который не виден в среднем.

Какой инструмент мониторинга выбрать для вашего проекта?

Выбор между MetricKit и Firebase Performance зависит от платформы и требований к real-time данным. MetricKit идеален для iOS-only проектов, где нужна агрегированная статистика от всех пользователей без установки SDK. Firebase Performance подходит для кроссплатформенных приложений и позволяет получать данные в реальном времени с разбивкой по устройствам. Подробнее о Firebase Performance можно узнать в документации Firebase Performance.

Как настроить мониторинг запуска?

1. Выберите инструмент: MetricKit или Firebase Performance.
2. Интегрируйте SDK в проект.
3. Добавьте кастомные метки для pre-main времени (iOS) или инициализации (Android).
4. Создайте дашборд метрик (P50, P95, распределение по версиям).
5. Настройте алерты на регрессию: уведомление, если P95 холодного запуска вырос на 20% по сравнению с предыдущей версией.
6. Проверьте сбор данных на реальных устройствах через TestFlight или Firebase App Distribution.

Встроенные инструменты платформ

iOS — MetricKit. Начиная с iOS 13, система агрегирует диагностику реальных пользователей и отдаёт через MXMetricManager:

class AppDelegate: MXMetricManagerSubscriber {
    func applicationDidFinishLaunching() {
        MXMetricManager.shared.add(self)
    }

    func didReceive(_ payloads: [MXMetricPayload]) {
        for payload in payloads {
            if let launchMetric = payload.applicationLaunchMetrics {
                let coldLaunchP50 = launchMetric.histogrammedTimeToFirstDrawKey
                    .histogram(for: .applicationLaunchTimeToFirstDraw)
                Analytics.track("cold_launch_p50", value: coldLaunchP50)
            }
        }
    }
}

MetricKit отдаёт данные раз в сутки, агрегированные за предыдущие 24 часа. Это не real-time, но реальная выборка по всем пользователям.

Android — Firebase Performance Monitoring. app_start trace собирается автоматически при подключении SDK. Разделяет app_start_cold и app_start_warm. Доступен в Firebase Console с разбивкой по устройствам, версиям ОС, версиям приложения.

Для кастомных меток в Android — FirebasePerformance.getInstance().newTrace("custom_init") + start() / stop(). Позволяет понять, какая именно инициализация тормозит.

Как измерить pre-main время на iOS?

Pre-main время (загрузка dynamic linker, инициализация Objective-C runtime) не покрывается обычными замерами в AppDelegate. Единственный способ увидеть его — включить переменную окружения DYLD_PRINT_STATISTICS в схеме Xcode. Для автоматического сбора используйте инструментирование через MetricKit и специализированные библиотеки.

Инструментирование в коде

Даже без внешних SDK можно измерить запуск самостоятельно.

iOS:

// В AppDelegate или @main
static let appLaunchTimestamp = Date()

// В viewDidAppear первого экрана
let launchDuration = Date().timeIntervalSince(AppDelegate.appLaunchTimestamp)
Analytics.track("cold_launch_duration", value: launchDuration)

Но этот метод неточен — не учитывает pre-main время (динамические библиотеки, runtime). Для pre-main: переменная окружения DYLD_PRINT_STATISTICS в Xcode схеме.

Android:

class App : Application() {
    override fun onCreate() {
        val start = SystemClock.elapsedRealtime()
        super.onCreate()
        // ... инициализации
        val initDuration = SystemClock.elapsedRealtime() - start
        FirebaseAnalytics.getInstance(this).logEvent("app_init_duration") {
            param("duration_ms", initDuration)
        }
    }
}

SystemClock.elapsedRealtime() точнее System.currentTimeMillis() для измерения интервалов.

Dashboard и алерты

Минимальный набор метрик для мониторинга:

Алерт на рост P95 между версиями — важнее абсолютного значения. Регрессия на 500 мс между двумя релизами — сигнал искать виновника в diff изменений.

В Grafana или Firebase Alerts настраиваем уведомление: если P95 cold launch в текущей версии превышает P95 предыдущей версии на 20% — уведомление в Slack.

Что входит в настройку мониторинга

• Интеграция MetricKit или Firebase Performance SDK.
• Настройка сбора данных cold/warm launch.
• Создание дашборда в Firebase Console или Grafana.
• Настройка алертов на регрессию (Slack, email).
• Документация по эксплуатации и рекомендации по оптимизации.
• Обучение разработчиков — до 1 часа консультации.

Мы гарантируем, что после настройки вы будете видеть P50, P95 и распределение времени запуска по версиям и устройствам.

Сроки: от 1 до 2 дней на базовую интеграцию. Оценим ваш проект бесплатно — свяжитесь с нами для консультации. Закажите настройку мониторинга запуска под ключ и получите готовую систему с алертами.

Оптимизация мобильных приложений: cold start, память, батарея, FPS, профилирование

Приложение с временем холодного старта 4+ секунды теряет пользователей ещё до первого экрана. Android Vitals в Google Play Console прямо влияют на ранжирование в поиске: приложения с плохими метриками получают меньший organic reach. Apple аналогично мониторит crash rate и время запуска через MetricKit. Оптимизация — это не «сделать быстрее», а понять где именно теряется время и что с этим делать.

Cold Start: где убивается время до первого кадра

Cold start — запуск приложения, когда процесс не существует в памяти. На Android это время от нажатия на иконку до Activity.onWindowFocusChanged(hasFocus = true). На iOS — от tap до viewDidAppear первого экрана.

Android: main thread перегружен при инициализации

Application.onCreate() — главный враг быстрого старта на Android. Разработчики инициализируют здесь всё подряд: Firebase, Analytics, базу данных, HTTP-клиент, DI-контейнер. Каждый SDK добавляет 20–200 мс на main thread.

Инструмент для диагностики: Android Studio Profiler → App Startup. Показывает граф инициализации с временем каждого компонента. Альтернатива — Tracing.beginSection("MyInitTag") в коде + systrace.

Решение: App Startup Library (Jetpack) с явным графом зависимостей инициализаторов. Компоненты, нужные только в конкретных сценариях, инициализируются лениво — by lazy {} или initializer с флагом lazyInit. Firebase Analytics, например, не нужен до первого пользовательского действия — его инициализацию можно отложить.

ContentProvider-ы, автоматически добавляемые SDK через AndroidManifest merge, тоже запускаются при старте. tools:node="remove" в манифесте позволяет отключить конкретный провайдер и инициализировать SDK вручную в нужный момент.

Ещё одна грабля: Room.databaseBuilder().build() на main thread. Это синхронная операция создания/открытия файла БД — на медленных устройствах занимает 50–300 мс. Переносим в coroutine с Dispatchers.IO, в ViewModel через viewModelScope.launch.

iOS: Dyld linking и +load

На iOS cold start делится на pre-main (до вызова main()) и post-main. Pre-main — время загрузки dylib, rebase/binding, Objective-C runtime initialization и выполнения +load методов.

Xcode Instruments → App Launch template показывает время pre-main и post-main раздельно. DYLD_PRINT_STATISTICS=1 в схеме запуска выводит детальное время загрузки в консоль.

Что убивает pre-main:

• Много динамических библиотек (каждая dylib — накладные расходы на линковку). CocoaPods добавляет отдельную dylib на каждый pod. Решение: Swift Package Manager со статической линковкой (type: .static) или use_frameworks! :linkage => :static в CocoaPods.
• +load методы в Objective-C — выполняются синхронно при загрузке класса, до main(). Сторонние SDK могут злоупотреблять этим. +initialize — ленивый аналог, вызывается при первом обращении к классу.

Post-main — application(_:didFinishLaunchingWithOptions:). Та же история что на Android: синхронная инициализация всего. lazy var для сервисов, которые не нужны немедленно. SwiftUI @StateObject инициализирует объект только когда View появляется — это уже встроенная ленивость.

Целевые метрики (App Store рекомендации): cold start < 400 мс для простых приложений, < 2 секунды для сложных. Warm start (процесс в памяти, но Activity/Scene пересоздаётся) — < 1 секунда.

Память: утечки, OOM, excessive pressure

Утечка памяти в iOS — retention cycle: объект A держит ссылку на B, B держит на A, ни один не освобождается. Классика: Timer с self в замыкании без [weak self]. Timer удерживает замыкание, замыкание удерживает self (ViewController), ViewController не освобождается при закрытии. Instruments → Leaks или Memory Graph Debugger в Xcode — находит живые объекты, которых не должно быть.

На Android garbage collector управляет памятью, но утечки всё равно случаются. Activity или Fragment, удерживаемые через статическую ссылку, singleton, или Handler/Runnable после onDestroy — классика. LeakCanary — обязательный инструмент в debug-сборке. Добавляется одной зависимостью debugImplementation "com.squareup.leakcanary:leakcanary-android" и автоматически детектирует утечки с полным стектрейсом.

OutOfMemoryError чаще всего происходит из-за загрузки изображений. Bitmap в памяти занимает ширина × высота × 4 байта. Изображение 4000×3000 px — 48 МБ в памяти, независимо от размера файла на диске. Glide / Coil правильно обрабатывают это: загружают с даунсемплингом под размер View, кешируют в LRU-кеш. Загружать в ImageView без Glide/Coil через BitmapFactory.decodeFile — путь к OOM на устройствах с 2 ГБ RAM.

На Flutter Dart VM имеет свой GC, но нативные ресурсы (изображения, текстуры) не управляются Dart GC. Image.network кеширует изображения в памяти без автоматического освобождения при выходе из дерева виджетов — при длинных списках с картинками используем cached_network_image с правильным memCacheWidth/memCacheHeight.

FPS и UI Performance

60 FPS — 16.67 мс на кадр. 120 FPS (ProMotion) — 8.33 мс. Всё что занимает больше на main thread — джанк.

Типичные причины просадок FPS:

На iOS: синхронная декодировка изображений в cellForRowAt. Когда ячейка таблицы появляется, UIImage(contentsOfFile:) декодирует JPEG/PNG на main thread — видно как заторможенный скролл на длинных списках. Решение: UIImage.preparingForDisplay() (iOS 15+) или ImageIO с kCGImageSourceCreateThumbnailWithTransform в background queue, результат через DispatchQueue.main.async.

На Android: RecyclerView.Adapter.onBindViewHolder с синхронными операциями. Базы данных, файловая система, синхронные сетевые запросы на main thread — StrictMode.ThreadPolicy с detectAll().penaltyLog() в debug-сборке покажет все нарушения.

На Flutter: build() метод вызывается часто, он должен быть дешёвым. setState() на верхнем виджете пересобирует всё дерево. const конструкторы, RepaintBoundary, разбиение на мелкие виджеты с локальным стейтом — основные инструменты. Flutter DevTools → Performance показывает janky frames (красные) с причинами.

Профилирование Compose: Recomposition Highlighter и трассировка через Trace.beginSection в @Composable. remember для дорогих вычислений, derivedStateOf для computed values, LazyColumn вместо Column + forEach для длинных списков.

Батарея: Wake locks, WorkManager, сетевые запросы

Приложение в топе по расходу батареи — пользователь видит это в настройках и удаляет. Android Battery Historian (из ADB bug report) показывает детальный timeline: wake locks, wakeups, network activity, sensor usage.

Основные потребители энергии:

• Постоянный GPS (разбираем в maps-geo)
• Polling сети каждые N секунд вместо push
• Holding wake lock дольше необходимого
• Excessive AlarmManager wakeups

WorkManager с Constraints — правильный способ планировать фоновые задачи: setRequiredNetworkType, setRequiresBatteryNotLow, setRequiresCharging. ОС батчирует задачи и выполняет в удобное время.

На iOS BGTaskScheduler с BGProcessingTaskRequest (для тяжёлых задач при зарядке) и BGAppRefreshTaskRequest (для лёгких обновлений) — система решает когда выполнять, разработчик только регистрирует и реализует логику.

Батчинг сетевых запросов: вместо 10 отдельных запросов в течение минуты — один батч запрос. Меньше радио-активностей (LTE radio потребляет много при инициализации соединения), меньше wakeups.

Инструменты профилирования

MetricKit на iOS — особенно ценен: реальные данные с устройств пользователей, а не симулятора. MXMetricManager получает агрегированные метрики раз в сутки: MXAppLaunchMetric, MXHangDiagnostic, MXCPUExceptionDiagnostic. Диагностики по hang и CPU-exceptions содержат стектрейс с реального устройства — золото для диагностики production-проблем.

Процесс оптимизации

Начинаем с измерения, не с предположений. Инструменты выше дают цифры: конкретное время cold start, конкретный объём памяти, конкретные кадры с просадкой. Потом — приоритизация по impact: что больше всего влияет на пользовательский опыт именно в этом приложении.

Аудит производительности существующего приложения: 3–5 рабочих дней. Реализация оптимизаций — от недели до двух месяцев в зависимости от запущенности проблем и архитектуры кода.