Frame Rate in mobilen Apps — was ist das, fps und wie man sie verbessert

Was ist Frame Rate

Frame Rate (Bildwiederholrate) ist eine Kennzahl, gemessen in Bildern pro Sekunde (fps), die angibt, wie oft pro Sekunde eine Anwendung das Bild auf dem Bildschirm aktualisiert. Das menschliche Auge nimmt Bewegung ab 24 fps (Kino) als flüssig wahr, aber für eine interaktive Benutzeroberfläche sind mindestens 60 fps erforderlich, damit Berührungen und Animationen sich augenblicklich anfühlen. Jedes Bild ist ein vollständiger Zyklus: Verarbeitung der Benutzereingabe, Berechnung des Layouts, Rendering der View-Hierarchie und Ausgabe auf den Bildschirm. Wenn eine dieser Phasen das zugewiesene Zeitbudget (16,6 ms bei 60 fps) überschreitet, wird das Bild ausgelassen und der Benutzer sieht ein Ruckeln.

Es ist wichtig, zwischen der Frame Rate der Anwendung und der Bildwiederholfrequenz des Displays zu unterscheiden. Die Bildwiederholfrequenz ist eine Hardware-Eigenschaft des Bildschirms: Wie oft pro Sekunde aktualisiert das Display physisch das Bild (60, 90, 120 oder 144 Hz). Die Frame Rate ist, wie viele Bilder pro Sekunde die Anwendung rendern kann. Wenn die Anwendung auf einem 120 Hz-Display 60 fps ausgibt, wird jedes zweite Bild dupliziert — das Bild bleibt flüssig, aber nicht so reaktionsschnell wie möglich. Laut Google I/O 2023 können moderne Flaggschiffe in einfachen UI-Szenarien 120 fps halten, aber unter hoher Last (Spiele, komplexe Listen) sinkt die Rate auf 40–60 fps.

Wie funktioniert Bild-Rendering

Das Rendering von Bildern in einer mobilen Anwendung durchläuft eine Pipeline aus mehreren Phasen. In Android umfasst die Pipeline: Eingabeverarbeitung (Input), Animation (Animation), Messung und Anordnung (Layout), Zeichnung (Draw), GPU-Synchronisation und Bildschirmausgabe (Swap). Jede Phase wird auf der CPU oder GPU ausgeführt, und die Gesamtzeit aller Phasen darf das Bildbudget nicht überschreiten. Für 60 fps beträgt das Budget 16,6 ms, für 120 fps — 8,3 ms. Choreographer (Android) und CADisplayLink (iOS) synchronisieren das Rendering mit der vertikalen Austastlücke des Displays (VSync) und stellen sicher, dass das Bild nur im Moment der Bildschirmaktualisierung ausgegeben wird, um Tearing zu vermeiden.

In iOS ist die Pipeline ähnlich: Run Loop verarbeitet Ereignisse, Core Animation berechnet Ebenen, Render Server (ein separater Prozess) rendert und sendet das Bild an die GPU. Der Unterschied in iOS ist der dedizierte Render Server-Prozess, der das Rendering von der Hauptanwendung isoliert. Wenn die Anwendung den Hauptthread blockiert, kann Render Server immer noch das letzte bekannte Bild zeichnen, aber Animationen werden gestoppt. Wenn Render Server selbst nicht mithalten kann — wird die GPU im Leerlauf und die Frame Rate sinkt. Laut Apple WWDC 2022 sind die häufigsten Ursachen für niedrige Frame Rate in iOS übermäßige CALayer-Verschachtelung, schwere shadowPath und Offscreen-Rendering.

Bildverfolgung mit Choreographer

Kotlin-Code abonniert Choreographer.FrameCallback und protokolliert die tatsächliche Zeit zwischen den Bildern. Wenn das Intervall 16,6 ms überschreitet, wird ein ausgelassenes Bild aufgezeichnet.

class FrameRateMonitor {

    private var lastFrameTime = 0L
    private val frameCallback =
        Choreographer.FrameCallback { frameTimeNanos ->
            if (lastFrameTime != 0L) {
                val deltaMs = (frameTimeNanos - lastFrameTime) / 1_000_000f
                if (deltaMs > 16.6f) {
                    Log.w("FrameRate",
                        "Skipped frame: $deltaMs ms")
                }
            }
            lastFrameTime = frameTimeNanos
            Choreographer.getInstance()
                .postFrameCallback(this)
        }

    fun start() {
        Choreographer.getInstance()
            .postFrameCallback(frameCallback)
    }
}

Bildwiederholfrequenz und Frame Rate

