Firebase Performance: что это, метрики и как отслеживать

Что такое Firebase Performance Monitoring

Firebase Performance Monitoring — это SDK и облачная платформа для сбора, агрегации и визуализации метрик производительности мобильных приложений. SDK встраивается в приложение и автоматически инструментирует ключевые точки: жизненный цикл Activity (Android) или ViewController (iOS), сетевые запросы через URLSession (iOS) или OkHttp (Android), и системные вызовы. Собранные данные отправляются на сервер Firebase, где агрегируются по версиям приложения, устройствам, странам и другим атрибутам.

Архитектура Performance SDK построена на принципе минимального overhead: инструментация добавляет не более 1–2% к времени выполнения измеряемых операций. Данные собираются асинхронно и буферизируются на устройстве перед отправкой, что исключает влияние на производительность UI-потока. Отправка данных происходит по расписанию (по умолчанию каждые 30 минут) или по достижении буфера в 100 КБ.

Ключевое отличие Firebase Performance от профайлеров Android Studio (CPU Profiler) или Xcode Instruments — production-мониторинг. Firebase Performance собирает данные с реальных устройств пользователей, а не только с устройств разработчика. Это позволяет обнаруживать проблемы, которые воспроизводятся только на определённых моделях, версиях ОС или в конкретных регионах — то есть проблемы, которые невозможно воспроизвести в controlled environment.

Как SDK собирает данные без изменения кода

Автоматическая инструментация — главная особенность Firebase Performance. Для Android SDK автоматически регистрирует ActivityLifecycleCallbacks и измеряет время между onCreate и onResume (screen rendering time). Для iOS — swizzles методы viewDidLoad и viewDidAppear. Сетевые запросы перехватываются на уровне OkHttpInterceptor (Android) или NSURLProtocol (iOS). Разработчику не нужно добавлять вызовы start/stop для стандартных метрик.

Включение и отключение Performance SDK управляется через Google Services плагин (Android) или Info.plist (iOS). Для отладки можно включить verbose-логирование Performance SDK, которое покажет, какие метрики собираются и отправляются. В production рекомендуется оставить логирование на уровне warning, чтобы не засорять логи лишней информацией. Для проектов на Flutter или React Native автоматическая инструментация может быть ограничена — подробнее в разделе примеров кода.

Бесплатные лимиты и тарификация

Firebase Performance предлагается на бесплатном тарифе Spark без ограничений по количеству трейсов или объёму данных. Платный тариф Blaze также не взимает плату за Performance Monitoring — это один из немногих Firebase-сервисов, полностью бесплатных на обоих тарифах. Ограничение только одно: данные хранятся 30 дней (на Spark) и до 365 дней (на Blaze). Для долгосрочного анализа выгружайте данные через BigQuery export.

Отсутствие платы делает Firebase Performance идеальным выбором для любого проекта — от прототипа до enterprise-приложения с миллионами пользователей. Единственная статья расходов — исходящий трафик данных Performance SDK, но он ничтожен по сравнению с другими сетевыми операциями приложения (менее 1 МБ в месяц на устройство). В BigQuery export взимается плата за хранение и запросы, но сам Performance SDK — бесплатен.

Автоматические метрики: что измеряется без кода

Firebase Performance автоматически собирает пять категорий метрик без единой строки кода: время запуска приложения (app start), медленные запросы (slow HTTP requests), скорость рендеринга экранов (screen rendering), потребление памяти (memory usage, только Android) и частота кадров (frame rate, только Android). Эти метрики доступны в консоли Firebase сразу после подключения SDK и первого сеанса пользователя.

App Start Time — время от запуска процесса до полной готовности UI к взаимодействию. Разделяется на холодный старт (приложение запускается с нуля) и тёплый старт (приложение восстанавливается из фонового состояния). Холодный старт включает загрузку DEX-файлов, инициализацию статических полей, вызов Application.onCreate и Activity.onCreate. Firebase автоматически классифицирует тип старта и показывает распределение времени для каждого типа.

Screen Rendering Time — время от начала загрузки экрана (onCreate для Android, viewDidLoad для iOS) до момента, когда экран готов к взаимодействию (onResume, viewDidAppear). Firebase агрегирует данные по каждому экрану (по имени класса или custom screen name), позволяя определить, какой экран грузится дольше всего. Для Android дополнительно измеряется dropped frames — количество кадров, пропущенных при рендеринге экрана (jank).

Сетевые запросы (HTTP/HTTPS)

