derivedStateOf – abgeleiteten Zustand berechnen, ohne Recompositions zu verschwenden

Ein klassischer Compose-Performance-Fehler: Du liest einen State, der sich sehr oft ändert, um daraus einen Wert zu berechnen, der sich selten ändert. Beispiel: „Zeige den Nach-oben-Button, sobald der Nutzer über Item 5 hinausgescrollt hat." Naiv geschrieben zeichnet dein UI bei jedem Scroll-Frame neu – obwohl sich das Ergebnis fast nie ändert.

Das Problem

val listState = rememberLazyListState()

// ❌ liest firstVisibleItemIndex direkt → recomposed bei JEDEM Scroll-Tick
val showButton = listState.firstVisibleItemIndex > 5

Jede Scroll-Bewegung ändert firstVisibleItemIndex, also wird der umgebende Composable ständig neu ausgewertet – auch wenn showButton konstant true bleibt.

Die Lösung: derivedStateOf

val showButton by remember {
    derivedStateOf { listState.firstVisibleItemIndex > 5 }
}

derivedStateOf merkt sich das Ergebnis und benachrichtigt Leser nur dann, wenn sich genau dieses Ergebnis (true/false) ändert – nicht bei jeder Änderung der Eingabe. Aus „recomposed bei jedem Pixel" wird „recomposed genau zweimal": beim Überschreiten und beim Zurückscrollen.

if (showButton) {
    FloatingActionButton(onClick = { /* nach oben scrollen */ }) {
        Icon(Icons.Default.KeyboardArrowUp, contentDescription = "Nach oben")
    }
}

Wann – und wann nicht

• Einsetzen, wenn aus einem häufig wechselnden State ein selten wechselnder Wert entsteht (Scroll-Position → Sichtbarkeit, langer Text → „ist gültig").
• Nicht nötig, wenn sich Eingabe und Ergebnis ähnlich oft ändern – dann ist es nur zusätzlicher Overhead. Für eine reine 1:1-Transformation reicht normales remember(key).
• Immer in remember wickeln, damit das abgeleitete State-Objekt über Recompositions erhalten bleibt.

Ein flüssiges Scroll-Erlebnis entscheidet oft über den ersten Eindruck einer App. Du willst genau das? Melde dich.

Quellen

• derivedStateOf – Compose side effects (developer.android.com)
• Compose performance – derivedStateOf (developer.android.com)