60fps w programowaniu mobilnym: istota, zasada działania i wpływ na wydajność

Co to jest 60fps

60fps (60 klatek na sekundę, frames per second) — wskaźnik częstotliwości zmiany klatek, przy którym wyświetlacz odświeża obraz 60 razy na sekundę. Ludzkie oko przestaje rozróżniać dyskretne klatki przy około 50–60 Hz dzięki efektowi persistencji wzroku, co czyni 60fps naturalnym progiem płynności dla większości użytkowników.

Każda klatka przy 60fps ma stały budżet czasu wynoszący 16.67 ms. W ten budżet wchodzi cały czas: od przetworzenia wejścia użytkownika po renderowanie i wyświetlenie na ekranie. Jeśli jakakolwiek operacja — fizyka, animacja, rysowanie złożonej sceny — przekroczy ten limit, częstotliwość klatek spada do 30fps lub niżej, co wizualnie odbierane jest jako zacinanie.

W programowaniu mobilnym 60fps przez długi czas był limitem ze względu na ograniczenia sprzętowe: większość wyświetlaczy przed 2017 rokiem działała na 60 Hz. Wraz z pojawieniem się ekranów 90 Hz i 120 Hz, 60fps stał się dolnym standardem, a nie górnym celem. Jednak dla aplikacji UI, wideo i większości gier casualowych 60fps pozostaje docelowym wskaźnikiem wydajności.

Dlaczego właśnie 60 klatek na sekundę

60 Hz — częstotliwość prądu przemiennego w sieciach elektrycznych USA i Japonii, która historycznie określiła częstotliwość odchylania pierwszych standardów telewizyjnych NTSC. Standard PAL używał 50 Hz ze względu na europejską sieć 50 Hz. Ta historyczna inercja przeszła na monitory komputerowe, a następnie — na wyświetlacze mobilne.

Fizjologia widzenia i persistencja

Efekt persistencji — właściwość ludzkiego wzroku polegająca na utrzymywaniu obrazu na siatkówce przez około 30–50 ms po zniknięciu bodźca. Przy 60fps nowa klatka pojawia się co 16.7 ms — wcześniej niż znika persistencyjny ślad poprzedniej, tworząc iluzję ciągłego ruchu. Badania Uniwersytetu w Cardiff (2023) pokazują, że piloci myśliwców są w stanie rozróżnić pojedynczą klatkę przy 220 Hz, ale dla zwykłego użytkownika różnica między 60 a 120 Hz jest znacznie mniej zauważalna niż między 30 a 60 Hz.

Standardy branżowe

Apple ustanowiło 60fps jako standard dla iOS w 2007 roku z pierwszym iPhonem i utrzymywało go aż do iPhone 13 Pro (2021). Android historycznie podążał za tym samym standardem, chociaż pierwsze urządzenia z 90 Hz (OnePlus 7 Pro, 2019) i 120 Hz (Razer Phone, 2017) pojawiły się wcześniej. Dziś 60fps to minimalny próg przejścia review w App Store i Google Play dla aplikacji z animacją, choć formalnie wymagania nie są udokumentowane.

Jak mierzyć i kontrolować FPS

Pomiar FPS — pierwszy krok optymalizacji. Bez obiektywnych metryk nie można określić, gdzie dokładnie tracona jest wydajność. Platformy mobilne oferują wbudowane narzędzia profilowania i programowe API do pomiaru częstotliwości klatek w czasie rzeczywistym.

Narzędzia profilowania

Android Studio Profiler i Xcode Instruments — główne narzędzia do analizy FPS. Android Profiler pokazuje GPU Render Time, Frame Rate oraz Jank (liczbę pominiętych klatek). Xcode Instruments zawiera szablon Core Animation, który wyświetla częstotliwość klatek, czas renderowania i liczbę draw calls. Dla silników gier Unity Profiler i Unreal Insights zapewniają szczegółowy podział czasu według modułów.

// Android — pomiar FPS przez FrameMetrics
window.addOnFrameMetricsAvailableListener(
    { _, frameMetrics ->
        val duration = frameMetrics[FrameMetrics.TOTAL_DURATION]
        val fps = 1000f / (duration / 1_000_000f)
        Log.d("FPS", "Frame duration: ${duration / 1_000_000} ms, FPS: $fps")
    },
    Handler(Looper.getMainLooper())
)

Programowe ograniczanie FPS

