Firebase Performance: mi ez, metrikák és hogyan kövessük nyomon

Mi az a Firebase Performance Monitoring

Firebase Performance Monitoring egy SDK és felhőplatform a mobilalkalmazások teljesítménymutatóinak gyűjtésére, aggregálására és vizualizálására. Az SDK beágyazódik az alkalmazásba, és automatikusan instrumentálja a kulcspontokat: az Activity (Android) vagy ViewController (iOS) életciklusát, a hálózati kéréseket URLSession (iOS) vagy OkHttp (Android) segítségével, valamint a rendszerhívásokat. Az összegyűjtött adatok elküldésre kerülnek a Firebase szerverre, ahol az alkalmazás verziói, eszközök, országok és egyéb attribútumok szerint aggregálódnak.

A Performance SDK architektúrája a minimális többletterhelés elvén épül: az instrumentáció legfeljebb 1–2%-kal növeli a mért műveletek végrehajtási idejét. Az adatok aszinkron módon gyűlnek, és elküldés előtt pufferelődnek az eszközön, ami kiküszöböli a hatást az UI szál teljesítményére. Az adatok küldése ütemezés szerint (alapértelmezetten 30 percenként) vagy a 100 KB-os puffer elérésekor történik.

A Firebase Performance legfontosabb különbsége az Android Studio (CPU Profiler) vagy Xcode Instruments profilerekhez képest a termelési monitorozás. A Firebase Performance valódi felhasználói eszközökről gyűjt adatokat, nem csak a fejlesztői eszközökről. Ez lehetővé teszi olyan problémák észlelését, amelyek csak bizonyos modelleken, operációsrendszer-verziókon vagy adott régiókban fordulnak elő — vagyis olyan problémákét, amelyek nem reprodukálhatók ellenőrzött környezetben.

Hogyan gyűjt az SDK adatokat a kód módosítása nélkül

Automatikus instrumentáció a Firebase Performance fő jellemzője. Android esetén az SDK automatikusan regisztrálja az ActivityLifecycleCallbacks-et, és méri az onCreate és onResume közötti időt (képernyőmegjelenítési idő). iOS esetén — swizzli a viewDidLoad és viewDidAppear metódusokat. A hálózati kérések az OkHttpInterceptor (Android) vagy NSURLProtocol (iOS) szintjén kerülnek elfogásra. A fejlesztőnek nem kell start/stop hívásokat hozzáadnia a szabványos metrikákhoz.

A Performance SDK be- és kikapcsolása a Google Services beépülő modulon (Android) vagy az Info.plist-en (iOS) keresztül történik. Hibakereséshez bekapcsolható a Performance SDK részletes naplózása, amely megmutatja, mely metrikák gyűlnek és kerülnek elküldésre. Éles környezetben ajánlott a naplózást warning szinten tartani, hogy ne terheljük a naplókat felesleges információkkal. Flutter vagy React Native projektek esetén az automatikus instrumentáció korlátozott lehet — további részletek a kódpéldák szakaszban.

Ingyenes korlátok és díjszabás

A Firebase Performance az ingyenes Spark díjcsomagban érhető el, korlátozás nélkül a nyomok számát vagy az adatmennyiséget illetően. A fizetős Blaze díjcsomag sem számít fel díjat a Performance Monitoringért — ez az egyik kevés Firebase-szolgáltatás, amely teljesen ingyenes mindkét díjcsomagban. Csak egy korlátozás van: az adatok 30 napig (Spark) és 365 napig (Blaze) tárolódnak. Hosszú távú elemzéshez exportálja az adatokat a BigQuery export segítségével.

Az ingyenesség teszi a Firebase Performance-ot ideális választássá bármely projekthez — a prototípustól a milliós felhasználói bázisú enterprise alkalmazásig. Az egyetlen költségtétel a Performance SDK adatainak kimenő forgalma, de ez elhanyagolható más hálózati műveletekhez képest (kevesebb mint 1 MB havonta eszközönként). A BigQuery exportban tárolási és lekérdezési díjak merülnek fel, de maga a Performance SDK ingyenes.

