Corrutinas de Kotlin `runBlocking`

Estoy aprendiendo rutinas de Kotlin. he leido eso runBlocking es la forma de unir el código sincrónico y asincrónico. Pero, ¿cuál es la ganancia de rendimiento si el runBlocking detiene el hilo de la interfaz de usuario? Por ejemplo, necesito consultar una base de datos en 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
    }
}

Consultar la base de datos detendría el hilo principal, por lo que parece que tomaría la misma cantidad de tiempo que el código síncrono. Por favor corrígeme si me estoy perdiendo algo.

runBlocking es la forma de unir el código síncrono y asíncrono

Sigo topándome con esta frase y es muy engañosa.

runBlocking es casi nunca una herramienta que utiliza en la producción. Deshace la naturaleza asincrónica y no bloqueante de las rutinas. Puede usarlo si ya tiene algún código basado en rutinas que desea usar en un contexto donde las rutinas no brindan ningún valor: en el bloqueo de llamadas. Un uso típico es la prueba JUnit, donde el método de prueba simplemente debe esperar a que se complete la rutina.

También puedes usarlo mientras juegas con rutinas, dentro de tu main método.

el mal uso de runBlocking se ha generalizado tanto que el equipo de Kotlin en realidad intentó agregar una verificación rápida que bloquearía inmediatamente su código si lo llama en el subproceso de la interfaz de usuario. Cuando hicieron esto, ya estaba rompiendo tanto código que tuvieron que eliminarlo.

en realidad usas runBlocking para llamar a funciones de suspensión en código de “bloqueo” que de otro modo no se podría llamar allí o en otras palabras: lo usa para llamar suspend funciones fuera del contexto coroutine (en su ejemplo, el bloque pasó a async es el suspend función). Además (más obvio, como ya implica el propio nombre), la llamada es una llamada de bloqueo. Entonces, en su ejemplo, se ejecuta como si no hubiera algo como async en su lugar. espera (bloquea interrumpiblemente) hasta que todo dentro del runBlocking-el bloque está terminado.

Por ejemplo, suponga una función en su biblioteca de la siguiente manera:

suspend fun demo() : Any = TODO()

Este método no sería invocable desde, por ejemplo main. Para tal caso se utiliza runBlocking entonces, por ejemplo:

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
}

Con respecto a la ganancia de rendimiento: en realidad, su aplicación puede ser más receptiva en lugar de tener más rendimiento (a veces también más rendimiento, por ejemplo, si tiene varias acciones paralelas en lugar de varias secuenciales). En su ejemplo, sin embargo, ya bloquea cuando asigna la variable, por lo que diría que su aplicación aún no responde mejor. Es posible que desee llamar a su consulta de forma asincrónica y luego actualizar la interfaz de usuario tan pronto como la respuesta esté disponible. Así que básicamente simplemente omites runBlocking y más bien usar algo como launch. Usted también podría estar interesado en Guía de programación de interfaz de usuario con rutinas.