Google ha empezado a aplicar una optimización llamada AutoFDO (Automatic Feedback-Directed Optimization) directamente en el kernel de Android, el núcleo que coordina apps, procesador y hardware. En una nota firmada por Yabin Cui, del equipo de herramientas LLVM de Android en Google, la compañía sostiene que «These aren’t just theoretical numbers» y que el efecto debería notarse en el uso diario sin que el usuario cambie hábitos ni menús.
La idea suena casi demasiado simple. Si el sistema aprende qué hace tu teléfono cuando abres WhatsApp, cambias de app o desbloqueas la pantalla, puede prepararse mejor para esas tareas. Y tú no tienes que tocar nada.
El kernel, explicado sin tecnicismos
El kernel es la parte de Android que decide quién usa el procesador en cada momento y cómo se reparten los recursos. Es como un agente de tráfico que gestiona miles de cruces a la vez para que una app no pise a otra.
Cuando ese “agente” toma decisiones más rápido, suelen notarse menos tirones en la interfaz y menos esperas al saltar entre aplicaciones. No es magia, es eficiencia en tareas pequeñas que se repiten todo el día.
AutoFDO en palabras sencillas
AutoFDO es una técnica de optimización basada en perfiles, algo así como entrenar al compilador con datos reales de uso. La documentación del kernel de Linux la describe como un método que usa muestreo del hardware para ver qué partes del código se ejecutan más y, con eso, generar un binario más eficiente.
En la práctica, el compilador es el traductor que convierte el código en instrucciones para la máquina. Sin AutoFDO, ese traductor trabaja con pistas más estáticas y con reglas generales, que a veces no coinciden con lo que pasa en un móvil de verdad.
Un truco que Android ya conocía
AutoFDO no es un invento nuevo que aparezca de la nada. En la documentación del Android Open Source Project se explica que el sistema de compilación de Android soporta AutoFDO desde Android 12 para optimizar componentes nativos del sistema, y que incluso puede reducir el tamaño de algunos binarios además de mejorar el rendimiento.
Lo distinto ahora es el lugar donde se aplica. Pasar del “software de arriba” al kernel es ir a la base de todo, donde se gestionan comunicaciones internas, llamadas al sistema y parte del trabajo que decide cuánta energía gasta el procesador.
Lo que midió Google en teléfonos Pixel
Para construir estos perfiles, Google no se limita a adivinar. En los repositorios públicos del kernel común de Android se detalla un proceso de laboratorio que combina recorrido por apps y lanzamientos repetidos de las 100 aplicaciones más populares, con pruebas pensadas para representar arranques en frío.
El mismo documento advierte de algo importante para bajar expectativas. Los resultados pueden variar entre actualizaciones porque el kernel cambia, el muestreo no es perfecto y el hardware de pruebas también influye, así que no hay una mejora fija garantizada para todos.
Cuánta mejora se ve en las pruebas
Los números que ha compartido Google apuntan a ganancias grandes en partes internas del sistema que se usan constantemente. En una batería de métricas, algunas pruebas ligadas a Binder, el “mensajero” que permite que apps y servicios se comuniquen, suben algo más de un 20 por ciento, mientras que otras rondan entre un 9 y un 12 por ciento.
También hay mejoras más pequeñas en lo que el usuario suele notar a simple vista. En esas pruebas, el arranque del sistema baja alrededor de un 2 por ciento y el arranque en frío de apps, cuando abres una app desde cero y no estaba en memoria, mejora algo más de un 4 por ciento.
Cuándo puede llegar a otros móviles
Este tipo de cambio no se instala como una app ni aparece como un ajuste nuevo en Configuración. Llega cuando el fabricante adopta un kernel común de Android ya compilado con esos perfiles, o cuando integra esta idea en su propia cadena de construcción.
La propia documentación del Android Open Source Project explica que estas ramas del kernel se organizan por versión de Android y versión de Linux, con nombres como android15-6.6, y sirven de base para que socios y fabricantes construyan sus dispositivos. Por eso, el alcance real depende de calendarios de actualización, modelos compatibles y decisiones de cada marca.
La nota oficial se ha publicado en Android Developers Blog.
