Performance- und Qualitäts-Capstone

Ein Performance- und Qualitäts-Capstone ist deine Abschlussprüfung für eine App, bevor du sie als ernsthaft releasefähig betrachtest. Du nimmst eine Beispiel-App und prüfst sie nicht nur auf „läuft bei mir“, sondern auf vier konkrete Achsen: Performance, Barrierefreiheit, Datenschutz und Sicherheit.

Was ist das?

Ein Capstone ist in diesem Kontext keine neue Android-API, sondern eine gebündelte Praxisaufgabe. Du führst mehrere Qualitätsprüfungen zusammen und bewertest, ob eine App unter realistischen Bedingungen stabil, schnell, zugänglich und vertrauenswürdig bleibt. Das ist wichtig, weil echte Android-Qualität selten an einer einzelnen Stelle scheitert. Eine App kann sauber mit Kotlin und Jetpack Compose gebaut sein, aber trotzdem ruckeln, für TalkBack schlecht bedienbar sein, zu viele Daten erfassen oder sensible Werte unsicher speichern.

Das mentale Modell ist: Qualität ist ein System aus beobachtbarem Verhalten, technischen Grenzen und Nutzererwartungen. Performance bedeutet nicht nur schnelle Algorithmen, sondern auch flüssige Frames, kurze Startzeiten, niedriger Akkuverbrauch und sinnvolle Arbeit im Hintergrund. Barrierefreiheit bedeutet, dass Menschen mit Screenreadern, größerer Schrift, eingeschränkter Motorik oder Kontrastbedarf die App bedienen können. Datenschutz bedeutet, dass du Daten nur dann erhebst und verarbeitest, wenn die App sie wirklich braucht. Sicherheit bedeutet, dass du Angriffsflächen reduzierst, vertrauliche Informationen schützt und Plattformmechanismen korrekt nutzt.

Im Android-Alltag taucht dieses Thema kurz vor einem Release, bei Pull Requests, bei Bug-Bashes und bei technischen Reviews auf. Junior-Entwickler denken oft zuerst an einzelne Tickets. Fortgeschrittene Entwickler prüfen zusätzlich, ob eine Änderung die Gesamtqualität beeinflusst. Genau dort setzt der Capstone an: Du trainierst, eine App aus mehreren Perspektiven zu prüfen, ohne dich in Randthemen zu verlieren.

Wie funktioniert es?

Du gehst systematisch vor. Zuerst definierst du den Prüfbereich: Welche Screens, Flows und Geräteklassen sind relevant? Bei einer Beispiel-App könnte das der Login, eine Listenansicht, ein Detail-Screen und ein Formular sein. Danach prüfst du jede Qualitätsachse mit passenden Methoden.

Für Performance startest du mit beobachtbaren Symptomen. Startet die App langsam? Ruckelt eine Compose-Liste beim Scrollen? Werden Bilder zu groß geladen? Blockiert Arbeit den Main Thread? Android bietet dir dafür Werkzeuge wie Profiler, Traces, Logcat, StrictMode und Metriken aus Android Vitals. In Compose achtest du zusätzlich auf unnötige Recomposition, instabile Parameter, teure Berechnungen in Composables und große Listen ohne passende Lazy-Komponenten. Die Grundregel lautet: Messe zuerst, ändere danach. Eine Optimierung ohne Messung kann Zeit kosten und das eigentliche Problem verfehlen.

Für Barrierefreiheit prüfst du, ob die Bedienung ohne visuelle Annahmen funktioniert. Bediene die App mit TalkBack, erhöhe die Schriftgröße, teste Landscape und prüfe Kontraste. In Compose sind contentDescription, semantische Rollen, ausreichende Touch-Ziele und klare Fokusreihenfolgen zentral. Ein Icon-Button ohne Beschreibung sieht für sehende Nutzer klar aus, ist für Screenreader aber nur ein namenloses Bedienelement. Auch dynamische Inhalte brauchen Aufmerksamkeit: Wenn ein Ladezustand, Fehler oder Erfolg angezeigt wird, sollte die Information nicht nur optisch erkennbar sein.

