Кажется мне, что дело не в быстроте (Sublime всё же пошустрее открывается, чем VS Code), а в том, что VS Code бесплатный и из коробки более функциональный. В подавляющем большинстве туда достаточно поставить:
Языки, которых не хватает (ставим нужные плагины);
Нормальные шорткаты (ставим плагин с предпочитаемой схемой);
Пак иконок по вкусу (ставим плагин с иконками);
И вуаля — удобный текстовый комбайн со всеми необходимыми инструментами, которые всегда под рукой.
Следовательно, всё блокирующее IO взаимодействие лучше выделить в отдельный пул потоков — Dispatchers.IO
В этом собственно и был вопрос: а стоит ли метод асинхронного ввода-вывода исполнять в контексте "блокирующего IO взаимодействия"?
В теории, блокирующие I/O операции вообще не должны использоваться, и вместо них необходимо использовать их неблокирующие аналоги. А для операций, которых не имеют таких аналогов (не приходит ничего на ум) — использовать Dispatcher.IO.
Хотя вот тоже спорно — стоило ли вообще делать отдельный диспетчер для ввода-вывода, если Default справляется точно так же? Только ради ограничения по количеству параллельно выполняемых операций? Но в Default по идее также должно стоять такое же ограничение по количеству параллельно выполняющихся блокирующих потоков…
А вот у меня такой вопрос: вот есть код из статьи:
launch(Dispatchers.Main) {
val image = withContext(Dispatchers.IO) { getImage() } // контекст IO
imageView.setImageBitmap(image) // контекст Main
}
Почему для I/O операций необходимо указывать свой контекст? Разве такой код в Android не будет работать/что-то заблокирует?
launch(Dispatchers.Main) {
val image = getImage() // контекст Main, но это I/O операция
imageView.setImageBitmap(image) // контекст Main
}
Если getImage() — это метод асинхронного ввода-вывода, разве он не приостановится при выполнении чтения как любая другая асинхронная функция в контексте main? Или это какой-то задел для мультиплатформы или типа того?
И вуаля — удобный текстовый комбайн со всеми необходимыми инструментами, которые всегда под рукой.
В этом собственно и был вопрос: а стоит ли метод асинхронного ввода-вывода исполнять в контексте "блокирующего IO взаимодействия"?
В теории, блокирующие I/O операции вообще не должны использоваться, и вместо них необходимо использовать их неблокирующие аналоги. А для операций, которых не имеют таких аналогов (не приходит ничего на ум) — использовать Dispatcher.IO.
Хотя вот тоже спорно — стоило ли вообще делать отдельный диспетчер для ввода-вывода, если Default справляется точно так же? Только ради ограничения по количеству параллельно выполняемых операций? Но в Default по идее также должно стоять такое же ограничение по количеству параллельно выполняющихся блокирующих потоков…
Почему для I/O операций необходимо указывать свой контекст? Разве такой код в Android не будет работать/что-то заблокирует?
Если getImage() — это метод асинхронного ввода-вывода, разве он не приостановится при выполнении чтения как любая другая асинхронная функция в контексте main? Или это какой-то задел для мультиплатформы или типа того?