AutoFDO para agilizar Android y mejorar batería y fluidez

En los últimos años, Google se ha tomado muy en serio la misión de hacer que Android sea más rápido, más fluido y con mejor batería sin que el usuario tenga que tocar nada. Una de las piezas clave de esta estrategia es AutoFDO, una tecnología de optimización que hasta ahora se usaba sobre todo en el espacio de usuario (apps y bibliotecas nativas), pero que ya está llegando también al kernel, el corazón del sistema.

Esta novedad puede sonar muy técnica, pero sus efectos son de lo más cotidiano: móviles que arrancan un poco antes, apps que se abren más deprisa y una ligera mejora en el consumo energético. No vas a sentir que estrenas teléfono nuevo, pero sí se suma a ese conjunto de pequeñas mejoras que hacen que Android se note cada vez más ágil y eficiente.

Qué es AutoFDO y por qué importa en Android

AutoFDO viene de Automatic Feedback-Directed Optimization, o lo que es lo mismo, optimización automática guiada por datos reales de ejecución. A diferencia de los métodos clásicos, donde el compilador se basa en reglas estáticas y suposiciones, AutoFDO utiliza información recogida mientras el código se ejecuta de verdad para decidir cómo optimizarlo.

En una compilación tradicional, el compilador toma constantemente miles de microdecisiones sobre cómo organizar el código: si conviene incrustar una función o dejarla aparte, qué rama de un if es más probable que se ejecute, cómo ordenar las instrucciones en memoria para que la CPU las aproveche mejor, etc. Todas esas decisiones se suelen basar en heurísticas generales, que no siempre encajan con lo que realmente pasa cuando usas tu móvil día a día.

Con AutoFDO, en lugar de confiar solo en esas suposiciones, el sistema recoge perfiles de ejecución reales: qué funciones se usan más, qué rutas de código se pisan continuamente y cuáles apenas se tocan. Esos datos se obtienen a partir de las capacidades de monitorización del hardware (trazado de ramas de la CPU) y se transforman en perfiles que el compilador entiende y utiliza para reordenar el código con mucho más criterio.

Esta técnica es una evolución de la clásica PGO (Profile-Guided Optimization) basada en instrumentación, que ya se usa en Windows, Linux y navegadores como Chrome. La diferencia es que AutoFDO es menos invasivo, permite recopilar datos sin recompilar con versiones especiales instrumentadas y, además, se acerca más al uso real del dispositivo.

En Android, AutoFDO se introdujo inicialmente en Android 12 para optimizar ejecutables y bibliotecas nativas. Ahora, Google está llevando la misma idea a un nivel todavía más bajo: el kernel de Android, que concentra aproximadamente un 40 % del tiempo de CPU. Optimizar ahí tiene un impacto directo en casi todo lo que haces con el móvil.

Cómo consigue AutoFDO acelerar el kernel de Android

El equipo de la cadena de herramientas LLVM de Android ha diseñado una canalización bastante sofisticada para que AutoFDO funcione en el kernel sin comprometer la estabilidad. La clave está en generar perfiles de alta calidad en un entorno de laboratorio y aplicarlos después al Generic Kernel Image (GKI), que sirve como base para muchos dispositivos.

Para empezar, Google necesita saber cómo se comporta realmente el kernel cuando usas el móvil. Para ello, flashea dispositivos de prueba (principalmente Pixel) con la imagen de kernel más reciente y utiliza herramientas como simpleperf apoyadas en funciones de hardware específicas, como ARM Embedded Trace Extension (ETE) y ARM Trace Buffer Extension (TRBE), para registrar el historial de ramificaciones de la CPU.

En esos dispositivos se reproduce una carga de trabajo representativa que incluye las 100 aplicaciones más populares de la Compatibility Test Suite (C-Suite). No se trata solo de abrirlas una vez y ya está; se simulan interacciones completas tipo usuario real, incluyendo acciones guiadas por IA que rastrean cómo se usan las apps a lo largo del tiempo.

