CoroutineScope — was es ist, Lebenszyklus und Arbeitsweise in Koroutinen

Was ist CoroutineScope in Kotlin?

CoroutineScope ist ein fundamentales Interface aus der Bibliothek kotlinx.coroutines, das als Container für Koroutinen dient. Es definiert die Grenzen des Koroutinen-Lebenszyklus: Wenn der Scope abgeschlossen wird, werden alle Koroutinen darin automatisch abgebrochen.

public interface CoroutineScope {
    public val coroutineContext: CoroutineContext
}

Das Interface enthält nur ein Feld — coroutineContext. Darüber stellt der Scope einen Dispatcher, einen Job, einen Ausnahmebehandler und andere Kontextelemente für alle darin gestarteten Koroutinen bereit.

Rolle in der Bibliothek kotlinx.coroutines

Alle Funktionen zum Starten von Koroutinen — launch, async, runBlocking — sind Erweiterungsfunktionen auf CoroutineScope. Das bedeutet, sie können nur aufgerufen werden, wenn ein Scope-Objekt verfügbar ist. Dieses Design stellt sicher, dass jede Koroutine einen klar definierten übergeordneten und Lebenszyklus hat.

Wo CoroutineScope verwendet wird

In Android hat jede Architekturkomponente ihren eigenen Scope: viewModelScope für ViewModel, lifecycleScope für Activity/Fragment. In Serveranwendungen kann ein Scope an eine HTTP-Anfrage oder einen Datenbankverbindungspool gebunden werden.

Wie CoroutineScope funktioniert: Job und strukturierte Nebenläufigkeit

Das Verständnis der inneren Arbeitsweise von CoroutineScope erfordert Vertrautheit mit dem Konzept des Job und dem Prinzip der strukturierten Nebenläufigkeit.

Job — die Aufgabe der Koroutine

Jede Koroutine gibt beim Start ein Job-Objekt (oder Deferred für async) zurück. Job repräsentiert eine Aufgabe mit einem endlichen Lebenszyklus: New, Active, Completing, Completed, Cancelling, Cancelled. Job-Objekte bilden eine Baumstruktur:

• Übergeordneter Job — der Scope, in dem die Koroutine gestartet wurde
• Untergeordneter Job — jede Koroutine, die über launch/async gestartet wurde
• Abbruch des Übergeordneten → Abbruch aller untergeordneten
• Ausnahme in einem Kind → Abbruch des Übergeordneten (außer in supervisorScope)

Das Prinzip der strukturierten Nebenläufigkeit

Strukturierte Nebenläufigkeit ist ein zentrales Architekturprinzip von Kotlin Coroutines, bei dem der Lebenszyklus der Koroutine an den Lebenszyklus ihres Scopes gebunden ist. Dies steht im Gegensatz zum „Feuer-und-vergiss“-Modell, bei dem eine Koroutine nach Abschluss des Scopes weiterlebt. Vorteile der strukturierten Nebenläufigkeit:

• Vorhersagbarer Lebenszyklus — wenn der Scope abgeschlossen wird, werden alle Koroutinen garantiert gestoppt
• Automatische Fehlerbehandlung — eine Ausnahme in einer untergeordneten Koroutine breitet sich zum Scope aus
• Keine Speicherlecks — keine Koroutine bleibt nach Abschluss des Scopes in Ausführung
• Klare Hierarchie — der Code spiegelt die logische Struktur paralleler Operationen wider

Lebenszyklus von CoroutineScope

Wenn scope.cancel() aufgerufen wird, wechselt der Job des Scopes in den Zustand Cancelled, was rekursiv alle untergeordneten Jobs abbricht. Nach dem Abbruch kann der Scope nur wiederverwendet werden, wenn eine neue CoroutineScope-Instanz erstellt wird.

Erstellung und Konfiguration von CoroutineScope

Sie können einen CoroutineScope über eine Factory-Funktion oder durch Implementierung des Interfaces in Ihrer Klasse erstellen. Sehen wir uns beide Ansätze an.

Factory-Funktion CoroutineScope()

val scope = CoroutineScope(Dispatchers.Default + SupervisorJob())

scope.launch {
    println("Running on ${Thread.currentThread().name}")
}

Die Factory-Funktion nimmt einen CoroutineContext entgegen und erstellt einen Scope mit dem angegebenen Kontext. Das Beispiel verwendet Dispatchers.Default für CPU-intensive Aufgaben und SupervisorJob, der Ausnahmen zwischen untergeordneten Koroutinen isoliert.

Implementierung des Interfaces durch Komposition

class MyRepository {
    private val scope = CoroutineScope(Dispatchers.IO + Job())

    suspend fun fetchData(): Data = scope.async {
        api.getData()
    }.await()

    fun cleanup() {
        scope.cancel()
    }
}

Wir speichern den Scope als Klassenfeld und rufen manuell cleanup auf, um ihn abzubrechen. Dieser Ansatz eignet sich für Komponenten mit verwaltetem Lebenszyklus — zum Beispiel Repositories oder Manager.

