Baseline Profiles

Wenn deine App fachlich korrekt ist, aber beim Start ruckelt oder der erste Compose-Screen zäh wirkt, fühlt sie sich für Nutzer trotzdem schwach an. Baseline Profiles sind ein Release-Werkzeug, mit dem du Android hilfst, wichtige Codepfade früher zu optimieren: Start, Navigation, erste Listen, zentrale Interaktionen und andere Stellen, an denen Jank besonders auffällt.

Was ist das?

Baseline Profiles sind Profildateien, die beschreiben, welche Klassen und Methoden deiner App besonders früh oder besonders häufig ausgeführt werden. Android nutzt diese Informationen, um ausgewählten Code ahead-of-time zu kompilieren, also vor der tatsächlichen Nutzung stärker vorzubereiten. Dadurch muss das System beim ersten App-Start weniger Arbeit zur Laufzeit erledigen.

Das mentale Modell ist: Deine App liefert Android eine Karte der wichtigsten Wege. Ohne diese Karte lernt das System zwar ebenfalls durch Nutzung, welche Teile relevant sind, aber das passiert später und hängt vom Gerät, vom Installationszeitpunkt und vom Nutzungsverhalten ab. Mit einem Baseline Profile gibst du einen sinnvollen Startpunkt mit, der direkt nach der Installation wirken kann.

Im modernen Android-Kontext ist das besonders wichtig, weil Apps oft aus vielen Schichten bestehen: Kotlin-Code, Jetpack-Bibliotheken, Compose, Navigation, Dependency Injection, Datenzugriff und Architekturkomponenten. Jede Schicht ist für sich legitim, erzeugt aber Code, der beim Start geladen, initialisiert oder kompiliert werden kann. Baseline Profiles ersetzen kein sauberes Design, keine schlanken Initialisierungen und keine Messungen. Sie ergänzen diese Arbeit, indem sie kritische Pfade für die Laufzeit optimierbarer machen.

Der Begriff passt deshalb in die Roadmap-Phase Performance, Accessibility, Privacy, and Security: Eine hochwertige App ist nicht nur funktional. Sie reagiert zuverlässig, bleibt zugänglich, schützt Daten und vermeidet unnötige Wartezeiten. Baseline Profiles konzentrieren sich auf den Performance-Teil dieser Qualität, besonders auf Startup und Jank.

Wie funktioniert es?

Android führt Apps nicht nur als statischen Code aus. Je nach Version, Gerät und Installationszustand werden Teile des Codes interpretiert, just-in-time kompiliert oder ahead-of-time vorbereitet. Baseline Profiles greifen in diesen Ablauf ein, indem sie dem System sagen: Diese Methoden sind für den typischen Nutzerfluss relevant und sollten früh optimiert werden.

In der Praxis erstellst du ein Profil nicht per Hand aus Bauchgefühl. Du lässt einen Benchmark oder Generator typische Flows ausführen, etwa App öffnen, Login-Zustand anzeigen, Hauptscreen laden, Liste scrollen oder Detailseite öffnen. Daraus entsteht eine Profildatei, die beim Build in dein Release-Artefakt einfließt. Auf dem Gerät kann Android diese Informationen verwenden, um die betroffenen Codepfade vorzubereiten.

Wichtig ist die Trennung zwischen drei Dingen:

Kritischer Pfad

Ein kritischer Pfad ist nicht jeder Code in deiner App. Kritisch ist Code, der direkt die wahrgenommene Geschwindigkeit beeinflusst. Dazu gehören der Kaltstart, die erste Activity, der erste Compose-Renderpfad, Navigation zum Hauptinhalt und Interaktionen, die viele Nutzer früh ausführen. Ein seltener Einstellungsdialog ist meist kein guter Kandidat für ein Baseline Profile.

Messbarer Effekt

Baseline Profiles sollen nicht „irgendwie schneller“ machen, sondern konkrete Metriken verbessern. Für Startup geht es zum Beispiel um Zeiten bis zur ersten sinnvollen Anzeige. Für Jank geht es um Frames, die zu lange brauchen und dadurch Ruckler erzeugen. Du solltest vor und nach einer Änderung messen, sonst weißt du nicht, ob das Profil wirklich hilft.

Release-Nähe

Ein Profil ist nur brauchbar, wenn es nahe an deinem echten Release ist. Debug-Builds, stark vereinfachte Testdaten oder künstliche Flows können ein falsches Bild erzeugen. Gerade Compose-Apps profitieren oft deutlich, aber nur dann, wenn die Profile echte Composables, echte Navigation und realistische Initialisierung abdecken.

