FPS mobilos alkalmazásokban: lényeg, számítás és optimalizálás

Mi az FPS

FPS (Frames Per Second) — a képkockasebesség mértékegysége, amelyet számítógépes grafikában, videóban és mobil felületeken használnak. Minden képkocka egy statikus kép, amely rövid ideig jelenik meg a képernyőn. A képkockák gyors váltakozásakor az agy folyamatos mozgásként érzékeli őket — ezt a hatást a látás perzisztenciájának nevezik. Mobilalkalmazásoknál az FPS kritikus metrika, mert bármely kihagyott képkocka (drop) a sima animációt észrevehető akadozássá változtatja. Az alkalmazásnak szigorúan az időkereten belül kell megjelenítenie minden képkockát: 16.6 ms 60 FPS esetén, 11.1 ms 90 FPS esetén, 8.3 ms 120 FPS esetén.

Az FPS-t nem csak a UI, hanem a játékok, videó és kamera esetében is mérik. Játékokban az FPS a jelenet összetettségétől, a textúrák minőségétől és a GPU teljesítményétől függ. Videóban az FPS rögzített (24, 30, 60 képkocka/s), és a tartalom határozza meg. Mobilalkalmazásokban az FPS a UI-kód hatékonyságától függ: a Layout összetettségétől, a View-k számától, az újrarajzolás gyakoriságától és a GC (Garbage Collection) működésétől. Az Apple WWDC 2022 szerint egy alkalmazás átlagos FPS-e 10–15%-kal csökkenhet a gyűjtemények hatékonyatlan frissítése miatt (reloadData az insert/delete/dequeueReusableCell helyett). Az FPS valós idejű mérése szabványos gyakorlat a QA-mérnökök és a teljesítményen dolgozó fejlesztők számára.

Hogyan számítják ki az FPS-t

Az FPS kiszámítása egy mobilalkalmazásban az egymást követő képkockák közötti idő mérésén alapul. A legegyszerűbb képlet: FPS = 1000 / deltaTimeMs, ahol a deltaTimeMs az előző képkocka befejezése és a jelenlegi képkocka befejezése közötti intervallum. Ha a jelenlegi képkocka 20 ms alatt készült el, FPS = 1000 / 20 = 50. A gyakorlatban azonban az FPS ritkán stabil még egy másodpercen belül sem: egy tipikus profil 12–16 ms-os képkockákat tartalmaz, amelyek kihagyott (jank) vagy lassú (40–60 ms) képkockákkal váltakoznak. Ezért az FPS-t 1–5 másodpercre vonatkozó mozgóátlagként vagy a képkockaidő-eloszlás percentiliseiként mérik.

Androidban az FPS-t a Choreographer számítja ki, amely visszahívást (callback) kap a VSync-től (a kijelző szinkronizációs impulzusa). Minden visszahívás egy képkockának felel meg. Ha a visszahívás nem érkezik meg — a képkocka kimaradt. A Choreographer lehetővé teszi a másodpercenkénti pontos képkockaszám és a kihagyott (skipped frames) számának mérését. iOS-ben a CADisplayLink hasonlóan működik — minden alkalommal meghívódik, amikor a kijelző készen áll egy új képkocka megjelenítésére. A timestamp tulajdonság az utolsó képkocka pontos idejét, a targetTimestamp pedig a következő várható idejét tartalmazza. A köztük lévő különbség az aktuális képkocka időkerete.

FPS monitorozás CADisplayLink segítségével

A Swift kód egyszerű FPS monitorozást mutat be a CADisplayLink segítségével. A frameCount számláló minden híváskor növekszik, és másodpercenként egyszer kiszámításra kerül a tényleges FPS.

class FpsCounter {

    private var displayLink: CADisplayLink?
    private var frameCount = 0
    private var lastTime = TimeInterval(0)

    func start() {
        displayLink = CADisplayLink(
            target: self,
            selector: #selector(countFrame)
        )
        displayLink?.add(to: .current,
            forMode: .common)
    }

    @objc
    private func countFrame() {
        frameCount += 1
        let now = Date().timeIntervalSince1970

        if now - lastTime >= 1.0 {
            print("FPS: \(frameCount)")
            frameCount = 0
            lastTime = now
        }
    }
}

Miért 60 FPS a szabvány

