Monitorowanie wydajności — co to jest, metryki i zbieranie danych

Co to jest monitorowanie wydajności

Monitorowanie wydajności to praktyka ilościowej oceny zachowania aplikacji poprzez zbieranie metryk czasu wykonania, wykorzystania pamięci, liczby klatek na sekundę i zużycia energii. W przeciwieństwie do raportowania crashy, które rejestruje tylko krytyczne awarie, monitorowanie wydajności śledzi stopniową degradację: aplikacja działa, ale wolniej niż powinna.

Według Google (2024), 53% użytkowników zamyka aplikację, jeśli ładuje się dłużej niż 3 sekundy. Każda dodatkowa sekunda opóźnienia zmniejsza konwersję średnio o 20% w różnych kategoriach. To sprawia, że monitorowanie wydajności jest nie tylko praktyką techniczną, ale koniecznością biznesową dla produktów mobilnych.

Nowoczesne monitorowanie wydajności obejmuje cztery poziomy: klient (iOS, Android), sieć (zapytania API, WebSocket), usługi backendowe i infrastruktura. W rozwoju aplikacji mobilnych nacisk kładzie się na metryki klienckie, ponieważ to właśnie na urządzeniu użytkownika pojawia się większość problemów z wydajnością.

Kluczowe metryki aplikacji mobilnej

Do pełnego monitorowania należy śledzić pięć grup metryk, z których każda odpowiada za inny aspekt doświadczenia użytkownika. FPS (frames per second) pokazuje płynność animacji i przewijania — wartość poniżej 30 klatek na sekundę jest odczuwalna jako spowolnienie.

Metryki czasu

Czas zimnego startu aplikacji — od momentu dotknięcia ikony do pełnej gotowości interfejsu. Czas gorącego startu — powrót z tła. Czas odpowiedzi na działanie użytkownika (tap-to-response). Czas uruchamiania dla Androida mierzony jest przez ActivityManager, dla iOS — przez dyld i czas premain. Według Firebase Performance, mediana czasu zimnego startu dla 100 najpopularniejszych aplikacji wynosi 1,8 sekundy.

Metryki pamięci i CPU

Zużycie pamięci RAM nie powinno przekraczać 80% dostępnego wolumenu na urządzeniu, w przeciwnym razie system zaczyna wyładowywać aplikację z tła. Ślad pamięciowy jest śledzony przez Xcode Instruments (iOS) i Android Profiler. Wycieki pamięci wykrywane są poprzez wzrost zużycia przy powtarzających się operacjach — na przykład przechodzeniu między ekranami.

Metryki sieciowe

Czas wykonania zapytania HTTP, rozmiar odpowiedzi, częstotliwość timeoutów i błędów. Opóźnienie sieciowe jest szczególnie krytyczne dla aplikacji mobilnych działających w warunkach niestabilnego połączenia (3G, metro, winda, roaming). Zaleca się śledzenie czasu odpowiedzi p95 — właśnie on pokazuje doświadczenie najbardziej „wymagających” użytkowników z najgorszymi warunkami sieciowymi.

Real User Monitoring i Synthetic Monitoring

Real User Monitoring (RUM) zbiera dane z rzeczywistych urządzeń użytkowników w środowisku produkcyjnym. Ta metoda pokazuje faktyczne opóźnienia, których doświadczają użytkownicy, biorąc pod uwagę ich urządzenia, wersje systemu operacyjnego, sieć i geolokalizację. RUM daje najdokładniejszy obraz wydajności, ale zależy od tego, jacy użytkownicy trafili do próbki.

Synthetic Monitoring natomiast wykonuje wcześniej zdefiniowane scenariusze na urządzeniach testowych w kontrolowanych warunkach. Pozwala wykryć regresję zanim trafi do użytkowników i odtwarzać problemy w jednolitym środowisku. Firebase Test Lab i BrowserStack udostępniają testy syntetyczne na rzeczywistych urządzeniach bez ręcznego uruchamiania.

Optymalna strategia to kombinacja obu podejść: testy syntetyczne wykrywają regresje na etapie CI, a RUM daje rzeczywisty obraz w produkcji. Według Datadog (2024), zespoły korzystające z obu metod wykrywają o 35% więcej problemów z wydajnością, zanim staną się incydentami.

