Firebase Performance — co to jest, narzędzie monitorowania i metryki

Czym jest Firebase Performance Monitoring?

Firebase Performance Monitoring to chmurowa usługa Google, która zbiera i wyświetla metryki wydajności aplikacji mobilnych. Usługa jest częścią zestawu narzędzi Firebase i nie wymaga osobnej opłaty — monitoring jest dostępny w ramach darmowego taryfu Spark (limit 500 000 zdarzeń dziennie) i płatnego Blaze. Firebase Performance automatycznie generuje trasy dla standardowych scenariuszy: cold start ekranu, warm start, tła zapytania HTTP.

Architektura usługi opiera się na dwóch typach danych: traces (trasy) i metrics (metryki). Trasa to przedział czasowy z początkiem i końcem, w którym mierzony jest czas wykonania. Metryka to wartość liczbowa: rozmiar odpowiedzi, częstotliwość błędów, prędkość w bajtach/sek. Każda trasa może zawierać wiele metryk. SDK zbiera dane na urządzeniu, buforuje je i wysyła do Firebase w tle z priorytetem niskiego opóźnienia, aby nie wpływać na doświadczenie użytkownika.

Według raportu Google I/O 2024, Firebase Performance jest używane w ponad 2 milionach aplikacji na całym świecie. Średni czas wykrycia problemu wydajnościowego za pomocą Firebase Performance wynosi 15 minut po wydaniu, jeśli skonfigurowano alerty. Bez monitorowania podobny problem jest wykrywany średnio po 2–3 dniach na podstawie skarg użytkowników do wsparcia.

Różnica od Firebase Crashlytics

Crashlytics śledzi awarie i błędy krytyczne — sytuacje, w których aplikacja ulega awarii. Firebase Performance monitoruje wydajność działającej aplikacji: wolne ekrany, długie zapytania sieciowe, opóźnienia odpowiedzi UI. Crashlytics odpowiada na pytanie „dlaczego aplikacja uległa awarii?„, a Performance na pytanie „dlaczego aplikacja działa wolno?„. Obie usługi integrują się przez jeden SDK (Firebase Core), a dane są wyświetlane w powiązanych sekcjach konsoli Firebase.

Metryki percentylowe

Firebase Performance nie pokazuje średnich wartości — tylko percentyle: P50, P75, P90, P95, P99. Jest to krytyczne dla wydajności: średni czas ukrywa odstające wartości. Jeśli 99 użytkowników otwiera ekran w 200 ms, a jeden w 20 sekund, średnia wyniesie ~400 ms, co wygląda akceptowalnie. P99 pokaże 20 sekund — rzeczywisty problem. Firebase wyświetla percentyle na osi czasu, co pozwala śledzić regresje z dokładnością do godziny.

Jak działa Firebase Performance Monitoring

Firebase Performance SDK jest integrowany z aplikacją poprzez standardową integrację: dodanie zależności w Gradle (Android) lub przez CocoaPods (iOS). Po inicjalizacji Firebase w kodzie, SDK automatycznie rozpoczyna zbieranie metryk bez dodatkowej konfiguracji. Ważną zasadą działania jest lazy collection: SDK nie wysyła danych natychmiast, ale gromadzi je i przekazuje partiami, gdy warunki sieciowe są sprzyjające.

Dla iOS SDK używa NSURLProtocol do przechwytywania zapytań HTTP, dla Android — OkHttp Interceptor. Jeśli aplikacja nie używa OkHttp, SDK automatycznie opakowuje HttpURLConnection. Przechwycone zapytania są wzbogacane o metadane: Content-Type, status odpowiedzi, rozmiar w bajtach, czas trwania. Wszystkie dane są przesyłane przez HTTPS na serwer Firebase z szyfrowaniem TLS 1.3.

Jednym z kluczowych wymagań Firebase Performance jest bycie ostatnią wtyczką na liście wtyczek Gradle. Jeśli kolejność jest naruszona, SDK może nie przechwytywać wszystkich zapytań lub nieprawidłowo mierzyć czas uruchamiania. Firebase zaleca umieszczanie wtyczki na końcu bloku plugins, po Crashlytics i innych wtyczkach Google Services.

// build.gradle (Module: app) — prawidłowa kolejność wtyczek
plugins {
    id "com.android.application"
    id "org.jetbrains.kotlin.android"
    id "com.google.gms.google-services"
    id "com.google.firebase.crashlytics"
    id "com.google.firebase.firebase-perf"  // na końcu!
}

