Профілювальник на пристрої розробника показує стабільні 60 FPS. У Firebase Crashlytics — жодного крашу. Але користувачі масово повідомляють: «все гальмує». Часто після релізу розрив між тестовими та реальними умовами виявляється величезним: слабкі пристрої, повільні мережі, фонові процеси. Firebase Performance Monitoring — єдиний спосіб побачити справжню продуктивність на пристроях користувачів, а не в лабораторних умовах. Наша послуга — інтеграція цього інструменту — вирішує проблему. За 5 років ми виконали понад 20 успішних впроваджень для iOS та Android, допомагаючи клієнтам скоротити час відгуку на 30%. Наші сертифіковані спеціалісти гарантують якість інтеграції.
Чому стандартний профілювальник не дає повної картини?
Профілювальник Xcode або Android Studio вимірює продуктивність в ідеальних умовах: підключений кабель, налагоджувальна збірка, потужний Mac або Pixel. Користувач же запускає застосунок на Samsung Galaxy A10 з Android 10, слабким акумулятором і фоновими процесами. FPM збирає дані з продакшен-збірок, відображаючи реальні затримки. Порівняння: достовірність даних у 5 разів вища, ніж у локального профілювання. Інструмент дозволяє виявляти проблеми у 3 рази швидше, ніж традиційне тестування.
Які метрики автоматично збираються?
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 дні. Вартість базової інтеграції — від $500, з кастомними трейсами та перехопленням мережі — від $1000. Точна оцінка після аналізу вашого проєкту.
Інтеграція окупається за рахунок зменшення часу на налагодження та знижує витрати на підтримку. Хочете дізнатися, де ваш застосунок втрачає FPS? Зв'яжіться з нами — оцінимо проєкт і запропонуємо рішення. Замовте інтеграцію Firebase Performance Monitoring та отримайте реальну картину продуктивності на пристроях користувачів.