CoroutineScope — définition, cycle de vie et travail dans les coroutines

Qu'est-ce que CoroutineScope dans Kotlin ?

CoroutineScope est une interface fondamentale de la bibliothèque kotlinx.coroutines qui sert de conteneur pour les coroutines. Elle définit les limites du cycle de vie des coroutines : lorsque le scope se termine, toutes les coroutines à l'intérieur sont automatiquement annulées.

public interface CoroutineScope {
    public val coroutineContext: CoroutineContext
}

L'interface ne contient qu'un seul champ — coroutineContext. À travers lui, le scope fournit un dispatcher (Dispatcher), un job (Job), un gestionnaire d'exceptions et d'autres éléments de contexte à toutes les coroutines lancées à l'intérieur.

Rôle dans la bibliothèque kotlinx.coroutines

Toutes les fonctions de lancement de coroutines — launch, async, runBlocking — sont des fonctions d'extension sur CoroutineScope. Cela signifie qu'elles ne peuvent être appelées que lorsqu'un objet scope est disponible. Cette conception garantit que chaque coroutine a un parent et un cycle de vie clairement définis.

Où CoroutineScope est utilisé

Dans Android, chaque composant architectural a son propre scope : viewModelScope pour ViewModel, lifecycleScope pour Activity/Fragment. Dans les applications serveur, un scope peut être lié à une requête HTTP ou à un pool de connexions de base de données.

Comment fonctionne CoroutineScope : Job et concurrence structurée

Comprendre le fonctionnement interne de CoroutineScope nécessite une familiarité avec le concept de Job et le principe de concurrence structurée.

Job — la tâche de la coroutine

Chaque coroutine au lancement retourne un objet Job (ou Deferred pour async). Job représente une tâche avec un cycle de vie fini : New, Active, Completing, Completed, Cancelling, Cancelled. Les objets Job forment une structure arborescente :

• Job parent — le scope dans lequel la coroutine a été lancée
• Job fils — chaque coroutine lancée via launch/async
• Annulation du parent → annulation de tous les fils
• Exception dans un fils → annulation du parent (sauf dans supervisorScope)

Le principe de concurrence structurée

Concurrence structurée est un principe architectural clé de Kotlin Coroutines, où le cycle de vie de la coroutine est lié au cycle de vie de son scope. Cela contraste avec le modèle « tirer et oublier », où une coroutine continue de vivre après la fin du scope. Avantages de la concurrence structurée :

• Cycle de vie prévisible — lorsque le scope se termine, toutes les coroutines sont arrêtées
• Gestion automatique des erreurs — une exception dans toute coroutine fille se propage au scope
• Pas de fuites mémoire — aucune coroutine ne reste en cours d'exécution après la fin du scope
• Hiérarchie claire — le code reflète la structure logique des opérations parallèles

Cycle de vie de CoroutineScope

Lorsque scope.cancel() est appelé, le Job du scope passe à l'état Cancelled, ce qui annule récursivement tous les Jobs fils. Après l'annulation, le scope ne peut être réutilisé qu'en créant une nouvelle instance de CoroutineScope.

Création et configuration de CoroutineScope

Vous pouvez créer un CoroutineScope via une fonction d'usine ou en implémentant l'interface dans votre classe. Examinons les deux approches.

Fonction d'usine CoroutineScope()

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

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

La fonction d'usine prend un CoroutineContext et crée un scope avec le contexte spécifié. L'exemple utilise Dispatchers.Default pour les tâches intensives en CPU et SupervisorJob, qui isole les exceptions entre coroutines filles.

Implémentation de l'interface via composition

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

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

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

Nous stockons le scope comme un champ de classe et appelons manuellement cleanup pour l'annuler. Cette approche convient aux composants avec un cycle de vie géré — par exemple, les repositories ou les gestionnaires.

Implémentation via délégation

Kotlin permet de déléguer l'implémentation de CoroutineScope via le mot-clé by :

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

