> Какой диспетчер использовать для загрузки ресурса с сети в Kotlin корутинах (Kotlin, Android)

Короткий ответ

Для загрузки ресурса с сети в Kotlin корутинах используйте Dispatchers.IO - он оптимизирован для блокирующих операций ввода-вывода. Если работаете с библиотеками вроде Retrofit или Ktor, которые уже поддерживают suspend-функции, корутина сама переключится на нужный диспетчер, и явное указание не требуется. Для тяжёлых CPU-bound задач (например, декодирование изображения) - Dispatchers.Default.

Подробное объяснение

Dispatchers.IO - пул потоков, предназначенный для операций, которые блокируют поток (сеть, диск, БД). Он имеет отдельный пул потоков, но делит ресурсы с Dispatchers.Default через механизм ограниченного параллелизма. Это позволяет не блокировать основной поток и эффективно использовать ядра.

Важно понимать: если вы используете suspend-функции из сетевых библиотек (Retrofit, Ktor, OkHttp с корутинами), они уже internally переключаются на Dispatchers.IO. В этом случае явный withContext(Dispatchers.IO) избыточен, но не вреден - он просто добавит лишний переключатель контекста.

Для случаев, когда вы работаете с блокирующим API напрямую (например, java.net.URL или старый HttpURLConnection), оборачивайте вызов в withContext(Dispatchers.IO).

На практике

• Для suspend-функций из сетевых библиотек - не указывайте диспетчер, полагайтесь на внутреннюю реализацию.
• Для блокирующих вызовов - withContext(Dispatchers.IO).
• Для обработки результата (JSON-парсинг, декодирование) - Dispatchers.Default, если операция CPU-bound.
• Никогда не используйте Dispatchers.Main для сетевых операций - это заблокирует UI.
• Для параллельной загрузки нескольких ресурсов - async + awaitAll на Dispatchers.IO.

Пример кода

// Блокирующий вызов - нужен явный диспетчер
suspend fun loadData(): String = withContext(Dispatchers.IO) {
    URL("https://example.com/data").readText()
}

// Retrofit suspend-функция - диспетчер не нужен
interface ApiService {
    @GET("data")
    suspend fun getData(): Response<Data>
}

// Параллельная загрузка нескольких ресурсов
suspend fun loadAll(): List<String> = coroutineScope {
    val results = listOf("url1", "url2", "url3").map { url ->
        async(Dispatchers.IO) { URL(url).readText() }
    }
    results.awaitAll()
}

// Правильный подход для UI: запуск в Main, сеть - в IO
viewModelScope.launch {
    val data = withContext(Dispatchers.IO) { loadFromNetwork() }
    // обновляем UI - уже в Main
}

Как отвечать на собеседовании

Начните с прямого ответа: Dispatchers.IO. Затем объясните, почему: он создан для блокирующих операций, не блокирует main thread. Упомяните, что современные сетевые библиотеки уже умеют переключаться на IO автоматически, поэтому явный вызов не всегда нужен. Добавьте про Dispatchers.Default для обработки данных после загрузки. Покажите понимание разницы между suspend-функциями и блокирующими вызовами.

Что проверяет интервьюер

• Понимаете ли вы модель потоков в корутинах.
• Знаете ли вы разницу между Dispatchers.IO и Dispatchers.Default.
• Понимаете ли вы, когда нужен явный withContext, а когда нет.
• Умеете ли вы организовывать параллельную загрузку.
• Осознаёте ли вы опасность блокировки main thread.

Типичные ошибки

• Использование Dispatchers.Main для сетевых вызовов - блокировка UI.
• Избыточный withContext(Dispatchers.IO) вокруг suspend-функций из Retrofit/Ktor - лишний переключатель контекста.
• Использование Dispatchers.Default для блокирующих операций - пул потоков не рассчитан на длительные блокировки.
• Запуск сетевых операций в GlobalScope без контроля жизненного цикла - утечки.
• Игнорирование Dispatchers.IO.limitedParallelism() для контроля количества одновременных запросов.