- Google está incorporando las optimizaciones guiadas por perfiles de AutoFDO directamente en el núcleo de Android para reducir la carga de la CPU y el consumo de energía.
- Los patrones de ejecución reales de las 100 aplicaciones más utilizadas guían al compilador para que priorice las rutas de código más utilizadas y reste importancia a las menos utilizadas.
- Las primeras pruebas muestran tiempos de arranque un 2.1 % más rápidos y un inicio de aplicaciones en frío un 4.3 % más rápido, con mejoras adicionales en la eficiencia en segundo plano.
- AutoFDO se está implementando en las ramas LTS del kernel de Android android16-6.12 y android15-6.6, y está previsto que se extienda a Android 17 y versiones posteriores.
Android está recibiendo una serie de cambios silenciosos y de bajo nivel que tienen como objetivo hacer que los teléfonos se sientan Más rápido y a la vez prolonga un poco más la duración de la batería.En lugar de funciones nuevas y llamativas, Google se está centrando en cómo el núcleo del sistema operativo toma decisiones cada milisegundo en segundo plano.
En el centro de este esfuerzo se encuentra una técnica llamada AutoFDO, abreviatura de Optimización automática basada en retroalimentación aplicada al kernel de Android.Al modificar la forma en que se compila el núcleo basándose en datos de uso reales, Google está intentando reducir el trabajo innecesario de la CPU, disminuir la sobrecarga en segundo plano y proporcionar a los dispositivos existentes una mejora modesta pero notable en la capacidad de respuesta.
Qué hace realmente AutoFDO en el kernel de Android.
Durante una compilación normal, un compilador tiene que hacer miles de microdecisiones sobre cómo organizar y ajustar el códigoAdivina qué ramas son probables, qué funciones deberían insertarse en línea, cómo deberían organizarse las instrucciones en la memoria, etc., basándose en gran medida en sugerencias estáticas y heurísticas genéricas.
El problema es que estas suposiciones no siempre coinciden con lo que realmente sucede cuando se usa el teléfono. El núcleo, que puede tener en cuenta alrededor del 40% del tiempo total de CPU en Android, pueden consumir ciclos en rutas de código poco utilizadas, mientras que las de uso frecuente no se optimizan con la agresividad que podrían.
AutoFDO invierte este enfoque alimentando al compilador perfiles construidos a partir de patrones de ejecución realesEn lugar de basarse principalmente en la teoría, el proceso de compilación se guía por cómo se comporta realmente el código en los dispositivos, lo que permite adaptar el binario del kernel a las cargas de trabajo cotidianas.
Para los usuarios, esto no aparece como una nueva configuración o menú. Aparece sutilmente como reacciones ligeramente más rápidas al abrir aplicaciones o reiniciar el teléfono.y, además, se consume menos tiempo de CPU en decisiones en segundo plano que los usuarios nunca ven directamente.

