Firebase Performance — o que é, ferramenta de monitoramento e métricas

O que é o Firebase Performance Monitoring?

Firebase Performance Monitoring é um serviço em nuvem do Google que coleta e exibe métricas de desempenho de aplicativos móveis. O serviço faz parte do conjunto de ferramentas Firebase e não requer pagamento separado — o monitoramento está disponível no nível gratuito Spark (limite de 500.000 eventos por dia) e no nível pago Blaze. O Firebase Performance gera automaticamente traces para cenários padrão: início frio de tela, início morno, requisições HTTP em segundo plano.

A arquitetura do serviço é baseada em dois tipos de dados: traces e metrics (métricas). Um trace é um intervalo de tempo com início e fim, dentro do qual a duração da execução é medida. Uma métrica é um valor numérico: tamanho da resposta, taxa de erros, velocidade em bytes/seg. Cada trace pode conter várias métricas. O SDK coleta dados no dispositivo, os armazena em buffer e os envia para o Firebase em segundo plano com prioridade de baixa latência para não afetar a experiência do usuário.

De acordo com o relatório do Google I/O 2024, o Firebase Performance é usado em mais de 2 milhões de aplicativos em todo o mundo. O tempo médio para detectar um problema de desempenho usando o Firebase Performance é de 15 minutos após o lançamento se os alertas estiverem configurados. Sem monitoramento, um problema semelhante é tipicamente detectado em 2-3 dias através de reclamações de usuários ao suporte.

Diferença do Firebase Crashlytics

Crashlytics rastreia quedas e erros fatais — situações em que o aplicativo termina inesperadamente. O Firebase Performance monitora o desempenho em um aplicativo em execução: telas lentas, requisições de rede longas, atrasos na resposta da UI. O Crashlytics responde à pergunta "por que o aplicativo caiu?", enquanto o Performance responde "por que o aplicativo está lento?". Ambos os serviços se integram através de um único SDK (Firebase Core) e os dados são exibidos em seções adjacentes do console Firebase.

Métricas de percentis

Firebase Performance não mostra valores médios — apenas percentis: P50, P75, P90, P95, P99. Isso é crítico para o desempenho: o tempo médio esconde valores atípicos. Se 99 usuários abrem uma tela em 200 ms e um a abre em 20 segundos, a média seria ~400 ms, o que parece aceitável. O P99 mostrará 20 segundos — o problema real. O Firebase exibe os percentis em uma linha do tempo, permitindo rastrear regressões com precisão de hora.

Como o Firebase Performance Monitoring funciona

Firebase Performance SDK é integrado em um aplicativo através de integração padrão: adicionando uma dependência no Gradle (Android) ou via CocoaPods (iOS). Após a inicialização do Firebase no código, o SDK começa automaticamente a coletar métricas sem configuração adicional. Um princípio importante é a coleta lazy: o SDK não envia dados imediatamente, mas os acumula e os transmite em lotes sob condições de rede favoráveis.

Para iOS, o SDK usa NSURLProtocol para interceptar requisições HTTP; para Android — OkHttp Interceptor. Se o aplicativo não usa OkHttp, o SDK automaticamente encapsula HttpURLConnection. As requisições interceptadas são enriquecidas com metadados: Content-Type, status da resposta, tamanho em bytes, duração. Todos os dados são transmitidos via HTTPS para o servidor Firebase com criptografia TLS 1.3.

Um dos requisitos principais do Firebase Performance é ser o último plugin na lista de plugins do Gradle. Se a ordem for violada, o SDK pode não interceptar todas as requisições ou medir incorretamente o tempo de inicialização. O Firebase recomenda colocar o plugin no final do bloco de plugins, após o Crashlytics e outros plugins do Google Services.

// build.gradle (Module: app) — ordem correta dos plugins
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"  // último!
}

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

Traces automáticos: telas, inicialização, rede

Firebase Performance cria três tipos de traces automáticos: screen trace (tempo de renderização de tela), app start trace (tempo de inicialização do aplicativo) e network request trace (requisições HTTP). O screen trace para Android mede o tempo entre a chamada Activity.onCreate e a conclusão da renderização do primeiro quadro. Para iOS, o tempo entre viewDidLoad e viewDidAppear é medido. O Firebase cria automaticamente um trace para cada tela, usando o nome da classe Activity ou ViewController.

App start trace é dividido em dois tipos: início frio (o aplicativo inicia do zero, o processo não existia) e início morno (o aplicativo é restaurado do estado de segundo plano). O início frio é a métrica mais crítica porque inclui a inicialização de todos os SDKs, carregamento de arquivos DEX e criação da primeira Activity. O Firebase mede o início frio desde o momento em que o processo começa até a renderização completa da primeira tela. De acordo com as recomendações do Google, o início frio não deve exceder 500 ms para P50 e 2 segundos para P99.

Network request trace registra automaticamente cada requisição HTTP com metadados: URL, método, código de resposta, tamanho da resposta, velocidade de transferência. No console do Firebase Performance, você pode filtrar requisições por padrão de URL — por exemplo, mostrar todas as requisições para /api/v2/orders. Para cada padrão, são exibidos os percentis de tempo de resposta e as taxas de erro 4xx/5xx. Isso permite detectar rapidamente a degradação de uma API específica sem configurar alertas individuais.