Refresh Rate (Bildwiederholfrequenz) ist eine Hardware-Eigenschaft des Displays, die bestimmt, wie oft pro Sekunde der Bildschirm das Bild physisch neu zeichnet. Standarddisplays haben 60 Hz, moderne Flaggschiffe haben 90, 120 oder 144 Hz. Die Frame Rate der Anwendung kann niedriger, gleich oder höher als die Bildwiederholfrequenz sein (im letzteren Fall werden überschüssige Bilder verworfen). Das ideale Szenario ist, wenn die Frame Rate mit der Refresh Rate übereinstimmt: Jeder Hardware-Zyklus erhält ein neues Bild von der Anwendung und die Bewegung ist maximal flüssig. Wenn die Frame Rate niedriger ist, wiederholt der Bildschirm das letzte Bild, was als Mikroruckeln wahrgenommen wird.

Android und iOS unterstützen dynamisches Umschalten der Bildwiederholfrequenz. Android 12+ verwendet Smart Refresh Rate: Beim Scrollen erhöht das System die Rate auf 120 Hz, bei statischen Inhalten senkt es sie auf 60 Hz, um Akku zu sparen. iOS ProMotion (iPhone 13 Pro und neuer) funktioniert ähnlich — die Rate variiert je nach Inhalt zwischen 10 und 120 Hz. Der Entwickler sollte überprüfen, ob das Gerät eine hohe Bildwiederholfrequenz unterstützt und das Zeitbudget pro Bild anpassen. Wenn die Anwendung ein Bild nicht innerhalb von 8,3 ms (für 120 Hz) rendern kann, ist es besser, 60 Hz zu erzwingen — dies gewährleistet eine stabile Frame Rate ohne ausgelassene Bilder.

Messwerkzeuge für Frame Rate

Sowohl integrierte Plattform-Tools als auch Drittanbieter-Profiler stehen zur Messung der Frame Rate in mobilen Anwendungen zur Verfügung. In Android ist das primäre Tool GPU Profiling (Developer Options → Profile GPU Rendering), das eine Zeitleiste jedes Bildes, aufgeschlüsselt nach Phasen (Draw, Prepare, Process, Execute), anzeigt. Eine detailliertere Analyse bietet Android Studio Profiler — er zeichnet ein vollständiges Rendering-Profil auf, das die spezifischen Views angibt, die Neuzeichnungen verursachen. In iOS wird Instruments mit der Vorlage Core Animation verwendet — es zeigt FPS, Ebenen-Rendering-Zeit und die Anzahl der Offscreen-Renderings an.

Für die Überwachung der Frame Rate in der Produktion wird Firebase Performance (Android) verwendet — es sammelt die Frame Rate im Hintergrund und aggregiert sie nach Gerät, OS-Version und Sitzung. In iOS bietet MetricKit ähnliche Daten über MXAnimatoryMetric. Für Spiele und Flutter-Anwendungen werden FrameTimingCallback (Flutter) und Unity Profiler verwendet. Es ist wichtig, nicht die durchschnittliche Frame Rate, sondern Perzentile zu messen: P50, P90 und P99. Eine Anwendung kann einen Durchschnitt von 55 fps anzeigen, aber einen P99 von 30 fps haben — das bedeutet, dass 1% der Zeit Benutzer starkes Ruckeln sehen, was für negative Bewertungen ausreicht.

Frame Rate in Flutter messen

Das Dart-Beispiel zeigt, wie man FrameTimingCallback in Flutter abonniert und die Anzahl der ausgelassenen Bilder protokolliert. Der Callback wird nach jedem abgeschlossenen Bild ausgelöst.

import 'package:flutter/scheduler.dart';

class FrameRateLogger {
    int totalFrames = 0;
    int missedFrames = 0;

    void start() {
        SchedulerBinding.instance
            .addTimingsCallback(_onReportTimings);
    }

    void _onReportTimings(List<FrameTiming> timings) {
        for (final timing in timings) {
            totalFrames++;
            if (timing.totalSpan()
                > Duration(milliseconds: 16)) {
                missedFrames++;
            }
        }
        debugPrint("FPS: \${totalFrames - missedFrames}");
    }
}

Optimierung der Bildrate