Performance SDK автоматически перехватывает и измеряет каждый HTTP/HTTPS запрос, отправленный из приложения через URLSession, OkHttp или URLConnection. Для каждого запроса фиксируются: URL (путь без query-параметров для безопасности), HTTP-метод, код ответа, размер ответа в байтах, длительность запроса и скорость соединения (WiFi, Cellular). Данные агрегируются в дашборде "Network Requests" консоли Firebase.

Slow Requests — запросы, длительность которых превышает заданный порог. По умолчанию порог "медленного запроса" — 4000 мс. Эта метрика критически важна для выявления проблем с серверной частью: если после обновления бэкенда количество slow requests выросло с 1% до 15%, это сигнал к немедленному анализу серверных логов. Пользователи не будут ждать ответа более 5 секунд — данные Firebase показывают, что 53% пользователей закрывают приложение, если запрос выполняется дольше 3 секунд.

Ограничения автоматической инструментации

iOS ограничения: на iOS Performance SDK не может измерить dropped frames (это приватный API). Для измерения jank на iOS используйте MetricKit или CADisplayLink. Также на iOS SDK не перехватывает запросы, выполненные через сторонние HTTP-клиенты, которые не используют URLSession (например, SwiftNIO). Для таких случаев используйте кастомные трейсы с HTTP-атрибутами.

Android ограничения: на Android автоматическое измерение памяти доступно только на устройствах с Android 8.0+ (API 26+). Для старых версий используйте кастомные трейсы с получением данных через Debug.getMemoryInfo(). Также SDK не перехватывает WebSocket-соединения — для них нужны отдельные трейсы. Несмотря на ограничения, автоматические метрики покрывают 80% потребностей в мониторинге производительности.

Кастомные трейсы и HTTP-атрибуты

Кастомные трейсы (custom traces) — это именованные интервалы времени, которые разработчик создаёт вручную для измерения производительности конкретных сценариев: загрузка ленты новостей, обработка изображения, синхронизация данных, выполнение сложного запроса к базе данных. Кастомные трейсы дополняют автоматические метрики и позволяют измерять именно те участки кода, которые разработчик считает критическими для производительности.

Каждый трейс имеет имя (максимум 100 символов) и может содержать до 5 пользовательских метрик (metrics) — числовых значений, которые записываются внутри трейса. Например, в трейсе "image_processing" можно измерить метрики "original_file_size" и "processed_file_size". Метрики отображаются в консоли Firebase как распределения (min, max, average, percentiles), что позволяет анализировать не только длительность, но и характеристики операции.

HTTP-атрибуты — специальный тип кастомных трейсов для сетевых запросов, которые не были автоматически перехвачены SDK (например, через WebSocket или сторонние библиотеки). HTTP-атрибуты включают URL, HTTP-метод, код ответа и размер ответа. Firebase отображает их в разделе "Network Requests" вместе с автоматически собранными запросами, обеспечивая единую картину сетевого взаимодействия.

Когда использовать кастомные трейсы

Кастомные трейсы незаменимы для измерения: времени загрузки данных из локальной базы данных (Room, CoreData), длительности сложных вычислений (шифрование, компрессия), производительности анимаций и переходов, времени ответа сторонних SDK (карты, платежи, аналитика). Для каждого такого сценария создайте трейс, оберните измеряемый код в start/stop и добавьте атрибуты для последующей сегментации.

Не злоупотребляйте кастомными трейсами. Каждый трейс — это дополнительный расход батареи и трафика. Рекомендуется не более 10–15 активных трейсов в production-версии приложения. Для отладки можно добавить больше трейсов, но перед релизом отключите избыточные через Remote Config (используйте флаг performance_tracing_enabled). Это позволяет включать детальное трассирование только для выбранных пользователей или сессий.

Атрибуты трейсов для сегментации

Пользовательские атрибуты (custom attributes) — это пары ключ-значение, которые можно добавить к трейсу для последующей фильтрации в консоли Firebase. Например, к трейсу "feed_load" можно добавить атрибуты "feed_type" (main, explore, following) и "cache_status" (cold, warm). В консоли данные трейса можно отфильтровать по этим атрибутам, чтобы определить, какой тип ленты грузится медленнее всего.

Ограничения: каждый трейс может иметь до 5 пользовательских атрибутов. Значение атрибута — строка до 100 символов. Атрибуты должны быть заданы до старта трейса; изменение атрибута после старта игнорируется. Это ограничение связано с производительностью: фиксация атрибутов после старта потребовала бы дополнительной синхронизации.

Пороги производительности и алерты

