Профилировщик на устройстве разработчика показывает стабильные 60 FPS. В Firebase Crashlytics — ни одного краша. Но пользователи массово сообщают: «всё тормозит». Часто после релиза разрыв между тестовыми и реальными условиями оказывается огромным: слабые устройства, медленные сети, фоновые процессы. Firebase Performance Monitoring — единственный способ увидеть настоящую производительность на устройствах пользователей, а не в лабораторных условиях. Наша услуга — интеграция Firebase Performance Monitoring в мобильное приложение — решает эту проблему. За 5 лет мы выполнили более 20 интеграций для iOS и Android, помогая клиентам сократить время отклика на 30%.
Почему стандартный профилировщик не даёт полной картины?
Профилировщик Xcode или Android Studio измеряет производительность в идеальных условиях: подключённый кабель, отладочная сборка, мощный Mac или Pixel. Пользователь же запускает приложение на Samsung Galaxy A10 с Android 10, слабой батареей и фоновыми процессами. Firebase Performance Monitoring собирает данные с продакшен-сборок, отображая реальные задержки. Сравнение: достоверность данных в 5 раз выше, чем у локального профилирования.
Какие метрики автоматически собираются?
SDK Firebase Performance автоматически измеряет:
- App start time — от вызова
applicationDidFinishLaunchingдо момента, когда приложение становится интерактивным. - Screen rendering — для каждого UIViewController на iOS и Activity/Fragment на Android: slow frames (>16 ms) и frozen frames (>700 ms).
- Network requests — время ответа, размер запроса/ответа, HTTP-статус для всех запросов через URLSession / OkHttp.
Эти метрики сразу доступны в консоли Firebase без единой строки кода.
Как добавить кастомные трейсы для критических операций?
Если нужно измерить конкретную операцию — например, загрузку каталога товаров или обработку фотографии — создайте кастомный трейс. Вот пошаговый процесс:
- Определите имя трейса, например
load_product_catalog. - Установите атрибуты для сегментации (версия API, страна и т.д.).
- Запустите трейс перед операцией и остановите после.
- При необходимости добавьте метрики (количество элементов).
iOS / Swift:
import FirebasePerformance func loadProductCatalog() async { let trace = Performance.startTrace(name: "load_product_catalog") defer { trace?.stop() } trace?.setValue("v2", forAttribute: "api_version") let products = await productRepository.fetchAll() trace?.incrementMetric("product_count", by: Int64(products.count)) } Android / Kotlin:
val trace = Firebase.performance.newTrace("load_product_catalog") trace.start() trace.putAttribute("api_version", "v2") val products = productRepository.fetchAll() trace.putMetric("product_count", products.size.toLong()) trace.stop() Атрибуты (setValue/putAttribute) позволяют сегментировать трейсы в консоли — например, сравнивать время загрузки разных версий API или пользователей из разных стран.
Как настроить перехват сетевых запросов в нестандартном стеке?
Автоматический перехват работает через swizzling URLSession на iOS. Если в проекте используется кастомная URLSession или Alamofire, потребуется ручная регистрация через HTTPMetric:
let metric = HTTPMetric(url: url, httpMethod: .get) metric?.start() URLSession.shared.dataTask(with: url) { data, response, error in metric?.responseCode = (response as? HTTPURLResponse)?.statusCode ?? -1 metric?.stop() }.resume() Для Alamofire добавьте EventMonitor, оборачивающий метрики вокруг каждого запроса. Наш опыт показывает: без правильной настройки сетевого перехвата вы рискуете пропустить до 30% медленных запросов. Этот метод выявляет аномалии в 5 раз быстрее традиционного тестирования.
Что даёт сегментация в консоли?
Консоль Firebase Performance показывает разбивку по версиям приложения, стране, типу устройства и версии ОС. Это единственный способ узнать, что конкретный экран тормозит только на Android 10 на бюджетных устройствах. Сравнение метрик по сегментам:
| Метрика | Порог тревоги | Типичная сегментация |
|---|---|---|
| App start time | >2 сек — проблема | По версии ОС, устройству |
| Slow frames | >1% | По версии приложения |
| Frozen frames | >0.1% | По стране |
| Время сетевого запроса | p95 > 5 сек | По эндпоинту |
Пороги выбираются на основе бенчмарков для вашего приложения. Например, если p95 времени загрузки каталога превышает 3 секунды, это сигнал к оптимизации. Мы помогаем настроить реалистичные границы, чтобы алерты не были шумными.
Какие пороги и алерты настраивать?
Мы рекомендуем следующие пороги для алертов:
| Метрика | Порог | Действие |
|---|---|---|
| App start time | >2.5 сек | Уведомление команде |
| Slow frames >5% | >5% | Автоматический баг-репорт |
| Frozen frames >0.5% | >0.5% | Немедленная реакция |
| Network errors | >1% | Проверка серверной части |
Алерты можно отправлять в Slack, Telegram или по email. Настройка занимает 1–2 часа. Подробнее о возможностях читайте в Firebase Performance Documentation.
Что входит в работу и сроки
Мы берём на себя полную интеграцию под ключ:
- Добавление SDK и базовая инициализация.
- Кастомные трейсы для ключевых операций (загрузка данных, рендер тяжёлых списков).
- Настройка перехвата сетевых запросов при нестандартном стеке.
- Базовый дашборд с порогами алертов.
- Инструкция по интерпретации метрик.
Сроки: базовая интеграция с автоматическими трейсами — 1 день. С кастомными трейсами и Network interceptor — 2 дня. Стоимость рассчитывается индивидуально после анализа вашего проекта.
Интеграция окупается за счёт уменьшения времени на отладку и снижает затраты на поддержку. Хотите узнать, где ваше приложение теряет FPS? Свяжитесь с нами — оценим проект и предложим решение. Закажите интеграцию Firebase Performance Monitoring и получите реальную картину производительности на устройствах пользователей.