Main Safety: sichere Suspend-Funktionen

Main Safety ist eine kleine Regel mit großer Wirkung: Deine Suspend-Funktionen sollen sicher vom Main Thread aus aufrufbar sein. Das ist besonders wichtig, weil ViewModels, Compose-UI und viele Jetpack-APIs nah am Main Thread arbeiten. Wenn du dort versehentlich Netzwerkzugriffe, Datenbankabfragen oder Dateioperationen blockierend ausführst, wirkt die App träge, Animationen ruckeln oder Android zeigt sogar einen ANR-Fehler an.

Was ist das?

Main Safety bedeutet: Eine Funktion mit suspend darf von Code aufgerufen werden, der gerade auf dem Main Thread läuft, ohne diesen Thread zu blockieren. Die Funktion selbst ist dafür verantwortlich, schwere oder blockierende Arbeit auf einen passenden Dispatcher zu verschieben.

Das mentale Modell ist wichtig. suspend heißt nicht automatisch: läuft im Hintergrund. Eine Suspend-Funktion kann pausieren, ohne einen Thread zu blockieren, aber sie läuft erst einmal im Coroutine-Kontext des Aufrufers. Wenn dein viewModelScope.launch { repository.loadUser() } auf Dispatchers.Main startet, dann beginnt auch loadUser() dort, solange die Funktion den Kontext nicht ändert oder intern eine nicht blockierende API verwendet.

Im Android-Kontext schützt Main Safety die Reaktionsfähigkeit der UI. Der Main Thread verarbeitet Eingaben, zeichnet Frames und führt viele Lifecycle-Callbacks aus. Compose, klassische Views, LiveData, StateFlow-Sammlungen und Navigation hängen indirekt daran. Wenn du ihn mit Thread.sleep, synchronem Datei-I/O, teurer JSON-Verarbeitung oder einer blockierenden Datenbankoperation belegst, kann die Oberfläche nicht sauber weiterarbeiten.

Für Lernende ist die wichtigste Grenze: Der Aufrufer soll nicht raten müssen, welchen Dispatcher eine Suspend-API braucht. Wenn eine Repository-Funktion Daten von einer REST-API lädt, aus einer Datei liest oder ein großes Objekt parst, dann kapselt diese Funktion die Dispatcher-Entscheidung. Das ViewModel ruft sie auf und kümmert sich um UI-State, nicht um Thread-Details.

Diese Regel passt zur modernen Android-Architektur: UI-Schicht und ViewModel bleiben schlank, die Data Layer übernimmt Datenzugriff und technische Details. Main Safety macht diese Schichten robuster, weil eine API an ihrer Signatur klar wirkt: suspend fun loadArticle(id: String): Article kann aus UI-nahem Coroutine-Code genutzt werden. Der Name sagt, was passiert; der Aufrufer muss nicht zusätzlich wissen, dass darunter ein blockierender Parser oder eine lokale Datei steckt.

Wie funktioniert es?

Coroutines arbeiten mit Kontexten. Ein wichtiger Teil dieses Kontextes ist der Dispatcher. Er entscheidet, auf welchem Thread oder Thread-Pool Coroutine-Code ausgeführt wird. In Android siehst du vor allem Dispatchers.Main, Dispatchers.IO und Dispatchers.Default.

Dispatchers.Main ist für UI-nahe Arbeit gedacht. Dazu zählen State-Updates im ViewModel, Interaktion mit Compose-State, Navigation und kurze Berechnungen, die keine merkliche Last erzeugen. Dispatchers.IO ist für blockierende Ein- und Ausgabe gedacht, etwa Dateien, SharedPreferences-Altcode, Netzwerkbibliotheken ohne echte Suspend-Unterstützung oder Datenbankzugriffe, wenn die konkrete API blockiert. Dispatchers.Default passt eher zu CPU-lastiger Arbeit, zum Beispiel Sortierung großer Listen, Diff-Berechnungen, Verschlüsselung oder Parsing größerer Datenmengen.

Die Kerntechnik für Main Safety ist withContext(...). Damit wechselst du innerhalb einer Suspend-Funktion gezielt den Dispatcher und kehrst danach wieder in den vorherigen Kontext zurück. Das ist kein globaler Modus, sondern ein klar begrenzter Block. Genau dadurch bleibt der Code lesbar: Du siehst, welcher Teil potenziell teuer ist.

