Hur AutoFDO-kärnoptimeringar tyst gör Android snabbare och effektivare

Hem » Python » Hur AutoFDO-kärnoptimeringar tyst gör Android snabbare och effektivare

Android får en serie tysta, lågnivåförändringar som syftar till att få telefoner att kännas snabbare samtidigt som batteritiden förlängs lite ytterligareIstället för flashiga nya funktioner fokuserar Google på hur operativsystemets kärna fattar beslut varje millisekund under huven.

I centrum för denna insats står en teknik som kallas AutoFDO, en förkortning för Automatisk feedback-riktad optimering tillämpad på Android-kärnanGenom att omforma hur kärnan kompileras baserat på verklig användningsdata försöker Google minska slöseri med CPU-arbete, trimma bakgrundsbelastning och ge befintliga enheter en blygsam men märkbar ökning av responsen.

Vad AutoFDO faktiskt gör i Android-kärnan

Under en normal build måste en kompilator göra tusentals mikrobeslut om hur man arrangerar och finjusterar kodDen gissar vilka grenar som är sannolika, vilka funktioner som ska infogas, hur instruktioner ska utformas i minnet och så vidare, till stor del baserat på statiska tips och generiska heuristik.

Problemet är att dessa gissningar inte alltid stämmer överens med vad som verkligen händer när din telefon används. Kärnan, som kan stå för cirka 40 % av den totala CPU-tiden i Android, kan spendera cykler på sällan använda kodvägar medan de som används ofta inte är optimerade så aggressivt som de skulle kunna vara.

AutoFDO vänder på den här metoden genom att mata kompilatorn profiler byggda från verkliga exekveringsmönsterIstället för att huvudsakligen förlita sig på teori styrs byggprocessen av hur koden faktiskt beter sig på enheter, vilket gör att kärnans binärfil kan formas kring vardagliga arbetsbelastningar.

För användare visas detta inte som en ny inställning eller meny. Det visas subtilt som något snabbare reaktioner när man startar appar eller startar om telefonen, och eftersom mindre CPU-tid förbrukas på bakgrundsbeslut som användarna aldrig ser direkt.

Från statiska gissningar till verkliga exekveringsprofiler

Traditionellt sett förlitade sig profilstyrd optimering på instrumenterade binärfiler som samlade in data under speciella körningar. Det fungerar, men det kan vara påträngande och kanske inte återspeglar hur människor faktiskt använder sina telefoner dagligenAutoFDO tar en lättare väg baserad på sampling.

Google använder en samplingsprofilerare för att fånga upp CPU:s grenhistorik och instruktionsvägar medan Android kör realistiska arbetsbelastningarDessa exempel visar vilka delar av kärnan som är "heta" (körs ofta) och vilka som är "kalla" (rörs sällan), utan att behöva bygga om allt med tunga instrument.

Specifikt för kärnan syntetiseras data i en laboratoriemiljö. Ingenjörer spelar upp representativa arbetsbelastningar som inkluderar de 100 mest populära Android-apparna från kompatibilitetstestsviten. Denna mix är utformad för att efterlikna verklig användning: öppna och stänga appar, växla mellan dem, bakgrundssynkroniseringar och kommunikation mellan processer.

När de råa spåren väl har samlats in går de igenom en aggregerings- och rengöringsprocessData från flera körningar och enheter slås samman, konverteras till standard LLVM AutoFDO-profilformat och filtreras så att endast relevanta symboler och funktioner finns kvar. Kalla funktioner trimmas ofta från profilen så att de återgår till konventionella kompilatorheuristik istället för att snedvrida optimeringen.

Denna kurerade profil vägleder sedan en ny kärnbyggnation. Med korrekt information om vilka kodsökvägar som är viktigast kan kompilatorn integrera kritiska rutiner mer aggressivt, arrangera het kod så att den är cachevänlig och minska betoningen på sällan använda grenar. Resultatet är en kärna som är bättre anpassad till de arbetsbelastningar som Android-telefoner faktiskt ser.

Hur mycket snabbare och effektivare kan Android bli?

De tidiga siffrorna från Googles interna tester är blygsamma men påtagliga. Med AutoFDO tillämpat på kärnan, enhetens starttid förbättras med ungefär 2.1 %Det kommer inte att förvandla en långsam telefon till en raket, men det kan minska väntetiden lite varje gång du startar om den.

