Firebase Performance: какво е, метрики и как да проследяваме

Какво е Firebase Performance Monitoring

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

Архитектурата на Performance SDK е изградена на принципа на минимално натоварване: инструментирането добавя не повече от 1–2% към времето за изпълнение на измерваните операции. Данните се събират асинхронно и се буферират на устройството преди изпращане, което елиминира влиянието върху производителността на UI нишката. Изпращането на данни става по график (по подразбиране на всеки 30 минути) или при достигане на буфера от 100 KB.

Ключовата разлика между Firebase Performance и профилиращите инструменти на Android Studio (CPU Profiler) или Xcode Instruments е производственият мониторинг. Firebase Performance събира данни от реални устройства на потребители, а не само от устройства на разработчици. Това позволява откриване на проблеми, които се проявяват само на определени модели, версии на ОС или в конкретни региони — тоест проблеми, които не могат да бъдат възпроизведени в контролирана среда.

Как SDK събира данни без промяна на код

Автоматично инструментиране е основната характеристика на Firebase Performance. За Android SDK автоматично регистрира ActivityLifecycleCallbacks и измерва времето между onCreate и onResume (време за рендиране на екран). За iOS — swizzle методите viewDidLoad и viewDidAppear. Мрежовите заявки се прихващат на ниво OkHttpInterceptor (Android) или NSURLProtocol (iOS). Разработчикът не трябва да добавя start/stop извиквания за стандартните метрики.

Активиране и деактивиране на Performance SDK се управлява чрез приставката Google Services (Android) или Info.plist (iOS). За отстраняване на грешки може да се активира подробно логиране на Performance SDK, което ще покаже кои метрики се събират и изпращат. В производствена среда се препоръчва да се запази логирането на ниво warning, за да не се затрупват логовете с ненужна информация. За проекти на Flutter или React Native автоматичното инструментиране може да бъде ограничено — повече подробности в раздела с примери за код.

Безплатни лимити и тарифи

Firebase Performance се предлага на безплатния тариф Spark без ограничения за броя проследявания или обема данни. Платеният тариф Blaze също не начислява такси за Performance Monitoring — това е една от малкото услуги на Firebase, напълно безплатни и на двата тарифа. Има само едно ограничение: данните се съхраняват 30 дни (на Spark) и до 365 дни (на Blaze). За дългосрочен анализ експортирайте данните чрез BigQuery export.

Безплатността прави Firebase Performance идеален избор за всеки проект — от прототип до корпоративно приложение с милиони потребители. Единствената разходна позиция е изходящият трафик на данните на Performance SDK, но той е пренебрежим в сравнение с други мрежови операции на приложението (по-малко от 1 MB на месец на устройство). В 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 агрегира данни за всеки екран (по име на клас или персонализирано име на екран), което позволява да се определи кой екран се зарежда най-бавно. За Android допълнително се измерват пропуснати кадри (dropped frames) — броят кадри, пропуснати по време на рендиране на екрана (jank).

Мрежови заявки (HTTP/HTTPS)

Performance SDK автоматично прихваща и измерва всяка HTTP/HTTPS заявка, изпратена от приложението чрез URLSession, OkHttp или URLConnection. За всяка заявка се записват: URL (път без параметри на заявката за сигурност), HTTP метод, код на отговор, размер на отговора в байтове, продължителност на заявката и скорост на връзката (WiFi, Cellular). Данните се агрегират в таблото „Network Requests” на конзолата Firebase.

Slow Requests — заявки, чиято продължителност надвишава зададен праг. По подразбиране прагът за „бавна заявка” е 4000 ms. Тази метрика е критична за идентифициране на проблеми със сървърната страна: ако след актуализация на backend броят на бавните заявки се е увеличил от 1% на 15%, това е сигнал за незабавен анализ на сървърните логове. Потребителите няма да чакат отговор повече от 5 секунди — данните на Firebase показват, че 53% от потребителите затварят приложението, ако заявката продължава повече от 3 секунди.

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

iOS ограничения: на iOS Performance SDK не може да измерва пропуснати кадри (това е частен 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, персентили), което позволява анализиране не само на продължителността, но и на характеристиките на операцията.

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

Кога да използваме персонализирани проследявания

Персонализирани проследявания са незаменими за измерване на: време за зареждане на данни от локална база данни (Room, CoreData), продължителност на сложни изчисления (криптиране, компресия), производителност на анимации и преходи, време за отговор на SDK на трети страни (карти, плащания, аналитика). За всеки такъв сценарий създайте проследяване, обградете измерения код в start/stop и добавете атрибути за последваща сегментация.

