Jank für mobile Anwendungen — was es ist, Ursachen und Lösungen

Was ist Jank

Jank ist ein Begriff aus der Computergrafik, der einen visuellen Defekt beschreibt, bei dem sich eine Animation ruckartig statt fließend bewegt. In der mobilen Entwicklung wird Jank als Anzahl der ausgelassenen Frames (skipped frames) pro Zeiteinheit gemessen. Wenn das System es nicht schafft, einen Frame rechtzeitig zum VSync-Zeitpunkt vorzubereiten, wiederholt das Display den vorherigen Frame — es entsteht eine Pause von 16,6 ms bei 60 Hz. Ein einzelner ausgelassener Frame kann unbemerkt bleiben, aber eine Serie von 3–5 aufeinanderfolgenden ausgelassenen Frames erzeugt ein 50–80 ms andauerndes „Ruckel“-Gefühl, das der Benutzer deutlich wahrnimmt.

Jank ist besonders kritisch für Animationen, die mit konstanter Geschwindigkeit laufen müssen: Scrollen von Feeds, Menüöffnungsanimationen, Parallaxeneffekte, Bildschirmübergänge. Laut einer Google-UX-Studie (2024) erhält eine App mit einer Jank-Rate von über 3% der Scroll-Sitzungen 22% mehr Ein-Sterne-Bewertungen als eine App mit einer Rate unter 0,5%. Das Android Vitals-Tool verfolgt Jank automatisch und klassifiziert es nach Schweregrad: moderat, schwerwiegend und kritisch.

Hauptursachen von Jank

Die Ursachen von Jank lassen sich in mehrere Kategorien einteilen. Die erste ist Layout Jank: verursacht durch häufige requestLayout()-Aufrufe aufgrund von Größenänderungen von Views, LayoutTransition-Animationen oder dynamischem Laden von Inhalten. Jeder requestLayout-Aufruf löst Measure + Layout für die gesamte View-Unterstruktur aus, was 5–30 ms dauern kann. Die zweite ist Draw Jank: verbunden mit Overdraw und der Verwendung schwerer Drawables. Die dritte ist Thread Jank: Blockierung des Hauptthreads durch synchrone Operationen — Laden von Dateien, Datenbankoperationen auf dem Hauptthread, Bitmap-Decodierung.

Die vierte Kategorie ist GC Jank: Garbage Collection in ART/Dalvik oder Swift ARC. Wenn sich viele Objekte im Heap ansammeln, startet GC eine Stop-The-World-Pause von 5–15 ms. Unter Android treten GC-Pausen am häufigsten bei häufigen Allokationen in Schleifen auf: Erstellen von Objekten in onDraw(), Allokation in Adaptern, ungenutzte Lambda-Ausdrücke. Die fünfte ist IPC Jank: Interprozesskommunikation (ContentProvider, Binder) auf dem Hauptthread. Die sechste ist Rendering Jank: langsames GPU-Rendering aufgrund nicht optimierter Shader oder großer Texturen.

Jank-Diagnose in Android

In Android beginnt die Jank-Diagnose mit dem System-Trace Perfetto. Perfetto zeichnet die Aktivität aller Threads, der CPU, GPU und des Schedulers auf. Ein deutlicher Indikator für Jank sind die Zeilen Choreographer.doFrame und Choreographer.doCallbacks: Wenn das Intervall zwischen zwei aufeinanderfolgenden doFrame-Aufrufen 16,6 ms überschreitet, wurde ein Frame ausgelassen. Perfetto zeigt die genaue Ursache — welcher Systemaufruf, Lock oder GC die Verzögerung verursacht hat. Im Android Studio Profiler ist ähnliche Funktionalität über den CPU Profiler verfügbar.

Für die automatische Jank-Erkennung in der Produktion wird FrameMetricsAggregator verwendet — eine API, die Statistik für jeden Frame sammelt und pro Sitzung aggregiert. In Android 12+ kam PerformanceHintManager hinzu — eine API, um dem System die Ziel-Framerate mitzuteilen. Wenn die App angibt, dass sie in einem 120-FPS-Szenario läuft, kann das System die CPU/GPU-Frequenz erhöhen, um Jank zu verhindern. Für einfaches Logging aller ausgelassenen Frames reicht es aus, Choreographer.FrameCallback zu abonnieren.