Baseline Profiles sind außerdem kein Freibrief für schwere Arbeit im App-Start. Wenn du beim Start synchron große Datenbanken öffnest, Netzwerkanfragen blockierend ausführst oder unnötige SDKs initialisierst, kaschiert ein Profil das Problem höchstens teilweise. Gute Performance entsteht aus mehreren Entscheidungen: schlanke Initialisierung, sinnvolle Architektur, asynchrone Arbeit mit Coroutines, stabile UI und gezielte Profilierung.

In der Praxis

Ein typischer Arbeitsablauf ist: Du definierst einen Macrobenchmark, der einen zentralen Nutzerfluss ausführt, generierst daraus ein Baseline Profile und prüfst die Wirkung im Release-Build. Für Lernende ist dabei wichtig, den Flow klein und realistisch zu halten. Starte nicht mit zehn Szenarien. Beginne mit dem Kaltstart und dem ersten Hauptscreen.

Ein vereinfachter Kotlin-Test kann so aussehen:

@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {

    @get:Rule
    val baselineProfileRule = BaselineProfileRule()

    @Test
    fun generate() {
        baselineProfileRule.collect(
            packageName = "de.beispiel.app"
        ) {
            pressHome()
            startActivityAndWait()

            device.waitForIdle()

            device.findObject(By.res("home_list"))
                ?.fling(Direction.DOWN)

            device.waitForIdle()
        }
    }
}

Der Code zeigt nicht jede Gradle-Konfiguration, aber das Prinzip: Der Test startet die App, wartet auf Stabilität und führt eine frühe, relevante Interaktion aus. In einer Compose-App würdest du dafür stabile Test-Tags oder Ressourcen nutzen, damit der Benchmark nicht an zufälligen Texten oder Layoutdetails hängt. Der Flow sollte den Zustand abbilden, den Nutzer nach der Installation oder nach einem normalen App-Start sehen.

Eine konkrete Entscheidungsregel: Nimm nur Pfade in dein erstes Profil auf, die viele Nutzer innerhalb der ersten 30 bis 60 Sekunden erreichen. Dazu gehören Start, Hauptnavigation, erste Liste, Suche oder Detailansicht. Später kannst du weitere Flows ergänzen, aber ein kleines, gepflegtes Profil ist besser als ein großes Profil, das niemand versteht.

Die häufigste Stolperfalle ist ein Profil, das technisch vorhanden ist, aber fachlich nichts Wertvolles beschreibt. Das passiert zum Beispiel, wenn der Generator nur einen leeren Splashscreen öffnet, wenn Testdaten fehlen oder wenn der Flow wegen eines Login-Dialogs hängen bleibt. Dann enthält das Profil Code für den falschen Zustand. Im Code-Review solltest du deshalb nicht nur prüfen, ob eine Profildatei erzeugt wurde. Prüfe, welcher Nutzerfluss sie erzeugt, ob der Paketname stimmt, ob die Selektoren stabil sind und ob der Benchmark im CI oder vor Releases reproduzierbar läuft.

Eine zweite Stolperfalle ist die Verwechslung von Baseline Profiles mit allgemeiner Performance-Arbeit. Wenn ein Compose-Screen beim Scrollen ruckelt, weil in jedem Item teure Berechnungen laufen oder instabile Parameter ständig Recomposition auslösen, kann ein Profil helfen, aber es löst die Ursache nicht vollständig. Dann musst du zusätzlich mit Compose-Tools, Tracing oder Benchmarks prüfen, wo Frames verloren gehen.

Auch Accessibility, Privacy und Security bleiben relevant. Ein schneller Start darf nicht bedeuten, dass du Zugänglichkeitszustände ignorierst, private Daten voreilig lädst oder Sicherheitslogik umgehst. Performance-Optimierung ist Teil der Produktqualität, aber sie steht neben anderen Qualitätsanforderungen. Ein guter Benchmark-Flow nutzt daher realistische UI-Zustände und bleibt nah an dem, was Nutzer tatsächlich erleben.

Fazit

Baseline Profiles sind ein praktisches Werkzeug, um Android beim Optimieren kritischer Codepfade zu unterstützen. Du solltest sie vor allem für Startup und frühe, häufige Nutzerflüsse einsetzen, nicht als Ersatz für saubere Architektur oder Messungen. Prüfe dein Verständnis aktiv: Schreibe einen kleinen Macrobenchmark für den App-Start, generiere ein Profil, vergleiche Messwerte vor und nach der Änderung und lass im Code-Review erklären, warum genau dieser Flow im Profil steht.