Не злоупотребявайте с персонализирани проследявания. Всяко проследяване означава допълнителен разход на батерия и трафик. Препоръчва се не повече от 10–15 активни проследявания в производствената версия на приложението. За отстраняване на грешки могат да се добавят повече проследявания, но преди пускане деактивирайте излишните чрез 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 изпраща при превишаване на праг. Предупрежденията могат да бъдат конфигурирани за имейл, Slack webhook, PagerDuty или Cloud Functions (за персонализирана обработка). Всяко предупреждение съдържа: име на метрика, текуща стойност, прагова стойност, версия на приложението, сегмент (устройство, държава). Предупрежденията позволяват реагиране на влошаване на производителността, преди тя да стане забележима за потребителите.

Препоръчителни прагове според индустриалния стандарт (Google I/O 2025): студен старт — под 2 секунди, топъл старт — под 1 секунда, рендиране на екран — под 500 ms, продължителност на HTTP заявка — под 3000 ms (95-и персентил), дял на бавните заявки — под 5%. За приложения с висока конкуренция (Social, E-commerce) целевите прагове могат да бъдат по-строги: студен старт < 1.5 секунди, HTTP < 1000 ms.

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

В конзолата на Firebase отидете в секцията Performance, отворете раздела Thresholds. За всяка метрика задайте желаната прагова стойност и процента потребители, които трябва да бъдат засегнати от превишаването. Например: „смятаме студения старт за бавен, ако надвишава 2 секунди за повече от 10% от потребителите”. Firebase ще покаже текущите стойности на метриките и историята на превишенията, за да помогне при избора на реалистични прагове.

Важно: праговете не влияят на събирането на данни, те управляват само генерирането на известия. Ако прагът е твърде нисък (например студен старт 1 секунда, въпреки че 50% от устройствата стартират за 3 секунди), предупрежденията ще идват постоянно и ще станат „шум”, който разработчиците ще спрат да забелязват. Задавайте прагове въз основа на текущите показатели, след което постепенно ги затягайте, докато оптимизирате приложението.

Табло за управление Performance в конзолата на Firebase

Таблото за управление Performance показва ключовите метрики като времеви редове с разбивка по версия на приложението, устройство, държава, тип връзка и версия на ОС. За всяка метрика са достъпни: средна стойност, медиана, 95-и персентил, 99-и персентил. 95-ият персентил е най-информативната метрика за оценка на производителността, тъй като показва как приложението работи на „слаби устройства”, игнорирайки отклоняващите се стойности.

Таблото поддържа сравнение на версии: изберете две версии на приложението (текуща и предишна) за визуално сравнение на метриките. Ако след актуализация 95-ият персентил на времето за стартиране се е увеличил от 2.1 на 3.4 секунди — регресията е очевидна и трябва да се намери commit-ът, причинил забавянето. Firebase Performance се интегрира с GitHub, GitLab и Bitbucket, което позволява свързване на промените в метриките с конкретни commits.

Примери за код за 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 без параметри на заявката (за сигурност и агрегиране) — тоест /data, а не /data?token=abc. Firebase автоматично групира подобни URL модели.

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

Третият пример демонстрира измерване на време за обработка на изображение (компресия, промяна на размер) с помощта на персонализирано проследяване. В този случай проследяването обгръща синхронна операция, но за производствена среда използвайте корутини или 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 ще покаже коя версия на приложението е започнала да стартира по-бавно — проверете кои зависимости са добавени или актуализирани.

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

Оптимизация на мрежови заявки

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

Firebase Performance показва разпределението на времето на заявката: DNS резолюция, TCP ръкостискане, TLS ръкостискане, изпращане на заявка, получаване на отговор. Ако по-голямата част от времето се пада на DNS — използвайте предварително зареждане на DNS (OkHttp DNS-over-HTTPS). Ако на TLS — използвайте възобновяване на сесия и настройка на cipher suites. Ако на получаване на отговор — проверете размера на отговора и скоростта на мрежата на потребителя. Данните на Firebase позволяват локализиране на проблема на ниво протокол, а не просто да се каже „заявката е бавна”.

Интеграция на Remote Config за деактивиране на проследяване

За производствена среда се препоръчва добавяне на Remote Config флаг performance_tracing_enabled, който позволява отдалечено деактивиране на персонализирани проследявания. Ако Firebase Performance SDK от страна на клиента генерира твърде много данни или влияе на производителността (на слаби устройства), можете да деактивирате проследяванията за всички потребители, оставяйки само автоматичните метрики, които имат минимално натоварване.

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