Middle Android (Kotlin) — Android-Interviewfragen

Was ist eine Coroutine, und wie unterscheidet sie sich von einem Thread?

Eine Coroutine ist eine suspendierbare Berechnung, die von der Kotlin-Runtime geplant wird; ein Thread wird vom Betriebssystem geplant. Suspendierung gibt den Thread frei, statt ihn zu blockieren, weshalb sich Tausende Coroutines einen kleinen Pool teilen können. Deshalb hebelt ein blockierender Aufruf innerhalb einer Coroutine den ganzen Sinn aus – er hält genau den Thread, der eigentlich freigegeben werden sollte.

Was ist Structured Concurrency, und was garantiert ein CoroutineScope?

Dass jede in einem Scope gestartete Coroutine dessen Kind ist, sodass das Abbrechen des Scopes alle abbricht und der Scope erst abschließt, wenn sie es tun. In der Praxis ist das viewModelScope – Arbeit stoppt, wenn das ViewModel geleert wird. Ein Start in GlobalScope steigt daraus aus, und so überlebt Arbeit den Screen, der sie gestartet hat.

Was ist der Unterschied zwischen `Flow`, `StateFlow` und `SharedFlow`?

Ein Flow ist kalt – er produziert Werte, wenn er gesammelt wird, einmal pro Collector. StateFlow ist heiß, hält immer einen aktuellen Wert und sendet ihn an jeden neuen Collector, genau das will UI-State. SharedFlow ist heiß ohne aktuellen Wert und eignet sich für Events, die nicht wiederholt werden sollen – ein Navigationsbefehl oder eine Snackbar.

Was ist Recomposition in Compose, und wodurch passiert sie zu oft?

Compose führt Composables erneut aus, deren Eingaben sich geändert haben. Zu oft passiert das, wenn eine Lambda oder ein instabiler Typ bei jedem Render des Parents neu erzeugt wird, oder wenn ein ganzer Screen einen häufig wechselnden Wert liest. Die Fixes sind remember, State so zu heben, dass nur der Teil, der ihn braucht, ihn liest, und stabile Typen – die Recomposition-Zähler im Layout Inspector zeigen dir, wo genau.

Warum ist ein gehaltener `Context` eine häufige Leak-Quelle?

Weil ein Activity Context an einen Screen gebunden ist, und alles Langlebige, das ihn hält, diesen ganzen Screen im Speicher behält. Die üblichen Fälle sind ein mit einer Activity initialisiertes Singleton, eine statische Referenz oder ein nie deregistrierter Listener. Application Context ist richtig für alles, was einen Screen überlebt – kann aber keine themed Views inflaten, weshalb der Fehler trotzdem passiert.

Wie würdest du herausfinden, warum eine App langsam startet?

Erst messen: adb shell am start -W liefert Cold-, Warm- und Hot-Start-Zeiten, und der System-Trace zeigt, was vor dem ersten Frame läuft. Die üblichen Ursachen sind Arbeit in Application.onCreate – besonders SDK-Initialisierung –, synchrones Lesen von Disk oder Netzwerk, und Dinge auf dem Main Thread zu tun, die sich bis nach dem ersten Frame verschieben ließen.

Was ist der Unterschied zwischen `launch` und `async`?

launch startet Arbeit und gibt einen Job ohne Ergebnis zurück; async gibt ein Deferred zurück, das du mit await abwartest. Nutze async nur, wenn du den Wert brauchst, und starte beide, bevor du eines von beiden abwartest, wenn sie parallel laufen sollen. Ein async, dessen Ergebnis nie abgewartet wird, verschluckt seine Exception – ein leiser Weg, einen Crash zu verlieren.

`Serializable` oder `Parcelable` – was und warum?

Parcelable ist die Android-Lösung: Du beschreibst, wie das Objekt geschrieben und gelesen wird, sodass keine Reflection nötig ist und die Datenübergabe zwischen Komponenten messbar schneller ist. Serializable ist das Java-Marker-Interface – fast umsonst zu schreiben, aber langsam zur Laufzeit und mit hohem Allokationsaufwand. In Kotlin verschwindet die Debatte fast, weil @Parcelize das Boilerplate generiert und damit den einzigen echten Grund entfernt, Serializable zu wählen.

Doze, App Standby, `WorkManager` oder ein `Service` – wie wählst du aus?

Doze und App Standby verschieben deine Hintergrundarbeit, wenn das Gerät idle oder die App ungenutzt ist – genau deshalb feuert ein Alarm oder ein Netzwerkaufruf einfach nicht dann, wenn du es erwartet hast. WorkManager ist für aufschiebbare Arbeit, die irgendwann garantiert stattfinden und Prozesstod sowie Neustart überleben muss – Sync, Upload, Cleanup. Ein Foreground Service ist für Arbeit, die der Nutzer gerade bewusst wahrnimmt, etwa Wiedergabe oder Navigation, und muss eine Notification zeigen. Stattdessen zu einem einfachen Background Service zu greifen, ist der Weg, wie Arbeit auf modernem Android still aufhört zu laufen.