A 60 FPS (60 Hz) szabvány több okból gyökeresedett meg az iparágban. Az első — fiziológiai: az emberi szem 50–60 Hz feletti frekvenciánál nem különbözteti meg az egyes képkockákat, sima mozgásként érzékeli őket. Ezt a küszöböt Critical Flicker Fusion (CFF) néven ismerik. A második — történelmi: az első katódsugárcsövek (CRT) 60 Hz-en működtek az USA-ban (NTSC) és 50 Hz-en Európában (PAL). A modern LCD-kijelzők ezt a frekvenciát örökölték. A harmadik — mérnöki: a UI-animációkhoz a 60 FPS ezredmásodperc alatti érintési válaszidőt biztosít, ami kritikus a szövegbevitel, görgetés és húzás szempontjából.

A mobilfejlesztők számára a 60 FPS nem csupán ajánlás, hanem szigorú, 16.6 ms-os keret képkockánként. Ez a keret megoszlik a renderelés összes fázisa között: Input (1–2 ms), Animation (2–3 ms), Layout (3–5 ms), Draw (3–5 ms) és Swap (1–2 ms). Ha bármely fázis túllépi az alkeretét, a képkocka nem biztos, hogy belefér a 16.6 ms-ba. A Google Android Performance azt javasolja, hogy 12–14 ms-ot fordítsunk a képkocka előkészítésére, 2–4 ms tartalékot hagyva a rendszermegszakításokra (GC, háttérszálak). A Firebase Performance adatai szerint azok az alkalmazások, amelyek átlagos FPS-e 52 alatt és P99 FPS-e 30 alatt van, 35%-kal több teljesítménypanaszt kapnak a Google Play-értékelésekben.

FPS és Frame Time: kapcsolat

Az FPS és a Frame Time (képkockaidő) — ugyanazon metrika két oldala, és fontos, hogy ne keverjük őket össze. Az FPS sebesség, a Frame Time késleltetés. 60 FPS esetén minden képkocka 16.6 ms-ig tart. 30 FPS esetén — 33.3 ms. De az FPS nemlineáris metrika: a 60-ról 30 FPS-re való csökkenés azt jelenti, hogy a képkockaidő megduplázódott, a 30-ról 20-ra való csökkenés pedig 1.5-szeresére nőtt. Ezért a profilozók nem FPS-t, hanem Frame Time-ot mutatnak — ez lehetővé teszi a problémás képkockák látását, nem az átlagos frekvenciát. Például az átlagos 55 FPS elrejtheti, hogy a képkockák 5%-ának Frame Time-ja 50–100 ms — ezek a képkockák Jank-ot okoznak, de nem befolyásolják jelentősen az átlagos FPS-t.

A teljesítményelemzésnél ajánlott nem az átlagos FPS-t, hanem a Frame Time hisztogramját nézni. Az Android Studio Profilerben és az iOS Instruments-ben a Frame Time egy skálaként jelenik meg, ahol a zöld zóna — 16.6 ms-ig (60 FPS), sárga — 16.6–33.3 ms (30–60 FPS), piros — 33.3 ms felett (30 FPS alatt). Minden piros oszlop a felhasználó számára észrevehető késleltetés. Gyakorlati szabály: a P95 Frame Time (a képkockák 95%-a X ms-ba belefér) — megbízhatóbb metrika, mint az átlagos FPS. Ha a P95 Frame Time meghaladja a 32 ms-t (30 FPS), az alkalmazás lassúnak érződik még átlagos 50 FPS mellett is.

Frame Time átszámítása FPS-be

Függvény Kotlinban a képkockaidők tömbjének FPS-be való átszámításához percentilisekkel. Nem csak az átlagos FPS-t adja vissza, hanem a P50, P90 és P99 értékeket is részletes elemzéshez.

data class FpsReport(
    val average: Float,
    val p50: Float,
    val p90: Float,
    val p99: Float
)

fun List<Long>.toFpsReport(): FpsReport {
    val fpsValues = this.map { ms ->
        if (ms > 0) 1000f / ms else 0f
    }.sorted()

    return FpsReport(
        average = fpsValues.average().toFloat(),
        p50 = fpsValues[fpsValues.size / 2],
        p90 = fpsValues[(fpsValues.size * 90 / 100)],
        p99 = fpsValues[(fpsValues.size * 99 / 100)]
    )
}

Magas FPS és az új kijelzők

A modern mobil eszközök 90, 120 és 144 Hz-es kijelzőkkel új követelményeket támasztanak az FPS-sel szemben. Ha egy alkalmazás 60 FPS-t ad le egy 120 Hz-es kijelzőn, a felhasználó mikro-akadozást lát, mert minden második képernyő-frissítési ciklus ugyanazt a képkockát kapja. A 120 FPS fenntartásához a képkockánkénti keret 16.6 ms-ról 8.3 ms-ra csökken — ez kétszer hatékonyabb renderelő kódot igényel. Az Android-fejlesztők (Google I/O 2023) szerint a stabil 120 FPS eléréséhez szükséges: kerülni az allokációkat a Draw ciklusban, minimalizálni a View-k számát a hierarchiában (kevesebb, mint 80), lemondani a nehéz drawable-okról a VectorDrawable javára, és surfaceView-t használni az összetett grafikához.

