viewModelScope: Was es ist, Bindung an ViewModel und Funktionsweise in Android

Was ist viewModelScope in Android?

viewModelScope ist eine Erweiterungseigenschaft für das ViewModel-Interface, die in der Bibliothek lifecycle-viewmodel-ktx (ab Version 2.1.0) hinzugefügt wurde. Sie bietet einen gebrauchsfertigen CoroutineScope, der an den Lebenszyklus von ViewModel gebunden ist.

// Internal structure (simplified)
val ViewModel.viewModelScope: CoroutineScope
    get() {
        val scope = this.getTag(JOB_KEY)
        if (scope != null) return scope
        return CoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)
            .also { setTag(JOB_KEY, it) }
    }

Der Scope wird beim ersten Zugriff lazy erstellt und über setTag zwischengespeichert. Er verwendet SupervisorJob, was bedeutet, dass eine Ausnahme in einer Child-Coroutine die anderen nicht abbricht. Der Standard-Dispatcher ist Dispatchers.Main.immediate, der Code auf dem Hauptthread ohne zusätzliche Dispatchierung ausführt, wenn bereits auf Main.

Wie viewModelScope über die Bereinigung benachrichtigt wird

Wenn die ViewModel den Lebenszyklus verlässt (Activity beendet oder Fragment entfernt), ruft das System clear() auf, das onCleared() auslöst. In diesem Callback bricht viewModelScope seinen Job ab, der rekursiv alle aktiven Coroutinen beendet. Der Mechanismus wird über die Closeable-Schnittstelle implementiert, bei der der Job des Scopes als Ressource für das automatische Schließen registriert wird.

Wie viewModelScope funktioniert: Bindung an den ViewModel-Lebenszyklus

Der Mechanismus der Bindung von viewModelScope an den ViewModel-Lebenszyklus basiert auf Tagging und dem onCleared-Callback. Betrachten wir es Schritt für Schritt.

Schritt 1: Erstellung des Scopes beim ersten Zugriff

Wenn die ViewModel viewModelScope.launch { ... } ausführt, prüft der Getter, ob bereits ein Scope unter dem Tag JOB_KEY gespeichert ist. Wenn kein Scope existiert, wird eine neue Instanz von CoroutineScope(SupervisorJob() + Dispatchers.Main.immediate) erstellt. Der Scope wird über eine interne Tag-Map innerhalb der ViewModel gespeichert.

Schritt 2: Lebenszyklus der Coroutinen

Alle über viewModelScope.launch oder viewModelScope.async gestarteten Coroutinen werden zu Kindern des SupervisorJob des Scopes. Sie laufen auf dem Hauptthread (sofern kein anderer Dispatcher über withContext angegeben wurde). Solange die ViewModel lebt, können Coroutinen aktiv, suspendiert oder abgeschlossen sein.

Schritt 3: Abbruch bei onCleared

Wenn das System die ViewModel zerstört, wird ViewModel.clear() aufgerufen. Innerhalb von clear() geschieht Folgendes:

• onCleared() wird für die benutzerdefinierte Bereinigungslogik aufgerufen
• Alle über addCloseable registrierten Closeable-Ressourcen werden geschlossen
• Der Job von viewModelScope wechselt in den Zustand Cancelled
• Alle Child-Coroutinen werden rekursiv abgebrochen
• Referenzen auf den Scope werden für die Garbage Collection freigegeben

Rotationsbeständigkeit

Bei Bildschirmrotation wird die Activity neu erstellt, aber die ViewModel überlebt (dank ViewModelStoreOwner). Das bedeutet, dass viewModelScope aktiv bleibt und Coroutinen ohne Unterbrechung weiterlaufen. Nach der Neuerstellung der Activity wird dieselbe ViewModel (und derselbe Scope) wiederverwendet — das Laden von Daten beginnt nicht von vorne.

viewModelScope in der MVVM-Architektur

MVVM (Model-View-ViewModel) ist die von Google empfohlene Architektur für Android-Anwendungen. viewModelScope nimmt darin eine zentrale Rolle als Ausführender asynchroner Operationen ein.

Die Rolle von viewModelScope in den Architekturschichten

Die ViewModel startet Coroutinen über viewModelScope, in denen sie suspend-Funktionen des Repository aufruft. Das Ergebnis wird in StateFlow umgewandelt, das von der UI-Schicht beobachtet wird. Dieses Design gewährleistet klare Trennung der Verantwortlichkeiten und unabhängige Testbarkeit jeder Schicht.

Warum viewModelScope in ViewModel und nicht in Fragment

Wenn Coroutinen von einem Fragment aus gestartet würden, würden sie bei Bildschirmrotation mit der Zerstörung des Fragments abgebrochen. ViewModel überlebt die Rotation, daher laufen in ihrem Scope gestartete Coroutinen weiter. Dies ist der Hauptvorteil von viewModelScope gegenüber lifecycleScope beim Laden von Daten.

Beispiele zur Verwendung von viewModelScope