Implementierung durch Delegation

Kotlin ermöglicht die Delegation der CoroutineScope-Implementierung über das Schlüsselwort by:

class DataLoader : CoroutineScope by CoroutineScope(Dispatchers.IO) {
    fun load() {
        launch {
            // coroutine runs in DataLoader scope
        }
    }
}

Dieser Ansatz ist praktisch, wenn die Klasse selbst ein Scope ist und Methoden zum Starten von Koroutinen bereitstellen möchte. Seien Sie jedoch vorsichtig: Die Klasse erbt alle Methoden von CoroutineScope, einschließlich cancel, was die Kapselung brechen kann.

GlobalScope vs benutzerdefinierter CoroutineScope

GlobalScope ist ein Singleton-CoroutineScope für die gesamte Anwendung. Seine Verwendung in Produktionscode wird offiziell nicht empfohlen.

Probleme mit GlobalScope

• Fehlende strukturierte Nebenläufigkeit — Koroutinen in GlobalScope sind nicht an den Komponentenlebenszyklus gebunden
• Speicherlecks — eine Koroutine kann nach dem Schließen der Activity/Fragment weiter ausgeführt werden
• Schwierige Tests — GlobalScope kann in Tests nicht ersetzt werden
• Unkontrollierte Ressourcennutzung — viele Koroutinen können länger als erwartet ausgeführt werden

Wann GlobalScope gerechtfertigt ist

JetBrains erlaubt GlobalScope nur in seltenen Szenarien: anwendungsweite Hintergrundprozesse, die auch nach dem Schließen aller Activities weiterlaufen sollen (z. B. Datensynchronisation, Analytik). Aber selbst in diesen Fällen ist es vorzuziehen, einen eigenen Scope mit CoroutineScope(SupervisorJob()) zu erstellen.

Empfehlung

Verwenden Sie immer einen benutzerdefinierten CoroutineScope mit explizitem Lebenszyklusmanagement. In Android sind dies viewModelScope und lifecycleScope. In Serveranwendungen erstellen Sie einen Scope für jede Anfrage oder jeden Verbindungspool.

coroutineScope vs supervisorScope: Was ist der Unterschied

Beide Funktionen sind Suspend-Funktionen, die einen temporären Scope für parallele Aufgaben erstellen, aber ihr Verhalten bei Ausnahmen unterscheidet sich grundlegend.

Wann coroutineScope wählen

Verwenden Sie coroutineScope, wenn mehrere parallele Operationen eine einzige atomare Operation bilden. Zum Beispiel das Laden von Daten von drei Servern: Wenn eine Anfrage fehlschlägt, sind die übrigen sinnlos.

suspend fun loadProductPage(): ProductPage = coroutineScope {
    val product = async { api.getProduct() }
    val reviews = async { api.getReviews() }
    ProductPage(product.await(), reviews.await())
}

Wenn getProduct oder getReviews eine Ausnahme auslöst — werden beide Koroutinen abgebrochen und die Ausnahme an den aufrufenden Code weitergegeben.

Wann supervisorScope wählen

Verwenden Sie supervisorScope, wenn parallele Operationen nicht voneinander abhängen. Zum Beispiel das Laden von Profildaten in mehreren unabhängigen Abschnitten: Wenn der Abschnitt mit Empfehlungen fehlschlägt, sollten die Profilkopfzeile und die Freundesliste angezeigt werden.

Häufige Fehler bei der Arbeit mit CoroutineScope

Betrachten wir die häufigsten Entwicklerfehler bei der Verwendung von CoroutineScope in Kotlin.

Fehler 1: Vergessen, den Scope abzubrechen

Das häufigste Szenario für Koroutinen-Leaks ist das Erstellen eines Scopes ohne Aufruf von cancel beim Beenden der Komponente. Wenn der Scope nicht abgebrochen wird, laufen die Koroutinen weiter und halten Referenzen auf Objekte. Verwenden Sie in Android viewModelScope oder lifecycleScope, die automatisch abgebrochen werden.

Fehler 2: Verwendung von GlobalScope in Activity oder Fragment

GlobalScope ignoriert den Android-Komponentenlebenszyklus. Eine in GlobalScope gestartete Koroutine, nachdem eine Activity geschlossen wurde, wird weiter ausgeführt und versucht, die UI zu aktualisieren — was zu einem Absturz führt. Verwenden Sie für UI-Komponenten immer lifecycleScope.

Fehler 3: Wiederverwendung eines abgebrochenen Scopes

Nach dem Aufruf von cancel() kann der Scope nicht wiederverwendet werden — alle Koroutinen darin sind bereits abgeschlossen. Erstellen Sie eine neue CoroutineScope-Instanz über die Factory-Funktion. Job() unterstützt keine Reaktivierung.

Fehler 4: Falsche Delegation des CoroutineScope-Interfaces

Bei der Delegation mit by erhält die Klasse eine öffentliche cancel()-Methode, die von überall aufgerufen werden kann und die Kapselung bricht. Speichern Sie den Scope als privates Feld, anstatt das Interface zu delegieren.