Automatikus metrikák: mit mérünk kód nélkül

A Firebase Performance automatikusan öt metrikakategóriát gyűjt egyetlen kódsor nélkül: alkalmazás indítási ideje (app start), lassú kérések (slow HTTP requests), képernyőmegjelenítési sebesség (screen rendering), memóriahasználat (memory usage, csak Android) és képkockasebesség (frame rate, csak Android). Ezek a metrikák azonnal elérhetők a Firebase konzolban az SDK csatlakoztatása és az első felhasználói munkamenet után.

App Start Time — a folyamat elindításától a UI teljes interakcióra kész állapotáig eltelt idő. Hidegindításra (az alkalmazás a semmiből indul) és melegindításra (az alkalmazás háttérállapotból áll helyre) oszlik. A hidegindítás magában foglalja a DEX-fájlok betöltését, a statikus mezők inicializálását, az Application.onCreate és Activity.onCreate hívását. A Firebase automatikusan osztályozza az indítás típusát, és megjeleníti az időeloszlást minden típushoz.

Screen Rendering Time — a képernyő betöltésének kezdetétől (onCreate Android esetén, viewDidLoad iOS esetén) a képernyő interakcióra kész állapotáig (onResume, viewDidAppear) eltelt idő. A Firebase minden képernyőhöz aggregálja az adatokat (osztálynév vagy egyedi képernyőnév alapján), lehetővé téve a leglassabban betöltő képernyő azonosítását. Android esetén továbbá mérik a kihagyott képkockákat (dropped frames) — a képernyő megjelenítése során kihagyott képkockák számát (jank).

Hálózati kérések (HTTP/HTTPS)

A Performance SDK automatikusan elfogja és méri az alkalmazásból URLSession, OkHttp vagy URLConnection segítségével küldött összes HTTP/HTTPS kérést. Minden kéréshez rögzítésre kerül: URL (útvonal lekérdezési paraméterek nélkül a biztonság érdekében), HTTP-metódus, válaszkód, válasz mérete bájtokban, kérés időtartama és kapcsolat sebessége (WiFi, Cellular). Az adatok a Firebase konzol „Network Requests” irányítópultján aggregálódnak.

Slow Requests — olyan kérések, amelyek időtartama meghaladja a beállított küszöbértéket. A „lassú kérés” alapértelmezett küszöbértéke 4000 ms. Ez a metrika kritikus fontosságú a szerveroldali problémák azonosításához: ha a backend frissítése után a lassú kérések száma 1%-ról 15%-ra nőtt, ez a szervernaplók azonnali elemzésére utaló jel. A felhasználók nem várnak 5 másodpercnél tovább a válaszra — a Firebase adatai szerint a felhasználók 53%-a bezárja az alkalmazást, ha egy kérés 3 másodpercnél tovább tart.

Az automatikus instrumentáció korlátozásai

iOS korlátozások: iOS-en a Performance SDK nem tudja mérni a kihagyott képkockákat (ez privát API). A jank méréséhez iOS-en használja a MetricKit vagy CADisplayLink eszközt. Emellett iOS-en az SDK nem fogja el a harmadik féltől származó HTTP-klienseken keresztül végrehajtott kéréseket, amelyek nem használnak URLSession-t (például SwiftNIO). Ilyen esetekben használjon egyedi nyomokat HTTP-attribútumokkal.

Android korlátozások: Androidon az automatikus memóriamérés csak Android 8.0+ (API 26+) rendszerű eszközökön érhető el. Régebbi verziókhoz használjon egyedi nyomokat a Debug.getMemoryInfo()-n keresztüli adatgyűjtéssel. Az SDK emellett nem fogja el a WebSocket-kapcsolatokat — ezekhez külön nyomok szükségesek. A korlátozások ellenére az automatikus metrikák lefedik a teljesítménymonitorozási igények 80%-át.