Пороги (thresholds) — это настраиваемые граничные значения метрик, при превышении которых Firebase Performance генерирует предупреждение. Пороги задаются в консоли Firebase (раздел Performance > Thresholds) для каждой автоматической метрики: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Можно задать глобальные пороги для всех версий приложения или специфичные для конкретных версий.

Алерты (alerts) — автоматические уведомления, которые Firebase отправляет при превышении порога. Алерты можно настроить на email, Slack webhook, PagerDuty или Cloud Functions (для кастомной обработки). Каждый алерт содержит: название метрики, текущее значение, пороговое значение, версию приложения, сегмент (устройство, страна). Алерты позволяют реагировать на деградацию производительности до того, как она станет заметна пользователям.

Рекомендуемые пороги по отраслевому стандарту (Google I/O 2025): холодный старт — менее 2 секунд, тёплый старт — менее 1 секунды, рендеринг экрана — менее 500 мс, длительность HTTP-запроса — менее 3000 мс (95-й перцентиль), доля медленных запросов — менее 5%. Для приложений с высокой конкурентностью (Social, E-commerce) целевые пороги могут быть жёстче: холодный старт < 1.5 секунд, HTTP < 1000 мс.

Настройка порогов в консоли Firebase

В консоли Firebase перейдите в раздел Performance, откройте вкладку Thresholds. Для каждой метрики задайте желаемое пороговое значение и процент пользователей, которых должно затронуть превышение. Например: "считаем холодный старт медленным, если он превышает 2 секунды для более чем 10% пользователей". Firebase покажет текущие значения метрик и историю превышений для помощи в выборе реалистичных порогов.

Важно: пороги не влияют на сбор данных, они только управляют генерацией уведомлений. Если порог слишком низкий (например, холодный старт 1 секунда, хотя 50% устройств запускаются за 3 секунды), алерты будут приходить постоянно и станут "шумом", который разработчики перестанут замечать. Выставляйте пороги на основе текущих показателей, затем постепенно ужесточайте их по мере оптимизации приложения.

Performance Dashboard в консоли Firebase

Дашборд Performance отображает ключевые метрики в виде временных рядов с разбивкой по версии приложения, устройству, стране, типу соединения и версии ОС. Для каждой метрики доступны: среднее значение, медиана, 95-й перцентиль, 99-й перцентиль. 95-й перцентиль — самая информативная метрика для оценки производительности, так как она показывает, как приложение работает "на слабых устройствах", игнорируя выбросы.

Дашборд поддерживает сравнение версий: выберите две версии приложения (текущую и предыдущую) для визуального сравнения метрик. Если после обновления 95-й перцентиль времени запуска вырос с 2.1 до 3.4 секунды — регрессия очевидна, и нужно найти коммит, вызвавший замедление. Firebase Performance интегрируется с GitHub, GitLab и Bitbucket, что позволяет связывать изменения метрик с конкретными коммитами.

Примеры кода для Performance Monitoring

Рассмотрим примеры интеграции Firebase Performance Monitoring в Android-приложение на Kotlin. Код демонстрирует создание кастомного трейса для измерения загрузки ленты новостей, добавление HTTP-атрибута для неавтоматически перехваченного запроса и использование Trace для измерения времени обработки изображения. Все примеры учитывают возможность отключения трейсинга через Remote Config.

Перед использованием добавьте зависимость: implementation("com.google.firebase:firebase-perf") через Firebase BOM. Для автоматической инструментации дополнительной настройки не требуется — SDK перехватывает стандартные операции автоматически после подключения зависимости.

Кастомный трейс для загрузки ленты

Первый пример — измерение времени загрузки ленты новостей с сервера. Трейс оборачивает асинхронную операцию fetchFeed, которая получает данные из сети и парсит JSON. В трейс добавлены пользовательские атрибуты: источник данных (cache или network) и количество полученных постов. Это позволяет сегментировать данные и понять, при каких условиях лента грузится дольше всего.

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

Функция loadFeedWithTrace принимает параметр source ("cache" или "network"), который используется как атрибут трейса. После завершения асинхронной операции трейс останавливается в блоке finally, гарантируя остановку даже при исключении. Метрика items_count позволяет анализировать, как количество постов влияет на время загрузки. В консоли Firebase можно отфильтровать трейсы по атрибуту source и увидеть, что загрузка из сети в 3 раза медленнее кэша.

HTTP-атрибут для нестандартного запроса

Второй пример — HTTP-атрибут для запроса, выполненного через WebSocket (не перехватывается автоматически). Используется класс HttpMetric, который позволяет вручную зарегистрировать URL-запрос, его метод, код ответа и размер. Firebase отобразит этот запрос в разделе Network Requests вместе с автоматически перехваченными.

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