iOS-ben a helyzet hasonló: a ProMotion (120 Hz) iPhone Pro kétszer annyi képkockát igényel, de a képkockánkénti idő feleannyi. Az Apple megjegyzi, hogy nem minden animációnak kell 120 FPS-en futnia — a Core Animation automatikusan csökkenti a frekvenciát a statikus vagy lassan változó elemeknél. Azonban a görgetés, gesztus-animációk és átmenetek 120 FPS-t kell, hogy adjanak a "selymes" érzésért. A 60-ról 120 FPS-re való áttérés fő problémái: megnövekedett energiafogyasztás (25–40% a GPU számára), az eszköz felmelegedése és throttling — amikor a frekvencia a túlmelegedés miatt csökken. Javasolt egy fallback mechanizmus implementálása: ha a Frame Time tartósan meghaladja a 8.3 ms-t, programozottan csökkentse a célfrekvenciát 60 FPS-re, ahelyett, hogy a rendszer throttlingjára várna.

Kapcsoló 60 és 120 FPS között

A Java kód Androidhoz meghatározza, hogy az eszköz képes-e támogatni a 120 FPS-t, és átkapcsolja a renderelési módot. A Display.getMode segítségével határozza meg a támogatott frekvenciákat.

class FpsModeSwitcher {

    static boolean canDo120Fps(Activity activity) {
        Display display = activity.getWindowManager()
            .getDefaultDisplay();
        for (Display.Mode mode : display.getSupportedModes()) {
            if (mode.getRefreshRate() >= 120f) {
                return true;
            }
        }
        return false;
    }
}

FPS optimalizálás alkalmazásokban

Az FPS optimalizálása szisztematikus megközelítést igényel, a profilozástól kezdve a problémás területek refaktorálásáig. Első szakasz — az aktuális FPS mérése egy profilozóval (. Második szakasz — a keretet túllépő képkockák megtalálása. Androidban ez a GPU Profiling vagy Perfetto segítségével tehető meg. iOS-ben — Instruments a Core Animation sablonnal. Harmadik szakasz — az okok megszüntetése: az overdraw csökkentése, a View-k egymásba ágyazási mélységének csökkentése, a Layout fázis cseréje ConstraintLayout-ra, ViewHolder Recycling hozzáadása, nehéz számítások háttérszálra helyezése.

A specifikus FPS-optimalizálások közé tartozik: a Frame Pacing — egy mechanizmus, amely egyenletesen osztja el az időt a képkockák között, hogy elkerülje a gyors és lassú képkockák "csomagjait". Androidban a Choreographer.FrameCallback fix intervallummal lehetővé teszi a Frame Pacing megvalósítását. iOS-ben a CADisplayLink.preferredFrameRateRange teszi ugyanezt. A második mechanizmus — Triple Buffering: a rendszer három puffert használ kettő helyett, ami lehetővé teszi a GPU számára, hogy megkezdje a következő képkocka rajzolását anélkül, hogy megvárná az előző felszabadulását. Android szükség esetén automatikusan bekapcsolja a Triple Buffering-et, de iOS-ben a fejlesztő kifejezetten kérheti a CAMetalLayer segítségével. A harmadik — Texture Caching: a bittérképek gyorsítótárazása a GPU memóriájában, hogy ne kelljen azokat minden képkockánál újratölteni.

Frame Pacing a Choreographer segítségével

A Kotlin példa a Frame Pacing implementációját mutatja be 16.6 ms fix intervallummal. Minden visszahívás egyenletes időközönként érkezik, még akkor is, ha a rendszer késlekedik.

class PacedFrameRenderer {

    private val targetDelta = 16_666_666L // 16.6 ms (60 FPS)
    private var lastFrameTime = 0L

    private val frameCallback =
        Choreographer.FrameCallback { frameTimeNanos ->
            val delta = frameTimeNanos - lastFrameTime
            if (delta >= targetDelta) {
                onFrame(delta)
                lastFrameTime = frameTimeNanos
            }
            Choreographer.getInstance()
                .postFrameCallback(this)
        }

    private fun onFrame(delta: Long) {
        // képkocka megjelenítése
    }
}