viewModelScope: corrutinas que mueren solas

Un objeto que sobrevive a la rotación es una bendición y una amenaza a partes iguales. Bendición porque conserva el estado; amenaza porque todo lo que ese objeto arranque y no sepa detener seguirá vivo mientras él viva, y él vive mucho. La lección anterior te dejó con un ViewModel que atraviesa impasible la destrucción de sus pantallas; esta lección te da la contrapartida imprescindible: el scope de corrutinas que nace con él, que muere con él y que arrastra en su caída a toda la descendencia que hayas lanzado dentro. viewModelScope es una propiedad de doce líneas, pero esas doce líneas codifican tres decisiones de diseño —dónde se guarda, qué Job usa y sobre qué despachador corre— que explican buena parte del comportamiento de tus pantallas.

Anatomía de viewModelScope

viewModelScope es una propiedad de extensión sobre ViewModel, no un campo declarado en la clase. Su implementación es sencilla y merece leerse despacio: la primera vez que la usas, crea un CoroutineScope y lo guarda en una bolsa interna de objetos etiquetados que todo ViewModel mantiene; en los accesos siguientes devuelve el que ya está guardado. Ese scope implementa Closeable, y cuando el framework limpia el ViewModelStore, cierra uno por uno los objetos de esa bolsa —cancelando el scope— y solo después invoca onCleared.

// Reconstrucción conceptual de lo que hace la librería
public val ViewModel.viewModelScope: CoroutineScope
    get() = getCloseable(SCOPE_KEY)
        ?: CloseableCoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)
            .also { addCloseable(SCOPE_KEY, it) }

De esa única línea de contexto se derivan las dos decisiones interesantes. La primera es el SupervisorJob. Con un Job corriente, el fallo de una corrutina hija cancela a su padre, y el padre cancela al resto de hermanas: una llamada de red que revienta se llevaría por delante la suscripción a la base de datos y cualquier otra tarea en vuelo, dejando el ViewModel vivo pero con el scope muerto y sordo a futuras peticiones. El SupervisorJob invierte esa propagación hacia arriba: una hija que falla no arrastra a nadie. Cada launch es un compartimento estanco, que es justo lo que quieres cuando cada corrutina atiende una acción independiente del usuario.

Hay un matiz que conviene fijar porque produce confusión: el SupervisorJob aísla a los hijos directos del scope, es decir, a cada launch que hagas sobre viewModelScope. Dentro de uno de esos launch, la jerarquía vuelve a ser la normal: si abres un coroutineScope y lanzas dos operaciones en paralelo, el fallo de una sí cancela a su hermana y sube al padre. Y así debe ser, porque esas dos operaciones colaboran en la misma tarea y la mitad de un resultado no vale para nada. La supervisión pertenece a la frontera entre acciones independientes del usuario, no al interior de una sola acción.

La segunda decisión es Dispatchers.Main.immediate, y es más sutil de lo que parece. El Dispatchers.Main a secas siempre encola el trabajo en el bucle de mensajes del hilo principal, aunque ya estés en él; la variante immediate comprueba primero si el hilo actual ya es el principal y, si lo es, ejecuta el bloque sin reenviarlo. La diferencia se nota justo donde importa: cuando actualizas el estado desde un gesto del usuario, la actualización se aplica en el mismo ciclo en lugar de en el siguiente. Sin immediate habría un fotograma en el que la pantalla ya reaccionó al toque pero el estado todavía no había cambiado; con immediate ese hueco desaparece, y con él el parpadeo característico de un indicador de carga que aparece un instante tarde.

Que el despachador por defecto sea el principal no significa que el trabajo pesado deba correr ahí. Significa lo contrario de lo que muchos concluyen: como el punto de partida es el hilo de la interfaz, cada operación costosa tiene que declarar explícitamente su cambio de contexto. Y la responsabilidad de declararlo pertenece a quien conoce el coste —el repositorio, la fuente de datos, el caso de uso— y no a quien la invoca. Una función suspend bien diseñada es segura de llamar desde el hilo principal porque ella misma se aparta con withContext cuando lo necesita; si tienes que recordar en cada llamada desde qué hilo invocarla, la abstracción está mal puesta.

// El coste lo declara quien lo conoce, no quien llama
class PerfilRepo(private val dao: PerfilDao) {
    suspend fun cargar(id: String): Perfil = withContext(Dispatchers.IO) {
        dao.buscar(id)   // seguro de invocar desde el hilo principal
    }
}

La cancelación es cooperativa

Cancelar en Kotlin no es matar. Cuando el scope se cancela, lo único que ocurre es que el Job de cada corrutina pasa a estado cancelado y las funciones suspend de la biblioteca —delay, withContext, await, la recolección de un Flow— lanzan una CancellationException la próxima vez que se les da el control. Si tu código nunca devuelve el control, nadie lo interrumpe: un bucle de cálculo puro o una llamada bloqueante de entrada y salida seguirán trabajando aunque el ViewModel esté muerto, sosteniendo lo que hayan capturado.