Durante estas pruebas se vigila el sistema al completo: apps en primer plano, procesos en segundo plano, servicios críticos y comunicación entre procesos. El resultado es un mapa bastante detallado de qué partes del kernel están “calientes” (se ejecutan continuamente) y cuáles son “frías” (apenas se tocan). Google afirma que esta carga de trabajo sintética llega a reproducir alrededor de un 85 % de los patrones de ejecución observados en su flota interna real, una cifra muy alta para un entorno controlado.

Una vez que se tiene esta información, el kernel se recompila incorporando estos perfiles AutoFDO. El compilador, ahora con datos de verdad sobre la mesa, puede priorizar la optimización justo donde más se nota: rutas de ejecución críticas, manejo intensivo de I/O, cambios de contexto entre procesos, etc., mientras deja que el resto del código se optimice con técnicas estándar.

Canalización completa: de la recogida de perfiles a la actualización continua

Para que AutoFDO sea útil a largo plazo, no basta con generar un perfil una vez y olvidarse. El código del kernel y del sistema cambia con cada versión y parche, de modo que los perfiles se “desalinean” con el tiempo. Por eso Google ha montado una canalización continua con varios pasos muy claros.

En el primer paso, la recogida de perfiles, se separa el proceso de generar perfiles del ciclo de lanzamiento de cada dispositivo. Es decir, se perfila la imagen genérica del kernel en laboratorio, sin depender de la flota real ni de versiones concretas en manos de usuarios. Esto permite actualizar perfiles con mucha más flexibilidad y rapidez, siempre que haya una nueva versión del kernel GKI.

Luego llega el procesamiento del perfil. Los datos de traza bruta que genera el hardware se postprocesan para que el compilador pueda aprovecharlos. Se agrupan mediciones de múltiples ejecuciones y múltiples dispositivos para lograr una vista global, se convierten esas trazas al formato estándar de AutoFDO y se filtran símbolos irrelevantes que no aportan nada útil al rendimiento.

Un punto importante es el recorte de perfiles. Al limpiar los datos, se eliminan las funciones frías del perfil para que sigan usando optimizaciones “de toda la vida”. Así se evitan regresiones raras en código que casi no se ejecuta y se mantiene el tamaño de los binarios bajo control, porque los datos de perfil también influyen en la disposición del código en memoria.

Antes de desplegar cualquier perfil nuevo, se realiza una verificación exhaustiva. El equipo analiza y compara el contenido del perfil (funciones activas, número de muestras, tamaño del perfil) con versiones anteriores y genera una nueva imagen de kernel con AutoFDO aplicado. Después se revisan con lupa los cambios en la sección de texto (el código) para confirmar que las modificaciones encajan con lo esperado.

En paralelo, se corren benchmarks específicos para validar que la nueva imagen mantiene o mejora las métricas de rendimiento objetivo: tiempos de arranque, apertura en frío de aplicaciones, fluidez de la interfaz, etc. Si algo no cuadra o aparece alguna regresión, el perfil se ajusta o se descarta antes de que llegue a los usuarios.

Por último, Google ejecuta esta canalización de forma continuada. Los perfiles se actualizan de manera periódica en las ramas LTS del kernel de Android y se integran en cada lanzamiento de GKI. De momento, el despliegue está centrado en las ramas android16-6.12 y android15-6.6, pero la intención es ampliarlo a versiones posteriores como la futura android17-6.18.

Resultados: cuánto se nota AutoFDO en el día a día

Toda esta ingeniería no tendría sentido si luego los números no acompañasen. Según las mediciones internas de Google, aplicar AutoFDO al kernel de Android en dispositivos Pixel ha logrado mejoras tangibles aunque moderadas en varias métricas clave.

En pruebas de laboratorio, se habla de un incremento medio de rendimiento en torno al 10,5 % en escenarios específicos, alcanzando aproximadamente el 85 % del beneficio que aportaría una optimización clásica guiada por retroalimentación basada en instrumentación. La gracia es que AutoFDO consigue algo muy parecido sin incurrir en el coste y la complejidad de instrumentar el código.

