Concurrencia estructurada: ninguna corrutina huérfana

La suspensión resolvió el problema del coste: esperar dejó de gastar hilos. Pero abrió otro más difícil, el mismo que hizo insoportable la programación con callbacks y con hilos crudos durante décadas. Si lanzar trabajo es tan barato que puedes hacerlo miles de veces, ¿quién responde por ese trabajo? ¿Quién sabe cuándo ha terminado todo? ¿Quién lo detiene cuando la pantalla que lo pidió ya no existe? La respuesta de Kotlin no es una función de limpieza ni una lista de suscripciones que recordar liberar: es una regla estructural sobre cómo se organiza el trabajo concurrente, tan vinculante como lo son las llaves en el flujo secuencial. Se llama concurrencia estructurada, y una vez la ves no puedes dejar de verla.

El ámbito no es un permiso, es un padre

Al leer que launch y async necesitan un ámbito, la lectura natural es pensar que se trata de un permiso administrativo: algo que hay que tener a mano para poder lanzar. Es una lectura equivocada y conviene sustituirla cuanto antes. Un CoroutineScope no autoriza: adopta. Cada vez que lanzas una corrutina, esta se registra como hija del Job que vive dentro del contexto del ámbito, y el resultado es una relación de parentesco duradera con obligaciones en las dos direcciones.

Ese Job es el objeto que representa el ciclo de vida de una corrutina: sabe si está activa, si se completó, si fue cancelada, quién es su padre y qué hijos tiene. El árbol que forman todos los Job de tu aplicación es la estructura sobre la que descansa el resto de la lección. La consecuencia inmediata es que un padre no se considera completado cuando su propio cuerpo termina, sino cuando además han completado todos sus hijos. Esperar la descendencia no es algo que tú programes: está en la definición de terminar.

suspend fun cargarPantalla() = coroutineScope {
    launch { repo.precalentarCache() }   // hijo 1
    launch { repo.registrarVisita() }    // hijo 2
    val datos = repo.perfil()            // trabajo del propio padre
    // el bloque no retorna aqui: espera tambien a los dos hijos
    datos
}

Léelo despacio porque contradice la intuición heredada de otros lenguajes. La última expresión no termina la función: coroutineScope no retorna hasta que los dos launch han completado. No hay que recolectar identificadores de tarea, ni llamar a un método de espera, ni mantener una lista. La espera es una propiedad del ámbito, y por eso quien llama a cargarPantalla obtiene una garantía muy fuerte: cuando la llamada retorna, no queda absolutamente nada en marcha por debajo. El trabajo concurrente recupera la propiedad más valiosa del código secuencial, que es tener un principio y un final visibles en el propio texto.

Las dos leyes del árbol

La jerarquía sería una curiosidad si solo sirviera para esperar. Su poder viene de dos reglas de propagación que van en direcciones opuestas y que conviene memorizar juntas, porque explican casi todo el comportamiento que verás en las dos lecciones siguientes.

La primera: la cancelación desciende. Cancelar un Job cancela recursivamente a todos sus hijos, a los hijos de estos y así hasta las hojas. Un solo cancel sobre la raíz apaga un subárbol entero de trabajo, por profundo que sea, sin que nadie haya tenido que llevar un registro de las tareas vivas.

La segunda: el fallo asciende. Si una corrutina termina con una excepción no capturada, no muere sola: cancela a su padre, que a su vez cancela al resto de sus hijos y sigue propagando hacia arriba. La lógica es coherente con la idea de responsabilidad: si una parte del trabajo conjunto fracasó, el conjunto ya no puede dar un resultado válido y mantener vivas a las hermanas solo consume recursos para nada.

flowchart TD
R[Job raiz del scope] --> A[Hijo A carga perfil]
R --> B[Hijo B carga posts]
B --> B1[Nieto B1 descarga avatar]
B --> B2[Nieto B2 escribe cache]
A -.->|si A falla el error asciende| R
R -.->|y la cancelacion desciende a todos| B
B -.-> B1
B -.-> B2
style R fill:#cba6f7,color:#11111b
style A fill:#f38ba8,color:#11111b

Merece la pena notar que las dos direcciones no son arbitrarias sino complementarias. La cancelación desciende porque es una orden y las órdenes van de quien tiene autoridad a quien la ejecuta: el padre sabe que su resultado ya no hace falta, y por tanto ninguno de sus hijos tiene sentido. El fallo asciende porque es información y la información va de quien la descubre a quien puede actuar: el hijo se encontró con la excepción, pero no sabe qué otras ramas dependían de él, y el único que puede decidirlo es el padre. Cuando dudes sobre el comportamiento de un caso concreto, reconstruye la respuesta desde esta asimetría entre orden e información en lugar de intentar recordar la tabla.

Las dos leyes juntas producen el invariante que da título a la lección: ninguna corrutina queda huérfana. No hay forma de lanzar trabajo que no tenga padre —salvo saltándose el sistema a propósito, y a eso llegamos al final—, y como todo padre espera y propaga, no existe la tarea zombi que sigue consumiendo batería y memoria después de que su pantalla desapareciera. La clase de fuga más común del Android de hace diez años deja de ser un bug que evitar con disciplina y pasa a ser un estado imposible de representar.

