Firebase Performance: ce este, metrici și cum să urmărești

Ce este Firebase Performance Monitoring

Firebase Performance Monitoring este un SDK și o platformă cloud pentru colectarea, agregarea și vizualizarea metricilor de performanță ale aplicațiilor mobile. SDK-ul este încorporat în aplicație și instrumentează automat punctele cheie: ciclul de viață Activity (Android) sau ViewController (iOS), solicitările de rețea prin URLSession (iOS) sau OkHttp (Android) și apelurile de sistem. Datele colectate sunt trimise la serverul Firebase, unde sunt agregate în funcție de versiunile aplicației, dispozitive, țări și alte atribute.

Arhitectura Performance SDK este construită pe principiul suprasarcinii minime: instrumentarea adaugă nu mai mult de 1–2% la timpul de execuție al operațiilor măsurate. Datele sunt colectate asincron și stocate în buffer pe dispozitiv înainte de trimitere, ceea ce elimină impactul asupra performanței firului UI. Trimiterea datelor are loc conform programului (implicit la fiecare 30 de minute) sau la atingerea bufferului de 100 KB.

Diferența cheie dintre Firebase Performance și profilerele Android Studio (CPU Profiler) sau Xcode Instruments este monitorizarea de producție. Firebase Performance colectează date de pe dispozitive reale ale utilizatorilor, nu doar de pe dispozitivele dezvoltatorului. Acest lucru permite detectarea problemelor care apar doar pe anumite modele, versiuni de OS sau în regiuni specifice — adică probleme care nu pot fi reproduse într-un mediu controlat.

Cum colectează SDK-ul date fără modificarea codului

Instrumentarea automată este principala caracteristică a Firebase Performance. Pentru Android, SDK-ul înregistrează automat ActivityLifecycleCallbacks și măsoară timpul dintre onCreate și onResume (timpul de randare a ecranului). Pentru iOS — face swizzle la metodele viewDidLoad și viewDidAppear. Solicitările de rețea sunt interceptate la nivelul OkHttpInterceptor (Android) sau NSURLProtocol (iOS). Dezvoltatorul nu trebuie să adauge apeluri start/stop pentru metricile standard.

Activarea și dezactivarea Performance SDK este gestionată prin pluginul Google Services (Android) sau Info.plist (iOS). Pentru depanare se poate activa logarea verbose a Performance SDK, care va arăta ce metrici sunt colectate și trimise. În producție se recomandă menținerea logării la nivelul warning pentru a nu aglomera logurile cu informații inutile. Pentru proiectele pe Flutter sau React Native, instrumentarea automată poate fi limitată — mai multe detalii în secțiunea exemplelor de cod.

Limite gratuite și tarifare

Firebase Performance este oferit pe tariful gratuit Spark fără limite privind numărul de urmăriri sau volumul de date. Tariful plătit Blaze nu percepe, de asemenea, taxe pentru Performance Monitoring — acesta este unul dintre puținele servicii Firebase complet gratuite pe ambele tarife. Există o singură limitare: datele sunt stocate 30 de zile (pe Spark) și până la 365 de zile (pe Blaze). Pentru analiza pe termen lung, exportați datele prin BigQuery export.

Absența taxelor face ca Firebase Performance să fie alegerea ideală pentru orice proiect — de la prototip la aplicația enterprise cu milioane de utilizatori. Singurul element de cost este traficul de ieșire al datelor Performance SDK, dar acesta este neglijabil în comparație cu alte operații de rețea ale aplicației (mai puțin de 1 MB pe lună per dispozitiv). În BigQuery export se percep taxe pentru stocare și interogări, dar Performance SDK în sine este gratuit.

Metrici automate: ce se măsoară fără cod

Firebase Performance colectează automat cinci categorii de metrici fără nici o linie de cod: timpul de pornire a aplicației (app start), solicitări lente (slow HTTP requests), viteza de randare a ecranelor (screen rendering), consumul de memorie (memory usage, doar Android) și rata de cadre (frame rate, doar Android). Aceste metrici sunt disponibile în consola Firebase imediat după conectarea SDK-ului și prima sesiune a utilizatorului.