dependencies {
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-perf"
}

Automatyczne trasy: ekrany, uruchamianie, sieć

Firebase Performance tworzy trzy typy automatycznych tras: screen trace (czas renderowania ekranu), app start trace (czas uruchamiania aplikacji) i network request trace (zapytania HTTP). Screen trace dla Android mierzy czas między wywołaniem Activity.onCreate a zakończeniem renderowania pierwszej klatki. Dla iOS mierzony jest czas między viewDidLoad a viewDidAppear. Firebase automatycznie tworzy trasę dla każdego ekranu, używając nazwy klasy Activity lub ViewController.

App start trace dzieli się na dwa typy: cold start (aplikacja uruchamiana od zera, proces nie istniał) i warm start (aplikacja przywracana ze stanu tła). Cold start jest najważniejszym wskaźnikiem, ponieważ obejmuje inicjalizację wszystkich SDK, ładowanie plików DEX i tworzenie pierwszego Activity. Firebase mierzy cold start od momentu uruchomienia procesu do pełnego renderowania pierwszego ekranu. Zgodnie z zaleceniami Google, cold start nie powinien przekraczać 500 ms dla P50 i 2 sekund dla P99.

Network request trace automatycznie rejestruje każde zapytanie HTTP z metadanymi: URL, metoda, kod odpowiedzi, rozmiar odpowiedzi, prędkość transferu. W konsoli Firebase Performance można filtrować zapytania według wzorca URL — na przykład pokazać wszystkie zapytania do /api/v2/orders. Dla każdego wzorca wyświetlane są percentyle czasu odpowiedzi i częstotliwość błędów 4xx/5xx. Pozwala to szybko wykryć degradację konkretnego API bez konfigurowania osobnych alertów.

Metryki ekranów w szczegółach

Dla ekranów Firebase Performance dodatkowo oblicza metric „frozen frames„ — klatki, które renderowały się dłużej niż 700 ms. Takie zawieszenia UI są odbierane przez użytkownika jako „aplikacja zawiesiła się„. Jeśli na ekranie jest więcej niż 1% frozen frames, Firebase oznacza metrykę jako problematyczną. Dla Android SDK dodatkowo zbiera metrykę slow renders — klatki dłuższe niż 16 ms (przekroczenie 60 FPS). Połączenie screen trace i frozen frames daje pełny obraz zarówno czasu ładowania, jak i płynności animacji.

Niestandardowe trasy dla scenariuszy biznesowych

Niestandardowe trasy pozwalają mierzyć czas trwania dowolnego scenariusza użytkownika: składanie zamówienia, ładowanie obrazu do chmury, synchronizacja danych. Deweloper jawnie określa początek i koniec trasy w kodzie oraz nadaje nazwę scenariusza. W przeciwieństwie do automatycznych tras, niestandardowe trasy dają pełną kontrolę nad tym, co jest mierzone, i pozwalają dodawać atrybuty do filtrowania.

Każda niestandardowa trasa może zawierać atrybuty — pary klucz-wartość, które są dodawane jako metadane. Atrybuty pomagają segmentować dane: na przykład można śledzić czas składania zamówienia osobno dla „promo_user„ i „regular_user„. Firebase Performance obsługuje do 5 atrybutów na trasę i do 100 unikalnych wartości atrybutu. Atrybuty są indeksowane i dostępne do filtrowania w konsoli Firebase.

Według raportu Google I/O 2024, zespół Spotify używa niestandardowych tras Firebase do monitorowania czasu przełączania między utworami. Pozwoliło to skrócić medianę czasu przełączania z 400 ms do 120 ms poprzez zidentyfikowanie wąskiego gardła w buforowaniu audio. Kluczowym odkryciem było filtrowanie według atrybutu „device_model„ — problem występował tylko na urządzeniach Samsung z Android 13.

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class CheckoutTracker {

    private val firebasePerf = FirebasePerformance.getInstance()

    fun trackCheckoutFlow(userId: String, promoApplied: Boolean) {
        val trace: Trace = firebasePerf.newTrace("checkout_flow")
        trace.putAttribute("promo_user", promoApplied.toString())
        trace.putAttribute("user_tier", "premium")
        trace.start()

        // Wykonanie scenariusza składania zamówienia
        validateCart()
        processPayment()
        confirmOrder()

        trace.stop()
    }
}