Cette approche est pratique lorsque la classe elle-même est un scope et souhaite fournir des méthodes de lancement de coroutines. Cependant, attention : la classe hérite de toutes les méthodes de CoroutineScope, y compris cancel, ce qui peut briser l'encapsulation.

GlobalScope vs CoroutineScope personnalisé

GlobalScope est un singleton CoroutineScope pour toute l'application. Son utilisation en code de production n'est officiellement pas recommandée.

Problèmes avec GlobalScope

• Absence de concurrence structurée — les coroutines dans GlobalScope ne sont pas liées au cycle de vie du composant
• Fuites mémoire — une coroutine peut continuer à s'exécuter après la fermeture de l'Activity/Fragment
• Tests difficiles — GlobalScope ne peut pas être remplacé dans les tests
• Consommation non contrôlée des ressources — de nombreuses coroutines peuvent s'exécuter plus longtemps que prévu

Quand GlobalScope est justifié

JetBrains autorise GlobalScope uniquement dans des scénarios rares : processus d'arrière-plan au niveau de l'application qui doivent vivre même après la fermeture de toutes les Activities (par exemple, synchronisation de données, analytique). Mais même dans ces cas, il est préférable de créer votre propre scope avec CoroutineScope(SupervisorJob()).

Recommandation

Utilisez toujours un CoroutineScope personnalisé avec une gestion explicite du cycle de vie. Dans Android, ce sont viewModelScope et lifecycleScope. Dans les applications serveur, créez un scope pour chaque requête ou pool de connexions.

coroutineScope vs supervisorScope : quelle est la différence

Les deux fonctions sont des fonctions suspend qui créent un scope temporaire pour les tâches parallèles, mais leur comportement face aux exceptions diffère fondamentalement.

Quand choisir coroutineScope

Utilisez coroutineScope lorsque plusieurs opérations parallèles forment une seule opération atomique. Par exemple, charger des données depuis trois serveurs : si une requête échoue, les autres n'ont pas de sens.

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

Si getProduct ou getReviews lève une exception — les deux coroutines sont annulées et l'exception est propagée au code appelant.

Quand choisir supervisorScope

Utilisez supervisorScope lorsque les opérations parallèles ne dépendent pas les unes des autres. Par exemple, charger les données de profil dans plusieurs sections indépendantes : si la section des recommandations échoue, l'en-tête du profil et la liste d'amis doivent s'afficher.

Erreurs courantes avec CoroutineScope

Examinons les erreurs les plus fréquentes des développeurs lors de l'utilisation de CoroutineScope dans Kotlin.

Erreur 1 : Oublier d'annuler le scope

Le scénario le plus courant de fuite de coroutine est la création d'un scope sans appeler cancel à la fin du composant. Si le scope n'est pas annulé, les coroutines continuent de s'exécuter, maintenant des références aux objets. Dans Android, utilisez viewModelScope ou lifecycleScope, qui sont annulés automatiquement.

Erreur 2 : Utiliser GlobalScope dans Activity ou Fragment

GlobalScope ignore le cycle de vie des composants Android. Une coroutine lancée dans GlobalScope après la fermeture d'une Activity continuera à s'exécuter et tentera de mettre à jour l'UI — ce qui provoquera un crash. Utilisez toujours lifecycleScope pour les composants UI.

Erreur 3 : Réutiliser un scope annulé

Après avoir appelé cancel(), le scope ne peut pas être réutilisé — toutes les coroutines à l'intérieur sont déjà terminées. Créez une nouvelle instance de CoroutineScope via la fonction d'usine. Job() ne prend pas en charge la réactivation.

Erreur 4 : Délégation incorrecte de l'interface CoroutineScope

En déléguant avec by, la classe obtient une méthode cancel() publique qui peut être appelée de n'importe où, brisant l'encapsulation. Stockez le scope comme un champ privé plutôt que de déléguer l'interface.