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 — swizzlује методе viewDidLoad и viewDidAppear. Мрежни захтеви се пресрећу на нивоу OkHttpInterceptor (Android) или NSURLProtocol (iOS). Програмер не мора да додаје позиве start/stop за стандардне метрике.

Укључивање и искључивање Performance SDK-а се управља преко Google Services прикључка (Android) или Info.plist (iOS). За отклањање грешака може се укључити verbose логирање Performance SDK-а, које ће показати које се метрике прикупљају и шаљу. У продукцији се препоручује задржавање логирања на нивоу warning како се не би затрпали логови непотребним информацијама. За пројекте на Flutter или React Native, аутоматска инструментација може бити ограничена — детаљније у одељку примера кода.

Бесплатна ограничења и тарификација

Firebase Performance се нуди на бесплатној тарифи Spark без ограничења по броју трагова или количини података. Платна тарифа Blaze такође не наплаћује Performance Monitoring — ово је једна од ретких Firebase услуга потпуно бесплатних на обе тарифе. Постоји само једно ограничење: подаци се чувају 30 дана (на Spark) и до 365 дана (на Blaze). За дугорочну анализу извезите податке путем BigQuery export-а.

Непосгојање накнаде чини Firebase Performance идеалним избором за сваки пројекат — од прототипа до enterprise апликације са милионима корисника. Једина ставка трошка је излазни саобраћај података 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 агрегира податке за сваки екран (по имену класе или 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 ms. Ова метрика је критична за откривање проблема са серверском страном: ако је након ажурирања backend-а број спорих захтева порастао са 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 активних трагова у продукцијској верзији апликације. За отклањање грешака можете додати више трагова, али пре издавања искључите сувишне путем 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 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 Dashboard у конзоли Firebase

Performance Dashboard приказује кључне метрике у облику временских серија са разврставањем по верзији апликације, уређају, држави, типу везе и верзији ОС-а. За сваку метрику доступни су: просечна вредност, медијана, 95. перцентил, 99. перцентил. 95. перцентил је најинформативнија метрика за процену перформанси јер показује како апликација ради „на слабим уређајима”, игноришући одступајуће вредности.

Dashboard подржава поређење верзија: изаберите две верзије апликације (тренутну и претходну) за визуелно поређење метрика. Ако је након ажурирања 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 шаблоне.

Мерење времена обраде слике

Трећи пример демонстрира мерење времена обраде слике (компресија, промена величине) помоћу прилагођеног трага. У овом случају траг обухвата синхрону операцију, али за продукцију користите корутине или 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 ms): узроци — сложена хијерархија 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 резолвинг. Решења: проверите серверску страну (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 класе која проверава заставицу пре креирања трага. Такав приступ омогућава укључивање детаљног праћења за одређене кориснике (beta тестере, програмере) без утицаја на целокупну публику.