Si alguna vez has sentido que tu aplicación de Android se queda congelada al cargar unos datos, es muy probable que estés peleando con el hilo principal. Las corrutinas de Kotlin llegaron para salvarme la vida a muchos desarrolladores, permitiéndonos escribir código asíncrono que parece secuencial y lineal, eliminando esos callbacks infinitos que hacían que el código pareciera una escalera.
Para aprovechar este superpoder, no basta con poner la palabra suspend delante de una función. Lo realmente importante es saber dónde se ejecuta cada trozo de código, y ahí es donde entran en juego los Dispatchers, que actúan como los directores de orquesta que deciden qué hilo se encarga de cada tarea.
¿Qué demonios es un Dispatcher?
Básicamente, un Dispatcher es el encargado de asignar una corrutina a un hilo o grupo de hilos específicos. Debemos recordar que, aunque las corrutinas son ligeras y no bloquean, por debajo siguen existiendo hilos que las soportan. Configurar el dispatcher adecuado evita que la app se cierre o que el rendimiento caiga en picado.
Cuando lanzamos una corrutina con launch, normalmente hereda el contexto donde se creó. Sin embargo, si necesitamos que una parte específica de la lógica se mueva a otro hilo, podemos indicarlo explícitamente. Para comprobar en qué hilo estamos realmente, un truco muy útil es imprimir Thread.currentThread().name, lo que nos permite ver la magia ocurriendo en tiempo real.
El trío dinámico: Main, IO y Default
Kotlin nos ofrece varias opciones, pero hay tres que vas a usar el 99% del tiempo. Primero tenemos Dispatchers.Main, que es el hilo de la interfaz de usuario. Solo debe usarse para cosas rapidísimas, como actualizar un texto en pantalla o interactuar con componentes de la UI. Si te pones a hacer cálculos aquí, la app se colgará y el usuario se desesperará.
Luego tenemos Dispatchers.IO, que es el caballo de batalla para todo lo que sea entrada y salida de datos. Es ideal para leer archivos, hacer peticiones a una API o consultar la base de datos con Room. Este dispatcher usa un pool de hilos mucho más amplio porque las tareas de E/S suelen pasar mucho tiempo esperando una respuesta externa sin consumir CPU.
Por último, encontramos Dispatchers.Default. Este está optimizado para tareas que exprimen el procesador, es decir, trabajo CPU-bound. Si tienes que analizar un JSON gigante, ordenar una lista enorme o hacer cálculos matemáticos complejos, este es tu sitio. Sus hilos suelen coincidir con la cantidad de núcleos de la CPU para no saturar el sistema.
También existe Dispatchers.Unconfined, pero la verdad es que apenas se utiliza en proyectos reales, ya que comienza donde se llama y puede reanudarse en cualquier hilo, lo que lo hace bastante impredecible para la mayoría de los casos.
El arte de cambiar de hilo con withContext
Aquí es donde ocurre la magia de la seguridad del hilo principal (main-safety). La función withContext permite suspender la corrutina actual, saltar a otro dispatcher, ejecutar el bloque de código y, una vez terminado, volver automáticamente al dispatcher original.
Lo mejor de este patrón es que el emisor de la función no tiene que preocuparse de en qué hilo llamarla. Una buena práctica es que la propia función suspendida gestione su propio contexto. Por ejemplo, una función getDatos() debería llamar internamente a withContext(Dispatchers.IO), así el ViewModel puede llamarla desde el hilo principal sin miedo a bloquear la pantalla.
En cuanto al rendimiento, withContext es extremadamente eficiente. No añade una carga extra comparado con los callbacks y, en ocasiones, Kotlin es capaz de optimizar el intercambio de hilos si detecta que ya estamos en el dispatcher deseado, evitando saltos innecesarios.
Controlando el ciclo de vida: Scopes y Jobs
Lanzar corrutinas al azar es una receta para el desastre y las fugas de memoria. Para evitarlo, usamos los CoroutineScopes, que definen el tiempo de vida de la tarea. En Android, tenemos viewModelScope para los ViewModels y lifecycleScope para las Activities o Fragments; cuando el componente muere, las corrutinas se cancelan automáticamente.
Cada vez que usamos launch o async, se genera un objeto Job. Este Job es como un ticket que nos permite controlar la corrutina: podemos usar job.join() para esperar a que termine o job.cancel() para detenerla si el resultado ya no nos interesa. Esto es la base de la concurrencia estructurada: los hijos están ligados al padre y no quedan procesos huérfanos dando vueltas por la memoria.
Ejecución paralela y la diferencia entre launch y async
A veces queremos hacer varias cosas a la vez para ganar tiempo. Para ello usamos async, que devuelve un objeto Deferred. A diferencia de launch (que es básicamente un dispara y olvida), async nos permite recuperar un valor mediante la función await().
Ojo aquí: que uses async no significa que automáticamente haya paralelismo. Si lanzas dos async en Dispatchers.Main, se ejecutarán uno tras otro en el mismo hilo. Para lograr un paralelismo real, debes asignarles Dispatchers.Default o IO, permitiendo que se distribuyan en los distintos núcleos de la CPU.
Para gestionar grupos de tareas paralelas, el constructor coroutineScope es fundamental. Este asegura que la función no termine hasta que todas las corrutinas hijas hayan completado su trabajo, capturando además cualquier excepción que pueda surgir en el camino para que no se pierda en el limbo.
Para cerrar el círculo, es fundamental no abusar de GlobalScope ya que es muy difícil de testear y cancelar. Lo ideal es siempre apoyarse en la jerarquía de scopes de Android y usar el dispatcher correcto según la carga de trabajo. Al combinar viewModelScope, withContext para las tareas pesadas y async para la concurrencia, conseguimos aplicaciones robustas que mantienen la interfaz fluida mientras procesan datos en segundo plano sin despeinarse.