В примере sendWithHttpMetric использует newHttpMetric для регистрации нестандартного HTTP-вызова. SDK не перехватывает его автоматически, поэтому разработчик вручную задаёт URL, метод, код ответа и размеры. Важно задавать URL без query-параметров (для безопасности и агрегации) — то есть /data, а не /data?token=abc. Firebase автоматически группирует одинаковые URL-шаблоны.

Измерение времени обработки изображения

Третий пример демонстрирует измерение времени обработки изображения (сжатие, изменение размера) с помощью кастомного трейса. В данном случае трейс оборачивает синхронную операцию, но для production используйте корутины или RxJava, чтобы не блокировать UI-поток.

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

Функция compressImage измеряет время сжатия изображения в JPEG с качеством 80%. Атрибут format позволяет в будущем сравнивать время сжатия JPEG против WebP. Метрика output_size_kb показывает, насколько эффективно сжатие. В консоли Firebase можно увидеть распределение: на слабых устройствах (бюджетные Android) сжатие занимает в 4 раза больше времени, чем на флагманах, что может быть причиной задержек при отправке изображений на сервер.

Как улучшать производительность на основе данных

Firebase Performance предоставляет данные, но не даёт готовых решений. Анализ метрик требует понимания типовых причин деградации производительности для каждой метрики. Рассмотрим основные паттерны ухудшения и способы их диагностики по данным Performance Monitoring. Подход: нашли аномалию в метрике → проверили типовые причины → применили оптимизацию → проверили результат через неделю.

Медленный холодный старт (> 2 секунд): причины — тяжёлая инициализация SDK в Application.onCreate (аналитика, crash reporting, map SDK), загрузка больших ресурсов (шрифты, темы), синхронные операции в главном потоке при старте. Решения: ленивая инициализация SDK, отложенная загрузка ресурсов, использование SplashScreen API (Android 12+) для показа placeholder во время инициализации. Firebase Performance покажет, какая версия приложения стала стартовать медленнее — проверьте, какие зависимости были добавлены или обновлены.

Медленный рендеринг экрана (> 500 мс): причины — сложная иерархия View (вложенные ConstraintLayout, множество Fragment), загрузка данных в UI-потоке (сеть или диск), тяжёлые draw-операции (большие изображения, кастомные View). Решения: оптимизация layout-иерархии (Layout Inspector в Android Studio), выгрузка данных на фоновый поток, кэширование изображений через Glide или Coil. Используйте фильтр Screen Rendering в Firebase, чтобы найти самый медленный экран и оптимизировать его в первую очередь.

Оптимизация сетевых запросов

Медленные HTTP-запросы (> 3 секунд): причины — медленный сервер, большие payload-ы, отсутствие кэширования, неоптимальный протокол (HTTP/1.1 вместо HTTP/2), DNS-резолвинг. Решения: проверьте серверную сторону (аптайм, latency), уменьшите размер ответа (пагинация, GraphQL, protobuf вместо JSON), включите кэширование через HTTP-заголовки (Cache-Control), используйте OkHttp Interceptor для добавления тайм-аутов и retry-логики.

Firebase Performance показывает распределение времени запроса: DNS resolution, TCP handshake, TLS handshake, request send, response receive. Если большая часть времени приходится на DNS — используйте предзагрузку DNS (OkHttp DNS-over-HTTPS). Если на TLS — используйте session resumption и тюнинг cipher suites. Если на response receive — проверьте размер ответа и скорость сети пользователя. Данные Firebase позволяют локализовать проблему на уровне протокола, а не просто сказать "запрос медленный".

Интеграция Remote Config для отключения трейсинга

Для production рекомендуется добавить Remote Config флаг performance_tracing_enabled, который позволяет удалённо отключать кастомные трейсы. Если Firebase Performance SDK на клиенте генерирует слишком много данных или влияет на производительность (на слабых устройствах), можно отключить трейсы для всех пользователей, оставив только автоматические метрики, которые имеют минимальный overhead.

Пример логики: при старте приложения проверяем Remote Config параметр performance_tracing_enabled. Если false — все вызовы Firebase.performance.newTrace() возвращают stub-объект, который не собирает данные. Это реализуется через wrapper-класс, который проверяет флаг перед созданием трейса. Такой подход позволяет включать детальное трассирование для конкретных пользователей (бета-тестеров, разработчиков) без влияния на всю аудиторию.