- AutoFDO bruger reelle runtime-data til at optimere Android-kernen og binære filer og prioriterer den mest anvendte kode.
- Test viser målbare forbedringer i opstart, åbning af apps og CPU-effektivitet, med en positiv indvirkning på batterilevetiden.
- Google anvender løbende profiler på LTS-grene af kernen og planlægger at udvide dækningen til flere versioner og moduler.
- Teknikken opretholder stabilitet ved kun at ændre compilerheuristikker uden at ændre logikken i kildekoden.
I de senere år har Google taget missionen om at lave Android meget alvorligt. hurtigere, mere jævnt og med bedre batterilevetid uden at brugeren behøver at røre ved noget. En af nøgleelementerne i denne strategi er AutoFDO, en optimeringsteknologi, der indtil nu primært blev brugt i brugerområdet (native apps og biblioteker), men som nu også når kernen, systemets hjerte.
Denne nye udvikling lyder måske meget teknisk, men dens virkninger er ret almindelige: Telefoner der starter lidt hurtigere, apps der åbner hurtigere, og en lille forbedring i energiforbrugetDu vil ikke føle, at du får en helt ny telefon, men det bidrager til de små forbedringer, der gør Android mere og mere fleksibel og effektiv.
Hvad er AutoFDO, og hvorfor er det vigtigt i Android?
AutoFDO kommer fra Automatisk feedback-rettet optimeringeller med andre ord, automatisk optimering styret af reelle runtime-data. I modsætning til klassiske metoder, hvor compileren er afhængig af statiske regler og antagelser, bruger AutoFDO information indsamlet, mens koden faktisk kører, til at beslutte, hvordan den skal optimeres.
I en traditionel kompilering tager compileren konstant tusindvis af mikrobeslutninger om, hvordan koden skal organiseresOm man skal integrere en funktion eller lade den være separat, hvilken gren af en if-sætning der mest sandsynligt udføres, hvordan man rækkefølger instruktioner i hukommelsen, så CPU'en udnytter dem bedre osv. Alle disse beslutninger er normalt baseret på generelle heuristikker, som ikke altid stemmer overens med, hvad der rent faktisk sker, når man bruger sin mobiltelefon dagligt.
Med AutoFDO indsamler systemet i stedet for udelukkende at stole på disse antagelser faktiske udførelsesprofilerHvilke funktioner bruges mest, hvilke kodestier overskrives konstant, og hvilke berøres næsten ikke. Disse data hentes fra hardwarens overvågningsfunktioner (CPU-branch tracing) og transformeres til profiler, som compileren forstår og bruger til at omarrangere koden med langt større præcision.
Denne teknik er en videreudvikling af den klassiske PGO (Profilstyret optimering) baseret på instrumentering, som allerede bruges i Windows, Linux og browsere som ChromeForskellen er, at AutoFDO er mindre invasiv, tillader dataindsamling uden rekompilering ved hjælp af specielt instrumenterede versioner og er tættere på den faktiske brug af enheden.
I Android blev AutoFDO oprindeligt introduceret i Android 12 for at optimere eksekverbare filer og native bibliotekerNu tager Google den samme idé til et endnu lavere niveau: Android-kernen, som tegner sig for cirka 40% af CPU-tiden. Optimering der har en direkte indflydelse på næsten alt, hvad du gør med din telefon.
Hvordan fremskynder AutoFDO Android-kernen?
Android LLVM-værktøjskædeteamet har designet en forholdsvis sofistikeret pipeline, der gør det muligt for AutoFDO at køre i kernen uden at gå på kompromis med stabiliteten. Nøglen er at generere profiler af høj kvalitet i et laboratoriemiljø og derefter anvende dem på kernen. Generisk kernebillede (GKI), som danner grundlag for mange enheder.
Til at begynde med skal Google vide, hvordan kernen rent faktisk opfører sig, når du bruger telefonen. For at gøre dette flasher den testenheder (primært Pixel) med det seneste kernebillede og bruger værktøjer som simpleperf understøttet af specifikke hardwarefunktioner, såsom ARM Embedded Trace Extension (ETE) og ARM Trace Buffer Extension (TRBE), til at registrere CPU-forgreningshistorikken.
Disse enheder reproducerer en repræsentativ arbejdsbyrde, der inkluderer De 100 mest populære anvendelser af Compatibility Test Suite (C-Suite)Det handler ikke bare om at åbne dem én gang, og det er det; komplette interaktioner med den virkelige bruger simuleres, inklusive AI-styrede handlinger, der sporer, hvordan appsene bruges over tid.
Under disse tests overvåges hele systemet: Forgrundsapps, baggrundsprocesser, kritiske tjenester og kommunikation mellem processerResultatet er et ret detaljeret kort over, hvilke dele af kernen der er "varme" (kører kontinuerligt), og hvilke der er "kolde" (næsten ikke berøres). Google hævder, at denne syntetiske arbejdsbelastning formår at reproducere omkring 85% af de udførelsesmønstre, der observeres i dens faktiske interne flåde, et meget højt tal for et kontrolleret miljø.
Når disse oplysninger er tilgængelige, rekompileres kernen med disse AutoFDO-profiler. Compileren, som nu har adgang til reelle data, kan Prioriter optimering lige dér, hvor det er mest synligtkritiske udførelsesstier, intensiv I/O-håndtering, kontekstskift mellem processer osv., samtidig med at resten af koden kan optimeres med standardteknikker.
Komplet pipeline: fra profilindsamling til løbende opdatering
For at AutoFDO kan være nyttig i det lange løb, er det ikke nok blot at generere en profil én gang og glemme alt om den. Kernel- og systemkode ændres med hver version og patch, så profiler bliver forældede. "bliver ubalanceret" over tidDerfor har Google oprettet en kontinuerlig pipeline med flere meget klare trin.
I det første trin, indsamlingen af profiler, adskilles processen fra generere startcyklusprofiler for hver enhedMed andre ord defineres det generiske kernebillede i laboratoriet uden at være afhængig af den virkelige flåde eller specifikke versioner, som brugerne har adgang til. Dette giver mulighed for langt mere fleksible og hurtigere profilopdateringer, når en ny version af GKI-kernen er tilgængelig.
Dernæst kommer profilbehandling. De rå sporingsdata, der genereres af hardwaren, efterbehandles, så compileren kan bruge dem. Målinger grupperes fra flere henrettelser og flere enheder For at opnå et globalt overblik konverteres disse spor til standard AutoFDO-formatet, og irrelevante symboler, der ikke bidrager med noget nyttigt til ydeevnen, filtreres fra.
Et vigtigt punkt er profiltrimning. Ved at rydde op i dataene fjernes unødvendige funktioner fra profilen, så de fortsat kan bruges. "traditionelle" optimeringerDette undgår sjældne regressioner i kode, der sjældent udføres, og holder størrelsen af de binære filer under kontrol, fordi profildata også påvirker kodens layout i hukommelsen.
Før implementering af en ny profil udføres en grundig verifikation. Teamet analyserer og sammenligner profilens indhold (aktive funktioner, antal prøver, profilstørrelse) med tidligere versioner og genererer et nyt kernebillede med AutoFDO anvendt. Derefter... ændringer i tekstafsnittet (koden) for at bekræfte, at ændringerne stemmer overens med forventningerne.
Parallelt køres specifikke benchmarks for at validere, at det nye image opretholder eller forbedrer de ønskede præstationsmålinger: opstartstider, koldstart af applikationer, grænsefladefluiditetosv. Hvis noget ikke passer, eller der opstår regression, justeres eller kasseres profilen, før den når brugerne.
Endelig kører Google denne pipeline kontinuerligt. Profiler opdateres med jævne mellemrum i Android-kernens LTS-grene og er integreret i hver GKI-udgivelse. I øjeblikket er udrulningen fokuseret på Android 16-6.12- og Android 15-6.6-grenene, men intentionen er at udvide den til senere versioner såsom den kommende Android 17-6.18.
Resultater: Hvor mærkbar er AutoFDO i hverdagen
Al denne ingeniørkunst ville være meningsløs, hvis tallene ikke understøttede det. Ifølge Googles interne målinger har anvendelsen af AutoFDO på Android-kernen på Pixel-enheder opnået håndgribelige, omend moderate, forbedringer i flere nøgleparametre.
I laboratorietests er den gennemsnitlige præstationsforøgelse omkring 10,5 % i specifikke scenarierhvilket opnår cirka 85% af den fordel, som en klassisk feedbackdrevet optimering baseret på instrumentering ville give. Det smukke er, at AutoFDO opnår noget meget lignende uden at pådrage sig omkostningerne og kompleksiteten ved at instrumentere koden.
Hvis vi ser på de tal, der er mest synlige for brugeren, taler Google om en reduktion af systemopstartstid på cirka 2,1% og en forbedring i opstartstider for kolde apps på omkring 4-4,3%. Det lyder måske småt, men det er vigtigt at huske, at kernen tegner sig for cirka 40% af den samlede CPU-tid, så enhver justering der resulterer i en mere raffineret samlet ydeevne.
Udover hastighed påvirker kerneloptimering også strømforbruget. Ved at omorganisere koden, så De hyppigste ruter er mere effektiveCPU'en kan udføre operationer hurtigere og vende tilbage til lavstrømstilstande hurtigere. I praksis hjælper dette med at få lidt mere ud af batteriet, især under gentagne handlinger som at skifte app, administrere notifikationer eller navigere i brugergrænsefladen.
Alt dette bidrager til de forbedringer, som AutoFDO allerede bringer til brugerområdet. På Android har denne teknologi været brugt i et stykke tid til at optimere ydeevnen. kritiske eksekverbare filer og bibliotekerMed tal som en forbedring på 4% i koldstartstider for apps og en reduktion på 1% i enhedens opstartstid takket være optimeringer af brugerplads, er den nye funktion, at systemkernen nu er inkluderet i denne pakke af optimeringer.
Stabilitet og sikkerhed: hvorfor AutoFDO ikke ødelægger systemet
En logisk bekymring, når man diskuterer kernejusteringer, er, om dette kan påvirke systemets stabilitet eller pålidelighedGoogle er opmærksom på dette og har designet AutoFDO i Android med en meget konservativ filosofi.
Det første, man skal huske på, er, at AutoFDO ikke ændrer kildekoden. Det, den gør, er at påvirke compiler heuristikkerDen bestemmer, hvor funktioner skal indsættes (inlining), hvordan kodeblokke skal rækkefølges, hvilke ruter der skal prioriteres i cachen osv. Med andre ord forbliver funktionaliteten den samme; det, der varierer, er, hvordan koden er placeret, så CPU'en udfører den med mindre indsats.
Derudover anvendes en "konservativ som standard"-tilgang. Funktioner, der ikke vises i high-fidelity-profilerne – fordi de sjældent eller næsten aldrig bruges i de analyserede scenarier – kompileres med samme standardoptimeringer som altidDette hjælper med at undgå overraskelser i sjældne udførelsesstier, såsom meget sjældne fejl eller mærkelig adfærd i kanttilfælde.
Det er også vigtigt at huske, at AutoFDO ikke er et skud i blinde. Denne teknologi har været anvendt i årevis i Android, ChromeOS og Googles serverinfrastruktur...såvel som på andre platforme, som et almindeligt optimeringsværktøj. Tidligere erfaringer viser, at det, når det anvendes korrekt, ikke introducerer væsentlige yderligere risici.
For Android gennemgår hver ny profil en intensiv testfase, før den når en LTS-gren af kernen. Profilens indhold sammenlignes med tidligere versioner, de resulterende binære filer analyseres, og målrettede benchmarks køres. Først når det er bekræftet, at Der er ingen præstationsregressioner eller ustabil adfærdProfilen er integreret og forberedt til implementering i GKI-billeder.
AutoFDO i AOSP og udviklersupport
Ud over kernen har Android-byggesystemet understøttet AutoFDO siden Android 12 til optimering. native moduler med specifikke kompileringsreglerI AOSP (Android Open Source Project) er AutoFDO som standard aktiveret for de fleste projekter, hvor ydeevne er afgørende.
Profilerne i AOSP er blevet samlet i telefoner og tablets og afspejler generelle brugsmønstre. De gemmes i path toolchain/pgo-profiles/sampling og anvendes automatisk under kompilering af mange relevante biblioteker og binære filer, hvilket giver mulighed for forbedret ydeevne og i mange tilfælde endda en reduktion i størrelsen af eksekverbare filer.
Hvis en producent, leverandør eller udvikler ønsker at udnytte AutoFDO til yderligere moduler eller lokalt modificeret kodeDu har mulighed for at samle dine egne profiler. Dette er især nyttigt, når du tilføjer nye projekter, tilpasser systemet med en masse af din egen kode eller har meget specifikke brugsmønstre, der ikke helt passer til generiske profiler.
For byggeregler af Blueprint-typen er aktivering af AutoFDO så simpelt som at tilføje attributten afdo:sand til definitionen af et delt bibliotek eller en binær fil. Derfra ved byggesystemet allerede, hvordan det skal søge efter og anvende den tilsvarende AutoFDO-profil i byggeprocessen.
Android understøtter profilindsamling på enheder x86, x86_64, ARM og ARM64Disse profiler kan genbruges på tværs af arkitekturer. Dataindsamling på ARM bruger dokumenterede procedurer baseret på Trace Extension (ETM), mens der på x86 anvendes funktioner som Last Branch Record (LBR). Derudover er der Profcollect, en mekanisme til Automatiser indsamling, behandling og upload af profiler i baggrundendesignet præcist til disse scenarier.
Når AutoFDO-profiler er genereret, kan de inspiceres ved hjælp af standard LLVM-værktøjer, f.eks. llvm-profdataScripts som afdo_summary.sh giver dig mulighed for hurtigt at se, hvilke funktioner der er de mest populære i henhold til profilen, hvilket letter både diagnostisk arbejde og justering af ydeevne.
Fremtidsplaner: mere dækning og mere optimerede komponenter
Den nuværende implementering af AutoFDO i kernen fokuserer på Android 16-6.12 og Android 15-6.6 grenene, men Google ser allerede længere frem. Intentionen er udvide dækningen til nyere versioner af GKI, inklusive den planlagte til Android 17 (android17-6.18) og andre yderligere build-mål ud over aarch64.
Indtil videre har optimeringen primært fokuseret på den primære kernebinære fil (vmlinux)Det næste logiske skridt er dog også at bringe AutoFDO til GKI-modulerne, som repræsenterer en vigtig del af kernesystemet og dækker specifikke funktionaliteter, der også påvirker systemets ydeevne.
En anden åben front er den mulige kompatibilitet med Leverandørmoduler bygget med Driver Development Kit (DDK)Da byggesystemet (Kleaf) og profileringsværktøjerne (simpleperf) allerede understøtter AutoFDO, er der et solidt fundament for producenter til at anvende den samme teknik på deres egne hardwaredrivere og yderligere finjustere ydeevnen til deres specifikke enheder.
Google overvejer også at udvide diversiteten af brugerprofiler ved at inkorporere yderligere kritiske brugerrejser (CUJ'er) for at dække en bredere vifte af virkelige situationer: spil, multimedia, tung multitasking og mere. Jo mere varieret samlingen af brugerprofiler er, desto mere raffineret vil optimeringen være. uden at miste den nødvendige generalitet så det fungerer godt på millioner af enheder.
Samlet set er AutoFDO en del af en bredere strategi, hvormed Google sigter mod at holde Android konkurrencedygtig, ikke kun ved at tilføje iøjnefaldende funktioner for brugeren, men også ved at forfine operativsystemets interne effektivitetI et så forskelligartet økosystem med tusindvis af forskellige modeller, hjælper disse forbedringer på lavt niveau selv beskeden hardware med at føles lidt mere responsiv, da high-end-telefoner får mest muligt ud af deres ressourcer.
I sidste ende omsættes alt dette arbejde fra AutoFDO på Android til noget ret simpelt for den person, der holder telefonen: et system, der reagerer lidt hurtigere, føles noget mere jævnt og bruger CPU og batteri smartere, uden skjulte menuer eller komplicerede indstillinger, simpelthen fordi softwaren lærer af, hvordan vi rent faktisk bruger den.
Passioneret forfatter om bytes-verdenen og teknologien generelt. Jeg elsker at dele min viden gennem skrivning, og det er det, jeg vil gøre i denne blog, vise dig alle de mest interessante ting om gadgets, software, hardware, teknologiske trends og mere. Mit mål er at hjælpe dig med at navigere i den digitale verden på en enkel og underholdende måde.