Si miramos las cifras más visibles para el usuario, Google habla de una reducción del tiempo de arranque del sistema cercana al 2,1 % y una mejora en la apertura en frío de aplicaciones alrededor del 4-4,3 %. Puede sonar discreto, pero hay que recordar que el kernel representa aproximadamente el 40 % del tiempo total de CPU, así que cualquier ajuste ahí se traduce en rendimiento global más afinado.

Además de la velocidad, la optimización del kernel también tiene impacto en el consumo. Al reorganizar el código para que las rutas más frecuentes sean más eficientes, la CPU puede completar operaciones antes y volver a estados de bajo consumo con mayor rapidez. Eso, en la práctica, ayuda a exprimir un poco mejor la batería, especialmente en acciones repetitivas como cambiar de app, gestionar notificaciones o movernos por la interfaz.

Todo esto se suma a las mejoras que AutoFDO ya aporta en el espacio de usuario. En Android, esta tecnología ya se usa desde hace tiempo para optimizar ejecutables y bibliotecas críticas, con cifras como un 4 % de mejora en el inicio en frío de aplicaciones y un 1 % de reducción en el tiempo de arranque del dispositivo gracias a la parte de espacio de usuario. La novedad es que ahora el núcleo del sistema se suma a ese paquete de optimizaciones.

Estabilidad y seguridad: por qué AutoFDO no rompe el sistema

Una preocupación lógica cuando se habla de ajustes en el kernel es si esto puede afectar a la estabilidad o a la fiabilidad del sistema. Google es consciente de ello y ha diseñado AutoFDO en Android con una filosofía muy conservadora.

Lo primero a tener en cuenta es que AutoFDO no cambia la lógica del código fuente. Lo que hace es influir en las heurísticas del compilador: decide dónde insertar funciones (inlining), cómo ordenar bloques de código, qué rutas priorizar en caché, etc. Es decir, la funcionalidad sigue siendo la misma; lo que varía es cómo se coloca el código para que la CPU lo ejecute con menos esfuerzo.

Además, se aplica un enfoque de “conservador por defecto”. Las funciones que no aparecen en los perfiles de alta fidelidad —porque se ejecutan poco o casi nunca en los escenarios analizados— se compilan con las mismas optimizaciones estándar de siempre. Eso ayuda a evitar sorpresas en rutas de ejecución infrecuentes, como errores muy raros o comportamientos extraños en casos límite.

Es importante recordar también que AutoFDO no es una apuesta a ciegas. Esta tecnología lleva años desplegada en Android, ChromeOS y la infraestructura de servidores de Google, así como en otras plataformas, como herramienta habitual de optimización. La experiencia previa demuestra que, bien aplicada, no introduce riesgos adicionales significativos.

Para Android, cada nuevo perfil pasa por una fase intensa de pruebas antes de llegar a una rama LTS del kernel. El contenido del perfil se contrasta frente a versiones anteriores, se analizan los binarios resultantes y se ejecutan comparativas dirigidas. Solo cuando se confirma que no hay regresiones de rendimiento ni comportamientos inestables, el perfil se integra y se prepara para su despliegue en imágenes GKI.

AutoFDO en AOSP y soporte para desarrolladores

Más allá del kernel, el sistema de compilación de Android soporta AutoFDO desde Android 12 para optimizar módulos nativos con reglas de compilación específicas. En el AOSP (Android Open Source Project), AutoFDO está activado por defecto para la mayoría de los proyectos donde el rendimiento es crucial.

Los perfiles que se incluyen en AOSP se han recopilado en teléfonos y tablets y reflejan patrones de uso generales. Se almacenan en la ruta toolchain/pgo-profiles/sampling y se aplican automáticamente durante la compilación de muchas bibliotecas y binarios relevantes, lo que permite mejorar rendimiento y, en bastantes casos, incluso reducir el tamaño de los ejecutables.

