Google acelera las rutas de corutinas en Android mediante R8
Google afirma que los desarrolladores Android pueden obtener rutas más rápidas de inicio y cancelación de corutinas al pasar a Android Gradle Plugin 9.2.0 o R8 9.2.0. En una publicación del 27 de julio de 2026, Andrei Shikov, ingeniero de Android Toolkit, y Jonathan Starup, ingeniero del equipo de R8, explicaron que R8 ahora optimiza la mayoría de las llamadas Atomic*FieldUpdater y las convierte en variantes Unsafe de menor sobrecarga cuando el compilador puede demostrar que el patrón es seguro.
El objetivo práctico es el código Android con uso intensivo de corutinas de Kotlin. Google dice que el cambio tiene un impacto importante en kotlinx.atomicfu, la biblioteca de operaciones atómicas usada por kotlinx.coroutines, y puede hacer que el inicio y la cancelación de corutinas sean hasta 2 veces más rápidos. El resultado importa sobre todo en rutas de interfaz que crean corutinas de vida corta con frecuencia, incluidas las effects de Jetpack Compose y la gestión de interacciones.
Por qué apareció este cuello de botella
La publicación de Android Developers describe una investigación de rendimiento en Compose en la que la creación y destrucción de corutinas se hizo visible en trazas de métodos. Google cita Modifier.clickable como ejemplo: antes de parte del trabajo de optimización relacionado, la mayor parte del tiempo dedicado a crear y actualizar ese modifier se consumía al iniciar y cancelar corutinas internas para las actualizaciones de InteractionSource.
La fuente de la sobrecarga no era solo la lógica de corutinas. El artículo señala a AtomicReferenceFieldUpdater, una primitiva de JVM usada por kotlinx.atomicfu para operaciones atómicas sin bloqueos. Esas llamadas usan nombres de campos y referencias de clase en tiempo de ejecución, por lo que incluyen comprobaciones reflexivas de acceso antes de llegar a la operación atómica subyacente. En el benchmark de Google con Pixel 5 y API 33, la ruta compare-and-set de kotlinx.atomicfu midió 135 ns frente a 50,7 ns con AtomicReference, lo que Google describió como una diferencia aproximada de 2,7 veces.
Qué cambia R8
R8 ya forma parte del flujo de compilación de versiones Android como optimizador de programa completo. El proyecto R8 lo describe como una herramienta que consume bytecode Java y produce DEX optimizado para aplicaciones Android. Esa visión global del programa permite al compilador reconocer patrones de updater que son estáticamente evidentes.
En el caso optimizado, R8 puede mantener la semántica de un updater válido mientras sustituye llamadas repetidas por operaciones directas Unsafe basadas en el offset del campo. Google divide la implementación en instrumentación, sustitución y limpieza: R8 introduce campos de offset, reescribe los puntos de llamada elegibles, conserva el comportamiento necesario ante null y elimina la inicialización del updater cuando todos los usos pueden optimizarse.
La limitación importante es que no se trata de una reescritura universal de todos los updater atómicos reflexivos. El artículo indica que R8 actúa sobre la mayoría de llamadas en las que el compilador puede seguir de forma segura el updater, el tipo contenedor y el tipo de campo. Los casos dinámicos que no cumplan esas condiciones pueden permanecer en la ruta original.
Por qué debería importarle a quienes desarrollan con Compose
Compose se apoya en corutinas para efectos secundarios controlados. La documentación de Compose explica que LaunchedEffect inicia una corutina cuando entra en composición y la cancela cuando sale; si cambian sus claves, cancela la corutina existente e inicia una nueva. Ese ciclo de vida es útil, pero implica que los costes de iniciar y cancelar corutinas pueden aparecer en cargas intensivas de interfaz.
Google dice que los microbenchmarks de Compose runtime vieron una mejora de 2 veces al iniciar y cancelar corutinas en LaunchedEffect tras la actualización de R8. Por separado, el equipo de Android Runtime está implementando optimizaciones relacionadas a nivel de máquina virtual. El artículo de Google indica que las apps orientadas a API 37 en versiones recientes de Android podrían ver ya un comportamiento similar desde la VM, y que sus benchmarks de corutinas observaron alrededor de un 15% de mejora tras actualizaciones recientes del JIT de ART.
Qué hacer ahora
Para equipos que publican apps Android centradas en Kotlin, la acción es clara: planificar el salto a AGP 9.2.0 o usar R8 9.2.0 directamente cuando las restricciones de build lo permitan. El beneficio debería verse sobre todo en rutas densas en corutinas, especialmente interacciones y effects de Compose, pero cada equipo debería medir su propia app porque la mejora depende de que las rutas calientes usen patrones de atomic updater optimizables.
Esta es una mejora de compilador y runtime, no una API nueva. El código existente de corutinas y Compose puede beneficiarse sin reescrituras a nivel de aplicación, siempre que la build use la ruta nueva de R8 y los patrones relevantes sean elegibles para la optimización.