Egyedi nyomok és HTTP-attribútumok

Az egyedi nyomok (custom traces) elnevezett időintervallumok, amelyeket a fejlesztő manuálisan hoz létre bizonyos forgatókönyvek teljesítményének mérésére: hírfolyam betöltése, képfeldolgozás, adatszinkronizálás, összetett adatbázis-lekérdezés végrehajtása. Az egyedi nyomok kiegészítik az automatikus metrikákat, és lehetővé teszik a fejlesztő által a teljesítmény szempontjából kritikusnak ítélt kódrészek mérését.

Minden nyomnak van neve (maximum 100 karakter), és legfeljebb 5 egyedi metrikát (metrics) tartalmazhat — numerikus értékeket, amelyek a nyomon belül kerülnek rögzítésre. Például az „image_processing” nyomban mérhető az „original_file_size” és „processed_file_size” metrika. A metrikák a Firebase konzolban eloszlásokként jelennek meg (min, max, average, percentilisek), ami lehetővé teszi nemcsak az időtartam, hanem a művelet jellemzőinek elemzését is.

A HTTP-attribútumok az egyedi nyomok egy speciális típusa azon hálózati kérésekhez, amelyeket az SDK nem fogott el automatikusan (például WebSocketen vagy harmadik féltől származó könyvtárakon keresztül). A HTTP-attribútumok tartalmazzák az URL-t, a HTTP-metódust, a válaszkódot és a válasz méretét. A Firebase ezeket a „Network Requests” szakaszban jeleníti meg az automatikusan gyűjtött kérésekkel együtt, egységes képet biztosítva a hálózati interakciókról.

Mikor használjunk egyedi nyomokat

Az egyedi nyomok nélkülözhetetlenek a következők méréséhez: adatok betöltési ideje a helyi adatbázisból (Room, CoreData), összetett számítások időtartama (titkosítás, tömörítés), animációk és átmenetek teljesítménye, harmadik féltől származó SDK-k válaszideje (térképek, fizetések, analitika). Minden ilyen forgatókönyvhöz hozzon létre egy nyomot, csomagolja a mért kódot start/stop közé, és adjon hozzá attribútumokat a későbbi szegmentáláshoz.

Ne éljen vissza az egyedi nyomokkal. Minden nyom további akkumulátor- és adatforgalom-fogyasztást jelent. Javasolt legfeljebb 10–15 aktív nyomot használni az alkalmazás éles verziójában. Hibakereséshez több nyomot is hozzáadhat, de a kiadás előtt kapcsolja ki a feleslegeseket a Remote Config segítségével (használja a performance_tracing_enabled jelzőt). Ez lehetővé teszi a részletes nyomkövetést csak kiválasztott felhasználók vagy munkamenetek számára.

A nyomok attribútumai szegmentáláshoz

Az egyedi attribútumok (custom attributes) kulcs-érték párok, amelyek egy nyomhoz adhatók a későbbi szűréshez a Firebase konzolban. Például a „feed_load” nyomhoz hozzáadhatók a „feed_type” (main, explore, following) és „cache_status” (cold, warm) attribútumok. A konzolban a nyom adatai ezen attribútumok szerint szűrhetők annak meghatározásához, hogy melyik hírfolyam-típus töltődik a leglassabban.

Korlátozások: minden nyom legfeljebb 5 egyedi attribútumot tartalmazhat. Az attribútum értéke legfeljebb 100 karakter hosszúságú sztring. Az attribútumokat a nyom elindítása előtt kell beállítani; az attribútum elindítás utáni módosítása figyelmen kívül marad. Ez a korlátozás a teljesítménnyel kapcsolatos: az attribútumok elindítás utáni beállítása további szinkronizációt igényelne.

Teljesítményküszöbök és figyelmeztetések