Si un fabricante, proveedor o desarrollador quiere aprovechar AutoFDO para módulos adicionales o código modificado localmente, tiene la opción de recolectar sus propios perfiles. Esto es especialmente útil cuando se añaden proyectos nuevos, se personaliza el sistema con mucho código propio o se tienen patrones de uso muy específicos que no encajan del todo con los perfiles genéricos.

Para las reglas de compilación tipo Blueprint, habilitar AutoFDO es tan simple como añadir el atributo afdo:true a la definición de una biblioteca compartida o un binario. A partir de ahí, el sistema de compilación ya sabe que debe buscar y aplicar el perfil AutoFDO correspondiente en el proceso de build.

Android soporta la recopilación de perfiles en dispositivos x86, x86_64, ARM y ARM64, y esos perfiles se pueden reutilizar entre arquitecturas. Para recabar datos en ARM, se documentan procedimientos basados en la extensión de trazado (ETM), mientras que en x86 se usan capacidades como Last Branch Record (LBR). Además, existe Profcollect, un mecanismo para automatizar la recogida, procesamiento y subida de perfiles en segundo plano, pensado precisamente para estos escenarios.

Una vez generados, los perfiles AutoFDO se pueden inspeccionar con herramientas estándar de LLVM, como llvm-profdata. Scripts como afdo_summary.sh permiten ver de forma rápida qué funciones son las más calientes según el perfil, facilitando tanto el trabajo de diagnóstico como el de afinado de rendimiento.

Planes de futuro: más cobertura y más componentes optimizados

El despliegue actual de AutoFDO en el kernel se centra en las ramas android16-6.12 y android15-6.6, pero Google ya mira más allá. La intención es extender la cobertura a versiones más recientes de GKI, incluida la prevista para Android 17 (android17-6.18) y otros destinos de compilación adicionales más allá de aarch64.

Por ahora, la optimización se ha enfocado principalmente en el binario principal del kernel (vmlinux). Sin embargo, el siguiente paso lógico es llevar AutoFDO también a los módulos de GKI, que representan una parte importante del subsistema del kernel y cubren funcionalidades específicas que también impactan en el rendimiento del sistema.

Otro frente abierto es la posible compatibilidad con módulos de proveedores construidos con el Driver Development Kit (DDK). Como el sistema de compilación (Kleaf) y las herramientas de perfilado (simpleperf) ya soportan AutoFDO, existe una base sólida para que los fabricantes puedan aplicar la misma técnica a sus propios controladores de hardware, ajustando aún más el rendimiento a sus dispositivos concretos.

Google también contempla ampliar la diversidad de perfiles, incorporando recorridos críticos adicionales (CUJs, Critical User Journeys) para cubrir un abanico más amplio de situaciones reales: juegos, multimedia, multitarea pesada, etc. Cuanto más variada sea la colección de perfiles, más afinada será la optimización sin perder la generalidad necesaria para que funcione bien en millones de dispositivos.

En conjunto, AutoFDO forma parte de una estrategia de fondo con la que Google pretende mantener Android competitivo, no solo añadiendo funciones llamativas para el usuario, sino puliendo la eficiencia interna del sistema operativo. En un ecosistema tan diverso, con miles de modelos distintos, estas mejoras de bajo nivel ayudan a que incluso hardware modesto se sienta algo más ágil y a que los teléfonos de gama alta expriman al máximo sus recursos.

Al final, todo este trabajo de AutoFDO en Android se traduce en algo bastante sencillo para quien tiene el móvil en la mano: un sistema que responde un poco más rápido, que se nota algo más suave y que hace un uso más inteligente de la CPU y de la batería, sin menús ocultos ni ajustes complicados, simplemente gracias a que el software aprende de cómo lo utilizamos de verdad.

Artículo relacionado:

Aumentar la memoria virtual en Android: qué es, cómo usarla y cuándo compensa

Isaac

Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.