Firebase Performance — ano ito, tool sa pagsubaybay at mga metrik

Ano ang Firebase Performance Monitoring?

Firebase Performance Monitoring ay isang cloud service ng Google na kumokolekta at nagpapakita ng mga metrik ng pagganap ng mga mobile application. Ang serbisyo ay bahagi ng Firebase toolset at hindi nangangailangan ng hiwalay na pagbabayad — ang pagsubaybay ay available sa loob ng libreng Spark tier (limitasyon ng 500,000 event bawat araw) at bayad na Blaze tier. Awtomatikong bumubuo ang Firebase Performance ng mga trace para sa mga karaniwang senaryo: cold start ng screen, warm start, background HTTP request.

Ang arkitektura ng serbisyo ay binuo sa dalawang uri ng data: traces (mga bakas) at metrics (mga metrik). Ang trace ay isang time interval na may simula at wakas, kung saan sinusukat ang tagal ng pagpapatupad. Ang metrik ay isang numerikong halaga: laki ng tugon, dalas ng error, bilis sa bytes/seg. Ang bawat trace ay maaaring maglaman ng maraming metrik. Kinokolekta ng SDK ang data sa device, ini-buffer ang mga ito, at ipinapadala sa Firebase sa background na may mababang latency priority upang hindi makaapekto sa karanasan ng user.

Ayon sa ulat ng Google I/O 2024, ang Firebase Performance ay ginagamit sa higit sa 2 milyong application sa buong mundo. Ang average na oras upang matukoy ang isang problema sa pagganap gamit ang Firebase Performance ay 15 minuto pagkatapos ng release, kung naka-configure ang mga alert. Kung walang pagsubaybay, ang isang katulad na problema ay natutukoy sa average pagkatapos ng 2-3 araw batay sa mga reklamo ng user sa suporta.

Pagkakaiba sa Firebase Crashlytics

Crashlytics ay sumusubaybay sa mga crash at fatal error — mga sitwasyon kung saan biglang humihinto ang application. Ang Firebase Performance ay sumusubaybay sa pagganap ng tumatakbong application: mabagal na screen, mahabang network request, pagkaantala ng tugon ng UI. Sinasagot ng Crashlytics ang tanong na “bakit nag-crash ang application?”, habang sinasagot naman ng Performance ang tanong na “bakit mabagal ang application?”. Ang parehong serbisyo ay isinasama sa pamamagitan ng isang SDK (Firebase Core) at ang data ay ipinapakita sa mga kaugnay na seksyon ng Firebase console.

Mga metrik ng percentile

Ang Firebase Performance ay hindi nagpapakita ng mga average na halaga — tanging percentile: P50, P75, P90, P95, P99. Ito ay kritikal para sa pagganap: ang average na oras ay nagtatago ng mga outlier. Kung 99 na user ang nagbukas ng screen sa loob ng 200 ms, at isa sa 20 segundo, ang average ay magiging ~400 ms, na mukhang katanggap-tanggap. Ang P99 ay magpapakita ng 20 segundo — ang tunay na problema. Ipinapakita ng Firebase ang mga percentile sa isang timeline, na nagbibigay-daan sa pagsubaybay ng mga regression na may katumpakan hanggang isang oras.

Paano gumagana ang Firebase Performance Monitoring

Firebase Performance SDK ay isinasama sa application sa pamamagitan ng standard integration: pagdaragdag ng dependency sa Gradle (Android) o sa pamamagitan ng CocoaPods (iOS). Pagkatapos ng pagsisimula ng Firebase sa code, awtomatikong magsisimula ang SDK ng pagkolekta ng metrik nang walang karagdagang configuration. Isang mahalagang prinsipyo ng pagpapatakbo — lazy collection: hindi agad ipinapadala ng SDK ang data, kundi iniipon ang mga ito at ipinapadala nang pa-batch kapag paborable ang kondisyon ng network.

Para sa iOS, ginagamit ng SDK ang NSURLProtocol para sa pag-intercept ng mga HTTP request, para sa Android — OkHttp Interceptor. Kung hindi gumagamit ng OkHttp ang application, awtomatikong binabalot ng SDK ang HttpURLConnection. Ang mga nai-intercept na request ay pinayayaman ng metadata: Content-Type, status ng tugon, laki sa bytes, tagal. Lahat ng data ay ipinapadala sa pamamagitan ng HTTPS papunta sa Firebase server na may TLS 1.3 encryption.

