Microbenchmark

Ein Microbenchmark hilft dir, eine kleine, wichtige Stelle in deinem Android-Code messbar zu verbessern. Statt eine ganze App zu bewerten, konzentrierst du dich auf einen engen Codepfad: eine Sortierung, eine Datenumwandlung, eine Formatierung, eine Compose-Hilfsfunktion oder einen Parser, der sehr oft läuft. Das ist besonders dann sinnvoll, wenn ein Hot Path viele Male pro Sekunde oder bei jedem Listen-Item ausgeführt wird und dadurch spürbar zur App-Performance beiträgt.

Was ist das?

Ein Microbenchmark ist eine gezielte Messung von kleinem Code. Du misst nicht, ob deine App insgesamt schnell wirkt, sondern wie lange eine bestimmte Funktion, ein Algorithmus oder ein kurzer Ablauf braucht. Der Begriff „micro“ ist wichtig: Es geht um kleine Einheiten, nicht um komplette Screens, Navigation, Netzwerk, Datenbank und Rendering zusammen.

Im Android-Kontext brauchst du diese Messart, wenn Low-Level-Performance zählt. Beispiele sind Code in einer LazyColumn, Berechnungen während einer Animation, Mapping von vielen DTOs in UI-Modelle oder eine Funktion, die bei jeder Sucheingabe neu läuft. Solche Stellen sind oft unscheinbar. Eine einzelne Ausführung dauert vielleicht nur wenige Mikrosekunden oder Millisekunden. Wenn sie aber tausendfach aufgerufen wird, entsteht daraus echte Wartezeit, höherer Akkuverbrauch oder eine Oberfläche, die nicht mehr flüssig reagiert.

Das mentale Modell ist: Du stellst eine kleine Hypothese auf und prüfst sie mit Messwerten. Nicht: „Die App ist langsam.“ Sondern: „Diese Normalisierung von Strings ist in unserer Ergebnisliste ein Hot Path. Variante A sollte schneller sein als Variante B, ohne das Verhalten zu ändern.“ Ein Microbenchmark ersetzt kein Profiling und keinen Blick auf reale Nutzererfahrung. Er ist ein Werkzeug, wenn du schon eine verdächtige Stelle kennst oder eine technische Entscheidung sauber vergleichen willst.

Für Lernende ist wichtig: Microbenchmarking ist keine Suche nach kosmetischer Optimierung. Du optimierst nicht jede Zeile, nur weil du sie messen kannst. Du suchst nach Code, der oft läuft, auf dem kritischen Pfad liegt und eine erkennbare Auswirkung auf Startzeit, Scrollen, Eingaben, Rendering oder Hintergrundarbeit haben kann. In der Roadmap gehört das Thema deshalb zu Performance, aber auch zu Qualität. Eine App soll schnell sein, ohne Barrierefreiheit, Sicherheit oder Datenschutz zu schwächen.

Wie funktioniert es?

Ein Microbenchmark trennt drei Dinge: Vorbereitung, gemessene Ausführung und Prüfung des Ergebnisses. Die Vorbereitung baut Testdaten auf, initialisiert Objekte oder setzt den Zustand. Diese Arbeit darf die Messung nicht verfälschen. Die gemessene Ausführung enthält nur den Code, dessen Laufzeit dich interessiert. Die Prüfung stellt sicher, dass der Code nicht vom Compiler oder der Laufzeitumgebung entfernt wird und dass beide Varianten fachlich dasselbe Ergebnis liefern.

Auf Android nutzt du dafür typischerweise Jetpack Benchmark. Die Bibliothek führt deinen Code mehrfach aus, wärmt die Laufzeit an und berichtet Kennzahlen wie Zeit pro Ausführung. Das ist stabiler als ein selbst gebauter Test mit System.currentTimeMillis(). Solche Handmessungen sind anfällig: Das Gerät kann gerade andere Arbeit erledigen, die erste Ausführung enthält Initialisierungskosten, die JIT-Optimierung verändert spätere Läufe, und kleine Messfehler fallen bei sehr kurzem Code stark ins Gewicht.

Bei Kotlin und modernen Android-Apps tauchen Microbenchmarks oft rund um kleine Transformationsfunktionen auf. Du wandelst API-Daten in UI-State um, filterst Listen, formatierst Labels oder berechnest stabile Schlüssel für Compose. In Compose selbst solltest du besonders vorsichtig sein: Nicht jede Performance-Frage ist ein Microbenchmark-Thema. Wenn es um Recomposition, Layout oder Rendering geht, brauchst du häufig andere Werkzeuge und reale UI-Messungen. Wenn es aber um eine pure Hilfsfunktion geht, die während der Erstellung von UI-State oft läuft, kann ein Microbenchmark sinnvoll sein.

Ein guter Microbenchmark ist deterministisch. Er hängt nicht vom Netzwerk ab, nicht von zufälligen Serverdaten, nicht von Benutzerinteraktion und nicht von aktueller Uhrzeit, außer genau diese Zeitlogik ist Teil des Themas. Er nutzt feste Eingaben und misst eng begrenzten Code. Je mehr Umgebung du hineinpackst, desto mehr misst du nicht mehr den Codepfad selbst, sondern Störungen, Framework-Verhalten oder Gerätezustand.

