Performance Principles in Android

Performance Principles sind Grundsätze, mit denen du Android-Apps gezielt schneller, stabiler und angenehmer machst. Der Kern ist nicht, jede Methode maximal zu verkürzen, sondern die Stellen zu verbessern, die Nutzer wirklich spüren: Startzeit, Scrollen, Eingaben, Navigation, Datenladen und Fehlerfälle.

Was ist das?

Performance Principles beschreiben eine Denkweise für Android-Entwicklung: Du misst zuerst, bewertest dann die Auswirkung auf echte User Journeys und entscheidest bewusst, welche Optimierung den Aufwand wert ist. Eine User Journey ist ein konkreter Weg durch deine App, etwa „App öffnen, Liste laden, Detailseite öffnen, Formular speichern“. Genau dort zeigt sich, ob eine App schnell wirkt oder träge.

Für Anfänger ist das wichtige mentale Modell: Performance ist kein isolierter Trick, sondern ein Qualitätsmerkmal. Eine App kann intern viele elegante Optimierungen enthalten und sich trotzdem langsam anfühlen, wenn der erste Bildschirm spät erscheint oder Compose bei jeder Eingabe unnötig neu zeichnet. Umgekehrt muss nicht jeder Codepfad perfekt optimiert sein, wenn er selten genutzt wird und keinen sichtbaren Einfluss hat.

Im modernen Android-Kontext betrifft Performance mehrere Ebenen. Kotlin-Code sollte nicht unnötig blockieren. Coroutines helfen, Arbeit vom Main Thread fernzuhalten. Jetpack Compose verlangt stabile Zustände und sinnvolle Recomposition-Grenzen. Architekturentscheidungen beeinflussen, wann Daten geladen, gecacht und angezeigt werden. Release-Prozesse und Tests sorgen dafür, dass Verbesserungen nicht nur lokal funktionieren, sondern über Zeit erhalten bleiben.

Wie funktioniert es?

Du arbeitest in drei Schritten: messen, priorisieren, handeln. Messen bedeutet, dass du nicht nach Gefühl entscheidest. Du nutzt Profiler, Logs, Benchmarks, Tests, Crash- und ANR-Daten oder Telemetrie aus deinen Release-Kanälen. Priorisieren bedeutet, dass du Performance mit Nutzerwirkung verbindest. Handeln bedeutet, dass du eine konkrete Änderung machst und danach erneut prüfst, ob sie geholfen hat.

Ein wichtiger Begriff ist der Main Thread. Alles, was die Oberfläche zeichnet oder auf Eingaben reagiert, hängt von ihm ab. Blockierst du ihn durch Datenbankzugriffe, JSON-Verarbeitung, Netzwerk-Warten oder schwere Berechnungen, entstehen Ruckler, verzögerte Klicks oder ANRs. In Compose kommt dazu, dass Zustandsänderungen Recomposition auslösen. Das ist normal und gewollt, kann aber teuer werden, wenn du große Listen, komplexe Berechnungen oder instabile Objekte unkontrolliert in UI-Funktionen verwendest.

Performance ist außerdem eng mit Qualität verbunden. Eine schnellere App nützt wenig, wenn sie dabei Accessibility verschlechtert, Sicherheitsregeln umgeht oder Daten inkonsistent darstellt. Ein aggressiver Cache kann Ladezeiten verbessern, aber veraltete Inhalte zeigen. Weniger Validierung kann ein Formular schneller machen, aber Fehler und Sicherheitsrisiken erhöhen. Deshalb gehört zu jedem Performance-Prinzip ein Trade-off: Was gewinnst du, was riskierst du, und wie prüfst du das Ergebnis?

Im Alltag zeigt sich das in Code-Reviews und Tickets. Statt „Diese Funktion ist langsam“ sollte die Frage lauten: „Welche Journey ist betroffen, wie messen wir sie, und welches Ziel akzeptieren wir?“ Ein gutes Ticket nennt zum Beispiel: „Produktliste soll beim zweiten Öffnen ohne sichtbare Ladepause erscheinen“ oder „Scrollen in der Chatliste darf bei 1000 Nachrichten nicht ruckeln“. Damit kannst du technische Änderungen gegen Nutzerwirkung prüfen.

In der Praxis

Stell dir eine Compose-App vor, die beim Öffnen einer Bestellliste langsam reagiert. Ein häufiger Fehler wäre, sofort kleine Kotlin-Ausdrücke zu optimieren, etwa eine Schleife umzuschreiben, ohne zu wissen, ob sie relevant ist. Besser ist: Du definierst zuerst die Journey „App starten, Bestellliste sehen, erste Bestellung öffnen“. Dann misst du, wo Zeit verloren geht: Netzwerk, Datenbank, Mapping, Compose-Recomposition oder Bildladen.

