Teljesítményteszt a mobilfejlesztésben: mi ez, mérőszámok és hogyan történik

Mi az a teljesítményteszt?

A teljesítményteszt a nem funkcionális tesztelés egy típusa, amely meghatározza, hogy az alkalmazás milyen gyorsan és hatékonyan végzi el feladatait. Ellentétben az egységtesztekkel vagy UI-tesztekkel, a teljesítményteszt mennyiségi jellemzőket mér: válaszidő, processzor terhelés, RAM-fogyasztás és akkumulátor-fogyasztás. A Sauce Labs (2025) jelentése szerint a mobilfejlesztő csapatok 68%-a beépíti a teljesítménytesztet a rendszeres tesztelési ciklusba, és 41%-a automatizálja azt CI-ben.

A teljesítményteszt fő célja annak biztosítása, hogy az alkalmazás megfeleljen a specifikációban rögzített teljesítménykövetelményeknek. Ha a képernyő megnyitásának ideje meghaladja az 500 milliszekundumot, vagy az alkalmazás több mint 200 MB RAM-ot fogyaszt egy átlagos eszközön, ez optimalizálási jelzés. Az alapvonal teljesítményét az első stabil kiadás szakaszában állapítják meg, és minden nagyobb frissítéskor felülvizsgálják.

A teljesítménytesztet valós eszközökön végzik, nem szimulátorokon, mert az emuláció nem ad pontos képet a CPU, GPU és hálózati erőforrások használatáról. Az Apple WWDC (2024) szerint a szimulátoron végzett tesztek 15-30%-kal magasabb eredményeket mutatnak a valós eszközhöz képest. A valós eszköz marad az egyetlen megbízható teljesítményadat-forrás.

A teljesítményteszt végrehajtásának rendszeressége a fejlesztési ciklustól függ. A Google Android Performance (2024) ajánlásaiban szerepel, hogy az alapvető teljesítményméréseket minden pull request-nél, a teljes készletet pedig minden kiadás előtt kell futtatni. E mérések automatizálása lehetővé teszi a teljesítményregressziók korai szakaszban történő észlelését.

Kulcsfontosságú teljesítménymérőszámok

A mobilfejlesztésben öt fő mérőszámot különböztetünk meg, amelyek a teljesítményteszt-forgatókönyvek 90%-át lefedik. Indítási idő (cold start és warm start) — az első mérőszám, amelyet minden kiadásnál ellenőriznek. A Google Play Console (2024) az indítási időt küszöbértékek szerint rögzíti: a cold start nem haladhatja meg az 5 másodpercet, a warm start az 1,5 másodpercet. E küszöbértékek túllépése közvetlenül befolyásolja az alkalmazásbolti értékelést.

Indítási idő (Cold Start)

A cold start mérése az ikonra kattintástól az alkalmazás első képkockájának megjelenéséig tart. Az iOS a `dispatch_async` használatával késlelteti az inicializálást, ami lerövidíti a látható indítási időt. Az Android cold start magában foglalja a folyamat létrehozását, az Application inicializálását és az Activity elindítását. A Google Performance (2024) szerint a cold start minden 100 ms-os késése 1,2%-kal csökkenti a konverziós arányt az e-kereskedelmi alkalmazásokban.

Képkockasebesség (FPS)

FPS (Frames Per Second) — a képkockasebesség animációk és listák görgetése során. A sima felülethez stabil 60 FPS szükséges. Az Android Studio Profiler és az Xcode GPU Report FPS-csökkenést mutat nehéz műveleteknél — képek betöltése, JSON elemzése vagy összetett elrendezések renderelése. A 30 FPS alá csökkenést a felhasználó lassulásként érzékeli, és az Adjust (2025) szerint 22%-kal csökkenti a megtartási arányt.

RAM-fogyasztás

A RAM-fogyasztás — a harmadik kritikus mérőszám. A memóriaszivárgás a teljesítménycsökkenés fő oka hosszú élettartamú munkamenetekben. Az Instruments Allocations és az Android Memory Profiler segít a ciklikus referenciák felismerésében Swiftben és a fel nem szabadított Activity-k észlelésében Androidon. Az akkumulátor-fogyasztás — egy olyan mérőszám, amelyet gyakran figyelmen kívül hagynak a tesztelési szakaszban. Az Apple Developer (2024) szerint a magas energiafogyasztású alkalmazások korlátozva vannak a háttérben iOS-en. Az Energy Log az Xcode-ban rögzíti az alkalmazás watt-profilját a munkamenet során.

A teljesítményteszt típusai

Terheléses tesztelés (Load Test) ellenőrzi az alkalmazás viselkedését a várható egyidejű felhasználók száma alatt. Mobil backend esetében ez 1000-10000 egyidejű API-kérés szimulálását jelenti. A szerveroldalnak kezelnie kell a csúcsterhelést anélkül, hogy a válaszidő több mint 20%-kal nőne az alapértékhez képest. A k6 benchmarkok (2024) szerint a tipikus Load Test konfiguráció 0-ról 1000 VU-ra (virtuális felhasználó) történő emelkedést foglal magában 5 perc alatt.