Jank-Logging via Choreographer

Kotlin-Code abonniert Choreographer.FrameCallback und protokolliert jeden ausgelassenen Frame mit der Verzögerungsdauer. Der Callback wird bei jedem VSync aufgerufen.

class JankDetector {

    private val frameBudget = 16_666_666L
    private var previousFrameTime = 0L

    private val callback =
        Choreographer.FrameCallback { currentTime ->
            if (previousFrameTime != 0L) {
                val frameDuration =
                    currentTime - previousFrameTime
                val skippedFrames =
                    (frameDuration / frameBudget) - 1
                if (skippedFrames > 0) {
                    Log.w("Jank",
                        "Skipped $skippedFrames frames")
                }
            }
            previousFrameTime = currentTime
            Choreographer.getInstance()
                .postFrameCallback(this)
        }

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

Jank-Diagnose in iOS

In iOS erfolgt die Jank-Diagnose über Instruments mit der Core Animation-Vorlage. Instruments zeigt Echtzeit-FPS, die Anzahl der Offscreen-Renderings und Hit-Tests. Die wichtigsten Jank-Indikatoren in iOS: rote Balken im Core Animation-Zeitstrahl (Frame-Budget überschritten), hoher Renderer-Wert (zeigt Offscreen-Rendering an) und niedrige FPS. Für die Produktionsüberwachung sammelt MetricKit Berichte mit der Metrik MXAnimatoryMetric, die durchschnittliche FPS, P50- und P95-Frame-Zeit umfasst.

Die native Jank-Diagnose in iOS umfasst CADisplayLink mit Überprüfung von timestamp und targetTimestamp. Wenn der aktuelle timestamp deutlich hinter dem targetTimestamp zurückliegt, wurden ein oder mehrere Frames ausgelassen. Apple empfiehlt außerdem die Verwendung von os_signpost für benutzerdefiniertes Profiling: Setzen Sie ein signpost-interval am Anfang und Ende der Frame-Renderings und prüfen Sie in Instruments, welche Intervalle 16,6 ms überschreiten. In SwiftUI wird UIView.invalidateIntrinsicContentSize zur Jank-Diagnose verwendet — häufige Aufrufe dieser Methode deuten auf ein instabiles Layout hin.

CADisplayLink zur Jank-Erkennung

Swift-Code erkennt ausgelassene Frames über CADisplayLink. Wenn die Differenz zwischen timestamp und targetTimestamp 16,6 ms überschreitet, wird Jank registriert.

class JankMonitor {

    private var displayLink: CADisplayLink?
    private var totalJank = 0

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

    @objc
    private func detectJank() {
        guard let link = displayLink else { return }
        let delay = link.targetTimestamp
            - link.timestamp
        if delay > 0.0167 {
            totalJank += 1
        }
    }
}

Jank-Profiling-Werkzeuge

Für das Jank-Profiling werden sowohl integrierte OS-Werkzeuge als auch Drittanbieter-SDKs verwendet. Unter Android ist das wichtigste Werkzeug Perfetto (Nachfolger von Systrace). Perfetto kann Traces von bis zu 30 Sekunden aufzeichnen und über die Weboberfläche ui.perfetto.dev analysieren. Es zeigt eine präzise Zeitleiste mit Choreographer-Aktivität, Rendering-Threads (RenderThread) und GPU. Für detaillierte GPU-Analysen wird AGI (Android GPU Inspector) verwendet, das nicht nur die Frame-Zeit, sondern auch die Auslastung bestimmter GPU-Blöcke anzeigt — Shader, Rasterizer, Textureinheit.

Unter iOS ist das Äquivalent Instruments mit den Vorlagen Core Animation, Metal System Trace und GPU Driver. Core Animation zeigt FPS und Frame-Zeit, Metal System Trace zeigt die GPU-Arbeit bis zu jedem einzelnen Draw Call. Für das Profiling auf realen Geräten unter Last werden Firebase Performance (sammelt Screen Rendering-Metrik) und Sentry (erfasst Stack Trace bei Jank) verwendet. Die neue Android 15 Performance Hint-API ermöglicht es Entwicklern, dem System mitzuteilen, welche Frames wichtig sind, und Warnungen vom System zu erhalten, wenn Jank bevorsteht.

FrameMetricsAggregator in der Produktion

Kotlin-Code verwendet FrameMetricsAggregator, um Frame-Statistiken über eine Sitzung zu sammeln. Nach dem Stoppen des Aggregators wird die Anzahl der ausgelassenen Frames ausgegeben.

class JankAggregator(private val activity: Activity) {