Förstärkningarna är något mer uttalade när man öppnar appar från ett "kallt" tillstånd – det vill säga när de inte redan finns i minnet. Här levererar AutoFDO ungefär en 4.3 % minskning av kallstarttider, särskilt användbart för tyngre appar som förlitar sig på inbyggda komponenter och kärnans tjänster.

Under dessa tydliga mätvärden noterar Google även förbättringar inom områden som är mindre synligt men ändå viktigt: smidigare bakgrundsschemaläggning, färre CPU-toppar för rutinmässiga kärnuppgifter och generellt smidigare hantering av operationer på systemnivå. Allt detta bidrar till känslan av att en enhet är mer responsiv, även om det är svårt att peka på en enda dramatisk förändring.

Eftersom kärnan kan förbruka en stor andel av den totala CPU-kapaciteten, kan även ensiffriga procentuella vinster omvandlas till frigjorda resurser som kan användas av appar och systemgränssnittSamtidigt bidrar det oundvikligen till energieffektivitet genom att minska onödigt CPU-arbete, så batteriet förbrukas lite utan några hårdvaruändringar.

Google är noga med att positionera dessa fördelar som stegvisa. Användare bör inte förvänta sig en kontinuerlig omvandling, utan snarare en stadig förfining av hur Android känns och beter sig över tid, särskilt när flera sådana optimeringar staplas tillsammans över olika utgåvor.

Bibehåller stabilitet samtidigt som man ändrar hur kärnan är uppbyggd

En återkommande oro vid all profilstyrd optimering är om den riskerar bryta förväntat beteende eller introducera subtila buggarNär det gäller AutoFDO betonar Google att tekniken modifierar hur kompilatorn prioriterar och utformar kod, inte själva kärnans logik.

Metoden beskrivs som "konservativ som standard". Det betyder att funktioner som inte är väl representerade i högpresterande profildata är lämnas till standardoptimeringsstrategier snarare än att omformas aggressivt. Kalla eller sällan exekverade banor beter sig i huvudsak som de skulle göra i en traditionell version, vilket minskar risken för regressioner i obskyra scenarier.

Innan profiler accepteras genomgår de flera kontroller. Ingenjörer analyserar profilinnehållet – aktiva funktioner, antal exempel och total storlek – och jämför det med tidigare versioner. En ny kärnavbildning byggs sedan, och riktmärken körs för att säkerställa att prestandavinsterna är konsekventa och att latens eller dataflöde inte oväntat försämras i viktiga arbetsbelastningar.

Detta är inte Googles första användning av AutoFDO. Tekniken har redan använts i stor utsträckning för kärnbibliotek i Android, ChromeOS-komponenter och till och med intern serverinfrastrukturDen tidigare erfarenheten fungerar som ett skyddsnät, vilket tyder på att optimeringsstilen i sig är mogen, även om det är relativt nytt att tillämpa den på Android-kärnan.

Resultatet är att AutoFDOs kärnintegration är utformad för att bevara funktionell stabilitet samtidigt som man fortfarande får ut extra effektivitetFör slutanvändare är förändringen tänkt att vara osynlig vad gäller tillförlitlighet, men i det tysta fördelaktig vad gäller prestanda.

Hur profiler uppdateras och lanseras över tid

En statisk profil skulle snabbt bli inaktuell eftersom Android, appar och användningsmönster utvecklasFör att hålla AutoFDO effektivt behandlar Google profilgenerering som en pågående process snarare än en engångsuppgift.

Profiler för den generiska kärnavbildningen (GKI) återskapas före varje ny LTS-kärnlanseringUppdaterade arbetsbelastningar baserade på aktuella versioner av de 100 bästa apparna spelas upp igen, data samplas på nytt och profiler rekonstrueras och valideras. Denna rullande pipeline hjälper till att säkerställa att nyare kärnversioner spårar hur människor faktiskt använder Android vid den tidpunkten.

Intressant nog noterar Google att Labbgenererade arbetsbelastningar visar cirka 85 % likhet till exekveringsmönster som samlats in från interna enhetsflottor. Den nivån av överlappning tyder på att den syntetiserade metoden är tillräckligt nära verkligt beteende för att vara användbar för att vägleda optimering, samtidigt som den är enklare att kontrollera och uppdatera.