A küszöbértékek (thresholds) a metrikák konfigurálható határértékei, amelyek túllépése esetén a Firebase Performance figyelmeztetést generál. A küszöbértékek a Firebase konzolban (Performance > Thresholds szakasz) állíthatók be minden automatikus metrikához: app start time (cold/warm), screen rendering time, slow HTTP requests, HTTP response time. Beállíthatók globális küszöbértékek az alkalmazás összes verziójához vagy specifikusak bizonyos verziókhoz.

A figyelmeztetések (alerts) automatikus értesítések, amelyeket a Firebase küld a küszöbérték túllépésekor. A figyelmeztetések beállíthatók email, Slack webhook, PagerDuty vagy Cloud Functions (egyedi feldolgozáshoz) számára. Minden figyelmeztetés tartalmazza: a metrika nevét, az aktuális értéket, a küszöbértéket, az alkalmazás verzióját, a szegmenst (eszköz, ország). A figyelmeztetések lehetővé teszik a teljesítményromlásra való reagálást, mielőtt az láthatóvá válna a felhasználók számára.

Ajánlott küszöbértékek az iparági szabvány szerint (Google I/O 2025): hidegindítás — kevesebb mint 2 másodperc, melegindítás — kevesebb mint 1 másodperc, képernyőmegjelenítés — kevesebb mint 500 ms, HTTP-kérés időtartama — kevesebb mint 3000 ms (95. percentilis), lassú kérések aránya — kevesebb mint 5%. Magas versenyintenzitású alkalmazásoknál (Social, E-commerce) a célküszöbértékek szigorúbbak lehetnek: hidegindítás < 1,5 másodperc, HTTP < 1000 ms.

Küszöbértékek beállítása a Firebase konzolban

A Firebase konzolban lépjen a Performance szakaszba, nyissa meg a Thresholds lapot. Minden metrikához állítsa be a kívánt küszöbértéket és azon felhasználók százalékos arányát, akiket érintenie kell a túllépésnek. Például: „lassúnak tekintjük a hidegindítást, ha az 2 másodpercnél tovább tart a felhasználók több mint 10%-ánál”. A Firebase megjeleníti a metrikák aktuális értékeit és a túllépések előzményeit, segítve a reális küszöbértékek kiválasztását.

Fontos: a küszöbértékek nem befolyásolják az adatgyűjtést, csak az értesítések generálását kezelik. Ha a küszöbérték túl alacsony (például hidegindítás 1 másodperc, miközben az eszközök 50%-a 3 másodperc alatt indul), a figyelmeztetések folyamatosan érkeznek, és „zajjá” válnak, amelyet a fejlesztők már nem vesznek észre. Állítsa be a küszöbértékeket az aktuális mutatók alapján, majd fokozatosan szigorítsa őket az alkalmazás optimalizálásával párhuzamosan.

Performance irányítópult a Firebase konzolban

A Performance irányítópult a kulcsmetrikákat idősorként jeleníti meg, az alkalmazás verziója, eszköz, ország, kapcsolattípus és operációsrendszer-verzió szerinti bontásban. Minden metrikához elérhető: átlag, medián, 95. percentilis, 99. percentilis. A 95. percentilis a leginformatívabb metrika a teljesítmény értékeléséhez, mivel megmutatja, hogy az alkalmazás hogyan teljesít „gyenge eszközökön”, figyelmen kívül hagyva a kiugró értékeket.

Az irányítópult támogatja a verziók összehasonlítását: válassza ki az alkalmazás két verzióját (aktuális és előző) a metrikák vizuális összehasonlításához. Ha a frissítés után a 95. percentilis indítási idő 2,1-ről 3,4 másodpercre nőtt — a regresszió egyértelmű, és meg kell találni a lassulást okozó commitot. A Firebase Performance integrálódik a GitHub, GitLab és Bitbucket rendszerekkel, lehetővé téve a metrikaváltozások összekapcsolását konkrét commitekkal.

Kódpéldák a Performance Monitoringhoz