Isa sa mga pangunahing kinakailangan ng Firebase Performance — maging huling plugin sa listahan ng mga Gradle plugin. Kung nilabag ang pagkakasunod-sunod, maaaring hindi ma-intercept ng SDK ang lahat ng request o hindi tama ang pagsukat ng oras ng pagsisimula. Inirerekomenda ng Firebase na ilagay ang plugin sa dulo ng plugins block, pagkatapos ng Crashlytics at iba pang Google Services plugin.

// build.gradle (Module: app) — tamang pagkakasunud-sunod ng mga plugin
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"  // panghuli!
}

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

Mga awtomatikong trace: screen, pagsisimula, network

Firebase Performance ay lumilikha ng tatlong uri ng awtomatikong trace: screen trace (oras ng pag-render ng screen), app start trace (oras ng pagsisimula ng application), at network request trace (mga HTTP request). Ang screen trace para sa Android ay sumusukat ng oras sa pagitan ng tawag sa Activity.onCreate at pagkumpleto ng pag-render ng unang frame. Para sa iOS, sinusukat ang oras sa pagitan ng viewDidLoad at viewDidAppear. Awtomatikong lumilikha ang Firebase ng trace para sa bawat screen, gamit ang pangalan ng klase ng Activity o ViewController.

App start trace ay nahahati sa dalawang uri: cold start (magsisimula ang application mula sa simula, wala pang proseso) at warm start (ibinabalik ang application mula sa background status). Ang cold start ay ang pinakamahalagang indicator dahil kasama rito ang pagsisimula ng lahat ng SDK, pag-load ng mga DEX file, at paggawa ng unang Activity. Sinusukat ng Firebase ang cold start mula sa sandaling magsimula ang proseso hanggang sa kumpletong pag-render ng unang screen. Ayon sa mga rekomendasyon ng Google, ang cold start ay hindi dapat lumampas sa 500 ms para sa P50 at 2 segundo para sa P99.

Network request trace ay awtomatikong nagtatala ng bawat HTTP request na may metadata: URL, paraan, code ng tugon, laki ng tugon, bilis ng paglipat. Sa Firebase Performance console, maaaring i-filter ang mga request ayon sa URL pattern — halimbawa, ipakita ang lahat ng request sa /api/v2/orders. Para sa bawat pattern, ipinapakita ang mga percentile ng oras ng tugon at dalas ng error na 4xx/5xx. Ito ay nagbibigay-daan sa mabilis na pagtuklas ng degradasyon ng isang partikular na API nang hindi nagko-configure ng hiwalay na mga alert.

Mga metrik ng screen nang detalyado

Para sa mga screen, kinakalkula rin ng Firebase Performance ang metrik na “frozen frames” — mga frame na nag-render nang mas matagal sa 700 ms. Ang ganitong mga pag-freeze ng UI ay nararanasan ng user bilang “nag-freeze ang application”. Kung ang isang screen ay may higit sa 1% frozen frames, minamarkahan ng Firebase ang metrik bilang problematiko. Para sa Android, kinokolekta rin ng SDK ang metrik na slow renders — mga frame na mas mahaba sa 16 ms (pagpalampas ng 60 FPS). Ang kombinasyon ng screen trace at frozen frames ay nagbibigay ng kumpletong larawan ng parehong oras ng pag-load at kinis ng mga animation.

Mga custom na trace para sa mga business scenario

Mga custom na trace ay nagbibigay-daan sa pagsukat ng tagal ng anumang user scenario: pag-order, pag-upload ng imahe sa cloud, pag-sync ng data. Ang developer ay tahasang nagpapahiwatig ng simula at wakas ng trace sa code at nagbibigay ng pangalan sa scenario. Hindi tulad ng mga awtomatikong trace, ang mga custom na trace ay nagbibigay ng ganap na kontrol sa kung ano ang sinusukat at nagbibigay-daan sa pagdaragdag ng mga attribute para sa pag-filter.

Ang bawat custom na trace ay maaaring maglaman ng attribute — mga pares ng key-value na idinaragdag bilang metadata. Ang mga attribute ay tumutulong sa pag-segment ng data: halimbawa, ang oras ng pag-order ay maaaring subaybayan nang hiwalay para sa “promo_user” at “regular_user”. Ang Firebase Performance ay sumusuporta ng hanggang 5 attribute bawat trace at hanggang 100 natatanging halaga ng attribute. Ang mga attribute ay ini-index at available para sa pag-filter sa Firebase console.

