На самом деле вы используете runBlocking
для вызова приостановленных функций в «блокирующем» коде, который в противном случае не был бы вызван там или другими словами: вы используете его для вызова suspend
функций вне сопрограммыcontext (в вашем примере блок, переданный в async
, является функцией suspend
).Кроме того (более очевидно, поскольку само название уже подразумевает), вызов тогда является блокирующим вызовом.Таким образом, в вашем примере это выполняется так, как если бы не было чего-то вроде async
.Он ожидает (блоки прерывисто ), пока все в runBlocking
-блоке не будет завершено.
Например, предположим, что функция в вашей библиотеке выглядит следующим образом:
suspend fun demo() : Any = TODO()
Этот метод не может быть вызван, например, main
.Для такого случая вы используете runBlocking
тогда, например:
fun main(args: Array<String>) {
// demo() // this alone wouldn't compile... Error:() Kotlin: Suspend function 'demo' should be called only from a coroutine or another suspend function
// whereas the following works as intended:
runBlocking {
demo()
} // it also waits until demo()-call is finished which wouldn't happen if you use launch
}
Что касается повышения производительности: на самом деле ваше приложение может быть скорее более отзывчивым, чем более производительным (иногда также более производительным, например, если у вас несколькопараллельные действия вместо нескольких последовательных).Однако в вашем примере вы уже блокируете при назначении переменной, поэтому я бы сказал, что ваше приложение еще не стало более отзывчивым.Возможно, вы захотите вызвать свой запрос асинхронно, а затем обновить интерфейс, как только ответ станет доступен.Таким образом, вы просто опускаете runBlocking
и используете что-то вроде launch
.Вас также может заинтересовать Руководство по программированию пользовательского интерфейса с сопрограммами .