CADisplayLink w iOS i Choreographer w Android — mechanizmy systemowe synchronizujące renderowanie z częstotliwością odświeżania wyświetlacza. CADisplayLink wywołuje metodę z każdą nową klatką, przekazując timestamp do obliczenia opóźnienia. Choreographer w Android robi to samo, ale obsługuje wywołania zwrotne dla różnych faz klatki: wejście, animacja, treviz, renderowanie. Programista może zasubskrybować Choreographer.FrameCallback i mierzyć czas pomiędzy klatkami.

Optymalizacja dla stabilnych 60fps

Stabilne 60fps oznaczają, że żadna klatka nie przekracza budżetu 16.7 ms. Nawet jedna długa klatka na sekundę tworzy zauważalne zacinanie. Optymalizacja dzieli się na trzy poziomy: CPU, GPU i pamięć. Każdy z nich może stać się wąskim gardełem.

Optymalizacja CPU: Layout i Measure

Layout pass — jeden z głównych konsumentów czasu CPU na Android i iOS. Złożona hierarchia View, zagnieżdżone ConstraintLayout, ciężkie drawable tworzą długie ńcuchy measure i layout. Dla aplikacji UI używaj płaskiej hierarchii View (głębokość nie więcej niż 3–4 poziomów), zagnieżdżone RecyclerView zastąp ConcatAdapter, a dla list w iOS — compositional layout z prefetching.

Optymalizacja GPU: Overdraw i Draw Calls

Overdraw — wielokrotne rysowanie tych samych pikseli. Każda warstwa View, tło, obraz pod przezroczystym elementem zwiększają liczbę operacji pikselowych. W Android używaj Debug GPU Overdraw w Developer Options, w iOS — Xcode Debug View Hierarchy. Zmniejszaj overdraw, usuwając niepotrzebne tła i używając opaque flag: w Android — @drawable z android:opaque, w iOS — isOpaque = true dla UIKit.View.

Draw calls — liczba poleceń rysowania wysyłanych do GPU. Nowoczesne mobilne GPU przetwarzają 200–400 draw calls na klatkę przy 60fps. Przekroczenie tej liczby powoduje spadek wydajności. Łącz sprite'y w atlasach tekstur, używaj batchingu i unikaj indywidualnego rysowania każdego elementu przez osobny draw call.

Pamięć i zbiórka śmieci

Zawieszki GC — jedna z głównych przyczyn niestabilnego FPS w aplikacjach JVM i Kotlin. Zbiórka śmieci na Android może zajmować do 30–50 ms, powodując pomijanie 2–3 klatek pod rząd. Unikaj alokacji w pętlach animacji, używaj pul obiektów i wstępnego przydziału pamięci. Na iOS problem jest mniej krytyczny ze względu na ARC, ale retain cycles i przepełnienie autorelease pool również tworzą mikrozacinania.

Dla gier 60fps to nie tylko standard, ale przewaga konkurencyjna. Badania Newzoo (2024) pokazują, że gry z niestabilnym FPS poniżej 60 otrzymują o 40% więcej negatywnych opinii w Google Play. Unity i Unreal Engine oferują wbudowane profilery do kontroli czasu renderowania: w Unity to Frame Debugger, w Unreal — GPU Visualizer, które pokazują dokładny czas każdego draw call i shadera. Stabilne 60fps są szczególnie ważne dla gier akcji, gdzie każda pominięta klatka może kosztować użytkownika przejście poziomu.

Przekroczenie 60fps i wysokie częstotliwości

90 Hz i 120 Hz wyświetlacze zmieniają docelową poprzeczkę wydajności. Dla aplikacji działających na urządzeniach ProMotion docelowy FPS może wynosić 120, a budżet klatki skraca się do 8.3 ms. Wymaga to dwukrotnie bardziej wydajnego kodu, szczególnie w draw calls i renderowaniu GPU.

Zaleta wysokich częstotliwości to nie tylko płynność: 120fps zmniejsza zauważalne opóźnienie wejścia o 8–10 ms, co jest krytyczne dla gier i aplikacji interaktywnych. Jednak różnica między 60 a 120fps wymaga indywidualnego podejścia: dla aplikacji UI (przewijanie, animacje) 90fps może być optymalnym kompromisem między płynnością a zużyciem energii, ponieważ renderowanie 120 klatek na sekundę zużywa o 30–40% więcej energii niż 60.

Apple udostępnia API do wyboru preferowanej częstotliwości: preferredFramesPerSecond w CADisplayLink. Android przed API 30 nie daje bezpośredniej kontroli nad częstotliwością, ale od Android 12 programista może ustawiać RefreshRate przez WindowManager, żądając 60, 90 lub 120 Hz w zależności od typu treści.