Eftersom dessa profiler följer standardformatet LLVM AutoFDO, ansluts de direkt till befintliga analysverktyg som llvm-profdataIngenjörsteam kan inspektera heta funktioner, granska anropsmönster och verifiera att optimeringsinsatser läggs där det faktiskt spelar roll.

Över flera iterationer förvandlar denna upprepade profilerings- och ombyggnadscykel AutoFDO till en kontinuerlig inställningsmekanism för kärnan, snarare än en enda tweak låst till en version av Android.

AutoFDO över Android-stacken och verktygen

Övergången till AutoFDO i kärnan bygger på arbete som har pågått på andra ställen i Android-stacken under en tid. Stöd för AutoFDO är inbyggt i Android-byggsystemet som används av AOSP, särskilt för nativa moduler som förlitar sig på byggdefinitioner i ritningsstil.

För många prestandakänsliga bibliotek och binärfiler inom AOSP har profiler redan samlats in från riktiga telefoner och surfplattor. färdiga AutoFDO-profiler finns bredvid källan och kan aktiveras genom att helt enkelt växla mellan motsvarande byggflaggor, så enhetstillverkare som spårar AOSP ärver optimeringarna noggrant med minimalt extra arbete.

Androids profileringsramverk kan samla in data över flera CPU-arkitekturer, inklusive x86, x86_64, ARM och ARM64Så länge arbetsbelastningen är representativ kan en profil som skapats på en arkitektur ibland anpassas till en annan, vilket förenklar distribution över heterogena enhetsuppställningar.

Utvecklare som behöver mer skräddarsydda optimeringar – till exempel när de lägger till egna inbyggda komponenter eller modifierar befintliga – uppmuntras att samla in profiler direkt från utvecklings- eller testenheterVerktyg som simpleperf och relaterade verktyg hjälper till att samla in nödvändiga prover utan att störa den normala driften i någon större utsträckning.

Kort sagt, AutoFDO är inte bara ett kärntrick. Det passar in i en bredare strategi där Androids viktigaste delar kompileras kontinuerligt om med vägledning från verklig användningsdata., snarare än att enbart förlita sig på statiska antaganden om prestanda.

Var och när dessa kärnförbättringar kommer att landa

Google introducerar AutoFDO-drivna kärnversioner först i långsiktigt stöd (LTS) grenar av Android-kärnan, närmare bestämt android16-6.12 och android15-6.6. Dessa grenar fungerar som baslinje för många tillverkare, som sedan lägger sina egna ändringar och enhetsspecifika justeringar ovanpå.

Företaget har också skisserat planer på att utöka användningen av AutoFDO till framtida GKI-versioner som android17-6.18Allt eftersom nya enheter levereras med dessa kärnor – och i takt med att befintliga telefoner får uppdateringar som drar in de nyare LTS-baserna – bör fler användare börja dra nytta av det förfinade beteendet.

Framöver utforskar Google sätt att utöka AutoFDO-täckningen bortom den huvudsakliga vmlinux-binärfilenDet inkluderar att profilstyrda optimeringar införs i GKI-moduler och, så småningom, i leverantörsmoduler byggda med Driver Development Kit. Detta skulle göra det möjligt för hårdvarupartners att tillämpa samma profileringstekniker på sina egna drivrutiner och sprida fördelarna djupare in i ekosystemet.

Den långsiktiga visionen är att AutoFDO-drivna byggen berör en allt större del av kärnan och dess moduler, från kärnschemaläggningskod till enhetsspecifika komponenterAllt eftersom det fotavtrycket växer kan den kumulativa effekten på respons och effektivitet bli mer uttalad, även om varje enskild förändring är subtil.

Allt detta bidrar till en tyst men meningsfull förändring i hur Android justeras på de lägsta nivåerna. Genom att låta verkliga exekveringsmönster vägleda kompilatorn siktar Google på telefoner som känns lite snabbare, slösar färre CPU-cykler och gör något bättre utnyttjande av varje milliamperetimme batteri — allt utan att användare behöver byta enhet eller bläddra igenom inställningar.