Für Datenschutz fragst du bei jeder Datennutzung: Braucht die App diese Information wirklich, und versteht der Nutzer den Zweck? Du prüfst Berechtigungen, Logging, Analytics, Netzwerkaufrufe, Datenspeicherung und Löschbarkeit. Ein häufiger Fehler ist, Daten „für später“ mitzunehmen. Das erhöht Risiko und Prüfaufwand. Besonders kritisch sind Standortdaten, Kontakte, Fotos, Gesundheitsdaten, Gerätekennungen und personenbezogene Nutzungsdaten. Gute Android-Entwicklung nutzt die geringste notwendige Berechtigung und erklärt Datenzugriffe klar im passenden Kontext.

Für Sicherheit prüfst du Angriffsflächen. Speichert die App Tokens im Klartext? Werden Debug-Logs mit sensiblen Daten erzeugt? Ist Network Security korrekt konfiguriert? Sind exportierte Activities, Services oder Broadcast Receiver wirklich nötig? Werden Eingaben validiert? Nutzt die App HTTPS und sichere Speichermechanismen wie Jetpack Security, wenn vertrauliche Daten lokal liegen müssen? Sicherheit ist nicht nur ein Server-Thema. Eine Android-App läuft auf Geräten, die verloren gehen, gerootet sein können oder mit unsicheren Netzwerken verbunden sind.

Tests verbinden diese Bereiche. Unit-Tests sichern Logik ab, Instrumentation-Tests prüfen Verhalten auf Geräten, UI-Tests decken wichtige Flows ab, und manuelle Checks fangen Aspekte ab, die Automatisierung nicht zuverlässig bewertet. Ein Capstone ist deshalb kein einzelner Testlauf, sondern ein Audit mit reproduzierbaren Notizen: Was wurde geprüft, was wurde gefunden, wie schwer ist es, und wie kannst du es belegen?

In der Praxis

Nimm als Beispiel eine Compose-App mit einer Produktliste und einem Detail-Screen. Dein Audit beginnt mit einem kurzen Prüfplan. Du notierst Geräteprofil, Android-Version, Testdaten und die wichtigsten Flows. Dann prüfst du den Listen-Screen: Startzeit, Scroll-Verhalten, Ladezustände, Screenreader-Ausgabe, Netzwerkfehler und lokale Speicherung.

Ein kleines Beispiel zeigt, wie ein zugänglicher und testbarer Button in Compose aussehen kann:

@Composable
fun FavoriteButton(
    isFavorite: Boolean,
    onToggle: () -> Unit,
    modifier: Modifier = Modifier
) {
    val label = if (isFavorite) {
        "Aus Favoriten entfernen"
    } else {
        "Zu Favoriten hinzufügen"
    }

    IconButton(
        onClick = onToggle,
        modifier = modifier
            .sizeIn(minWidth = 48.dp, minHeight = 48.dp)
            .semantics {
                contentDescription = label
            }
    ) {
        Icon(
            imageVector = if (isFavorite) Icons.Filled.Favorite else Icons.Outlined.FavoriteBorder,
            contentDescription = null
        )
    }
}

Der wichtige Punkt ist nicht der Button selbst, sondern die Denkweise. Du prüfst hier mehrere Qualitätsaspekte gleichzeitig: Das Touch-Ziel ist groß genug, der Screenreader bekommt eine sinnvolle Beschreibung, die visuelle Darstellung ist von der semantischen Bedeutung getrennt, und die Aktion ist klar testbar. In einem UI-Test könntest du prüfen, ob das Element mit der passenden Beschreibung existiert und klickbar ist. In einem Code-Review würdest du außerdem fragen, ob onToggle Fehlerzustände behandelt und ob die App den Favoritenstatus lokal oder remote speichert.