Eine einfache Regel lautet: Optimiere zuerst die langsamste sichtbare Stelle in einer häufigen Journey. Seltene Admin-Abläufe sind meist weniger wichtig als der Startbildschirm oder eine Liste, die Nutzer täglich öffnen. Eine zweite Regel: Verschiebe schwere Arbeit aus der UI, aber halte den Code verständlich. Performance-Code, den niemand mehr sicher ändern kann, wird später selbst zum Risiko.

Ein typisches ViewModel kann so aussehen:

class OrdersViewModel(
    private val repository: OrdersRepository
) : ViewModel() {

    val uiState: StateFlow<OrdersUiState> =
        repository.observeOrders()
            .map { orders ->
                OrdersUiState.Content(
                    orders = orders.map { order ->
                        OrderRowUi(
                            id = order.id,
                            title = order.customerName,
                            total = order.totalFormatted
                        )
                    }
                )
            }
            .stateIn(
                scope = viewModelScope,
                started = SharingStarted.WhileSubscribed(5_000),
                initialValue = OrdersUiState.Loading
            )
}

@Composable
fun OrdersScreen(viewModel: OrdersViewModel) {
    val state by viewModel.uiState.collectAsStateWithLifecycle()

    when (val current = state) {
        OrdersUiState.Loading -> CircularProgressIndicator()
        is OrdersUiState.Content -> LazyColumn {
            items(
                items = current.orders,
                key = { it.id }
            ) { order ->
                OrderRow(order)
            }
        }
    }
}

Der Code löst nicht jedes Performance-Problem, zeigt aber mehrere Prinzipien. Daten werden außerhalb der Composable vorbereitet. Der State wird lebenszyklusbewusst gesammelt. LazyColumn rendert nur sichtbare Einträge, und stabile Keys helfen Compose, Listenelemente korrekt wiederzuverwenden. Wenn die Liste trotzdem ruckelt, misst du weiter: Ist OrderRow zu komplex? Werden Bilder falsch geladen? Ändert sich der komplette State bei jeder kleinen Aktualisierung?

Eine Stolperfalle ist vorzeitige Optimierung. Du kannst Stunden damit verbringen, eine seltene Berechnung zu verkürzen, während der eigentliche Schaden vom blockierten Main Thread beim App-Start kommt. Eine andere Stolperfalle ist die reine Laborperspektive. Ein Benchmark auf deinem Gerät ist hilfreich, aber echte Nutzer haben verschiedene Geräte, Akkuzustände, Netzwerke und Schriftgrößen. Accessibility kann Performance ebenfalls beeinflussen: Größere Schrift, Screenreader und längere Inhalte müssen weiterhin flüssig bedienbar bleiben.

Für Tests brauchst du mehrere Ebenen. Unit-Tests prüfen, ob dein Mapping und deine Zustände korrekt bleiben. UI-Tests prüfen wichtige Journeys. Continuous Integration hilft, diese Prüfungen regelmäßig auszuführen. Performance-Messungen sollten reproduzierbar sein, aber du musst sie nicht für jede kleine Änderung maximal ausbauen. Entscheidend ist, dass kritische Wege nicht nur nach Bauchgefühl bewertet werden.

In Code-Reviews kannst du gezielt fragen: Läuft schwere Arbeit auf dem Main Thread? Wird Compose-State unnötig groß oder instabil? Gibt es eine Messung vor und nach der Änderung? Ist der Trade-off dokumentiert, etwa mehr Speicherverbrauch für schnellere Darstellung? Passt die Änderung zu Datenschutz und Sicherheit, zum Beispiel wenn Caching personenbezogene Daten betrifft? Diese Fragen machen Performance zu einem überprüfbaren Teil deiner Entwicklungsroutine.

Fazit

Performance Principles helfen dir, nicht an der falschen Stelle zu optimieren. Prüfe bei deiner nächsten App eine konkrete User Journey: Miss den Start, eine Liste, eine Detailseite oder ein Formular, ändere nur eine relevante Sache und vergleiche das Ergebnis. Nutze Profiler, Tests, Debugger und Code-Review, um deine Annahmen zu überprüfen. So lernst du, Performance nicht als Sammlung einzelner Tricks zu sehen, sondern als technische Entscheidung mit messbarem Nutzen für echte Nutzer.