Stressztesztelés (Stress Test) meghatározza az alkalmazás meghibásodási pontját — amikor a rendszer nem válaszol a kérésekre vagy elfogadhatatlan mértékben leromlik. Ellentétben a Load Test-tel, a Stress Test a normál határok fölé terheli a rendszert. A meghibásodási pontot az alábbi kritériumok egyike szerint rögzítik: a válaszidő meghaladja a 10 másodpercet, az 5XX hibák százaléka meghaladja az 5%-ot, vagy a RAM-fogyasztás eléri a rendelkezésre álló memória 90%-át.

Volumentesztelés (Volume Test) értékeli az alkalmazás viselkedését nagy adatmennyiségekkel való munka során. Mobil kontextusban ez a helyi adatbázisban lévő több ezer rekorddal, több tíz gigabájt gyorsítótárral vagy több millió push értesítéssel való munka ellenőrzése. Az SQLite Androidon és a Core Data iOS-en eltérő teljesítményt mutat 100000 rekord feletti mennyiségnél.

Eszközök a teljesítményteszthez

Xcode Instruments

Az Xcode Instruments — a fő eszköz iOS-alkalmazások profilozásához. A Time Profiler megmutatja, mely metódusok fogyasztják a legtöbb CPU-t, az Allocations pedig nyomon követi a memória lefoglalását és felszabadítását. Az Instruments támogatja a hosszú munkamenetek (akár 30 perc) rögzítését és a nyomok exportálását a build-ek közötti összehasonlításhoz. Az Activity Monitor az Instruments-on belül valós időben mutatja a rendszer teljes terhelését.

Android Studio Profiler

Az Android Studio Profiler — a beépített profilozó Androidhoz. Egyesíti a CPU, Memory, Network és Energy profilozókat egyetlen felületen. Az Android Profiler jellemzője az interaktív munkamenetek támogatása: a fejlesztő műveleteket hajthat végre az alkalmazásban, és láthatja a mérőszámok azonnali reagálását. A Google I/O (2024) szerint a Profiler támogatja a .perf formátumú rögzítést, amely összehasonlítható a baseline-lal a CI-ben.

Charles Proxy

A Charles Proxy és a Proxyman — hálózati forgalom elemzésére szolgáló eszközök. Megmutatják az egyes HTTP-kérések idejét, a válasz méretét és a fejléceket. A teljesítményteszt szempontjából fontos az 500 ms-nál tovább tartó kérések rögzítése — ezek a gyorsítótárazás vagy optimalizálás jelöltjei. A Charles támogatja a throttle módot, amely lassú hálózatokat szimulál: 3G, Edge és LTE. A Proxyman könnyebb alternatíva macOS-hez natív Swift architektúrával.

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

Teljesítményteszt a CI/CD pipeline-ban

A teljesítményteszt CI/CD-be történő integrálása iparági szabvány a 2025-2026-os évekre. A teljesítmény pipeline három szakaszból áll: pre-commit (gyors mérések pull request-nél), nightly (teljes tesztkészlet) és pre-release (összehasonlítás a baseline-lal referenciául szolgáló eszközökön). A Bitrise és a GitHub Actions támogatja az Xcode Instruments CLI és a Gradle Profiler futtatását.

A GitHub Actions (2024) hivatalos sablont tett közzé iOS teljesítményteszthez `xcodebuild test-without-building` használatával. A sablon futtatja a teszteket az egyik GitHub-gépen, és közzéteszi a jelentést egy összetevőben. A baseline egy JSON-fájlban tárolódik a tárolóban: ha a küszöbértéket 10%-kal túllépik, a pipeline hibával meghiúsul. Ez a megközelítés megakadályozza a teljesítmény romlását anélkül, hogy minden build-et manuálisan kellene ellenőrizni.

A mobil teljesítményteszt problémája a CI-ben az eredmények instabilitása a különböző gépeken. Az Apple Silicon (M1-M4) és az Intel Xeon eltérő végrehajtási időket adnak. A megoldás a baseline-hoz viszonyított százalékos arány használata, nem az abszolút értékek. Ha a teszt 15%-kal tovább tart, mint a baseline — a build ellenőrzendőként van megjelölve.

Teljesítménytesztek írása iOS és Android platformon

Az XCTest Performance iOS-en a `measure(metrics:)` metódust használja, amely 10-szer futtatja a kódblokkot, és statisztikát ad vissza: átlag, medián, szórás. Az adatbázis-teljesítmény teszteléséhez kényelmes az XCTMemoryMetric használata, amely rögzíti a csúcs RAM-fogyasztást. A küszöbértéket az `XCTPerformanceReport` segítségével állítják be a teszt befejezése után.

Az Android Macrobenchmark — egy Google-könyvtár az alkalmazásszintű teljesítmény mérésére. A Macrobenchmark felhasználói forgatókönyveket futtat (Activity indítása, RecyclerView görgetése, WebView megnyitása), és méri a végrehajtási időt. A Baseline Profile — osztályok és metódusok halmaza, amelyeket az Android fordító előre optimalizál. A Google Play a Baseline Profile segítségével 30%-kal gyorsítja az első indítást.

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

Mindkét megközelítés — az XCTest Performance és az Android Macrobenchmark — ugyanazt a koncepciót használja: többszörös mérés átlagolással és a küszöbértékkel való összehasonlítással. A teljesítmény nem redukálható egyetlen számra. Minden kiadást teljesítményjelentésnek kell kísérnie, amely az utolsó 5 build mérőszámainak trendjeit tartalmazza. Egy ilyen jelentés lehetővé teszi a csapat számára, hogy észrevegye a romlást, mielőtt a felhasználók észlelnék.