Integracja Firebase Performance z projektem Android

Integracja Firebase Performance w Android wymaga trzech kroków: dodania wtyczki google-services, podłączenia BOM (Bill of Materials) Firebase i dodania zależności firebase-perf. Firebase Performance automatycznie działa na wszystkich Activity i fragmentach, jeśli używają AppCompatActivity. Dla ekranów Compose Firebase zaleca używanie niestandardowych tras, ponieważ automatyczne screen trace nie obsługuje Compose bezpośrednio.

Ważny szczegół: Firebase Performance Gradle-plugin modyfikuje kod bajtowy aplikacji na etapie kompilacji. Plugin dodaje kod instrumentujący do każdego Activity i klienta OkHttp. Może to zwiększyć czas budowania o 5–10% i rozmiar APK o 200–400 KB. W kompilacjach debug Firebase Performance jest automatycznie wyłączany — chroni to przed zniekształceniem metryk podczas lokalnego rozwoju. Do wymuszonego włączenia w debug używany jest flag firebasePerformanceInstrumentationEnabled w manifeście.

Firebase Performance obsługuje również MetricKit dla iOS i Perfetto dla Android — niskopoziomowe trackery systemowe. MetricKit dostarcza dane o częstotliwości klatek, zużyciu CPU i pamięci na poziomie systemu operacyjnego. Firebase agreguje te dane i wyświetla je w tej samej konsoli, gdzie pokazywane są trasy HTTP i screen traces, łącząc telemetrię systemową i aplikacyjną w jednym interfejsie.

Zapytania HTTP z OkHttp

import okhttp3.OkHttpClient
import com.google.firebase.perf.network.FirebasePerfOkHttpClient

val client = OkHttpClient.Builder()
    .addInterceptor FirebasePerfOkHttpClient
    .build()

val request = Request.Builder()
    .url("https://api.example.com/orders")
    .build()

client.newCall(request).enqueue(object : Callback {
    override fun onFailure(call: Call, e: IOException) { /* handle */ }
    override fun onResponse(call: Call, response: Response) { /* handle */ }
})

Integracja Firebase Performance z projektem iOS

Dla iOS integracja Firebase Performance odbywa się przez CocoaPods lub Swift Package Manager. Po zainstalowaniu podów FirebasePerformance i FirebaseCore, SDK automatycznie rozpoczyna zbieranie metryk. Do przechwytywania zapytań HTTP Firebase Performance iOS używa NSURLProtocol — systemowego mechanizmu, który pozwala przechwytywać wszystkie ładowania URL w aplikacji. SDK rejestruje swoją podklasę NSURLProtocol podczas uruchamiania, a wszystkie zapytania przez URLSession automatycznie trafiają pod monitoring.

Ograniczenie dla iOS: Firebase Performance nie obsługuje automatycznego screen trace dla SwiftUI. Dla aplikacji SwiftUI konieczne jest ręczne tworzenie niestandardowych tras, opakowując ciało View w blok start/stop. Firebase pracuje nad natywną obsługą SwiftUI, ale obecnie SDK automatycznie śledzi tylko UIView-kontrolery. Dla hybrydowych aplikacji na UIKit + SwiftUI zaleca się tworzenie ekranów na UIKit i osadzanie SwiftUI przez UIHostingController.

Firebase Performance iOS udostępnia również integrację z MetricKit — frameworkiem Apple, który zbiera dane diagnostyczne na poziomie systemu operacyjnego. MetricKit wysyła codzienne raporty z metrykami CPU, GPU, pamięci i częstotliwości klatek. Firebase Performance agreguje te raporty i wyświetla je w konsoli obok niestandardowych tras, co daje pełny obraz wydajności zarówno na poziomie aplikacji, jak i na poziomie systemu.

import FirebasePerformance

final class ImageUploadService {

    func uploadImage(_ data: Data, to url: URL) async throws {
        guard let trace = Performance.startTrace(name: "image_upload") else { return }
        trace?.setValue("image/jpeg", forAttribute: "content_type")
        trace?.setValue("\(data.count)", forAttribute: "file_size")

        var request = URLRequest(url: url)
        request.httpMethod = "POST"
        request.httpBody = data

        let (_, response) = try await URLSession.shared.data(for: request)
        guard let httpResponse = response as? HTTPURLResponse else { return }
        trace?.setValue("\(httpResponse.statusCode)",
                        forAttribute: "status_code")
        trace?.stop()
    }
}