App Start Time — timpul de la pornirea procesului până la pregătirea completă a UI pentru interacțiune. Se împarte în pornire la rece (aplicația pornește de la zero) și pornire la cald (aplicația se restabilește din starea de fundal). Pornirea la rece include încărcarea fișierelor DEX, inițializarea câmpurilor statice, apelul Application.onCreate și Activity.onCreate. Firebase clasifică automat tipul de pornire și arată distribuția timpului pentru fiecare tip.

Screen Rendering Time — timpul de la începerea încărcării ecranului (onCreate pentru Android, viewDidLoad pentru iOS) până când ecranul este gata pentru interacțiune (onResume, viewDidAppear). Firebase agregă datele pentru fiecare ecran (după numele clasei sau custom screen name), permițând determinarea celui mai lent ecran. Pentru Android se măsoară suplimentar dropped frames — numărul de cadre omise în timpul randării ecranului (jank).

Solicitări de rețea (HTTP/HTTPS)

Performance SDK interceptează și măsoară automat fiecare solicitare HTTP/HTTPS trimisă din aplicație prin URLSession, OkHttp sau URLConnection. Pentru fiecare solicitare se înregistrează: URL (calea fără parametrii query pentru securitate), metoda HTTP, codul de răspuns, dimensiunea răspunsului în octeți, durata solicitării și viteza conexiunii (WiFi, Cellular). Datele sunt agregate în tabloul de bord „Network Requests” al consolei Firebase.

Slow Requests — solicitări a căror durată depășește pragul stabilit. Pragul implicit pentru „solicitare lentă” este de 4000 ms. Această metrică este critică pentru identificarea problemelor cu partea de server: dacă după o actualizare a backend-ului numărul de solicitări lente a crescut de la 1% la 15%, acesta este un semnal pentru analiza imediată a logurilor serverului. Utilizatorii nu vor aștepta un răspuns mai mult de 5 secunde — datele Firebase arată că 53% dintre utilizatori închid aplicația dacă o solicitare durează mai mult de 3 secunde.

Limitări ale instrumentării automate

Limitări iOS: pe iOS, Performance SDK nu poate măsura dropped frames (aceasta este o API privată). Pentru măsurarea jank pe iOS utilizați MetricKit sau CADisplayLink. De asemenea, pe iOS SDK nu interceptează solicitările efectuate prin clienți HTTP terți care nu utilizează URLSession (de exemplu, SwiftNIO). Pentru astfel de cazuri utilizați urmăriri personalizate cu atribute HTTP.

Limitări Android: pe Android, măsurarea automată a memoriei este disponibilă doar pe dispozitivele cu Android 8.0+ (API 26+). Pentru versiuni mai vechi utilizați urmăriri personalizate cu obținerea datelor prin Debug.getMemoryInfo(). SDK-ul nu interceptează nici conexiunile WebSocket — pentru acestea sunt necesare urmăriri separate. În ciuda limitărilor, metricile automate acoperă 80% din nevoile de monitorizare a performanței.

Urmăriri personalizate și atribute HTTP

Urmăririle personalizate (custom traces) sunt intervale de timp denumite pe care dezvoltatorul le creează manual pentru măsurarea performanței scenariilor specifice: încărcarea feedului de știri, procesarea imaginii, sincronizarea datelor, executarea unei interogări complexe la baza de date. Urmăririle personalizate completează metricile automate și permit măsurarea exactă a acelor porțiuni de cod pe care dezvoltatorul le consideră critice pentru performanță.

Fiecare urmărire are un nume (maximum 100 de caractere) și poate conține până la 5 metrici (metrics) personalizate — valori numerice care sunt înregistrate în interiorul urmăririi. De exemplu, în urmărirea „image_processing” se pot măsura metricile „original_file_size” și „processed_file_size”. Metricile sunt afișate în consola Firebase ca distribuții (min, max, average, percentile), ceea ce permite analizarea nu doar a duratei, ci și a caracteristicilor operației.

Atributele HTTP sunt un tip special de urmăriri personalizate pentru solicitările de rețea care nu au fost interceptate automat de SDK (de exemplu, prin WebSocket sau biblioteci terțe). Atributele HTTP includ URL, metoda HTTP, codul de răspuns și dimensiunea răspunsului. Firebase le afișează în secțiunea „Network Requests” împreună cu solicitările colectate automat, asigurând o imagine unitară a interacțiunilor de rețea.

