Dispatchers — concepts clés, types de dispatchers et leur fonctionnement

Que sont les Dispatchers ?

Dispatchers sont des implémentations de l'interface CoroutineDispatcher, qui sont des éléments de CoroutineContext. Ils déterminent sur quel thread ou pool de threads la coroutine sera exécutée. Lors de la création d'une coroutine via launch ou async, le dispatcher peut être passé comme premier paramètre : launch(Dispatchers.IO) { ... }. Si aucun dispatcher n'est spécifié, il est hérité du CoroutineScope externe.

Kotlin fournit quatre dispatchers intégrés : Main, IO, Default, Unconfined. Chaque dispatcher utilise son propre pool de threads optimisé pour un type d'opération spécifique. Choisir le bon dispatcher détermine les performances de l'application : un mauvais choix entraîne des ralentissements de l'UI, des cœurs CPU inactifs ou une utilisation inefficace des threads.

Dispatchers.Main : Thread UI

Dispatchers.Main est le dispatcher qui exécute les coroutines sur le thread principal Android. Il est conçu pour les opérations liées à l'interface : mise à jour de TextView, appel de notifyDataSetChanged, travail avec LiveData et StateFlow. Dans Android, ce dispatcher est implémenté via Handler (Looper.getMainLooper()).

// Correct switch to Main for UI updates
viewModelScope.launch(Dispatchers.IO) {
    val data = repository.fetchData()
    withContext(Dispatchers.Main) {
        _uiState.value = data
    }
}

Si une coroutine est déjà sur le dispatcher Main, un withContext(Dispatchers.Main) supplémentaire ne crée pas de surcharge — le dispatcher vérifie le thread actuel et ignore la commutation. withContext est la méthode préférée pour basculer entre les dispatchers.

Dispatchers.IO : Opérations réseau et disque

Dispatchers.IO est un dispatcher optimisé pour les opérations d'E/S : requêtes HTTP (Ktor, OkHttp), lecture et écriture de fichiers, travail avec Room ou SQLDelight. Il utilise un pool de 64 threads par défaut, évolutif sous charge. Chaque nouvelle requête d'E/S peut créer un thread supplémentaire jusqu'à atteindre la limite.

Limitation du parallélisme

Pour contrôler le nombre d'opérations d'E/S simultanées, utilisez limitedParallelism(). Cette fonction crée un nouveau dispatcher avec une limite sur le nombre de threads parallèles, empêchant l'épuisement du pool lors des opérations de masse.

val limitedIo = Dispatchers.IO.limitedParallelism(4)

// Load 100 files with limit of 4 concurrent operations
coroutineScope {
    val files = (1..100).map { index ->
        async(limitedIo) {
            downloadFile("file_$index")
        }
    }
    files.awaitAll()
}

Utilisez le dispatcher IO pour toutes les opérations où la coroutine passe du temps à attendre (I/O-bound). Les tâches intensives CPU sur le dispatcher IO sont inefficaces — elles occupent des threads destinés aux E/S, réduisant le débit du système.

Dispatchers.Default : Tâches intensives CPU

Dispatchers.Default est le dispatcher pour les opérations de calcul qui chargent le processeur : tri, filtrage, analyse JSON (Moshi, Kotlinx Serialization), traitement d'images, calculs. La taille du pool est égale au nombre de cœurs du processeur (mais pas moins de 2). Cela garantit une utilisation maximale du CPU sans changement de contexte.

suspend fun processData(input: List<RawRecord>): List<ProcessedRecord> {
    return withContext(Dispatchers.Default) {
        input
            .parallelStream()
            .map { transform(it) }
            .toList()
    }
}

N'utilisez pas Dispatchers.Default pour les opérations d'E/S — cela bloquera les threads du pool CPU qui pourraient traiter des tâches computationnelles. La séparation entre IO et Default permet une utilisation optimale des ressources système : les threads IO attendent les E/S, les threads CPU sont constamment occupés par des calculs.

Dispatchers.Unconfined : Thread actuel

Dispatchers.Unconfined est un dispatcher spécial qui ne lie pas une coroutine à un pool. La coroutine commence son exécution dans le thread où launch/async a été appelé, et après la suspension, reprend dans le thread qui a appelé resume. Ce comportement convient aux opérations intermédiaires qui ne nécessitent pas de contexte fixe.

fun main() = runBlocking {
    launch(Dispatchers.Unconfined) {
        println("Before delay: ${Thread.currentThread().getName()}")
        delay(500L)
        println("After delay: ${Thread.currentThread().getName()}")
    }
}

Dans le code de production, Dispatchers.Unconfined est rarement utilisé. Cas d'utilisation principaux : transformations légères avant de passer des données à un autre dispatcher et tests. Pour les charges de production, utilisez des dispatchers explicites — Unconfined est imprévisible car le thread d'exécution dépend de l'implémentation de resume.

Comment choisir un dispatcher

La sélection du dispatcher dépend du type de tâche : opérations UI → Main, I/O-bound → IO, CPU-bound → Default, intermédiaires → hériter du scope. Pour Android, il est recommandé de lancer une coroutine sur le dispatcher où le travail principal est effectué, et de basculer vers Main via withContext avant de mettre à jour l'UI.

• N'exécutez pas d'opérations d'E/S sur le dispatcher Main — cela bloque l'UI
• N'exécutez pas de tâches intensives CPU sur le dispatcher IO — cela consomme inefficacement les threads du pool IO
• Utilisez limitedParallelism pour contrôler la concurrence lors des opérations d'E/S de masse
• Basculez de dispatcher avec withContext, pas en créant un nouveau scope
• Héritez du dispatcher du scope si la coroutine ne nécessite pas de pool spécifique

Pour les scénarios complexes, combinez les dispatchers avec l'opérateur + : Dispatchers.IO + SupervisorJob() + CoroutineExceptionHandler. Cela crée un CoroutineContext avec un dispatcher spécifié, une gestion des erreurs et une hiérarchie Job isolée.