Kotlin 协程`runBlocking`

Question

我正在学习 Kotlin 协程。我读过runBlocking 是桥接同步和异步代码的方法。但是如果runBlocking 停止 UI 线程，性能提升是多少？ 比如我需要在Android中查询一个数据库：

    val result: Int
    get() = runBlocking { queryDatabase().await() }

private fun queryDatabase(): Deferred<Int> {
    return async {
        var cursor: Cursor? = null
        var queryResult: Int = 0
        val sqlQuery = "SELECT COUNT(ID) FROM TABLE..."
        try {
            cursor = getHelper().readableDatabase.query(sqlQuery)
            cursor?.moveToFirst()
            queryResult = cursor?.getInt(0) ?: 0
        } catch (e: Exception) {
            Log.e(TAG, e.localizedMessage)
        } finally {
            cursor?.close()
        }
        return@async queryResult
    }
}

查询数据库会停止主线程，所以看起来它需要与同步代码相同的时间？如果我遗漏了什么，请纠正我。

Answer 1

实际上，您使用runBlocking 在“阻塞”代码中调用挂起函数，否则将无法在其中调用，换句话说：您使用它在协程上下文之外调用suspend 函数（在您的示例中传递给async 的块是suspend 函数）。此外（更明显，正如其名称本身已经暗示的那样），该调用是阻塞调用。因此，在您的示例中，它的执行就像没有 async 之类的东西一样。它会等待（阻塞中断）直到runBlocking-block 中的所有内容都完成。

例如，假设您的库中的函数如下：

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
}

关于性能提升：实际上，您的应用程序可能更具有响应性，而不是性能更高（有时性能也更高，例如，如果您有多个并行操作而不是多个连续操作）。但是，在您的示例中，您在分配变量时已经阻塞，所以我想说您的应用程序还没有得到更多响应。您可能更希望异步调用您的查询，然后在响应可用时立即更新 UI。所以你基本上只是省略runBlocking，而是使用launch之类的东西。你可能也对Guide to UI programming with coroutines感兴趣。

Answer 2

runBlocking是桥接同步和异步代码的方式

我经常碰到这个短语，它非常具有误导性。

runBlocking几乎从不是您在生产中使用的工具。它取消了协程的异步、非阻塞特性。如果您碰巧已经有一些基于协程的代码想要在协程不提供任何价值的上下文中使用：在阻塞调用中，您可以使用它。一种典型的用途是 JUnit 测试，其中测试方法必须坐下来等待协程完成。

您也可以在main 方法中使用它来玩协程。

runBlocking 的滥用已经变得如此普遍，以至于 Kotlin 团队实际上试图添加一个快速失败检查，如果你在 UI 线程上调用它会立即使你的代码崩溃。到他们这样做的时候，它已经破坏了很多代码，以至于他们不得不将其删除。