Wichtig ist auch die Unterscheidung zwischen suspendierenden und blockierenden APIs. Eine gut geschriebene Netzwerkfunktion von Retrofit mit suspend blockiert den Main Thread nicht, weil die Bibliothek intern asynchron arbeitet. Eine normale Dateioperation wie inputStream.readBytes() kann dagegen blockieren. Sie wird nicht dadurch ungefährlich, dass du sie in eine Suspend-Funktion schreibst. suspend ist keine automatische Thread-Magie.

Für Flow gilt dieselbe Denkweise. Ein Flow kann auf dem Main Thread gesammelt werden, zum Beispiel aus Compose heraus über Lifecycle-bewusste APIs. Die Arbeit, die Werte erzeugt oder transformiert, sollte aber dort laufen, wo sie hingehört. Mit flowOn(Dispatchers.IO) kannst du den Kontext für den vorgelagerten Teil eines Flows ändern. Auch hier gilt: Der Verbraucher des Flows soll nicht wissen müssen, dass die Quelle intern eine Datei oder Datenbank liest.

In der täglichen Android-Entwicklung zeigt sich Main Safety oft in Repositorys und Use Cases. Ein ViewModel startet eine Coroutine im viewModelScope, ruft eine Suspend-Funktion auf und schreibt danach einen UI-State. Wenn die Suspend-Funktion Main-safe ist, bleibt dieser Code sauber:

class ArticleViewModel(
    private val repository: ArticleRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow<ArticleUiState>(ArticleUiState.Loading)
    val uiState: StateFlow<ArticleUiState> = _uiState

    fun load(id: String) {
        viewModelScope.launch {
            _uiState.value = ArticleUiState.Loading
            _uiState.value = try {
                ArticleUiState.Success(repository.loadArticle(id))
            } catch (e: IOException) {
                ArticleUiState.Error("Artikel konnte nicht geladen werden.")
            }
        }
    }
}

Das ViewModel gibt hier keinen Dispatcher an. Das ist Absicht. Es beschreibt den UI-Ablauf: Laden, Erfolg, Fehler. Die Data Layer entscheidet, ob und wo Thread-Wechsel nötig sind. Dadurch bleibt die Architektur testbarer und leichter zu ändern. Wenn später statt einer Datei eine Datenbank oder ein Remote-Endpoint genutzt wird, muss das ViewModel nicht angepasst werden.

In der Praxis

Stell dir vor, du hast eine Repository-Funktion, die einen Artikel aus einer lokalen JSON-Datei liest und parst. Datei-I/O und Parsing können teuer sein. Diese Funktion muss Main-safe sein, weil sie aus einem ViewModel oder aus einem Use Case aufgerufen werden kann, der selbst im Main-Kontext läuft.