Când să utilizați urmăririle personalizate

Urmăririle personalizate sunt indispensabile pentru măsurarea: timpului de încărcare a datelor din baza de date locală (Room, CoreData), duratei calculelor complexe (criptare, compresie), performanței animațiilor și tranzițiilor, timpului de răspuns al SDK-urilor terțe (hărți, plăți, analitică). Pentru fiecare astfel de scenariu creați o urmărire, înfășurați codul măsurat în start/stop și adăugați atribute pentru segmentarea ulterioară.

Nu abuzați de urmăririle personalizate. Fiecare urmărire înseamnă consum suplimentar de baterie și trafic. Se recomandă nu mai mult de 10–15 urmăriri active în versiunea de producție a aplicației. Pentru depanare se pot adăuga mai multe urmăriri, dar înainte de lansare dezactivați-le pe cele în exces prin Remote Config (utilizați flagul performance_tracing_enabled). Acest lucru permite activarea urmăririi detaliate doar pentru anumiți utilizatori sau sesiuni.

Atribute ale urmăririlor pentru segmentare

Atributele personalizate (custom attributes) sunt perechi cheie-valoare care pot fi adăugate la o urmărire pentru filtrarea ulterioară în consola Firebase. De exemplu, la urmărirea „feed_load” se pot adăuga atributele „feed_type” (main, explore, following) și „cache_status” (cold, warm). În consolă, datele urmăririi pot fi filtrate după aceste atribute pentru a determina ce tip de feed se încarcă cel mai lent.

Limitări: fiecare urmărire poate avea până la 5 atribute personalizate. Valoarea atributului este un șir de caractere de până la 100 de caractere. Atributele trebuie setate înainte de începerea urmăririi; modificarea atributului după începere este ignorată. Această limitare este legată de performanță: stabilirea atributelor după începere ar necesita sincronizare suplimentară.

Praguri de performanță și alerte

Pragurile (thresholds) sunt valori limită configurabile ale metricilor, la depășirea cărora Firebase Performance generează o avertizare. Pragurile se stabilesc în consola Firebase (secțiunea Performance > Thresholds) pentru fiecare metrică automată: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Se pot stabili praguri globale pentru toate versiunile aplicației sau specifice pentru anumite versiuni.

Alertele (alerts) sunt notificări automate pe care Firebase le trimite la depășirea pragului. Alertele pot fi configurate pentru email, Slack webhook, PagerDuty sau Cloud Functions (pentru procesare personalizată). Fiecare alertă conține: numele metricii, valoarea curentă, valoarea pragului, versiunea aplicației, segmentul (dispozitiv, țară). Alertele permit reacționarea la degradarea performanței înainte ca aceasta să devină vizibilă pentru utilizatori.

Praguri recomandate conform standardului industrial (Google I/O 2025): pornire la rece — sub 2 secunde, pornire la cald — sub 1 secundă, randarea ecranului — sub 500 ms, durata solicitării HTTP — sub 3000 ms (percentila 95), ponderea solicitărilor lente — sub 5%. Pentru aplicațiile cu concurență ridicată (Social, E-commerce) pragurile țintă pot fi mai stricte: pornire la rece < 1.5 secunde, HTTP < 1000 ms.

Configurarea pragurilor în consola Firebase

În consola Firebase accesați secțiunea Performance, deschideți fila Thresholds. Pentru fiecare metrică stabiliți valoarea pragului dorită și procentul de utilizatori pe care trebuie să îl afecteze depășirea. De exemplu: „considerăm pornirea la rece lentă dacă depășește 2 secunde pentru mai mult de 10% dintre utilizatori”. Firebase va afișa valorile curente ale metricilor și istoricul depășirilor pentru a ajuta la alegerea unor praguri realiste.

Important: pragurile nu afectează colectarea datelor, ele gestionează doar generarea notificărilor. Dacă pragul este prea scăzut (de exemplu, pornire la rece 1 secundă, deși 50% dintre dispozitive pornesc în 3 secunde), alertele vor veni constant și vor deveni „zgomot” pe care dezvoltatorii nu îl vor mai observa. Stabiliți pragurile pe baza indicatorilor actuali, apoi înăspriți-le treptat pe măsură ce optimizați aplicația.