Für Performance würdest du denselben Screen mit vielen Testdaten öffnen. Wenn die Liste ruckelt, schaust du nicht nur auf die sichtbare Stelle. Du prüfst, ob Bilder korrekt skaliert werden, ob LazyColumn stabile Keys nutzt und ob ViewModel-State unnötig große Objekte an die UI weitergibt. Wenn ein Filter bei jeder Texteingabe die komplette Liste auf dem Main Thread sortiert, ist das ein konkreter Befund. Die Lösung kann sein, Berechnungen in die passende Schicht zu verlagern, State sauber zu modellieren oder Arbeit mit Coroutines kontrolliert auszuführen. Wichtig bleibt: Du belegst den Befund mit Messung oder reproduzierbarem Verhalten.

Für Datenschutz stellst du Fragen an denselben Flow. Muss die Produktliste den Standort kennen? Wird Suchverhalten in Analytics gesendet? Enthalten Logs Nutzer-IDs oder E-Mail-Adressen? Wenn du im Debug-Build Netzwerkantworten protokollierst, darf das nicht versehentlich im Release-Build landen. Eine nützliche Entscheidungsregel lautet: Alles, was du nicht brauchst, erhebst du nicht; alles, was du brauchst, schützt du sichtbar und nachvollziehbar.

Für Sicherheit prüfst du dann Speicher und Schnittstellen. Ein Token gehört nicht in normale SharedPreferences, wenn er vertraulich ist. Ein API-Key im Client ist kein echtes Geheimnis, weil App-Bundles analysiert werden können. Exportierte Komponenten brauchen klare Gründe. WebViews, Deep Links und Dateiimporte verdienen besondere Aufmerksamkeit, weil sie Eingaben von außen in deine App bringen. Du musst nicht bei jeder Lern-App ein komplettes Penetration Testing durchführen, aber du solltest unsichere Muster erkennen und begründen können.

Eine typische Stolperfalle ist, diese Prüfung erst am Ende eines Projekts zu machen. Dann wirken Qualitätsprobleme wie zusätzliche Arbeit, obwohl sie oft aus frühen Architekturentscheidungen entstehen. Wenn UI-State unklar modelliert ist, werden Tests schwer. Wenn Datenzugriffe überall verteilt sind, wird Datenschutz schwer. Wenn Hintergrundarbeit unkontrolliert startet, wird Performance schwer. Der Capstone soll dir zeigen, dass Qualität schon beim Entwurf beginnt.

Eine zweite Stolperfalle ist Tool-Gläubigkeit. Ein grüner Testlauf bedeutet nicht automatisch, dass die App barrierefrei ist. Eine gute Profiler-Zahl bedeutet nicht, dass der wichtigste Nutzerflow angenehm ist. Ein fehlender Crash bedeutet nicht, dass Datenschutz korrekt umgesetzt ist. Nutze Tools als Belege, nicht als Ersatz für technische Bewertung.

Ein praktischer Audit kann so aussehen: Du startest mit einem Smoke-Test der Hauptflows, misst Start und Scrollen, aktivierst TalkBack, erhöhst Schrift und Displaygröße, prüfst Berechtigungen, suchst nach sensiblen Logs, kontrollierst lokale Speicherung und liest die wichtigsten Manifest-Einträge. Danach priorisierst du Findings. Ein Absturz im Hauptflow, ein unbedienbarer Checkout-Button oder ein Token im Klartext ist schwerwiegender als eine kleine Layout-Unschärfe in einem seltenen Screen. Diese Priorisierung ist Teil professioneller Android-Arbeit.

Fazit

Ein Performance- und Qualitäts-Capstone macht aus einzelnen Lernbausteinen eine echte Android-Prüfung: Du misst Performance, testest Bedienbarkeit, hinterfragst Datennutzung und kontrollierst Sicherheitsrisiken. Übe das an einer kleinen Compose-App, schreibe deine Findings mit Reproduktionsschritten auf, belege sie mit Tests, Profiler-Daten oder Screenshots und bespreche sie in einem Code-Review. Wenn du erklären kannst, warum ein Problem relevant ist und wie du es prüfen würdest, bist du deutlich näher an belastbarer Release-Qualität.