Ayon sa ulat ng Google I/O 2024, ang Spotify team ay gumagamit ng Firebase custom trace para sa pagsubaybay sa oras ng paglipat sa pagitan ng mga track. Ito ay nagbigay-daan upang bawasan ang median na oras ng paglipat mula 400 ms hanggang 120 ms sa pamamagitan ng pagtukoy ng bottleneck sa audio buffer cache. Ang pangunahing insight ay ang pag-filter ayon sa attribute na “device_model” — ang problema ay lumitaw lamang sa mga Samsung device na may 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()

        // Pagpapatupad ng scenario ng pag-order
        validateCart()
        processPayment()
        confirmOrder()

        trace.stop()
    }
}

Pagsasama ng Firebase Performance sa Android project

Ang pagsasama ng Firebase Performance sa Android ay nangangailangan ng tatlong hakbang: pagdaragdag ng google-services plugin, pagkonekta ng Firebase BOM (Bill of Materials), at pagdaragdag ng firebase-perf dependency. Awtomatikong gumagana ang Firebase Performance sa lahat ng Activity at fragment kung gumagamit sila ng AppCompatActivity. Para sa mga Compose screen, inirerekomenda ng Firebase ang paggamit ng mga custom na trace dahil hindi direktang sinusuportahan ng awtomatikong screen trace ang Compose.

Isang mahalagang nuance: binabago ng Firebase Performance Gradle plugin ang bytecode ng application sa yugto ng compilation. Ang plugin ay nagdaragdag ng instrumenting code sa bawat Activity at OkHttp client. Maaari nitong dagdagan ang oras ng build ng 5-10% at laki ng APK ng 200-400 KB. Sa mga debug build, awtomatikong nadi-disable ang Firebase Performance — pinoprotektahan nito laban sa pagbaluktot ng mga metrik sa panahon ng lokal na pag-develop. Para sa sapilitang pag-enable sa debug, ginagamit ang flag na firebasePerformanceInstrumentationEnabled sa manifest.

Sinusuportahan din ng Firebase Performance ang MetricKit para sa iOS at Perfetto para sa Android — mga mababang antas na system tracer. Ang MetricKit ay nagbibigay ng data tungkol sa frame rate, pagkonsumo ng CPU at memory sa antas ng operating system. Ina-aggregate ng Firebase ang data na ito at ipinapakita sa parehong console kung saan ipinapakita ang mga HTTP trace at screen traces, na pinagsasama ang system at application telemetry sa isang interface.

Mga HTTP request gamit ang 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 */ }
})

Pagsasama ng Firebase Performance sa iOS project

Para sa iOS, ang pagsasama ng Firebase Performance ay ginagawa sa pamamagitan ng CocoaPods o Swift Package Manager. Pagkatapos i-install ang mga pod na FirebasePerformance at FirebaseCore, awtomatikong magsisimula ang SDK ng pagkolekta ng metrik. Para sa pag-intercept ng mga HTTP request, ginagamit ng Firebase Performance iOS ang NSURLProtocol — isang system mechanism na nagbibigay-daan sa pag-intercept ng lahat ng URL load sa application. Nirerehistro ng SDK ang sarili nitong NSURLProtocol subclass sa pagsisimula, at lahat ng request sa pamamagitan ng URLSession ay awtomatikong napapasailalim sa pagsubaybay.

Limitasyon para sa iOS: Hindi sinusuportahan ng Firebase Performance ang awtomatikong screen trace para sa SwiftUI. Para sa mga SwiftUI application, kinakailangan na manu-manong gumawa ng mga custom na trace sa pamamagitan ng pagbalot ng body ng View sa isang start/stop block. Ang Firebase ay gumagawa sa native na suporta para sa SwiftUI, ngunit sa kasalukuyan ang SDK ay awtomatikong sumusubaybay lamang ng mga UIView controller. Para sa mga hybrid na application sa UIKit + SwiftUI, inirerekomenda na gumawa ng mga screen sa UIKit at i-embed ang SwiftUI sa pamamagitan ng UIHostingController.

Ang Firebase Performance iOS ay nagbibigay din ng integration sa MetricKit — ang Apple framework na kumokolekta ng diagnostic data sa antas ng OS. Ang MetricKit ay nagpapadala ng araw-araw na ulat na may mga metrik ng CPU, GPU, memory, at frame rate. Ina-aggregate ng Firebase Performance ang mga ulat na ito at ipinapakita sa console sa tabi ng mga custom na trace, na nagbibigay ng kumpletong larawan ng pagganap pareho sa antas ng application at sa antas ng system.

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