Betrachten wir drei praktische Szenarien zur Verwendung von viewModelScope in einer Android-Anwendung mit Kotlin.

Beispiel 1: Daten laden bei ViewModel-Erstellung

class ProfileViewModel(
    private val repo: ProfileRepository
) : ViewModel() {

    private val _profile = MutableStateFlow<Profile?>(null)
    val profile: StateFlow<Profile?> = _profile

    init {
        loadProfile()
    }

    private fun loadProfile() {
        viewModelScope.launch {
            val result = repo.getProfile()
            _profile.value = result
        }
    }
}

Im init-Block beginnt das Laden des Profils sofort. Die Coroutine läuft auf dem Hauptthread (standardmäßig). Das Repository verwendet withContext(Dispatchers.IO) für die Netzwerkanfrage innerhalb seiner suspend-Funktion, sodass sich die ViewModel nicht um Thread-Wechsel kümmern muss.

Beispiel 2: Fehlerbehandlung mit sealed class

sealed class UiState {
    object Loading : UiState()
    data class Success(val data: List<Item>) : UiState()
    data class Error(val message: String) : UiState()
}

fun fetchItems() {
    _state.value = UiState.Loading
    viewModelScope.launch {
        try {
            val items = repo.getItems()
            _state.value = UiState.Success(items)
        } catch (e: Exception) {
            _state.value = UiState.Error(e.message ?: "Unknown error")
        }
    }
}

Der UI-Zustand wird durch eine sealed class UiState beschrieben. Die ViewModel aktualisiert den Zustand bei jeder Änderung. Das Fragment abonniert StateFlow und reagiert nur auf den aktuellen Zustand, wobei veraltete Aufrufe von früheren Rotationen ignoriert werden.

Beispiel 3: Vorherige Coroutine bei neuer Anfrage abbrechen

private var searchJob: Job? = null

fun search(query: String) {
    searchJob?.cancel()
    searchJob = viewModelScope.launch {
        delay(300)
        val results = repo.search(query)
        _searchResults.value = results
    }
}

Bei jeder neuen Suchanfrage wird die vorherige Coroutine abgebrochen. delay(300) implementiert Entprellung — die Suche wird erst nach 300 ms Inaktivität ausgeführt. Dies reduziert die Serverlast und verhindert veraltete Ergebnisse.

viewModelScope vs lifecycleScope: Wann was wählen

Beide Scopes werden von der AndroidX Lifecycle-Bibliothek bereitgestellt, sind jedoch an unterschiedliche Lebenszyklen gebunden. Die Wahl hängt von der Art der Aufgabe ab.

Vergleich der Scopes

Google-Empfehlungen

Google empfiehlt die Verwendung von viewModelScope für alle Aufgaben zum Laden und Verarbeiten von Daten. lifecycleScope sollte für Operationen verwendet werden, die an einen bestimmten Moment des UI-Lebenszyklus gebunden sind — zum Beispiel das Starten einer Animation beim ersten Erscheinen des Bildschirms oder das Abonnieren von Standortaktualisierungen, die beim Verlassen des Bildschirms gestoppt werden sollen.

Häufige Fehler bei der Arbeit mit viewModelScope

Selbst in einer gut dokumentierten Android-API machen Entwickler typische Fehler. Betrachten wir vier der häufigsten Probleme.

Fehler 1: UI nach Scope-Abbruch aktualisieren

Der heimtückischste Fehler ist der Versuch, StateFlow oder LiveData zu aktualisieren, nachdem die ViewModel bereinigt wurde. Obwohl viewModelScope bei onCleared() abgebrochen wird, kann eine Coroutine Code ausführen, bevor der Abbruch wirksam wird. Verwenden Sie isActive zur Überprüfung oder verlassen Sie sich auf den Abschluss des catch-Blocks.

Fehler 2: Coroutinen ohne Berücksichtigung von SupervisorJob starten

viewModelScope verwendet intern SupervisorJob, das Fehler zwischen Coroutinen isoliert. Wenn Sie jedoch eine Coroutine mit einem eigenen Job() innerhalb von viewModelScope.launch starten, wird diese Coroutine zu einem Kind von SupervisorJob, ist aber nicht vor Abbruch durch Fehler in anderen Coroutinen geschützt.

Fehler 3: Zu viele Coroutinen in einem Scope

Obwohl viewModelScope keine strikte Grenze hat, können tausende aktive Coroutinen das System verlangsamen. Verwenden Sie für lange Datenlisten Flow mit collectLatest anstatt separate Coroutinen für jedes Element zu erstellen.

Fehler 4: GlobalScope statt viewModelScope verwenden

Wenn versehentlich GlobalScope statt viewModelScope importiert wird, wird die Coroutine beim Bereinigen der ViewModel nicht abgebrochen. Dies führt zu Speicherlecks und potenziellen Abstürzen. Stellen Sie immer sicher, dass Coroutinen über viewModelScope gestartet werden, insbesondere in Fragment-Unterklassen.