Тестирование производительности мобильного приложения

Ваше приложение работает безупречно на флагманах — плавный скролл, мгновенный запуск. Но на бюджетных устройствах вроде Xiaomi Redmi 10A или iPhone SE первого поколения начинаются тормоза: выпадающие кадры при скролле, задержки при открытии экранов, необъяснимые паузы. Firebase Crashlytics не фиксирует ошибки — это не крэши, а просадки производительности. App Store Reviews сообщают о проблеме через неделю после релиза, когда лояльные пользователи уже удалили приложение. На основе опыта в 12 проектах по оптимизации мы гарантируем: каждое измерение воспроизводимо и локализовано до конкретного метода. Тестирование производительности мобильного приложения — это не разовая проверка, а системный процесс выявления узких мест и их устранения с измеримыми результатами.

Проблема в том, что стандартные инструменты (Instruments, Android Profiler) дают сырые данные без контекста. Мы не просто запускаем профилировщик — мы воспроизводим реалистичные сценарии: скролл с загрузкой изображений, глубокая навигация, переключение между экранами. Каждая рекомендация подкрепляется числовыми замерами до и после. Например, в одном проекте мы подняли FPS с 35 до 58, а время холодного старта сократили на 1.2 секунды. Получите консультацию, чтобы оценить ваш проект.

Тестирование производительности мобильного приложения: как измерить FPS на iOS

Instruments — основной инструмент для iOS. Мы используем три шаблона:

1. Time Profiler — определяет, где CPU тратит время. Запускаем «тяжёлый» сценарий (скролл, загрузка экрана), смотрим Call Tree с Invert Call Tree и Hide System Libraries. Видим собственный код с процентами нагрузки.

2. Core Animation (Rendering) — FPS и причины просадок. Commit — время формирования слоёв, Render — время GPU. Если Commit высокий — проблема на main thread. Красная линия в 16.67 ms (60 fps) или 8.33 ms (120 fps, ProMotion) — наглядная граница.

3. Allocations — паттерны выделения памяти. Запускаем, совершаем действие, смотрим Generation Analysis. Если память после Release навигации не падает — утечка.

Пример: экран с коллекцией фото тормозил при скролле. Time Profiler показал 23% времени на UIImage(data:) в cellForItemAt. Синхронная декодировка JPEG на main thread. Решение — ImageIO + kCGImageSourceShouldCacheImmediately: false + декодировка на background queue с DispatchQueue.global(qos: .userInitiated). Время декодирования сократилось с 70 ms до 12 ms, FPS вырос с 35 до 58.

Метрики запуска — тестирование производительности мобильного

MetricKit (iOS 13+) собирает production-метрики с реальных устройств пользователей:

class AppMetricsObserver: NSObject, MXMetricManagerSubscriber { func didReceive(_ payloads: [MXMetricPayload]) { for payload in payloads { if let launchMetrics = payload.applicationLaunchMetrics { // resumeTime — время при background→foreground // timeToFirstDraw — cold start let coldStart = launchMetrics.histogrammedTimeToFirstDraw // отправляем в аналитику } } } } 

Это не синтетические измерения — реальные данные с устройств пользователей. Дополняет профилирование в Instruments.

Что делать, если кадры падают на Android

В Android Studio — Android Profiler. CPU profiler в режиме Sample Java/Kotlin Methods для общей картины, Trace Java/Kotlin Methods для точного трассирования (с overhead'ом). System Trace показывает взаимодействие с GPU, Choreographer, RenderThread.

Janky frames (кадры > 16 ms): adb shell dumpsys gfxinfo com.example.app | grep "Janky frames". Более 5% janky frames — проблема.

Macrobenchmark — библиотека из Jetpack для воспроизводимых измерений:

@RunWith(AndroidJUnit4::class) class StartupBenchmark { @get:Rule val benchmarkRule = MacrobenchmarkRule() @Test fun startup() = benchmarkRule.measureRepeated( packageName = "com.example.myapp", metrics = listOf(StartupTimingMetric()), iterations = 5, startupMode = StartupMode.COLD, ) { pressHome() startActivityAndWait() } } 

Запускается на реальном устройстве (не эмуляторе), возвращает timeToInitialDisplay и timeToFullDisplay в миллисекундах. Результаты стабильны между запусками — это измерения, а не «запустили и засекли секундомером». Macrobenchmark даёт в 3 раза более стабильные результаты, чем разовые замеры через adb shell.

Slow rendering: Jetpack Compose

Для Compose — Recomposition счётчик в Layout Inspector. Точнее — ComposeUiTest с measureRepeated:

@Test fun scrollPerformance() { benchmarkRule.measureRepeated( packageName = "com.example.myapp", metrics = listOf(FrameTimingMetric()), iterations = 5, ) { val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation()) device.findObject(UiSelector().resourceId("com.example.myapp:id/feed_list")) .flingForward() } } 

FrameTimingMetric собирает данные о каждом кадре: frameOverrunMs — насколько кадр вышел за пределы бюджета.

Flutter: DevTools и flutter_driver

Flutter DevTools → Performance view показывает Frame chart с UI thread и Raster thread. Красные кадры — UI thread занят дольше 16 ms. Жёлтые — Raster thread.

Частая причина красных кадров: setState() перестраивает слишком большое поддерево. Решение — const конструкторы там, где данные не меняются, RepaintBoundary для изолирования перерисовки анимированных элементов.

// Плохо: весь экран перестраивается при каждом тике таймера class CounterScreen extends StatefulWidget { ... } // Лучше: только счётчик изолирован class CounterScreen extends StatelessWidget { @override Widget build(BuildContext context) { return Column(children: [ const HeaderWidget(), // const — не перестраивается CounterWidget(), // только эта часть ребилдится ]); } } 

Пошаговый план профилирования

1. Определяем сценарии (скролл, открытие, background-переключение).
2. Запускаем инструмент (Instruments / Profiler / DevTools) и фиксируем базовые метрики.
3. Локализуем узкое место (метод, поток, аллокация).
4. Вносим исправление и повторяем замеры.
5. Сравниваем результаты в таблице.

Что входит в работу

• Профилирование запуска приложения (cold start, warm start)
• Анализ FPS при скролле и навигации
• Поиск утечек памяти через Allocations / Memory Profiler
• Анализ CPU-профиля на тяжёлых операциях
• Macrobenchmark-тесты для Android, MetricKit-интеграция для iOS
• Отчёт с конкретными числами до/после и рекомендациями

Сроки

3–5 дней — профилирование, локализация проблем, отчёт. Если нужна ещё и реализация оптимизаций — оцениваем отдельно по объёму правок. Стоимость рассчитывается индивидуально. Закажите аудит производительности, чтобы получить конкретные цифры и план оптимизации. Свяжитесь с нами для оценки вашего проекта.

Instruments Macrobenchmark