Prestandaövervakning — vad det är, mätvärden och datainsamling

Vad är prestandaövervakning

Prestandaövervakning är praktiken att kvantitativt bedöma applikationens beteende genom att samla in mätvärden för exekveringstid, minnesanvändning, bildfrekvens och energiförbrukning. Till skillnad från kraschrapportering, som endast registrerar allvarliga fel, spårar prestandaövervakning gradvis försämring: applikationen fungerar men långsammare än den borde.

Enligt Google (2024) stänger 53 % av användarna appen om den laddar längre än 3 sekunder. Varje extra sekunds fördröjning minskar konverteringen med i genomsnitt 20 % per kategori. Detta gör prestandaövervakning inte bara till en teknisk praxis utan en affärsnödvändighet för mobilprodukter.

Modern prestandaövervakning täcker fyra nivåer: klientsidan (iOS, Android), nätverk (API-anrop, WebSocket), backend-tjänster och infrastruktur. Inom mobilutveckling ligger fokus på klientmätvärden eftersom de flesta prestandaproblem uppstår precis på användarens enhet.

Nyckelmätvärden för mobilappar

För fullständig övervakning måste fem grupper av mätvärden följas, var och en ansvarig för en aspekt av användarupplevelsen. FPS (frames per second) visar smidigheten i animationer och scrollning — ett värde under 30 bilder per sekund upplevs som fördröjning.

Tidsmätvärden

Kallstartstid för appen — från att ikonen trycks ned till att gränssnittet är helt klart. Varmstartstid — återkomst från bakgrunden. Svarstid på användaråtgärd (tap-to-response). Starttid för Android mäts via ActivityManager, för iOS — via dyld och premain-tid. Enligt Firebase Performance är den median kalla starttiden för topp-100-appar 1,8 sekunder.

Minnes- och CPU-mätvärden

RAM-förbrukningen bör inte överstiga 80 % av den tillgängliga volymen på enheten, annars börjar systemet avlasta appen från bakgrunden. Minnesavtryck spåras via Xcode Instruments (iOS) och Android Profiler. Minnesläckor upptäcks genom ökande förbrukning vid upprepade operationer — till exempel navigering mellan skärmar.

Nätverksmätvärden

Exekveringstid för HTTP-begäran, svarsstorlek, frekvens av timeouts och fel. Nätverksfördröjning är särskilt kritisk för mobilappar som arbetar under instabila anslutningsförhållanden (3G, tunnelbana, hiss, roaming). Det rekommenderas att följa p95-svarstiden — den visar precis upplevelsen för de ”tyngsta” användarna med de sämsta nätverksförhållandena.

Real User Monitoring och Synthetic Monitoring

Real User Monitoring (RUM) samlar in data från verkliga användarenheter i produktionsmiljön. Denna metod visar de faktiska fördröjningar som användarna upplever, med hänsyn till deras enheter, OS-versioner, nätverk och geolokalisering. RUM ger den mest exakta bilden av prestanda men beror på vilka användare som ingår i urvalet.

Synthetic Monitoring utför däremot fördefinierade scenarier på testenheter under kontrollerade förhållanden. Det gör det möjligt att upptäcka regression innan den når användarna och återskapa problem i samma miljö. Firebase Test Lab och BrowserStack tillhandahåller syntetiska tester på verkliga enheter utan manuell start.

Den optimala strategin är en kombination av båda metoderna: syntetiska tester fångar regressioner i CI-fasen och RUM ger den verkliga bilden i produktion. Enligt Datadog (2024) upptäcker team som använder båda metoderna 35 % fler prestandaproblem innan de blir incidenter.

Konfigurera Firebase Performance Monitoring

Firebase Performance Monitoring är ett gratis verktyg från Google för att samla in prestandamätvärden på iOS och Android. Det mäter automatiskt appens starttid, HTTP-begäranden och skärmrendering utan att du behöver skriva kod. För installation räcker det att lägga till SDK i projektet och aktivera Performance-modulen i Firebase-konsolen.

Automatisk insamling av mätvärden

Efter anslutning av SDK skapar Firebase Performance automatiskt ett trace för varje HTTP-begäran via URLSession (iOS) eller OkHttp (Android). Skärmrendering mäts för UIViewController och Activity, och registrerar tiden från onCreate/viewDidLoad till slutförandet av första renderingen. Alla mätvärden aggregeras i Firebase-konsolen uppdelade efter appversioner, enheter och länder.

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

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // betalningsgenomförande
        trace.stop()
    }
}

Koden skapar ett anpassat trace för betalningsscenariot med ett attribut för beloppet. Via detta trace i Firebase-konsolen kan du se median och p95 för betalningens exekveringstid, grupperat efter appversioner och enheter.

HTTP-övervakning

Firebase fångar automatiskt nätverksbegäranden och registrerar URL, svarskod, payload-storlek och exekveringstid. För OkHttp på Android fungerar automatisk instrumentering utan extra konfiguration. Nätverksbegäranden visas i konsolen med gruppering efter slutpunkter, vilket gör att du snabbt kan upptäcka fördröjning av ett specifikt API.

Anpassade trace för affärslogik

Standardmätvärden täcker allmän prestanda, men för diagnos av affärsprocesser krävs instrumentering av specifika scenarier. Anpassade trace gör det möjligt att mäta exekveringstiden för autentisering, laddning av nyhetsflöde, bildbehandling eller datasynkronisering.

Varje anpassat trace bör ha ett meningsfullt namn i formatet ”scenario-åtgärd” och innehålla attribut för filtrering. Till exempel skulle ett trace ”image-upload” med attributen ”file_size” och ”compression_quality” göra det möjligt att upptäcka beroendet av laddningstid på bildstorlek. Det rekommenderas att inte skapa fler än 20 anpassade trace per skärm — överdriven instrumentering skapar brus och försvårar analys.

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // bildladdning
    trace?.stop()
}

Exemplet i Swift skapar ett trace för bildladdning med attribut för filstorlek och kompressionsnivå. I Firebase-konsolen blir dessa attribut fält för gruppering och filtrering av mätvärden.

Tröskelvärden och larm

Att samla in mätvärden utan ett larmsystem är värdelöst. Larm bör informera teamet när mätvärden överskrider tillåtna gränser, där tröskelvärdena är indelade i tre nivåer: varning (warning), kritisk (critical) och driftstopp (outage). Varje nivå bestämmer larmkanalen: warning — till teamets Slack-kanal, critical — till jourhavande ingenjörens PagerDuty, outage — massutskick till alla intressenter.

För mobila mätvärden rekommenderas dynamiska tröskelvärden baserade på percentiler: p95 för kallstart överstiger 4 sekunder — kritiskt larm. Statiska tröskelvärden (t.ex. CPU > 90 %) fungerar sämre eftersom de inte tar hänsyn till normala belastningsfluktuationer beroende på tid på dagen och veckodag. Firebase Performance stöder konfigurering av larm via Firebase Console med utskick till Slack, PagerDuty och e-post, med möjlighet till eskalering om bekräftelse uteblir.

Enligt Incident Management Survey (2024) missar team som konfigurerar larm baserat på percentiler istället för medelvärden 45 % färre incidenter. Medelvärdet (average) jämnar ut toppar — p95 visar garanterat det värsta scenariot för användarna, oavsett tid på dagen och säsongsbundna belastningsfluktuationer.