Nézzük meg a Firebase Performance Monitoring integrációs példáit egy Kotlin nyelven írt Android-alkalmazásban. A kód bemutatja egy egyedi nyom létrehozását a hírfolyam betöltésének mérésére, egy HTTP-attribútum hozzáadását egy nem automatikusan elfogott kéréshez, valamint a Trace használatát a képfeldolgozás idejének mérésére. Minden példa figyelembe veszi a nyomkövetés Remote Config segítségével történő kikapcsolásának lehetőségét.

Használat előtt adja hozzá a függőséget: implementation("com.google.firebase:firebase-perf") a Firebase BOM-on keresztül. Az automatikus instrumentációhoz nincs szükség további konfigurációra — az SDK automatikusan elfogja a szabványos műveleteket a függőség csatlakoztatása után.

Egyedi nyom a hírfolyam betöltéséhez

Az első példa — a hírfolyam betöltési idejének mérése a szerverről. A nyom körülveszi az aszinkron fetchFeed műveletet, amely adatokat kér le a hálózatról és JSON-t elemez. A nyomhoz egyedi attribútumok lettek hozzáadva: adatforrás (cache vagy network) és a kapott bejegyzések száma. Ez lehetővé teszi az adatok szegmentálását és annak megértését, hogy milyen körülmények között töltődik a hírfolyam a leglassabban.

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

A loadFeedWithTrace függvény a source („cache” vagy „network”) paramétert fogadja, amely a nyom attribútumaként szolgál. Az aszinkron művelet befejezése után a nyom a finally blokkban leáll, garantálva a leállítást még kivétel esetén is. Az items_count metrika lehetővé teszi annak elemzését, hogy a bejegyzések száma hogyan befolyásolja a betöltési időt. A Firebase konzolban a nyomok a source attribútum szerint szűrhetők, és látható, hogy a hálózatról történő betöltés 3-szor lassabb, mint a gyorsítótárból.

HTTP-attribútum nem szabványos kéréshez

Második példa — HTTP-attribútum egy WebSocketen keresztül végrehajtott kéréshez (nem kerül automatikusan elfogásra). A HttpMetric osztály használatos, amely lehetővé teszi egy URL-kérés, annak metódusa, válaszkódja és méretének manuális regisztrálását. A Firebase ezt a kérést a Network Requests szakaszban jeleníti meg az automatikusan elfogott kérésekkel együtt.

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

A példában a sendWithHttpMetric a newHttpMetric segítségével regisztrál egy nem szabványos HTTP-hívást. Az SDK nem fogja el automatikusan, ezért a fejlesztő manuálisan állítja be az URL-t, a metódust, a válaszkódot és a méreteket. Fontos, hogy az URL-t lekérdezési paraméterek nélkül állítsa be (a biztonság és aggregáció érdekében) — azaz /data, ne /data?token=abc. A Firebase automatikusan csoportosítja a hasonló URL-mintákat.

Képfeldolgozási idő mérése

A harmadik példa a képfeldolgozás (tömörítés, méretváltoztatás) idejének mérését mutatja be egyedi nyom segítségével. Ebben az esetben a nyom egy szinkron műveletet vesz körül, de éles környezetben használjon korutinokat vagy RxJava-t, hogy ne blokkolja az UI szálat.

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
}

A compressImage függvény méri a kép JPEG formátumba tömörítésének idejét 80%-os minőséggel. A format attribútum lehetővé teszi a JPEG és WebP tömörítési idők jövőbeli összehasonlítását. Az output_size_kb metrika megmutatja, mennyire hatékony a tömörítés. A Firebase konzolban látható az eloszlás: gyenge eszközökön (budget Android) a tömörítés 4-szer tovább tart, mint a csúcskészülékeken, ami késedelmeket okozhat a képek szerverre küldésekor.

Hogyan javítsuk a teljesítményt az adatok alapján

