Coroutine Builder : qu'est-ce que c'est, types de constructeurs de coroutines et comment ils fonctionnent

Qu'est-ce qu'un Coroutine Builder ?

Coroutine Builder est une fonction d'extension de Kotlin qui prend un CoroutineScope et un bloc suspend, créant et lançant une nouvelle coroutine. Chaque constructeur définit comment la coroutine sera exécutée : avec ou sans retour de résultat, avec blocage de thread ou de manière asynchrone. Les constructeurs sont les points d'entrée dans le modèle de coroutines du langage.

Tous les constructeurs fonctionnent via CoroutineScope, qui gère le cycle de vie des coroutines filles. Lorsqu'un scope est annulé, toutes les coroutines lancées via celui-ci sont automatiquement annulées — c'est le principe de la concurrence structurée. Cette approche empêche les fuites de coroutines et garantit une terminaison prévisible.

import kotlinx.coroutines.*

fun main() = runBlocking {
    // Les constructeurs s'exécutent dans CoroutineScope
    val job = launch {
        delay(1000L)
        println("Monde !")
    }
    println("Bonjour,")
    job.join()
}

Principaux types de constructeurs de coroutines

Kotlin fournit quatre constructeurs de coroutines intégrés : launch, async, runBlocking et produce. Chacun a son propre type de retour et son domaine d'application. Pour le développement mobile Android, les principaux sont launch et async — ils fonctionnent de manière non bloquante et s'intègrent aux composants architecturaux.

Chaque constructeur accepte des paramètres supplémentaires : CoroutineStart (stratégie de lancement), CoroutineContext (répartiteur, exceptions) et un bloc de code nommé. Par défaut, la coroutine démarre immédiatement (CoroutineStart.DEFAULT).

launch : exécution fire-and-forget

launch est le constructeur le plus utilisé dans le développement Android. Il lance une coroutine qui ne retourne pas de résultat, et retourne un objet Job pour gérer son cycle de vie. C'est le choix idéal pour les opérations qui nécessitent seulement un effet secondaire : sauvegarde en base de données, envoi d'analyses, mise à jour de l'UI.

Syntaxe et utilisation de launch

Le constructeur launch accepte CoroutineScope, un CoroutineContext optionnel et un bloc suspend. Le Job retourné permet d'annuler la coroutine, d'attendre sa fin ou de vérifier son statut.

val scope = CoroutineScope(Dispatchers.IO + SupervisorJob())
val job: Job = scope.launch(CoroutineStart.LAZY) {
    val data = fetchFromNetwork()
    saveToDatabase(data)
}
job.start()
job.join()

Le paramètre CoroutineStart.LAZY reporte l'exécution jusqu'à un appel explicite à start() ou join(). Ceci est utile pour l'initialisation différée et l'exécution conditionnelle. Pour l'exécution immédiate standard, on utilise CoroutineStart.DEFAULT ou on omet le paramètre.

async : calculs parallèles avec résultat

async est un constructeur qui retourne Deferred<T> — une promesse asynchrone d'un résultat. L'appel à await() suspend la coroutine jusqu'à l'obtention du résultat, sans bloquer le thread. C'est le mécanisme principal pour les tâches parallèles dans les coroutines Kotlin.

Lancement de deux requêtes en parallèle

async est particulièrement efficace lorsque vous devez exécuter plusieurs opérations indépendantes simultanément. Contrairement aux appels séquentiels de fonctions suspend, async lance les coroutines en parallèle, réduisant le temps d'exécution total.

suspend fun fetchUserData(): UserData {
    val deferred1 = CoroutineScope(Dispatchers.IO).async { api.getProfile() }
    val deferred2 = CoroutineScope(Dispatchers.IO).async { api.getSettings() }
    val deferred3 = CoroutineScope(Dispatchers.IO).async { api.getNotifications() }
    return UserData(
        profile = deferred1.await(),
        settings = deferred2.await(),
        notifications = deferred3.await()
    )
}

Deferred hérite de Job, donc async prend en charge toutes les opérations du cycle de vie : annulation, attente de fin, gestion des exceptions. Lorsqu'un scope est annulé, les coroutines Deferred filles sont automatiquement annulées.

runBlocking : pont vers le monde bloquant

runBlocking est le seul constructeur qui bloque le thread actuel jusqu'à la fin de la coroutine. Il crée un nouveau CoroutineScope et lance la coroutine passée, bloquant le thread appelant. Il est utilisé dans les points d'entrée main(), dans les tests et lors de l'intégration avec du code bloquant.

Quand runBlocking est nécessaire

runBlocking est justifié dans trois scénarios : le point d'entrée de l'application (main), les tests unitaires de fonctions suspend et l'intégration avec des bibliothèques basées sur des callbacks où suspend ne peut pas être utilisé. Dans le code Android de production, l'utilisation de runBlocking sur le thread principal n'est pas recommandée.

class CoroutineTest {
    @Test
    fun `test suspend function`() = runBlocking {
        val result = mySuspendFunction()
        assertEquals("expected", result)
    }
}

Pour les tests, il est recommandé d'utiliser kotlinx-coroutines-test avec TestCoroutineDispatcher au lieu de runBlocking — cela offre un contrôle du temps et évite les blocages dans l'environnement de test.

Comment choisir le bon constructeur

Le choix du Coroutine Builder dépend du résultat retourné et du scénario d'exécution. Si l'opération ne nécessite pas de retour de données — utilisez launch. Si vous avez besoin du résultat d'une opération asynchrone — utilisez async. runBlocking ne doit être utilisé que pour le pont, et remplacez produce par Flow pour les flux réactifs.

Recommandations pratiques pour Android

Dans les projets Android utilisant Kotlin Coroutines, la paire principale de constructeurs sont launch et async. launch est utilisé dans ViewModel et UseCases pour lancer des coroutines, tandis qu'async est utilisé pour les requêtes parallèles au réseau ou à la base de données. Les bibliothèques modernes (Ktor, Room) supportent déjà les fonctions suspend, ce qui minimise le besoin d'utilisation directe d'async.

• launch — pour fire-and-forget (logging, analyses, cache)
• async — pour les requêtes parallèles avec combinaison de résultats
• runBlocking — seulement dans main() et les tests (pas sur le thread Main en production)
• produce — remplacer par Flow / SharedFlow / StateFlow