Test wydajności w rozwoju aplikacji mobilnych: co to jest, metryki i jak przeprowadzać

Czym jest Performance Test?

Performance Test — to rodzaj testowania niefunkcjonalnego, który określa, jak szybko i efektywnie aplikacja wykonuje swoje zadania. W przeciwieństwie do testów jednostkowych lub UI, Performance Test mierzy cechy ilościowe: czas odpowiedzi, obciążenie procesora, zużycie pamięci RAM i pobór baterii. Według raportu Sauce Labs (2025), 68% zespołów tworzących aplikacje mobilne włącza Performance Test do regularnego cyklu testowania, a 41% automatyzuje go w CI.

Głównym celem Performance Test jest upewnienie się, że aplikacja spełnia wymagania dotyczące wydajności określone w specyfikacji. Jeśli czas uruchomienia ekranu przekracza 500 milisekund lub aplikacja zużywa więcej niż 200 MB pamięci RAM na średnim urządzeniu, jest to sygnał do optymalizacji. Linia bazowa wydajności jest ustalana na etapie pierwszej stabilnej wersji i weryfikowana przy każdej dużej aktualizacji.

Performance Test przeprowadza się na rzeczywistych urządzeniach, a nie na symulatorach, ponieważ emulacja nie daje dokładnego obrazu użycia CPU, GPU i zasobów sieciowych. Według Apple WWDC (2024), testy na symulatorze pokazują zawyżone wyniki w porównaniu z rzeczywistym urządzeniem o 15–30%. Rzeczywiste urządzenie pozostaje jedynym wiarygodnym źródłem danych o wydajności.

Regularność przeprowadzania Performance Test zależy od cyklu rozwoju. W zaleceniach Google Android Performance (2024) wskazano, że podstawowe pomiary wydajności powinny być uruchamiane przy każdym pull requeście, a pełny zestaw — przed każdym wydaniem wersji. Automatyzacja tych pomiarów pozwala wykrywać regresje wydajności na wczesnych etapach.

Kluczowe metryki wydajności

W rozwoju aplikacji mobilnych wyróżnia się pięć głównych metryk, które pokrywają 90% scenariuszy Performance Test. Czas uruchomienia (cold start i warm start) — pierwsza metryka sprawdzana przy każdej wersji. Google Play Console (2024) rejestruje czas uruchomienia według progów: zimny start nie powinien przekraczać 5 sekund, ciepły — 1,5 sekundy. Przekroczenie tych progów bezpośrednio wpływa na ocenę w sklepie z aplikacjami.

Czas uruchomienia (Cold Start)

Zimny start mierzony jest od momentu kliknięcia ikony do pojawienia się pierwszej klatki aplikacji. iOS używa `dispatch_async` do opóźnionej inicjalizacji, co skraca widoczny czas uruchomienia. Android zimny start obejmuje utworzenie procesu, inicjalizację Application i uruchomienie Activity. Według Google Performance (2024), każde 100 ms opóźnienia zimnego startu obniża Conversion Rate o 1,2% w aplikacjach e-commerce.

Częstotliwość klatek (FPS)

FPS (Frames Per Second) — częstotliwość klatek podczas animacji i przewijania list. Dla płynnego interfejsu wymagane jest stabilne 60 FPS. Android Studio Profiler i Xcode GPU Report pokazują spadki FPS przy ciężkich operacjach — ładowaniu obrazów, parsowaniu JSON lub renderowaniu złożonych układów. Spadek poniżej 30 FPS jest odczuwalny przez użytkownika jako „zacięcia” i prowadzi do obniżenia Retention Rate o 22% według Adjust (2025).

Zużycie pamięci RAM

Zużycie pamięci RAM — trzecia krytyczna metryka. Wycieki pamięci (memory leaks) — główna przyczyna spadku wydajności w długotrwałych sesjach. Instruments Allocations i Android Memory Profiler pomagają wykryć cykliczne referencje w Swift i niezwolnione Activity w Android. Pobór baterii — metryka często pomijana na etapie testowania. Według Apple Developer (2024), aplikacje o wysokim zużyciu energii są ograniczane w tle na iOS. Energy Log w Xcode rejestruje profil wattage aplikacji podczas sesji.

Rodzaje testowania wydajności

Testowanie obciążeniowe (Load Test) sprawdza zachowanie aplikacji pod oczekiwaną liczbą jednoczesnych użytkowników. Dla backendu mobilnego oznacza to symulację 1000–10000 jednoczesnych zapytań do API. Część serwerowa powinna obsługiwać szczytowe obciążenie bez zwiększania czasu odpowiedzi o więcej niż 20% od wartości bazowej. Według benchmarków k6 (2024), typowa konfiguracja Load Test obejmuje rampę od 0 do 1000 VU (wirtualnych użytkowników) w ciągu 5 minut.

Testowanie stresowe (Stress Test) określa punkt awarii aplikacji — moment, w którym system przestaje odpowiadać na zapytania lub degraduje w sposób nieakceptowalny. W przeciwieństwie do Load Test, Stress Test obciąża system powyżej normalnych limitów. Punkt awarii jest rejestrowany według jednego z kryteriów: czas odpowiedzi przekracza 10 sekund, odsetek błędów 5XX przekracza 5% lub zużycie pamięci RAM osiąga 90% dostępnej.

