Welche unerwarteten Probleme können bei der Arbeit mit Koroutinen in Android auftreten?

• Unerwartete Stornierung: Die Coroutine kann implizit storniert werden, z.B. beim Ändern der Geräte-Konfiguration oder beim Schließen von Activity/Fragment, wenn der Lifecycle-Kontext nicht sorgfältig verwaltet wird. Dies kann zu Speicherlecks oder nicht abgeschlossenen Operationen führen.
• Probleme mit dem Kontext (Kontextweitergabe): Die Weitergabe des Coroutine-Kontexts zwischen den Schichten der Anwendung (UI, ViewModel, Repository) erfordert Aufmerksamkeit. Falsche Verwendung des Kontexts kann UI-Blockaden oder Thread-Blockaden verursachen.
• Ressourcenlecks bei unbehandelten Ausnahmen: Nicht behandelte Ausnahmen in Kind-Coroutines können den Eltern-Job implizit stornieren, aber Ressourcen innerhalb der Kind-Coroutine werden möglicherweise nicht freigegeben.
• "Kalte" Flows (Flow) und Lifecycle-Management: Flow ist von Natur aus lazy und erfordert eine aktive Datensammlung. Wenn die Sammlung nicht richtig verwaltet wird (z.B. mit flowWithLifecycle oder collectLatest), kann es zu unerwünschtem Verhalten bei UI- oder Lifecycle-Änderungen kommen.
• Blockierende Aufrufe: Das Einfügen blockierender Aufrufe (z.B. Netzwerk- oder Dateivorgänge) in eine Coroutine, die auf dem Main-Dispatcher läuft (Dispatchers.Main), führt zu ANRs.

// Beispiel für ein potenzielles Problem bei Coroutine-Stornierung bei Konfigurationsänderung
class MyViewModel : ViewModel() {
    fun loadData() {
        viewModelScope.launch {
            // Lange Operation
            delay(5000)
            // Wenn die Activity während des delays neu erstellt wird, wird diese Zeile möglicherweise nicht ausgeführt
            println("Daten geladen")
        }
    }
}

// Beispiel für blockierenden Aufruf auf dem Main-Dispatcher
import kotlinx.coroutines.*

fun performBlockingOperation() {
    runBlocking { // Nicht im UI-Thread verwenden!
        delay(1000) // Blockiert den Thread
    }
}

// Es sollte so sein:
fun performNonBlockingOperation() {
    CoroutineScope(Dispatchers.Default).launch {
        delay(1000) // Blockiert den Haupt-Thread nicht
    }
}