Dispatchers — kernbegrippen, typen dispatchers en hoe ze werken

Wat zijn Dispatchers?

Dispatchers — zijn implementaties van de CoroutineDispatcher-interface, die elementen zijn van CoroutineContext. Ze bepalen op welke thread of threadpool de coroutine wordt uitgevoerd. Bij het maken van een coroutine via launch of async kan de dispatcher als eerste parameter worden doorgegeven: launch(Dispatchers.IO) { ... }. Als er geen dispatcher is opgegeven, wordt deze overgenomen van de externe CoroutineScope.

Kotlin biedt vier ingebouwde dispatchers: Main, IO, Default, Unconfined. Elke dispatcher gebruikt zijn eigen threadpool, geoptimaliseerd voor een specifiek type operatie. De juiste keuze van de dispatcher bepaalt de prestaties van de applicatie: een verkeerde keuze leidt tot vertragingen in de interface, het onbenut laten van CPU-kernen of inefficiënt gebruik van threads.

Dispatchers.Main: UI-thread

Dispatchers.Main — dispatcher die coroutines uitvoert op de hoofdthread van Android. Het is bedoeld voor bewerkingen die verband houden met de interface: TextView bijwerken, notifyDataSetChanged aanroepen, werken met LiveData en StateFlow. In Android is deze dispatcher geïmplementeerd via Handler (Looper.getMainLooper()).

// Correct overschakelen naar Main voor UI-updates
viewModelScope.launch(Dispatchers.IO) {
    val data = repository.fetchData()
    withContext(Dispatchers.Main) {
        _uiState.value = data
    }
}

Als de coroutine zich al op de Main-dispatcher bevindt, creëert extra withContext(Dispatchers.Main) geen overhead — de dispatcher controleert de huidige thread en slaat de omschakeling over. withContext is de geprefereerde manier om tussen dispatchers te schakelen.

Dispatchers.IO: netwerk en schijfbewerkingen

Dispatchers.IO — dispatcher geoptimaliseerd voor invoer-uitvoerbewerkingen: HTTP-verzoeken (Ktor, OkHttp), lezen en schrijven van bestanden, werken met Room of SQLDelight. Het gebruikt standaard een pool van 64 threads, schaalbaar onder belasting. Elk nieuw IO-verzoek kan een extra thread creëren tot de limiet is bereikt.

Parallellisme beperken

Gebruik limitedParallelism() om het aantal gelijktijdige IO-bewerkingen te beheren. Deze functie creëert een nieuwe dispatcher met een beperking van het aantal parallelle threads, waardoor uitputting van de pool bij massale bewerkingen wordt voorkomen.

val limitedIo = Dispatchers.IO.limitedParallelism(4)

// Laad 100 bestanden met een limiet van 4 gelijktijdige bewerkingen
coroutineScope {
    val files = (1..100).map { index ->
        async(limitedIo) {
            downloadFile("file_$index")
        }
    }
    files.awaitAll()
}

Gebruik de IO-dispatcher voor alle bewerkingen waarbij de coroutine tijd besteedt aan wachten (I/O-bound). CPU-intensieve taken op de IO-dispatcher zijn inefficiënt — ze bezetten threads die bedoeld zijn voor invoer-uitvoer, waardoor de doorvoer van het systeem afneemt.

Dispatchers.Default: CPU-intensieve taken

Dispatchers.Default — dispatcher voor rekenintensieve bewerkingen die de processor belasten: sorteren, filteren, JSON-parsen (Moshi, Kotlinx Serialization), beeldverwerking, berekeningen. De poolgrootte is gelijk aan het aantal processorkernen (maar niet minder dan 2). Dit zorgt voor maximale CPU-belasting zonder contextomschakeling.

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

Gebruik Dispatchers.Default niet voor IO-bewerkingen — dit blokkeert threads van de CPU-pool die rekentaken zouden kunnen verwerken. De scheiding in IO en Default maakt optimaal gebruik van systeembronnen mogelijk: IO-threads wachten op invoer-uitvoer, CPU-threads zijn constant bezig met berekeningen.

Dispatchers.Unconfined: huidige thread

Dispatchers.Unconfined — een speciale dispatcher die de coroutine niet aan een pool bindt. De coroutine begint met uitvoeren in de thread waarin launch/async werd aangeroepen en wordt na onderbreking hervat in de thread die resume aanriep. Dit gedrag is geschikt voor tussenliggende bewerkingen die geen vaste context vereisen.

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

In productiecode wordt Dispatchers.Unconfined zelden gebruikt. Belangrijkste gevallen: lichte transformaties voordat gegevens naar een andere dispatcher worden gestuurd en tests. Gebruik voor productiebelasting expliciete dispatchers — Unconfined is onvoorspelbaar omdat de uitvoeringsthread afhankelijk is van de implementatie van resume.

Hoe kiest u een dispatcher

De keuze van de dispatcher wordt bepaald door het taaktype: UI-bewerkingen → Main, I/O-bound → IO, CPU-bound → Default, tussenliggend → overerving van scope. Voor Android wordt aanbevolen de coroutine te starten op de dispatcher waar het hoofdwerk wordt uitgevoerd en voor UI-updates over te schakelen naar Main via withContext.

• Start geen IO-bewerkingen op de Main-dispatcher — dit blokkeert de UI
• Start geen CPU-intensieve taken op de IO-dispatcher — dit gebruikt threads van de IO-pool inefficiënt
• Gebruik limitedParallelism om parallellisme bij massale IO-bewerkingen te beheren
• Schakel dispatcher met withContext, niet door een nieuwe scope te maken
• Erf dispatcher van scope, als de coroutine geen specifieke pool nodig heeft

Combineer voor complexe scenario's dispatchers met de operator +: Dispatchers.IO + SupervisorJob() + CoroutineExceptionHandler. Dit creëert een CoroutineContext met een gespecificeerde dispatcher, foutafhandeling en een geïsoleerde Job-hiërarchie.