    private val aggregator = FrameMetricsAggregator()

    fun startCollection() {
        aggregator.add(activity.window)
    }

    fun stopAndReport() {
        aggregator.remove()
        val result = aggregator.getMetrics()
        val totalFrames = result
            ?.get(FrameMetrics.TOTAL_DURATION)
            ?.size ?: 0
        val jankFrames = result
            ?.get(FrameMetrics.TOTAL_DURATION)
            ?.count { it > 16_666_666L} ?: 0
        Log.d("JankReport",
            "Jank ratio: \${jankFrames * 100 / totalFrames}%")
    }
}

Methoden zur Beseitigung von Frame-Rucklern

Die Beseitigung von Jank erfordert eine Kombination von Techniken, je nach Art. Für Layout Jank: Ersetzen Sie tiefe Hierarchien durch ConstraintLayout/Compose/SwiftUI, verwenden Sie merge-Tags, vermeiden Sie requestLayout in Animationen. Für Draw Jank: Verwenden Sie Debug GPU Overdraw, um 4x+-Overdraw zu finden, ersetzen Sie schwere Drawables durch Vektorgrafiken (VectorDrawable/PDF), verwenden Sie Hardware-Layers mit Vorsicht — sie beschleunigen das Rendering, verbrauchen aber mehr GPU-Speicher. Für Thread Jank: Verlagern Sie alle I/O-Operationen, Datenbankarbeit und Bitmap-Decodierung in Hintergrundthreads, verwenden Sie Kotlin Coroutines mit dem richtigen Dispatcher oder RxJava mit Schedulers.io().

Für GC Jank: Minimieren Sie Allokationen in onDraw() und getView(), verwenden Sie Objektpools (ObjectPool), ersetzen Sie for-each durch indizierte for, verwenden Sie unveränderliche data class in Kotlin mit copy() vorsichtig — copy erzeugt ein neues Objekt. Für IPC Jank: Initialisieren Sie ContentProvider lazy über App Startup, verlagern Sie Binder-Aufrufe in einen Hintergrundthread. Für Rendering Jank: Reduzieren Sie Texturgrößen auf die maximale Bildschirmauflösung, verwenden Sie ASTC- oder ETC2-Komprimierung, vermeiden Sie übermäßige Shader-Kompilierung (Shader vorab kompilieren). Eine umfassende Lösung ist die regelmäßige Perfetto/Instruments-Profiling in CI und die Verfolgung von Jank-Regressionen.

Anti-Jank-Muster: Async Layout

Kotlin-Code demonstriert das asynchrone Laden von Daten auf den Bildschirm nach reportFullyDrawn, damit schwere Arbeit den ersten Frame nicht blockiert. Der Callback wird aufgerufen, nachdem der Benutzer die Oberfläche sieht.

class JankSafeLoader {

    suspend fun loadAfterFirstFrame(
        activity: Activity
    ) {
        // garantieren, dass der erste Frame bereits gerendert ist
        if (Build.VERSION.SDK_INT >= 29) {
            activity.reportFullyDrawn()
        }

        // schweres Laden — nach dem ersten Frame
        withContext(Dispatchers.IO) {
            val data = fetchHeavyData()
            withContext(Dispatchers.Main) {
                updateUI(data)
            }
        }
    }
}