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()).

// Correct switch to Main for UI updates
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)

// Load 100 files with limit of 4 concurrent operations
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("Before delay: ${Thread.currentThread().getName()}")
        delay(500L)
        println("After delay: ${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.