Métricas de tela em detalhes

Para telas, o Firebase Performance calcula adicionalmente a métrica "frozen frames" — quadros que levaram mais de 700 ms para renderizar. Esses congelamentos de UI são percebidos pelo usuário como "o aplicativo congelou". Se uma tela tem mais de 1% de frozen frames, o Firebase marca a métrica como problemática. Para Android, o SDK coleta adicionalmente a métrica de slow renders — quadros com mais de 16 ms (perdendo 60 FPS). A combinação de screen trace e frozen frames fornece uma imagem completa tanto do tempo de carregamento quanto da suavidade das animações.

Traces personalizados para cenários de negócio

Traces personalizados permitem medir a duração de qualquer cenário de usuário: fazer um pedido, enviar uma imagem para a nuvem, sincronizar dados. O desenvolvedor especifica explicitamente o início e o fim do trace no código e define o nome do cenário. Ao contrário dos traces automáticos, os traces personalizados fornecem controle total sobre o que é medido e permitem adicionar atributos para filtragem.

Cada trace personalizado pode conter atributos — pares chave-valor que são adicionados como metadados. Os atributos ajudam a segmentar os dados: por exemplo, você pode rastrear o tempo de finalização da compra separadamente para "promo_user" e "regular_user". O Firebase Performance suporta até 5 atributos por trace e até 100 valores de atributo únicos. Os atributos são indexados e estão disponíveis para filtragem no console do Firebase.

De acordo com a apresentação do Google I/O 2024, a equipe do Spotify usa traces personalizados do Firebase para monitorar o tempo de troca entre faixas. Isso ajudou a reduzir o tempo médio de troca de 400 ms para 120 ms ao identificar um gargalo no cache do buffer de áudio. A percepção principal veio da filtragem pelo atributo "device_model" — o problema se manifestava apenas em dispositivos Samsung com 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()

        // Executando o cenário de finalização da compra
        validateCart()
        processPayment()
        confirmOrder()

        trace.stop()
    }
}

Integração do Firebase Performance em um projeto Android

A integração do Firebase Performance no Android requer três etapas: adicionar o plugin google-services, conectar o BOM (Bill of Materials) do Firebase e adicionar a dependência firebase-perf. O Firebase Performance funciona automaticamente em todas as Activities e fragmentos se eles usarem AppCompatActivity. Para telas Compose, o Firebase recomenda usar traces personalizados, pois o screen trace automático não suporta Compose diretamente.

Uma nuance importante: o plugin Gradle do Firebase Performance modifica o bytecode do aplicativo no momento da compilação. O plugin adiciona código de instrumentação a cada Activity e cliente OkHttp. Isso pode aumentar o tempo de compilação em 5-10% e o tamanho do APK em 200-400 KB. Em compilações de depuração, o Firebase Performance é desativado automaticamente — isso evita a distorção de métricas durante o desenvolvimento local. Para ativação forçada em depuração, use a flag firebasePerformanceInstrumentationEnabled no manifesto.

Firebase Performance também suporta MetricKit para iOS e Perfetto para Android — rastreadores de sistema de baixo nível. O MetricKit fornece dados sobre taxa de quadros, uso de CPU e memória no nível do sistema operacional. O Firebase agrega esses dados e os exibe no mesmo console onde os traces HTTP e screen traces são mostrados, combinando telemetria de sistema e aplicativo em uma única interface.

Requisições HTTP com 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 */ }
})

Integração do Firebase Performance em um projeto iOS

Para iOS, a integração do Firebase Performance é feita através de CocoaPods ou Swift Package Manager. Após instalar os pods FirebasePerformance e FirebaseCore, o SDK começa automaticamente a coletar métricas. Para interceptar requisições HTTP, o Firebase Performance iOS usa NSURLProtocol — um mecanismo do sistema que permite interceptar todos os carregamentos de URL no aplicativo. O SDK registra sua subclasse de NSURLProtocol na inicialização, e todas as requisições através de URLSession caem automaticamente sob monitoramento.

Limitação para iOS: o Firebase Performance não suporta screen trace automático para SwiftUI. Para aplicativos SwiftUI, você deve criar manualmente traces personalizados envolvendo o corpo da View em um bloco de início/fim. O Firebase está trabalhando no suporte nativo ao SwiftUI, mas atualmente o SDK rastreia automaticamente apenas controladores UIView. Para aplicativos híbridos em UIKit + SwiftUI, é recomendado criar telas em UIKit e incorporar SwiftUI através de UIHostingController.

Firebase Performance iOS também fornece integração com MetricKit — um framework da Apple que coleta dados de diagnóstico no nível do SO. O MetricKit envia relatórios diários com métricas de CPU, GPU, memória e taxa de quadros. O Firebase Performance agrega esses relatórios e os exibe no console juntamente com traces personalizados, fornecendo uma imagem completa do desempenho tanto no nível do aplicativo quanto do sistema.

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