Die Optimierung der Frame Rate beginnt mit der Identifizierung von Engpässen in der Rendering-Pipeline. In der Layout-Phase sind die Hauptprobleme übermäßige Verschachtelung der View-Hierarchie, die Verwendung relativer Layouts (RelativeLayout mit vielen Regeln) und häufige requestLayout-Aufrufe. Die Lösung ist die Verwendung von ConstraintLayout oder einer flachen Hierarchie, wobei Verschachtelungen von mehr als 5–6 Ebenen vermieden werden sollten. In der Draw-Phase — Overdraw: wenn ein Pixel mehrmals pro Bild gezeichnet wird. Zum Beispiel ein weißer Activity-Hintergrund unter einem halbtransparenten Fragment, darunter eine weitere Schicht — jedes Pixel wird dreimal gezeichnet. Das Tool Debug GPU Overdraw zeigt Problembereiche mit Farbindikatoren an. Es wird empfohlen, Overdraw bei 2x oder darunter zu halten.

In iOS sind die Hauptprobleme schwere cornerRadius und masksToBounds — sie verursachen Offscreen-Rendering, bei dem Core Animation einen temporären Puffer erstellt, darin zeichnet und dann das Ergebnis auf den Bildschirm kopiert. Offscreen-Rendering ist in Instruments Core Animation leicht zu erkennen: Wenn die Renderer-Zeile rot ist — gibt es Probleme. Die Lösung ist die Verwendung von UIImageView mit vorbeschnittenen Bildern anstelle von cornerRadius, Vermeidung von groupOpacity und shouldRasterize ohne zwingende Notwendigkeit. Für beide Plattformen ist es kritisch, die Anzahl der Aufrufe von invalidate() und setNeedsDisplay() zu minimieren — jeder dieser Aufrufe löst einen vollständigen View-Neuzeichnungszyklus aus.

Hierarchieoptimierung in Android

Der Code demonstriert das Ersetzen tiefer RelativeLayout-Verschachtelung durch eine flache ConstraintLayout-Struktur. Die Reduzierung der Verschachtelungsebene von 4 auf 1 verkürzt die Layout-Zeit um 30–50%.

// Beispiel: flache Struktur mit ConstraintLayout
class OptimizedView(context: Context) :
    ConstraintLayout(context) {

    private val binding =
        ItemProfileBinding.inflate(
            LayoutInflater.from(context)
        )

    fun bind(user: User) {
        binding.avatar.setImageURI(user.avatarUrl)
        binding.nameText.text = user.name
        // Daten binden ohne den gesamten Container neu zu zeichnen
    }
}

Adaptive Frequenzen und dynamische Frame Rate

Moderne mobile Anwendungen verwenden zunehmend eine adaptive Frame Rate — ein System, das die Zielfrequenz dynamisch an das aktuelle Szenario anpasst. Schnelles Scrollen erfordert 120 fps für Flüssigkeit, während ein statischer Bildschirm nur 60 fps oder sogar 30 fps für Video benötigt. In Android wird die Anpassung über Choreographer.setFrameInterval (API 33+) und Window.setFrameRate implementiert. Der Entwickler kann eine bevorzugte Frequenz angeben: setPreferredRefreshRate in SurfaceView oder setFrameRate in Window. iOS verwaltet die Frequenz automatisch über ProMotion, aber der Entwickler kann explizit preferredFramesPerSecond für CADisplayLink festlegen.

Die dynamische Frame Rate ist besonders wichtig für Spiele und Anwendungen mit Animationen. Laut Google spart die Reduzierung der Frame Rate von 120 auf 60 Hz auf einem statischen Bildschirm bis zu 30–40% GPU-Energie. Um die beste Balance zwischen Flüssigkeit und Stromverbrauch zu erreichen, wird empfohlen: die tatsächliche Frame Rate in verschiedenen Szenarien zu messen, die Ziel-fps je nach Szene festzulegen (Spiel — 60, Menü — 30, Video — 24) und die Modi über Lifecycle-aware-Komponenten umzuschalten, damit die Anwendung beim Minimieren keine Ressourcen für das Rendern von 120 fps im Hintergrund verschwendet.

Einstellen der bevorzugten Frame Rate

Der Swift-Code setzt preferredFramesPerSecond für CADisplayLink in iOS. Beim Scrollen steigt die Rate auf 120 Hz, beim Anhalten sinkt sie auf 60 Hz.

class AdaptiveFrameRateManager {

    private var displayLink: CADisplayLink?

    func startWithHighRate() {
        displayLink = CADisplayLink(
            target: self,
            selector: #selector(step)
        )
        if #available(iOS 15.0, *) {
            displayLink?.preferredFrameRateRange =
                CAFrameRateRange(
                    minimum: 60,
                    maximum: 120,
                    preferred: 120
                )
        }
        displayLink?.add(to: .current,
            forMode: .common)
    }

    @objc
    private func step() {
        // Animationsaktualisierung
    }
}