class ArticleRepository(
    private val context: Context,
    private val json: Json,
    private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO,
    private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {

    suspend fun loadArticle(id: String): Article {
        val rawJson = withContext(ioDispatcher) {
            context.assets.open("articles/$id.json").bufferedReader().use { reader ->
                reader.readText()
            }
        }

        return withContext(defaultDispatcher) {
            json.decodeFromString<Article>(rawJson)
        }
    }
}

Diese Funktion kann vom Main Thread aus aufgerufen werden, ohne ihn während des Dateilesens zu blockieren. Zusätzlich verschiebt sie das Parsing auf Dispatchers.Default, weil dabei CPU-Arbeit entstehen kann. In kleinen Apps würdest du Parsing und I/O manchmal zusammen auf Dispatchers.IO legen. Für Lernzwecke ist die Trennung aber hilfreich: Du erkennst, dass nicht jede Hintergrundarbeit denselben Charakter hat.

Eine wichtige Entscheidungsregel lautet: Die Funktion, die blockierende Arbeit kennt, wechselt den Dispatcher. Nicht der Aufrufer. Wenn loadArticle() weiß, dass sie eine Datei liest, dann gehört withContext(ioDispatcher) dort hinein. Wenn ein ViewModel stattdessen viewModelScope.launch(Dispatchers.IO) nutzt, verschiebst du zu viel Verantwortung nach oben. Danach musst du für UI-State wieder zurück auf Main wechseln, und die Schichten vermischen sich schneller.

Für Tests ist es sinnvoll, Dispatcher nicht hart im Code zu verstecken. Im Beispiel werden ioDispatcher und defaultDispatcher injiziert. Dadurch kannst du im Test kontrollierte Test-Dispatcher verwenden. Das macht Tests stabiler und verhindert, dass echte Hintergrund-Threads dein Ergebnis zeitlich schwer nachvollziehbar machen. Auch im Code-Review ist diese Form leichter zu prüfen: Du siehst direkt, welche Arbeit wohin verschoben wird.

Eine typische Stolperfalle ist diese Funktion:

suspend fun loadArticle(id: String): Article {
    val rawJson = context.assets.open("articles/$id.json")
        .bufferedReader()
        .use { it.readText() }

    return json.decodeFromString(rawJson)
}

Sie sieht harmlos aus, weil suspend davorsteht. Trotzdem liest sie synchron aus den Assets und parst direkt im aktuellen Coroutine-Kontext. Wird sie aus dem ViewModel aufgerufen, kann sie auf dem Main Thread laufen. Bei kleinen Dateien merkst du vielleicht nichts. Bei größeren Dateien, langsameren Geräten oder mehreren Aufrufen hintereinander wird die UI spürbar belastet. Genau solche Fehler bleiben in der Entwicklung oft lange unsichtbar, weil High-End-Testgeräte mehr verzeihen als reale Geräte deiner Nutzer.

Eine weitere Stolperfalle ist ein zu grober Dispatcher-Wechsel im ViewModel:

fun load(id: String) {
    viewModelScope.launch(Dispatchers.IO) {
        val article = repository.loadArticle(id)
        _uiState.value = ArticleUiState.Success(article)
    }
}

Das kann funktionieren, ist aber als Standardmuster ungünstig. Das ViewModel verliert seine klare UI-Rolle, und du gewöhnst dir an, Dispatcher dort zu setzen, wo die eigentliche Arbeit gar nicht beschrieben ist. Besser ist: ViewModel auf Main starten, Main-safe Suspend-API aufrufen, Ergebnis als State veröffentlichen.

Bei Flow sieht ein ähnliches Muster so aus:

fun observeArticles(): Flow<List<Article>> {
    return articleDao.observeArticles()
        .map { entities ->
            entities.map { entity -> entity.toDomain() }
        }
        .flowOn(Dispatchers.Default)
}

Hier bestimmt flowOn, dass die vorgelagerte Mapping-Arbeit nicht beim Collector auf Main ausgeführt werden muss. In einer echten App hängt die genaue Platzierung davon ab, ob dein DAO bereits selbst Dispatcher oder asynchrone Mechanik nutzt. Die Regel bleibt gleich: Teure Erzeugung oder Transformation sollte nicht heimlich beim UI-Collector landen.

Du kannst dein Verständnis praktisch prüfen, indem du im Debugger auf den aktuellen Thread achtest oder gezielt Log-Ausgaben einbaust. Für Code-Reviews hilft eine kurze Frage: Kann diese Suspend-Funktion gefahrlos aus viewModelScope.launch { ... } aufgerufen werden? Wenn die Antwort nur lautet „ja, solange der Aufrufer vorher auf IO wechselt“, ist die API nicht Main-safe.

Auch Tests können das Thema greifbar machen. Schreibe einen Unit-Test, der eine Repository-Funktion mit einem Test-Dispatcher ausführt, und prüfe, ob sie ohne zusätzliche Dispatcher-Vorgabe des Aufrufers funktioniert. Bei komplexeren Fällen kannst du außerdem prüfen, ob blockierende Abhängigkeiten hinter injizierten Dispatchern liegen. Es geht dabei nicht darum, jeden Thread-Wechsel pedantisch zu testen, sondern darum, die Architekturregel sichtbar zu machen.

In Compose ist Main Safety besonders nützlich, weil UI-Code sehr schnell unübersichtlich wird, wenn technische Thread-Entscheidungen dort landen. Ein LaunchedEffect(articleId) oder ein ViewModel-Aufruf aus der UI sollte nicht darüber nachdenken müssen, ob ein Repository Dateien, Netzwerk oder Cache nutzt. Compose beschreibt Zustand und Darstellung. Die Datenquelle liefert Main-safe APIs. Diese Trennung macht deinen Code ruhiger und leichter wartbar.

Fazit

Main Safety sorgt dafür, dass Suspend-APIs ehrlich benutzbar sind: Du kannst sie aus UI-nahem Coroutine-Code aufrufen, ohne versteckte Blockaden auf dem Main Thread zu riskieren. Merke dir die Praxisregel: Wer blockierende Arbeit ausführt, setzt intern den passenden Dispatcher; ViewModels und Compose bleiben bei UI-State und Ablaufsteuerung. Prüfe das aktiv in deinem nächsten Code-Review, setze einen Breakpoint in eine Repository-Funktion und frage dich bei jeder Suspend-API, ob sie wirklich sicher vom Main Thread aus aufgerufen werden kann.