Eine weitere Regel: Vergleiche nur Varianten, die fachlich gleichwertig sind. Schnellere Ergebnisse sind wertlos, wenn du dadurch falsche Lokalisierung, fehlende Accessibility-Labels, unsichere Datenverarbeitung oder schwächere Validierung erzeugst. Performance ist ein Qualitätsmerkmal, aber nicht das einzige. Android-Dokumentation zu Barrierefreiheit, Datenschutz und Sicherheit gehört deshalb gedanklich dazu: Eine Optimierung darf zum Beispiel keine sprechenden Beschreibungen entfernen, keine sensiblen Daten unnötig cachen und keine Sicherheitsprüfung umgehen.

In der Praxis

Angenommen, du hast eine Suchliste mit vielen Einträgen. Für jedes Element wird ein Titel normalisiert, damit die Suche unabhängig von Großschreibung funktioniert. Beim Scrollen oder Filtern fällt auf, dass diese Normalisierung sehr häufig läuft. Jetzt kannst du zwei Varianten vergleichen: direkte Normalisierung pro Aufruf oder vorbereitete normalisierte Werte im Modell.

Ein vereinfachter Microbenchmark könnte so aussehen:

@RunWith(AndroidJUnit4::class)
class SearchNormalizeBenchmark {
    @get:Rule
    val benchmarkRule = BenchmarkRule()

    private val titles = List(1_000) { index ->
        "Android Kurs Teil $index"
    }

    @Test
    fun normalizeTitles() {
        benchmarkRule.measureRepeated {
            val result = titles.map { title ->
                title.lowercase().trim()
            }

            assertEquals(1_000, result.size)
        }
    }
}

Der Code ist absichtlich klein. Er misst nur die Normalisierung einer festen Liste. In einem echten Projekt würdest du daraus keine allgemeine Wahrheit ableiten wie „lowercase() ist langsam“. Du würdest prüfen, ob genau dieser Codepfad in deiner App oft genug ausgeführt wird, um relevant zu sein. Danach könntest du eine zweite Variante messen, bei der die normalisierte Form einmal beim Erzeugen des UI-Modells berechnet wird.

Eine praktische Entscheidungsregel lautet: Schreibe einen Microbenchmark erst dann, wenn du eine konkrete Hot-Path-Vermutung hast. Gute Signale sind auffällige Profile, wiederholte Aufrufe in großen Listen, Code in Animationsnähe oder eine Funktion, die in einem kritischen Nutzerfluss ständig läuft. Schlechte Signale sind Bauchgefühl, unklare Beschwerden oder der Wunsch, beliebigen Code „schneller“ zu machen.

Eine typische Stolperfalle ist, zu viel in die Messung zu legen. Wenn dein Benchmark Testdaten erzeugt, JSON lädt, eine Datenbank öffnet und danach eine Mapping-Funktion misst, weißt du nicht mehr, was die Zahl bedeutet. Packe Setup nach außen. Miss innen nur den verdächtigen Abschnitt. Eine zweite Stolperfalle ist, nur lokale Debug-Builds zu betrachten. Debug-Code verhält sich anders als optimierte Builds. Für belastbare Werte brauchst du eine Umgebung, die deiner Release-Konfiguration möglichst nahekommt.

Auch die Interpretation braucht Disziplin. Ein Unterschied von wenigen Nanosekunden ist oft nicht relevant, wenn der Code selten läuft. Ein etwas langsamerer Code kann richtig sein, wenn er lesbarer, sicherer und weniger fehleranfällig bleibt. Umgekehrt kann eine kleine Verbesserung wichtig sein, wenn sie pro Frame, pro sichtbarem Item oder pro Tastendruck mehrfach auftritt. Du bewertest also nicht nur die Zahl, sondern Zahl mal Häufigkeit mal Nutzerwirkung.

Für Code-Reviews ist ein Microbenchmark besonders nützlich, wenn jemand eine weniger lesbare Optimierung einführt. Dann sollte die Änderung eine klare Messung mitbringen: Welche Funktion wurde gemessen? Welche Eingaben wurden genutzt? Wie groß ist der Unterschied? Warum ist diese Stelle ein Hot Path? Ohne diese Antworten bleibt Performance-Argumentation schnell vage. Mit Benchmark und Erklärung kann das Team bewusst entscheiden.

Fazit

Ein Microbenchmark ist dein Werkzeug für kleine, häufig ausgeführte Codepfade, bei denen Messung wichtiger ist als Vermutung. Übe das Thema an einer reinen Kotlin-Funktion aus deinem Projekt: Schreibe zwei fachlich gleiche Varianten, trenne Setup und Messung, prüfe das Ergebnis und besprich im Code-Review, ob der gemessene Unterschied den zusätzlichen Aufwand rechtfertigt. So lernst du, Performance präzise zu behandeln, ohne Lesbarkeit, Barrierefreiheit, Datenschutz oder Sicherheit aus dem Blick zu verlieren.