A Firebase Performance adatokat szolgáltat, de nem ad kész megoldásokat. A metrikák elemzése megköveteli a teljesítményromlás tipikus okainak megértését minden metrika esetében. Tekintsük át a romlás fő mintázatait és diagnosztizálásuk módjait a Performance Monitoring adatai alapján. Megközelítés: találjon anomáliát a metrikában → ellenőrizze a tipikus okokat → alkalmazza az optimalizálást → ellenőrizze az eredményt egy hét múlva.

Lassú hidegindítás (> 2 másodperc): okok — nehéz SDK-inicializálás az Application.onCreate-ben (analitika, crash reporting, map SDK), nagy erőforrások betöltése (betűtípusok, témák), szinkron műveletek a főszálon induláskor. Megoldások: lusta SDK-inicializálás, késleltetett erőforrás-betöltés, SplashScreen API (Android 12+) használata helyőrző megjelenítéséhez az inicializálás alatt. A Firebase Performance megmutatja, melyik alkalmazásverzió kezdett lassabban indulni — ellenőrizze, milyen függőségek kerültek hozzáadásra vagy frissítésre.

Lassú képernyőmegjelenítés (> 500 ms): okok — összetett View-hierarchia (egymásba ágyazott ConstraintLayout, sok Fragment), adatok betöltése az UI szálon (hálózat vagy lemez), nehéz draw műveletek (nagy képek, egyedi View). Megoldások: layout hierarchia optimalizálása (Layout Inspector az Android Studio-ban), adatok áthelyezése a háttérszálra, képek gyorsítótárazása Glide vagy Coil segítségével. Használja a Screen Rendering szűrőt a Firebase-ben a leglassabb képernyő megtalálásához és annak elsőként történő optimalizálásához.

Hálózati kérések optimalizálása

Lassú HTTP-kérések (> 3 másodperc): okok — lassú szerver, nagy payloadok, gyorsítótárazás hiánya, nem optimális protokoll (HTTP/1.1 a HTTP/2 helyett), DNS-feloldás. Megoldások: ellenőrizze a szerveroldalt (uptime, latency), csökkentse a válasz méretét (lapozás, GraphQL, protobuf a JSON helyett), kapcsolja be a gyorsítótárazást HTTP-fejléceken keresztül (Cache-Control), használja az OkHttp Interceptort időtúllépések és újrapróbálkozási logika hozzáadásához.

A Firebase Performance megjeleníti a kérés időeloszlását: DNS-feloldás, TCP-kézfogás, TLS-kézfogás, kérés küldése, válasz fogadása. Ha az idő nagy része a DNS-re esik – használja a DNS előzetes betöltését (OkHttp DNS-over-HTTPS). Ha a TLS-re – használja a munkamenet-folytatást és a titkosítási csomagok beállítását. Ha a válasz fogadására – ellenőrizze a válasz méretét és a felhasználó hálózati sebességét. A Firebase adatai lehetővé teszik a probléma protokollszintű lokalizálását, nem csak azt, hogy „a kérés lassú”.

Remote Config integráció a nyomkövetés kikapcsolásához

Éles környezethez ajánlott hozzáadni egy performance_tracing_enabled Remote Config jelzőt, amely lehetővé teszi az egyedi nyomok távoli kikapcsolását. Ha a Firebase Performance SDK az kliens oldalon túl sok adatot generál vagy befolyásolja a teljesítményt (gyenge eszközökön), a nyomok kikapcsolhatók minden felhasználó számára, csak az automatikus metrikákat hagyva meg, amelyek minimális többletterheléssel rendelkeznek.

Logikai példa: az alkalmazás indításakor ellenőrizzük a Remote Config performance_tracing_enabled paramétert. Ha false — az összes Firebase.performance.newTrace() hívás egy stub objektumot ad vissza, amely nem gyűjt adatokat. Ez egy wrapper osztályon keresztül valósul meg, amely a nyom létrehozása előtt ellenőrzi a jelzőt. Ez a megközelítés lehetővé teszi a részletes nyomkövetést bizonyos felhasználók (bétatesztelők, fejlesztők) számára a teljes közönség befolyásolása nélkül.