Аудит производительности мобильного приложения
Аудит производительности — это не «посмотреть, что тормозит». Это систематическое измерение конкретных метрик на конкретных устройствах с конкретными результатами. Без измерений любые оптимизации — догадки. С измерениями — приоритизированный список проблем с понятным эффектом от каждого исправления.
Что измеряем
Время запуска (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 для детального trace.
Сетевые запросы
Charles Proxy или mitmproxy — перехватываем все запросы приложения. Смотрим:
- Дублирующиеся запросы за одними данными
- Отсутствие кэширования там, где оно уместно
- Слишком большие payload (JSON без pagination, изображения без сжатия)
- Отсутствие HTTP/2 (особенно заметно при множестве мелких запросов)
Расход батареи
iOS: Xcode Energy Impact gauge + MetricKit в продакшене. Android: Battery Historian (adb bugreport → анализ в Battery Historian web tool).
Методология аудита
Аудит проводим в три этапа:
1. Автоматизированный сбор базовых метрик. Firebase Performance, Sentry Performance, или собственный instrumentation. Смотрим P50/P75/P95 по launch time, screen render time, HTTP latency на реальных пользователях. Это показывает, где проблема в масштабе.
2. Воспроизведение на девайсах. Два-три устройства: флагман (последний iPhone/Pixel), mid-range (что-то уровня Samsung A54 / iPhone 12), low-end (4-летний mid-range Android). Проблемы на флагмане часто невоспроизводимы, а у 30–40% аудитории именно mid-range и старше.
3. Статический анализ кода. Ручной review ключевых путей: onCreate/viewDidLoad, методы рендеринга, сетевой слой, работа с БД. Ищем синхронные операции в UI thread, неоптимальные запросы, отсутствие debounce на user input.
Формат результатов
По итогам аудита — документ с таблицей проблем:
| Проблема | Метрика | Устройство | Приоритет |
|---|---|---|---|
Синхронный DB read в onCreate |
+340 мс к cold start | Samsung A54 | Высокий |
| 8 параллельных запросов на старте | 600 мс TTFR | Все | Высокий |
| Retain cycle в ProfileViewController | +12 МБ утечка за сессию | iOS | Средний |
| Overdraw в FeedCell | 15% slow frames | Pixel 6a | Средний |
Каждая проблема — с воспроизводимыми шагами, скриншотами из профайлера и конкретной рекомендацией по исправлению.
Сроки аудита: три-пять рабочих дней для приложения среднего масштаба (10–30 экранов). Крупное приложение с несколькими модулями — семь-десять дней.