Tabla de bord Performance în consola Firebase

Tabla de bord Performance afișează metricile cheie sub formă de serii temporale cu defalcare pe versiunea aplicației, dispozitiv, țară, tipul conexiunii și versiunea OS. Pentru fiecare metrică sunt disponibile: media, mediana, percentila 95, percentila 99. Percentila 95 este cea mai informativă metrică pentru evaluarea performanței, deoarece arată cum funcționează aplicația pe dispozitivele slabe, ignorând valorile aberante.

Tabla de bord suportă compararea versiunilor: selectați două versiuni ale aplicației (actuală și anterioară) pentru compararea vizuală a metricilor. Dacă după actualizare percentila 95 a timpului de pornire a crescut de la 2.1 la 3.4 secunde — regresia este evidentă și trebuie găsit commit-ul care a cauzat încetinirea. Firebase Performance se integrează cu GitHub, GitLab și Bitbucket, permițând asocierea modificărilor metricilor cu commit-uri specifice.

Exemple de cod pentru Performance Monitoring

Să examinăm exemple de integrare a Firebase Performance Monitoring într-o aplicație Android în Kotlin. Codul demonstrează crearea unei urmăriri personalizate pentru măsurarea încărcării feedului de știri, adăugarea unui atribut HTTP pentru o solicitare neinterceptată automat și utilizarea Trace pentru măsurarea timpului de procesare a imaginii. Toate exemplele iau în considerare posibilitatea dezactivării urmăririi prin Remote Config.

Înainte de utilizare adăugați dependența: implementation("com.google.firebase:firebase-perf") prin Firebase BOM. Pentru instrumentarea automată nu este necesară o configurare suplimentară — SDK-ul interceptează operațiile standard automat după conectarea dependenței.

Urmărire personalizată pentru încărcarea feedului

Primul exemplu — măsurarea timpului de încărcare a feedului de știri de pe server. Urmărirea înfășoară operația asincronă fetchFeed, care obține date din rețea și parsează JSON. La urmărire au fost adăugate atribute personalizate: sursa datelor (cache sau network) și numărul de postări primite. Acest lucru permite segmentarea datelor și înțelegerea condițiilor în care feedul se încarcă cel mai lent.

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()
    }
}

Funcția loadFeedWithTrace primește parametrul source („cache” sau „network”), care este utilizat ca atribut al urmăririi. După finalizarea operației asincrone, urmărirea este oprită în blocul finally, garantând oprirea chiar și în cazul unei excepții. Metricul items_count permite analizarea modului în care numărul de postări afectează timpul de încărcare. În consola Firebase se pot filtra urmăririle după atributul source și se poate vedea că încărcarea din rețea este de 3 ori mai lentă decât din cache.

Atribut HTTP pentru o solicitare nestandard

Al doilea exemplu — atribut HTTP pentru o solicitare efectuată prin WebSocket (neinterceptată automat). Se utilizează clasa HttpMetric, care permite înregistrarea manuală a unei solicitări URL, a metodei sale, a codului de răspuns și a dimensiunii. Firebase va afișa această solicitare în secțiunea Network Requests împreună cu cele interceptate automat.

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()
    }
}

În exemplu, sendWithHttpMetric utilizează newHttpMetric pentru înregistrarea unui apel HTTP nestandard. SDK-ul nu îl interceptează automat, astfel încât dezvoltatorul setează manual URL, metoda, codul de răspuns și dimensiunile. Este important să setați URL-ul fără parametrii query (pentru securitate și agregare) — adică /data, nu /data?token=abc. Firebase grupează automat modelele de URL similare.

Măsurarea timpului de procesare a imaginii

Al treilea exemplu demonstrează măsurarea timpului de procesare a imaginii (compresie, redimensionare) cu ajutorul unei urmăriri personalizate. În acest caz, urmărirea înfășoară o operație sincronă, dar pentru producție utilizați corutine sau RxJava pentru a nu bloca firul 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
}