Konfiguracja Firebase Performance Monitoring

Firebase Performance Monitoring to darmowe narzędzie od Google do zbierania metryk wydajności na iOS i Android. Automatycznie mierzy czas uruchamiania aplikacji, zapytania HTTP i renderowanie ekranów bez konieczności pisania kodu. Do instalacji wystarczy dodać SDK do projektu i aktywować moduł Performance w konsoli Firebase.

Automatyczne zbieranie metryk

Po podłączeniu SDK Firebase Performance automatycznie tworzy trace dla każdego zapytania HTTP przez URLSession (iOS) lub OkHttp (Android). Renderowanie ekranów jest mierzone dla UIViewController i Activity, rejestrując czas od onCreate/viewDidLoad do zakończenia pierwszego renderowania. Wszystkie metryki są agregowane w konsoli Firebase z podziałem na wersje aplikacji, urządzenia i kraje.

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())
        // przetwarzanie płatności
        trace.stop()
    }
}

Kod tworzy niestandardowy trace dla scenariusza płatności z atrybutem kwoty. Po tym tracie w konsoli Firebase można zobaczyć medianę i p95 czasu realizacji płatności, pogrupowane według wersji aplikacji i urządzeń.

Monitorowanie HTTP

Firebase automatycznie przechwytuje zapytania sieciowe i rejestruje URL, kod odpowiedzi, rozmiar payloadu i czas wykonania. Dla OkHttp na Androidzie automatyczna instrumentacja działa bez dodatkowej konfiguracji. Zapytania sieciowe są wyświetlane w konsoli z grupowaniem według endpointów, co pozwala szybko wykryć spowolnienie konkretnego API.

Niestandardowe trace dla logiki biznesowej

Standardowe metryki pokrywają ogólną wydajność, ale do diagnostyki procesów biznesowych wymagana jest instrumentacja konkretnych scenariuszy. Niestandardowe trace pozwalają zmierzyć czas wykonania uwierzytelniania, ładowania kanału wiadomości, przetwarzania obrazu lub synchronizacji danych.

Każdy niestandardowy trace powinien mieć znaczącą nazwę w formacie „scenariusz-działanie” i zawierać atrybuty do filtrowania. Na przykład trace „image-upload” z atrybutami „file_size” i „compression_quality” pozwoli wykryć zależność czasu ładowania od rozmiaru obrazu. Zaleca się nie tworzyć więcej niż 20 niestandardowych trace na jeden ekran — nadmierna instrumentacja tworzy szum i utrudnia analizę.

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")
    // ładowanie obrazu
    trace?.stop()
}

Przykład w Swift tworzy trace dla ładowania obrazu z atrybutami rozmiaru pliku i poziomu kompresji. W konsoli Firebase te atrybuty stają się polami do grupowania i filtrowania metryk.

Progi alarmowe i alerting

Zbieranie metryk bez systemu powiadomień jest bezużyteczne. Alerting powinien informować zespół o przekroczeniu dopuszczalnych granic metryk, przy czym progi alarmowe dzielą się na trzy poziomy: ostrzeżenie (warning), krytyczny (critical) i awaryjny (outage). Każdy poziom określa kanał powiadomienia: warning — na kanał Slack zespołu, critical — do PagerDuty dyżurnego inżyniera, outage — masowe powiadomienie wszystkich zainteresowanych.

Dla metryk mobilnych zaleca się stosowanie dynamicznych progów opartych na percentylach: p95 czasu zimnego startu przekracza 4 sekundy — alert krytyczny. Statyczne progi (np. CPU > 90%) działają gorzej, ponieważ nie uwzględniają normalnych wahań obciążenia w zależności od pory dnia i dnia tygodnia. Firebase Performance obsługuje konfigurację alertów przez Firebase Console z wysyłką do Slack, PagerDuty i poczty elektronicznej z możliwością eskalacji w przypadku braku potwierdzenia.

Według Incident Management Survey (2024), zespoły, które konfigurują alerty w oparciu o percentyle, a nie średnie, przegapiają o 45% mniej incydentów. Wartość średnia (average) wygładza skoki — p95 gwarantowanie pokazuje najgorszy scenariusz dla użytkowników, niezależnie od pory dnia i sezonowych wahań obciążenia.