Anatomía de un Job

Conviene mirar de cerca el objeto que sostiene toda la estructura, porque manejarlo con soltura desactiva mucha confusión posterior. Un Job no es un identificador opaco: es un valor con estados observables y con operaciones propias. Nace activo cuando la corrutina arranca, pasa a completando cuando su cuerpo terminó pero aún espera a sus hijos, y solo llega a completado cuando el último descendiente ha acabado. La rama alternativa es simétrica: cancelando mientras se propaga la orden y se ejecutan las limpiezas, y cancelado cuando todo el subárbol se apagó.

val trabajo: Job = scope.launch { sincronizar() }

trabajo.isActive        // sigue en marcha
trabajo.isCompleted     // termino, con exito o no
trabajo.children        // secuencia de sus hijos vivos
trabajo.invokeOnCompletion { causa -> registro.fin(causa) }
trabajo.join()          // suspende hasta que este subarbol termine del todo

Repara en join, que es la contrapartida explícita de la espera automática del ámbito: suspende a quien llama hasta que ese Job y toda su descendencia han terminado. coroutineScope no hace otra cosa que llamarlo por ti sobre todos sus hijos, y por eso los dos mecanismos dan la misma garantía. invokeOnCompletion, por su parte, permite enganchar una acción al final de la rama sin ocupar un hilo esperando, y recibe la causa: nula si acabó bien, la excepción si falló, la de cancelación si lo apagaron.

Existe también la posibilidad de construir un Job a mano y ponerlo en el contexto de un ámbito. Es lo que ocurre cuando escribes CoroutineScope(Job() + Dispatchers.Default): le estás dando al ámbito una raíz propia que podrás cancelar cuando quieras. Y existe su variante supervisora, SupervisorJob, que desactiva la segunda ley para sus hijos directos, de modo que el fallo de uno no arrastra a los demás. La última lección del nivel la estudia en detalle; por ahora basta con saber que el mismo lugar del contexto admite dos políticas distintas de propagación, y que elegir entre ellas es una decisión de diseño y no un detalle.

Dos formas de tener un ámbito

Kotlin ofrece dos maneras de introducir un ámbito, y confundirlas produce errores sutiles. La diferencia es de ciclo de vida y de firma.

coroutineScope { } es una función suspend que crea un ámbito local y efímero: existe mientras dura el bloque, hereda el contexto de quien lo llama, suspende hasta que todos sus hijos terminan y luego devuelve el valor de la última expresión. Es la herramienta para decir aquí necesito hacer varias cosas a la vez y no seguir hasta que todas acaben. No se guarda en una propiedad ni sobrevive a la llamada.

La firma delata la diferencia mejor que cualquier explicación: coroutineScope es una función suspend que devuelve un valor, así que solo puedes invocarla desde dentro de otra corrutina y su resultado es el de la operación que agrupó. No es un objeto que se guarde, ni una propiedad, ni algo que sobreviva a la llamada.

CoroutineScope(...) con su constructor, en cambio, crea un ámbito duradero que asocias a un objeto con ciclo de vida propio y que alguien deberá cancelar cuando ese objeto muera. Es la herramienta para decir este componente puede lanzar trabajo mientras exista. En Android casi nunca lo construyes a mano porque la plataforma ya te da los que necesitas.

// Ambito local: agrupa, paraleliza y no sobrevive al bloque
suspend fun resumen(id: String): Resumen = coroutineScope {
    val perfil = async { repo.perfil(id) }
    val stats  = async { repo.estadisticas(id) }
    Resumen(perfil.await(), stats.await())
}

// Ambito duradero: pertenece a un objeto y alguien debe cancelarlo
class Sincronizador : Closeable {
    private val scope = CoroutineScope(SupervisorJob() + Dispatchers.IO)
    fun arrancar() { scope.launch { bucleDeSincronizacion() } }
    override fun close() { scope.cancel() }   // sin esto, la rama nunca muere
}

La línea que cancela en close no es una cortesía: es la contrapartida obligatoria de haber creado una raíz. Un ámbito duradero pone un Job sin padre, y por tanto nadie lo va a cancelar en tu lugar. Quien crea la raíz asume el deber de terminarla, y el sitio correcto para ese deber es el mismo método donde el objeto declara que ha dejado de existir.

Aquí se cierra el círculo con lo que ya sabías de Orbit. La fábrica container de orbit-viewmodel construye su ámbito sobre viewModelScope, cuyo Job se cancela en onCleared. Cada intent que declaras es una corrutina hija de ese ámbito, y cada launch o async que abres dentro del intent es un nieto. Cuando el usuario abandona la pantalla, un solo cancel en la raíz desciende por todo el subárbol y detiene las descargas en vuelo, los coleccionadores de Flow que no terminaban nunca y los temporizadores. La frase de la lección anterior sobre que Orbit no inventa cancelación se entiende ahora del todo: lo único que hizo fue elegir bien de qué rama colgar.