De estimaciones estáticas a perfiles de ejecución en el mundo real
Tradicionalmente, la optimización guiada por perfiles se basaba en binarios instrumentados que recopilaban datos durante ejecuciones especiales. Eso funciona, pero puede ser intrusivo y puede no reflejar cómo la gente usa realmente sus teléfonos en el día a díaAutoFDO adopta un enfoque más ligero basado en el muestreo.
Google utiliza un perfilador de muestreo para capturar la Historial de ramificaciones y rutas de instrucciones de la CPU mientras Android ejecuta cargas de trabajo realistas.Estas muestras revelan qué partes del núcleo son "activas" (se ejecutan con frecuencia) y cuáles son "inactivas" (se utilizan raramente), sin necesidad de reconstruir todo con instrumentación compleja.
En lo que respecta al kernel, los datos se sintetizan en un entorno de laboratorio. Los ingenieros reproducen cargas de trabajo representativas que incluyen: Las 100 aplicaciones de Android más populares del conjunto de pruebas de compatibilidad. Esta combinación está diseñada para simular el uso real: abrir y cerrar aplicaciones, alternar entre ellas, sincronizaciones en segundo plano y comunicación entre procesos.
Una vez recolectados, los rastros en bruto pasan por un proceso de agregación y limpiezaLos datos de múltiples ejecuciones y dispositivos se combinan, se convierten al formato de perfil AutoFDO estándar de LLVM y se filtran para que solo queden los símbolos y funciones relevantes. Las funciones que no se utilizan habitualmente se eliminan del perfil para que recurran a las heurísticas convencionales del compilador en lugar de distorsionar la optimización.
Este perfil seleccionado guía entonces una nueva compilación del kernel. Con información precisa sobre qué rutas de código son más importantes, el compilador puede insertar rutinas críticas de forma más agresiva, organizar el código de uso frecuente para que sea compatible con la caché y restar importancia a las ramas poco utilizadas. El resultado es un kernel que es mejor alineado con las cargas de trabajo que realmente ven los teléfonos Android.
¿Hasta qué punto puede mejorar su velocidad y eficiencia Android?
Las primeras cifras de las pruebas internas de Google son modestas pero tangibles. Con AutoFDO aplicado al kernel, El tiempo de arranque del dispositivo mejora aproximadamente un 2.1%.Eso no convertirá un teléfono lento en un cohete, pero puede reducir un poco el tiempo de espera cada vez que lo reinicies.
Las ganancias son ligeramente más pronunciadas al abrir aplicaciones desde un estado "frío", es decir, cuando no están ya en la memoria. Aquí, AutoFDO ofrece aproximadamente un Reducción del 4.3% en los tiempos de arranque en frío., particularmente útil para aplicaciones más pesadas que dependen de componentes nativos y de los servicios del kernel.
Debajo de esas métricas claras, Google también señala mejoras en áreas que son Menos visible pero igualmente importanteProgramación en segundo plano más fluida, menos picos de CPU para tareas rutinarias del núcleo y, en general, un manejo más eficiente de las operaciones a nivel del sistema. Todo esto contribuye a la sensación de que un dispositivo responde mejor, aunque sea difícil señalar un único cambio drástico.
Debido a que el núcleo puede consumir una gran parte de la capacidad total de la CPU, incluso las ganancias porcentuales de un solo dígito se traducen en Recursos liberados que pueden ser utilizados por las aplicaciones y la interfaz de usuario del sistema.Al mismo tiempo, reducir el trabajo innecesario de la CPU contribuye inevitablemente a la eficiencia energética, por lo que la batería se beneficia sin necesidad de realizar cambios de hardware.
Google se cuida de presentar estos beneficios como incrementales. Los usuarios no deben esperar una transformación radical, sino más bien una mejora gradual. Perfeccionamiento constante de cómo se siente y se comporta Android con el tiempo.especialmente cuando se acumulan varias optimizaciones de este tipo en diferentes versiones.
Mantener la estabilidad al cambiar la forma en que se compila el núcleo.
Una preocupación recurrente con cualquier optimización guiada por perfiles es si conlleva riesgos. romper el comportamiento esperado o introducir errores sutilesEn el caso de AutoFDO, Google subraya que la técnica modifica la forma en que el compilador prioriza y organiza el código, no la lógica del núcleo en sí.
El enfoque se describe como “conservador por defecto”. Eso significa que las funciones que no están bien representadas en los datos de perfil de alta fidelidad son Se dejaron a las estrategias de optimización estándar. En lugar de ser remodelados agresivamente, los caminos fríos o poco ejecutados se comportan esencialmente como lo harían en una compilación tradicional, lo que reduce la probabilidad de regresiones en escenarios poco comunes.
Antes de que se acepten los perfiles, se someten a múltiples comprobaciones. Los ingenieros analizan el contenido del perfil (funciones de uso frecuente, recuento de muestras y tamaño total) y lo comparan con versiones anteriores. A continuación, se crea una nueva imagen del kernel y Se realizan pruebas de rendimiento para garantizar que las mejoras en el desempeño sean consistentes. y que la latencia o el rendimiento no empeoren inesperadamente en las cargas de trabajo clave.
Este no es el primer uso de AutoFDO por parte de Google. La técnica ya se ha implementado ampliamente para Bibliotecas principales de Android, componentes de ChromeOS e incluso infraestructura de servidor interna.Esa experiencia previa actúa como una red de seguridad, lo que sugiere que el estilo de optimización en sí mismo es maduro, incluso si su aplicación al kernel de Android es relativamente nueva.
El resultado es que la integración del kernel de AutoFDO está diseñada para preservar la estabilidad funcional al tiempo que se obtiene una eficiencia adicionalPara los usuarios finales, el cambio está pensado para ser imperceptible en términos de fiabilidad, pero discretamente beneficioso en términos de rendimiento.
Cómo se actualizan y se implementan los perfiles a lo largo del tiempo.
Un perfil estático se volvería obsoleto rápidamente Android, las aplicaciones y los patrones de uso evolucionan.Para que AutoFDO siga siendo eficaz, Google trata la generación de perfiles como un proceso continuo en lugar de una tarea puntual.
Se regeneran los perfiles para la imagen genérica del kernel (GKI). antes de cada nuevo lanzamiento del kernel LTSSe reproducen cargas de trabajo actualizadas basadas en las versiones actuales de las 100 aplicaciones más populares, se vuelven a muestrear los datos y se reconstruyen y validan los perfiles. Este proceso continuo ayuda a garantizar que las compilaciones más recientes del kernel reflejen cómo los usuarios utilizan Android en ese momento.
Curiosamente, Google señala que el Las cargas de trabajo generadas en laboratorio muestran una similitud de alrededor del 85%. a patrones de ejecución capturados de flotas de dispositivos internos. Ese nivel de coincidencia sugiere que el enfoque sintetizado se acerca lo suficiente al comportamiento del mundo real como para ser útil para guiar la optimización, a la vez que resulta más fácil de controlar y actualizar.
Debido a que estos perfiles siguen el formato estándar LLVM AutoFDO, se conectan directamente a herramientas de análisis existentes como llvm-profdataLos equipos de ingeniería pueden inspeccionar las funciones más utilizadas, analizar los patrones de llamadas y verificar que los esfuerzos de optimización se estén destinando a donde realmente importan.
A lo largo de múltiples iteraciones, este ciclo repetido de creación de perfiles y reconstrucción convierte a AutoFDO en un Mecanismo de ajuste continuo para el núcleo, en lugar de un único ajuste restringido a una sola versión de Android.
AutoFDO en toda la pila y las herramientas de Android
El cambio a AutoFDO en el kernel se basa en el trabajo que se ha estado realizando en otras partes de la pila de Android durante algún tiempo. El soporte de AutoFDO es Integrado en el sistema de compilación de Android utilizado por AOSP., especialmente para módulos nativos que dependen de definiciones de compilación de estilo blueprint.
Para muchas bibliotecas y binarios sensibles al rendimiento dentro de AOSP, ya se han recopilado perfiles de teléfonos y tabletas reales. Los perfiles AutoFDO predefinidos se encuentran junto al código fuente. y se pueden habilitar simplemente activando o desactivando las banderas de compilación correspondientes, de modo que los fabricantes de dispositivos que siguen de cerca AOSP heredan las optimizaciones con un mínimo de trabajo adicional.
El marco de creación de perfiles de Android puede recopilar datos en múltiples arquitecturas de CPU, incluyendo: x86, x86_64, ARM y ARM64Siempre que la carga de trabajo sea representativa, un perfil creado en una arquitectura a veces se puede adaptar a otra, lo que simplifica la implementación en conjuntos de dispositivos heterogéneos.
Se anima a los desarrolladores que necesitan optimizaciones más personalizadas —por ejemplo, al agregar sus propios componentes nativos o modificar los existentes— a que recopilar perfiles directamente de los dispositivos de desarrollo o pruebaHerramientas como simpleperf y utilidades relacionadas ayudan a capturar las muestras necesarias sin interrumpir en gran medida el funcionamiento normal.
En resumen, AutoFDO no es solo un truco del kernel. Se integra en una estrategia más amplia donde Las partes más importantes de Android se recompilan continuamente teniendo en cuenta los datos de uso reales.en lugar de basarse únicamente en suposiciones estáticas sobre el rendimiento.
Dónde y cuándo se implementarán estas mejoras del kernel.
Google está introduciendo compilaciones de kernel impulsadas por AutoFDO primero en el ramas de soporte a largo plazo (LTS) del kernel de Android, específicamente android16-6.12 y android15-6.6. Estas ramas sirven como base para muchos fabricantes, quienes luego añaden sus propios cambios y ajustes específicos para cada dispositivo.
La compañía también ha esbozado planes para extender el uso de AutoFDO a futuras versiones de GKI como android17-6.18A medida que los nuevos dispositivos se envíen con estos núcleos, y a medida que los teléfonos existentes reciban actualizaciones que incorporen las bases LTS más recientes, más usuarios deberían empezar a beneficiarse del comportamiento mejorado.
De cara al futuro, Google está explorando formas de Ampliar la cobertura de AutoFDO más allá del binario principal de vmlinux.Esto incluye incorporar optimizaciones basadas en perfiles a los módulos GKI y, eventualmente, a los módulos de los proveedores desarrollados con el Driver Development Kit. Esto permitiría a los socios de hardware aplicar las mismas técnicas de creación de perfiles a sus propios controladores, extendiendo así los beneficios a todo el ecosistema.
La visión a largo plazo es que las compilaciones basadas en AutoFDO afecten a una porción cada vez mayor del kernel y sus módulos, desde el código de planificación principal hasta los componentes específicos del dispositivoA medida que esa huella se expande, el efecto acumulativo sobre la capacidad de respuesta y la eficiencia podría volverse más pronunciado, incluso si cada cambio individual es sutil.
Todo esto se traduce en un cambio silencioso pero significativo en la forma en que Android se ajusta en los niveles más bajos. Al permitir que los patrones de ejecución del mundo real guíen al compilador, Google busca teléfonos que se sientan un poco más rápidos, desperdicien menos ciclos de CPU y hagan un uso ligeramente mejor de cada miliamperio-hora de batería — todo ello sin que los usuarios tengan que cambiar de dispositivo ni rebuscar en la configuración.