// Cooperar con la cancelación en trabajo pesado
fun procesar(datos: List<Registro>) = viewModelScope.launch(Dispatchers.Default) {
    val salida = buildList {
        datos.forEach { registro ->
            ensureActive()          // punto de cancelación explícito
            add(transformar(registro))
        }
    }
    withContext(NonCancellable) {   // limpieza que debe completarse igual
        cache.volcar(salida)
    }
}

ensureActive es la forma más barata de sembrar puntos de cancelación en un bucle largo; yield hace lo mismo y además cede el turno. En el otro extremo está NonCancellable: un bloque que necesita terminar sí o sí —cerrar un fichero, confirmar una transacción, soltar un bloqueo— debe envolverse así, porque de lo contrario la primera suspensión dentro de la limpieza abortará también la limpieza. Son dos herramientas complementarias: una para dejarse cancelar bien, otra para negarse a ser cancelado en el tramo exacto donde negarse es correcto.

flowchart TD
VM[ViewModel] --> SJ[SupervisorJob del scope]
SJ --> C1[Corrutina de carga inicial]
SJ --> C2[Corrutina que colecciona la base de datos]
SJ --> C3[Corrutina de una accion del usuario]
C1 -.si falla no arrastra a sus hermanas.-> X[Fallo aislado]
CL[El owner se destruye] --> CLR[Se limpia el ViewModelStore]
CLR --> CAN[Se cancela el scope en cascada]
CAN --> SJ
style SJ fill:#a6e3a1,color:#11111b
style CAN fill:#f38ba8,color:#11111b
style VM fill:#89b4fa,color:#11111b

Fugas: lo que se escapa del scope

Toda fuga de corrutinas en un ViewModel responde a la misma causa: trabajo que corre fuera de la jerarquía que se cancela. La primera variante es el scope artesanal, un CoroutineScope(Dispatchers.IO) creado como campo de la clase porque hacía falta otro despachador. Nadie lo cancela nunca, así que sus corrutinas sobreviven al onCleared reteniendo el ViewModel entero. La corrección es trivial y siempre la misma: no cambies de scope para cambiar de hilo, cambia de contexto con withContext(Dispatchers.IO) dentro del scope que ya se cancela solo.

La segunda es GlobalScope, que es literalmente el scope de toda la aplicación: nada de lo que lances ahí se cancelará jamás por causa de tu pantalla. La tercera es más difícil de ver porque la referencia va al revés: un componente de larga vida —un repositorio singleton, un gestor de sesión, un oyente registrado en un servicio— guarda una lambda que captura el ViewModel. Aunque el scope se cancele con puntualidad, el objeto no puede recolectarse porque alguien más lo sujeta desde fuera, y con él queda retenido todo el estado que custodiaba.

Detectar estas fugas a ojo es poco fiable, así que conviene automatizarlo. Una herramienta de detección de fugas instrumenta la destrucción de los objetos con ciclo de vida y avisa cuando un ViewModel sigue accesible después de haberse limpiado, mostrándote la cadena exacta de referencias que lo sujeta. Leer esa cadena es la parte instructiva: siempre termina en algo que vive más que la pantalla y que un día decidiste guardar por comodidad.

Esa tercera pregunta señala el error inverso, menos comentado pero igual de real: meter en viewModelScope trabajo que no debe morir con la pantalla. Subir una foto, sincronizar un borrador o registrar una compra son operaciones cuyo destino no puede depender de que el usuario decida volver atrás. Si viven en el scope del ViewModel, se cancelarán a mitad de camino en cuanto la pantalla se destruya, y el usuario perderá el trabajo sin entender por qué. Esas tareas pertenecen a un componente de ámbito de aplicación o, si deben resistir incluso a la muerte del proceso, a un planificador de trabajo persistente. El scope correcto no es el más cómodo: es aquel cuya duración coincide con la duración legítima de la tarea.

Orbit corre sobre este mismo scope

Nada de lo anterior es teoría separada del patrón que estás estudiando: la fábrica container de orbit-viewmodel construye el contenedor precisamente sobre viewModelScope. Cada intent que escribes es una corrutina hija de ese scope, así que hereda las tres propiedades de golpe: se aísla de sus hermanos por el SupervisorJob, aplica sus reduce sin salto de fotograma por Dispatchers.Main.immediate y se cancela en cascada cuando el ViewModel muere.

// Un intent que colecciona para siempre: nunca tendrás que cancelarlo
fun observarMensajes() = intent {
    repo.mensajesFlow(state.chatId).collect { lista ->
        reduce { state.copy(mensajes = lista) }
    }
}

Ese intent no termina jamás por sí mismo, y sin embargo no es una fuga. Termina cuando el usuario abandona la pantalla de forma definitiva, porque en ese instante se limpia el ViewModelStore, se cierra el scope y la recolección recibe su CancellationException en la siguiente suspensión. Escribir código que no termina y que aun así no fuga solo es posible cuando la vida de la corrutina está atada estructuralmente a la vida de algo con significado para el usuario.