Dispatchers — ключови понятия, видове диспечери и как работят

Какво са Dispatchers?

Dispatchers — имплементации на интерфейса CoroutineDispatcher, които са елементи на CoroutineContext. Те определят на коя нишка или пул от нишки ще се изпълнява корутината. При създаване на корутина чрез launch или async, диспечерът може да бъде предаден като първи параметър: launch(Dispatchers.IO) { ... }. Ако диспечерът не е указан, се наследява от външния CoroutineScope.

Kotlin предоставя четири вградени диспечера: Main, IO, Default, Unconfined. Всеки диспечер използва собствен пул от нишки, оптимизиран за конкретен тип операции. Правилният избор на диспечер определя производителността на приложението: грешен избор води до забавяне на интерфейса, неизползване на CPU ядра или неефективно изразходване на нишки.

Dispatchers.Main: UI нишка

Dispatchers.Main — диспечер, изпълняващ корутини на главната нишка на Android. Предназначен е за операции, свързани с интерфейса: актуализиране на TextView, извикване на notifyDataSetChanged, работа с LiveData и StateFlow. В Android този диспечер е имплементиран чрез Handler (Looper.getMainLooper()).

// Правилно превключване към Main за UI актуализации
viewModelScope.launch(Dispatchers.IO) {
    val data = repository.fetchData()
    withContext(Dispatchers.Main) {
        _uiState.value = data
    }
}

Ако корутината вече е на Main-диспечера, допълнителният withContext(Dispatchers.Main) не създава допълнително натоварване — диспечерът проверява текущата нишка и пропуска превключването. withContext е предпочитаният начин за превключване между диспечери.

Dispatchers.IO: мрежа и дискови операции

Dispatchers.IO — диспечер, оптимизиран за входно-изходни операции: HTTP заявки (Ktor, OkHttp), четене и запис на файлове, работа с Room или SQLDelight. По подразбиране използва пул от 64 нишки, мащабируем под натоварване. Всяка нова IO заявка може да създаде допълнителна нишка до достигане на лимита.

Ограничаване на паралелизма

За контрол на броя едновременни IO операции използвайте limitedParallelism(). Тази функция създава нов диспечер с ограничение на броя паралелни нишки, предотвратявайки изчерпване на пула при масови операции.

val limitedIo = Dispatchers.IO.limitedParallelism(4)

// Зареди 100 файла с лимит от 4 едновременни операции
coroutineScope {
    val files = (1..100).map { index ->
        async(limitedIo) {
            downloadFile("file_$index")
        }
    }
    files.awaitAll()
}

Използвайте IO-диспечера за всички операции, където корутината прекарва време в чакане (I/O-bound). CPU-интензивните задачи на IO-диспечера са неефективни — те заемат нишки, предназначени за вход-изход, намалявайки пропускателната способност на системата.

Dispatchers.Default: CPU-интензивни задачи

Dispatchers.Default — диспечер за изчислителни операции, натоварващи процесора: сортиране, филтриране, парсване на JSON (Moshi, Kotlinx Serialization), обработка на изображения, изчисления. Размерът на пула е равен на броя на ядрата на процесора (но не по-малко от 2). Това осигурява максимално натоварване на CPU без превключване на контекст.

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

Не използвайте Dispatchers.Default за IO операции — това ще блокира нишките на CPU пула, които биха могли да обработват изчислителни задачи. Разделянето на IO и Default позволява оптимално използване на системните ресурси: IO нишките чакат вход-изход, CPU нишките са постоянно заети с изчисления.

Dispatchers.Unconfined: текуща нишка

Dispatchers.Unconfined — специален диспечер, който не обвързва корутината с никакъв пул. Корутината започва изпълнение в същата нишка, в която е извикана launch/async, а след спиране продължава в нишката, която е извикала resume. Това поведение е подходящо за междинни операции, които не изискват фиксиран контекст.

fun main() = runBlocking {
    launch(Dispatchers.Unconfined) {
        println("Преди закъснение: ${Thread.currentThread().getName()}")
        delay(500L)
        println("След закъснение: ${Thread.currentThread().getName()}")
    }
}

В production код Dispatchers.Unconfined се използва рядко. Основни случаи: леки трансформации преди предаване на данни на друг диспечер и тестове. За production натоварване използвайте изрични диспечери — Unconfined е непредсказуем, тъй като нишката на изпълнение зависи от имплементацията на resume.

Как да изберем диспечер

Изборът на диспечер се определя от типа задача: UI операции → Main, I/O-bound → IO, CPU-bound → Default, междинни → наследяване от scope. За Android се препоръчва корутината да се стартира на диспечера, където се извършва основната работа, а преди актуализиране на UI да се превключи на Main чрез withContext.

• Не стартирайте IO операции на Main-диспечера — това блокира UI
• Не стартирайте CPU-интензивни задачи на IO-диспечера — това неефективно изразходва нишките на IO пула
• Използвайте limitedParallelism за контрол на паралелизма при масови IO операции
• Превключвайте диспечера с withContext, а не чрез създаване на нов scope
• Наследявайте диспечера от scope, ако корутината не изисква специфичен пул

За сложни сценарии комбинирайте диспечери с оператора +: Dispatchers.IO + SupervisorJob() + CoroutineExceptionHandler. Това създава CoroutineContext с определен диспечер, обработка на грешки и изолирана Job йерархия.