Funcția compressImage măsoară timpul de compresie a imaginii în JPEG cu calitate de 80%. Atributul format permite compararea viitoare a timpului de compresie JPEG vs WebP. Metricul output_size_kb arată cât de eficientă este compresia. În consola Firebase se poate vedea distribuția: pe dispozitivele slabe (Android bugetar) compresia durează de 4 ori mai mult decât pe flagmanuri, ceea ce poate fi cauza întârzierilor la trimiterea imaginilor pe server.

Cum să îmbunătățești performanța pe baza datelor

Firebase Performance furnizează date, dar nu oferă soluții gata făcute. Analiza metricilor necesită înțelegerea cauzelor tipice ale degradării performanței pentru fiecare metrică. Să examinăm principalele modele de înrăutățire și metodele de diagnosticare pe baza datelor Performance Monitoring. Abordare: găsiți anomalia în metrică → verificați cauzele tipice → aplicați optimizarea → verificați rezultatul peste o săptămână.

Pornire la rece lentă (> 2 secunde): cauze — inițializare grea a SDK-urilor în Application.onCreate (analitică, crash reporting, map SDK), încărcarea resurselor mari (fonturi, teme), operații sincrone în firul principal la pornire. Soluții: inițializare leneșă a SDK-urilor, încărcare amânată a resurselor, utilizarea SplashScreen API (Android 12+) pentru afișarea unui placeholder în timpul inițializării. Firebase Performance va arăta care versiune a aplicației a început să pornească mai lent — verificați ce dependențe au fost adăugate sau actualizate.

Randare lentă a ecranului (> 500 ms): cauze — ierarhie View complexă (ConstraintLayout imbricate, multe Fragment), încărcarea datelor în firul UI (rețea sau disc), operații draw grele (imagini mari, View personalizate). Soluții: optimizarea ierarhiei layout (Layout Inspector în Android Studio), mutarea datelor pe firul de fundal, stocarea în cache a imaginilor prin Glide sau Coil. Utilizați filtrul Screen Rendering din Firebase pentru a găsi cel mai lent ecran și a-l optimiza mai întâi.

Optimizarea solicitărilor de rețea

Solicitări HTTP lente (> 3 secunde): cauze — server lent, payloaduri mari, lipsa cache-ului, protocol neoptim (HTTP/1.1 în loc de HTTP/2), rezolvare DNS. Soluții: verificați partea de server (uptime, latency), reduceți dimensiunea răspunsului (paginare, GraphQL, protobuf în loc de JSON), activați cache-ul prin antete HTTP (Cache-Control), utilizați OkHttp Interceptor pentru a adăuga timeout-uri și logică de reîncercare.

Firebase Performance arată distribuția timpului solicitării: rezolvare DNS, strângere de mână TCP, strângere de mână TLS, trimiterea solicitării, primirea răspunsului. Dacă cea mai mare parte a timpului revine DNS-ului — utilizați preîncărcarea DNS (OkHttp DNS-over-HTTPS). Dacă TLS-ului — utilizați reluarea sesiunii și ajustarea suitei de cifruri. Dacă primirii răspunsului — verificați dimensiunea răspunsului și viteza rețelei utilizatorului. Datele Firebase permit localizarea problemei la nivel de protocol, nu doar să spuneți „solicitarea este lentă”.

Integrarea Remote Config pentru dezactivarea urmăririi

Pentru producție se recomandă adăugarea unui flag Remote Config performance_tracing_enabled, care permite dezactivarea de la distanță a urmăririlor personalizate. Dacă Firebase Performance SDK pe client generează prea multe date sau afectează performanța (pe dispozitive slabe), se pot dezactiva urmăririle pentru toți utilizatorii, lăsând doar metricile automate, care au o suprasarcină minimă.

Exemplu de logică: la pornirea aplicației verificăm parametrul Remote Config performance_tracing_enabled. Dacă este false — toate apelurile Firebase.performance.newTrace() returnează un obiect stub care nu colectează date. Acest lucru se implementează printr-o clasă wrapper care verifică flagul înainte de crearea urmăririi. O astfel de abordare permite activarea urmăririi detaliate pentru anumiți utilizatori (beta testeri, dezvoltatori) fără a afecta întregul public.