Представьте: пользователь открывает ваше приложение, видит белый экран 4 секунды, а затем — зависший список. Это не баг, а системная проблема производительности. В App Store приложение с медленным запуском получает оценки ниже 4.0, а удержание падает на 20% за первую минуту. Аудит производительности — не разовая проверка, а методология сбора и анализа метрик: время старта, рендеринг, память, сеть, батарея. Мы, инженеры с 5+ летним опытом, проводим аудит на реальных устройствах и даём приоритизированный отчёт с измеримыми рекомендациями. Без данных вы гадаете — с отчётом вы точно знаете, что исправлять и какой эффект получите.
Например, в одном проекте мы сократили cold launch с 4.2 с до 380 мс, удалив синхронную инициализацию четырёх SDK в AppDelegate. Это увеличило регистрации на 7%. Хотите то же для вашего приложения? Продолжайте читать.
Какие метрики мы измеряем?
Мы фокусируемся на пяти аспектах, напрямую влияющих на удержание пользователей и рейтинг в сторах.
Время запуска (Launch Time)
iOS: XCTest с measure(metrics:) + XCTApplicationLaunchMetric. Разделяем cold launch (первый запуск после перезагрузки) и warm launch (повторный). Apple рекомендует cold launch < 400 мс до первого кадра. Типичная проблема: статическая инициализация в AppDelegate — множество SDK, БД, аналитика — всё синхронно в main thread.
Android: adb shell am start -W com.package/.MainActivity — выводит TotalTime и WaitTime. Firebase Performance Monitoring автоматически собирает app_start. Частая причина медленного старта: ранняя инициализация Room/Realm в Application.onCreate(), синхронный SharedPreferences read.
Память
iOS: Xcode Memory Graph + leaks. Ищем retain cycles (closure захватывает self, self держит closure). os_signpost для отметок.
Android: Memory Profiler в Android Studio, Heap Dump. Смотрим Leaked Activities (Activity не уничтожается из-за static reference), Bitmap большого размера (некорректный inSampleSize).
Рендеринг
iOS: Instruments → Core Animation. Offscreen-rendered content — лишние CALayer, Color blended layers — overdraw.
Android: adb shell dumpsys gfxinfo com.package framestats. Slow frames > 5% — проблема. systrace или Perfetto.
Сеть
Charles Proxy или mitmproxy. Проверяем: дублирующиеся запросы, отсутствие кэширования, большие payload (JSON без пагинации, несжатые изображения), отсутствие HTTP/2.
Батарея
iOS: Xcode Energy Impact + MetricKit. Android: Battery Historian (adb bugreport).
Почему аудит производительности выгоден?
Снижение времени запуска на 300 мс увеличивает конверсию в регистрацию на 3-5% (отраслевые исследования). Уменьшение slow frames с 10% до 1% повышает оценки в Store на 0.3-0.5 балла. Аудит даёт измеримый ROI: вы вкладываете 3-10 дней команды и получаете прирост метрик, конкурентоспособность и снижение нагрузки на поддержку. Средняя экономия бюджета на доработки — от 15%. Окупаемость аудита составляет от 3 до 6 месяцев за счёт сокращения времени на баг-фиксинг и поддержку.
Как проходит аудит: пошагово
- Сбор базовых метрик. Автоматизированно собираем Firebase Performance, Sentry Performance или собственный инструментарий. Смотрим P50/P75/P95 по launch time, screen render, HTTP latency на реальных пользователях.
- Анализ кода. Статический анализ ключевых путей:
onCreate/viewDidLoad, методы рендеринга, сетевой слой, работа с БД. Ищем синхронные операции в UI thread, неоптимальные запросы, отсутствие debounce.
- Воспроизведение на устройствах. Два-три устройства: флагман, mid-range, low-end. Проблемы на флагмане часто невоспроизводимы, а у 30–40% аудитории именно mid-range и старше.
- Формирование отчёта. Составляем таблицу проблем с приоритетами, шагами воспроизведения, скриншотами и рекомендациями. Прилагаем графики распределения метрик и сравнение до/после.
Что входит в отчёт?
По итогам аудита — документ с таблицей проблем:
| Проблема |
Метрика |
Устройство |
Приоритет |
Синхронный DB read в onCreate |
+340 мс к cold start |
Samsung A54 |
Высокий |
| 8 параллельных запросов на старте |
600 мс TTFR |
Все |
Высокий |
| Retain cycle в ProfileViewController |
+12 МБ утечка за сессию |
iOS |
Средний |
| Overdraw в FeedCell |
15% slow frames |
Pixel 6a |
Средний |
Каждая проблема — с шагами воспроизведения, скриншотами и рекомендацией. Дополнительно прилагаем: исходный код с измерениями, графики распределения метрик, сравнение до/после.
Типичные проблемы производительности
- Статическая инициализация SDK в главном потоке
- Отсутствие пагинации при загрузке списков
- Retain cycles из-за замыканий в iOS
- Синхронные операции с БД на Android
- Избыточные перерисовки вложенных RecyclerView
Сроки аудита
| Размер приложения |
Срок |
| 10–30 экранов |
3–5 рабочих дней |
| Крупное (несколько модулей) |
7–10 рабочих дней |
Точный срок рассчитывается индивидуально после знакомства с проектом. Закажите аудит сейчас — получите отчёт с приоритетами через 3-5 дней. Свяжитесь с нами для предварительной оценки вашего проекта.
Гарантируем конфиденциальность кода и данных. Опыт работы с приложениями из фитнеса, банкинга, маркетплейсов, edtech. Закажите аудит, и мы покажем, насколько быстрее может работать ваше приложение.
Согласно iOS Performance Guidelines от Apple, cold launch не должен превышать 400 мс.
Оптимизация мобильных приложений: 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.
Инструменты профилирования
| Платформа |
Инструмент |
Что показывает |
| iOS |
Xcode Instruments (Time Profiler) |
CPU, call stack, горячие методы |
| iOS |
Allocations |
Живые объекты, пики памяти |
| iOS |
Leaks |
Retention cycles |
| iOS |
MetricKit |
Производственные метрики (crash rate, hang rate, launch time) |
| Android |
Android Profiler |
CPU, Memory, Network, Energy |
| Android |
Systrace / Perfetto |
System-level трейсы |
| Android |
LeakCanary |
Утечки памяти |
| Android |
Battery Historian |
Энергопотребление |
| Flutter |
Flutter DevTools |
Recomposition, frame rendering, memory |
| Flutter |
Dart Observatory |
Dart VM profiling |
MetricKit на iOS — особенно ценен: реальные данные с устройств пользователей, а не симулятора. MXMetricManager получает агрегированные метрики раз в сутки: MXAppLaunchMetric, MXHangDiagnostic, MXCPUExceptionDiagnostic. Диагностики по hang и CPU-exceptions содержат стектрейс с реального устройства — золото для диагностики production-проблем.
Процесс оптимизации
Начинаем с измерения, не с предположений. Инструменты выше дают цифры: конкретное время cold start, конкретный объём памяти, конкретные кадры с просадкой. Потом — приоритизация по impact: что больше всего влияет на пользовательский опыт именно в этом приложении.
Аудит производительности существующего приложения: 3–5 рабочих дней. Реализация оптимизаций — от недели до двух месяцев в зависимости от запущенности проблем и архитектуры кода.