Testowanie objętościowe (Volume Test) ocenia zachowanie aplikacji podczas pracy z dużymi ilościami danych. W kontekście mobilnym jest to sprawdzenie pracy z tysiącami rekordów w lokalnej bazie danych, dziesiątkami gigabajtów pamięci podręcznej lub milionami powiadomień push. SQLite na Android i Core Data na iOS wykazują różną wydajność przy objętości powyżej 100000 rekordów.

Narzędzia do Performance Test

Xcode Instruments

Xcode Instruments — główne narzędzie do profilowania aplikacji iOS. Time Profiler pokazuje, które metody zużywają najwięcej CPU, a Allocations śledzi alokację i zwalnianie pamięci. Instruments obsługuje nagrywanie podczas długich sesji (do 30 minut) i eksport śladów do porównania między kompilacjami. Activity Monitor wewnątrz Instruments pokazuje ogólne obciążenie systemu w czasie rzeczywistym.

Android Studio Profiler

Android Studio Profiler — wbudowany profilator dla Androida. Łączy CPU, Memory, Network i Energy profilery w jeden interfejs. Cechą Android Profiler jest obsługa interaktywnych sesji: programista może wykonywać czynności w aplikacji i widzieć natychmiastową reakcję metryk. Według Google I/O (2024), Profiler obsługuje zapis w formacie .perf, który można porównywać z baseline w CI.

Charles Proxy

Charles Proxy i Proxyman — narzędzia do analizy ruchu sieciowego. Pokazują czas każdego zapytania HTTP, rozmiar odpowiedzi i nagłówki. Dla Performance Test ważne jest rejestrowanie zapytań, które wykonują się dłużej niż 500 ms — są to kandydaci do buforowania lub optymalizacji. Charles obsługuje tryb throttle symulujący wolne sieci: 3G, Edge i LTE. Proxyman — lżejsza alternatywa dla macOS z natywną architekturą Swift.

import XCTest

class PerformanceTests: XCTestCase {

    func testLaunchPerformance() {
        measure(metrics: [XCTClockMetric(),
                         XCTMemoryMetric()]) {
            XCUIApplication().launch()
        }
    }

    func testScrollPerformance() {
        let app = XCUIApplication()
        app.launch()
        let tableView = app.tables["list"]
        measure {
            tableView.swipeUp()
            tableView.swipeDown()
        }
    }
}

Performance Test w pipeline CI/CD

Wbudowanie Performance Test w CI/CD to standard branżowy na lata 2025–2026. Pipeline wydajności obejmuje trzy etapy: pre-commit (szybkie pomiary przy pull requeście), nightly (pełny zestaw testów) i pre-release (porównanie z baseline na referencyjnych urządzeniach). Bitrise i GitHub Actions obsługują uruchamianie Xcode Instruments CLI i Gradle Profiler.

GitHub Actions (2024) opublikował oficjalny szablon dla iOS Performance Test z użyciem `xcodebuild test-without-building`. Szablon uruchamia testy na jednej z maszyn GitHub i publikuje raport w artifact. Baseline jest przechowywany w pliku JSON w repozytorium: po przekroczeniu progu o 10% pipeline kończy się błędem. Takie podejście zapobiega degradacji wydajności bez ręcznego przeglądania każdej kompilacji.

Problemem mobilnego Performance Test w CI jest niestabilność wyników na różnych maszynach. Apple Silicon (M1–M4) i Intel Xeon dają różne czasy wykonania. Rozwiązaniem jest użycie stosunku procentowego do baseline, a nie wartości bezwzględnych. Jeśli test wykonuje się o 15% dłużej niż baseline — kompilacja jest oznaczana jako wymagająca sprawdzenia.

Pisanie Performance Test na iOS i Android

XCTest Performance na iOS używa metody `measure(metrics:)`, która uruchamia blok kodu 10 razy i zwraca statystyki: średnią, medianę, odchylenie standardowe. Do testowania wydajności bazy danych XCTest wygodnie jest użyć XCTMemoryMetric, który rejestruje szczytowe zużycie RAM. Próg jest ustawiany przez `XCTPerformanceReport` po zakończeniu testu.

Android Macrobenchmark — biblioteka od Google do pomiaru wydajności na poziomie aplikacji. Macrobenchmark uruchamia scenariusze użytkownika (uruchomienie Activity, przewijanie RecyclerView, otwieranie WebView) i mierzy czas wykonania. Baseline Profile — to zestaw klas i metod, które kompilator Android wstępnie optymalizuje. Google Play używa Baseline Profile do przyspieszenia pierwszego uruchomienia o 30%.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 5
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}

Oba podejścia — XCTest Performance i Android Macrobenchmark — używają tej samej koncepcji: wielokrotny pomiar z uśrednianiem i porównaniem z progiem. Wydajność nie może być sprowadzona do jednej liczby. Każde wydanie wersji powinno być opatrzone raportem wydajności zawierającym trendy metryk z ostatnich 5 kompilacji. Taki raport pozwala zespołowi zobaczyć degradację zanim zauważą ją użytkownicy.