- Google està incorporant les optimitzacions guiades per perfils d'AutoFDO directament al nucli d'Android per reduir la sobrecàrrega de la CPU i el consum d'energia.
- Els patrons d'execució del món real de les 100 aplicacions més utilitzades guien el compilador per afavorir les rutes de codi calent i desprioritzar les de codi fred.
- Les primeres proves mostren temps d'arrencada al voltant d'un 2.1% més ràpids i inicis d'aplicacions en fred al voltant d'un 4.3% més ràpids, amb guanys addicionals en l'eficiència en segon pla.
- AutoFDO s'està implementant a les branques LTS del nucli d'Android android16-6.12 i android15-6.6 i està previst que s'expandeixi a Android 17 i posteriors.
Android està rebent una sèrie de canvis discrets i de baix nivell que tenen com a objectiu fer que els telèfons siguin més àgils i, alhora, allargar una mica més la durada de la bateria . En lloc de noves funcions cridaneres, Google se centra en com el nucli del sistema operatiu pren decisions cada mil·lisegon.
Al centre d'aquest esforç hi ha una tècnica anomenada AutoFDO, abreviatura de Automatic Feedback-Directed Optimization (Optimització Dirigida per Retroalimentació Automàtica) aplicada al nucli d'Android . En remodelar la manera com es compila el nucli en funció de dades d'ús reals, Google intenta reduir el treball de CPU malgastat, retallar la sobrecàrrega en segon pla i donar als dispositius existents un augment modest però notable en la capacitat de resposta.
Què fa realment AutoFDO al nucli d'Android
Durant una compilació normal, un compilador ha de prendre milers de microdecisions sobre com organitzar i ajustar el codi . Endevina quines branques són probables, quines funcions s'han d'incloure en línia, com s'han de disposar les instruccions a la memòria, etc., basant-se principalment en pistes estàtiques i heurístiques genèriques.
El problema és que aquestes conjectures no sempre coincideixen amb el que realment passa quan el telèfon està en ús. El nucli, que pot representar al voltant del 40% del temps total de CPU a Android , pot passar cicles en rutes de codi que s'utilitzen rarament, mentre que les que s'utilitzen amb freqüència no estan optimitzades tan agressivament com podrien.
AutoFDO inverteix aquest enfocament alimentant el compilador amb perfils creats a partir de patrons d'execució reals . En lloc de basar-se principalment en la teoria, el procés de compilació es guia per com es comporta realment el codi als dispositius, cosa que permet que el binari del nucli es modeli al voltant de les càrregues de treball diàries.
Per als usuaris, això no apareix com una nova configuració o menú. Apareix subtilment com a reaccions una mica més ràpides en iniciar aplicacions o reiniciar el telèfon , i com a menys temps de CPU consumit en decisions en segon pla que els usuaris no veuen mai directament.
De conjectures estàtiques a perfils d'execució del món real
Tradicionalment, l'optimització guiada per perfils es basava en binaris instrumentats que recollien dades durant execucions especials. Això funciona, però pot ser intrusiu i potser no reflecteix com la gent fa servir realment els seus telèfons diàriament . AutoFDO pren un camí més lleuger basat en el mostreig.
Google utilitza un perfilador de mostreig per capturar l' historial de ramificacions i les rutes d'instruccions de la CPU mentre Android executa càrregues de treball realistes . Aquests exemples revelen quines parts del nucli estan "calentes" (s'executen amb freqüència) i quines són "fredes" (poques vegades es toquen), sense haver de reconstruir-ho tot amb instrumentació pesada.
Pel que fa al nucli específicament, les dades es sintetitzen en un entorn de laboratori. Els enginyers reprodueixen càrregues de treball representatives que inclouen les 100 aplicacions Android més populars del conjunt de proves de compatibilitat. Aquesta combinació està dissenyada per imitar l'ús real: obrir i tancar aplicacions, canviar entre elles, sincronitzacions en segon pla i comunicació entre processos.
Un cop recollides, les traces en brut passen per un procés d'agregació i neteja . Les dades de diverses execucions i dispositius es fusionen, es converteixen al format de perfil LLVM AutoFDO estàndard i es filtren perquè només quedin els símbols i les funcions rellevants. Les funcions fredes sovint es retallen del perfil perquè tornin a l'heurística convencional del compilador en lloc de distorsionar l'optimització.
Aquest perfil curat guia una nova compilació del nucli. Amb informació precisa sobre quines rutes de codi són més importants, el compilador pot integrar rutines crítiques de manera més agressiva, organitzar el codi calent perquè sigui compatible amb la memòria cau i desemfatitzar les branques que rarament s'utilitzen. El resultat és un nucli que està millor alineat amb les càrregues de treball que realment veuen els telèfons Android.
Quant més ràpid i eficient pot arribar a ser Android?
Les primeres xifres de les proves internes de Google són modestes però tangibles. Amb AutoFDO aplicat al nucli, el temps d'arrencada del dispositiu millora aproximadament un 2.1% . Això no convertirà un telèfon lent en un coet, però pot reduir una mica l'espera cada vegada que reinicieu.
Els guanys són lleugerament més pronunciats quan s'obren aplicacions des d'un estat "fred", és a dir, quan no estan ja a la memòria. Aquí, AutoFDO ofereix una reducció d'aproximadament un 4.3% en els temps d'inici en fred , especialment útil per a aplicacions més pesades que es basen en components nadius i els serveis del nucli.
A més d'aquestes mètriques clares, Google també observa millores en àrees menys visibles però importants : una programació en segon pla més fluida, menys pics de CPU per a tasques rutinàries del nucli i, en general, una gestió més àgil de les operacions a nivell de sistema. Tot això contribueix a la sensació que un dispositiu respon millor, fins i tot si és difícil assenyalar un sol canvi dràstic.
Com que el nucli pot consumir una gran part de la capacitat total de la CPU, fins i tot els guanys percentuals d'un sol dígit es tradueixen en recursos alliberats que poden ser utilitzats per les aplicacions i la interfície d'usuari del sistema . Al mateix temps, retallar el treball innecessari de la CPU inevitablement ajuda a l'eficiència energètica, de manera que la bateria veu un cert alleujament sense cap canvi de maquinari.
Google té cura de posicionar aquests beneficis com a incrementals. Els usuaris no haurien d'esperar una transformació constant, sinó un refinament constant en com es comporta i es percep Android al llarg del temps , sobretot quan diverses optimitzacions d'aquest tipus s'acumulen en diferents versions.
Mantenir l'estabilitat mentre es canvia la manera com es compila el nucli
Una preocupació recurrent amb qualsevol optimització guiada per perfils és si corre el risc de trencar el comportament esperat o introduir errors subtils . En el cas d'AutoFDO, Google emfatitza que la tècnica modifica la manera com el compilador prioritza i disposa el codi, no la lògica del nucli en si.
L'enfocament es descriu com a "conservador per defecte". Això significa que les funcions que no estan ben representades a les dades de perfil d'alta fidelitat es deixen a estratègies d'optimització estàndard en lloc de ser remodelates agressivament. Els camins freds o rarament executats es comporten essencialment com ho farien en una compilació tradicional, cosa que redueix la possibilitat de regressions en escenaris poc clars.
Abans que els perfils siguin acceptats, se sotmeten a múltiples comprovacions. Els enginyers analitzen el contingut del perfil (funcions actives, recompte de mostres i mida general) i el comparen amb versions anteriors. A continuació, es crea una nova imatge del nucli i s'executen proves comparatives per garantir que els guanys de rendiment siguin consistents i que la latència o el rendiment no empitjorin inesperadament en càrregues de treball clau.
Aquest no és el primer ús d'AutoFDO per part de Google. La tècnica ja s'ha implementat àmpliament per a biblioteques bàsiques d'Android, components de ChromeOS i fins i tot infraestructura de servidors interns . Aquesta experiència prèvia actua com a xarxa de seguretat, cosa que suggereix que l'estil d'optimització en si és madur, fins i tot si aplicar-lo al nucli d'Android és relativament nou.
El resultat és que la integració del nucli d'AutoFDO està dissenyada per preservar l'estabilitat funcional alhora que s'aconsegueix una eficiència addicional . Per als usuaris finals, el canvi està pensat per ser invisible pel que fa a la fiabilitat, però discretament beneficiós pel que fa al rendiment.
Com s'actualitzen i es despleguen els perfils al llarg del temps
Un perfil estàtic esdevindria ràpidament obsolet a mesura que Android, les aplicacions i els patrons d'ús evolucionen . Per mantenir l'eficàcia d'AutoFDO, Google tracta la generació de perfils com un procés continu en lloc d'una tasca puntual.
Els perfils de la imatge genèrica del nucli (GKI) es regeneren abans de cada nova versió del nucli LTS . Es reprodueixen les càrregues de treball actualitzades basades en les versions actuals de les 100 aplicacions principals, es tornen a mostrejar les dades i es reconstrueixen i validen els perfils. Aquest procés continu ajuda a garantir que les compilacions del nucli més noves facin un seguiment de com la gent utilitza realment Android en aquell moment.
Curiosament, Google observa que les càrregues de treball generades al laboratori mostren al voltant d'un 85% de similitud amb els patrons d'execució capturats de les flotes de dispositius internes. Aquest nivell de superposició suggereix que l'enfocament sintetitzat s'acosta prou al comportament del món real per ser útil per guiar l'optimització, alhora que és més fàcil de controlar i actualitzar.
Com que aquests perfils segueixen el format estàndard LLVM AutoFDO, es connecten directament a eines d'anàlisi existents com ara llvm-profdata . Els equips d'enginyeria poden inspeccionar les funcions actives, aprofundir en els patrons de crides i verificar que l'esforç d'optimització s'està dedicant on realment importa.
Durant múltiples iteracions, aquest cicle repetit de perfilació i reconstrucció converteix AutoFDO en un mecanisme d'ajust continu per al nucli , en lloc d'un únic ajust bloquejat a una versió d'Android.
AutoFDO a la pila i les eines d'Android
El canvi a AutoFDO al nucli es basa en la feina que s'ha estat fent en altres parts de la pila d'Android durant un temps. La compatibilitat amb AutoFDO està integrada al sistema de compilació d'Android que utilitza AOSP , especialment per a mòduls nadius que es basen en definicions de compilació d'estil blueprint.
Per a moltes biblioteques i binaris sensibles al rendiment dins d'AOSP, els perfils ja s'han recopilat de telèfons i tauletes reals. Aquests perfils AutoFDO prefabricats conviuen al costat del codi font i es poden activar simplement activant els indicadors de compilació corresponents, de manera que els fabricants de dispositius que segueixen de prop AOSP hereten les optimitzacions amb un mínim treball addicional.
El marc de treball de perfils d'Android pot recopilar dades a través de múltiples arquitectures de CPU, com ara x86, x86_64, ARM i ARM64 . Sempre que la càrrega de treball sigui representativa, un perfil creat en una arquitectura de vegades es pot adaptar a una altra, cosa que simplifica el desplegament en línies de dispositius heterogènies.
Es recomana als desenvolupadors que necessitin optimitzacions més personalitzades (per exemple, a l'hora d'afegir els seus propis components nadius o modificar-ne d'existents) que recopilin perfils directament des dels dispositius de desenvolupament o de prova . Eines com ara simpleperf i utilitats relacionades ajuden a capturar les mostres necessàries sense interrompre greument el funcionament normal.
En resum, AutoFDO no és només un truc del nucli. S'emmarca en una estratègia més àmplia on les peces més crítiques d'Android es recopilen contínuament amb l'orientació de dades d'ús reals , en lloc de confiar únicament en suposicions estàtiques sobre el rendiment.
On i quan arribaran aquestes millores del nucli
Google introdueix les compilacions del nucli basades en AutoFDO primer a les branques de suport a llarg termini (LTS) del nucli d'Android , concretament android16-6.12 i android15-6.6. Aquestes branques serveixen com a base per a molts fabricants, que després hi afegeixen els seus propis canvis i ajustos específics del dispositiu.
L'empresa també ha descrit plans per estendre l'ús d'AutoFDO a futures versions de GKI com ara android17-6.18 . A mesura que els nous dispositius s'incloguin amb aquests nuclis (i a mesura que els telèfons existents rebin actualitzacions que incorporin les bases LTS més noves), més usuaris haurien de començar a beneficiar-se del comportament refinat.
De cara al futur, Google està explorant maneres d' ampliar la cobertura d'AutoFDO més enllà del binari principal de vmlinux . Això inclou portar optimitzacions guiades per perfils als mòduls GKI i, finalment, als mòduls de proveïdors creats amb el Driver Development Kit. Això permetria als socis de maquinari aplicar les mateixes tècniques de perfilació als seus propis controladors, estenent els beneficis més profundament a l'ecosistema.
La visió a llarg termini és que les compilacions basades en AutoFDO toquin una part cada cop més gran del nucli i els seus mòduls, des del codi de planificació del nucli fins als components específics del dispositiu . A mesura que aquesta petjada creixi, l'efecte acumulatiu sobre la capacitat de resposta i l'eficiència podria arribar a ser més pronunciat, fins i tot si cada canvi individual és subtil.
Tot això contribueix a un canvi discret però significatiu en la manera com Android s'ajusta als nivells més baixos. En deixar que els patrons d'execució del món real guiïn el compilador, Google pretén aconseguir telèfons que semblin una mica més ràpids, que malgastin menys cicles de CPU i que aprofitin una mica millor cada mil·liampere-hora de bateria , tot sense que els usuaris hagin de canviar de dispositiu o revisar la configuració.
