- Google uvodi optimizacije vođene profilima AutoFDO izravno u Androidovu jezgru kako bi smanjio opterećenje CPU-a i potrošnju energije.
- Obrasci izvršavanja iz stvarnog svijeta iz 100 najčešće korištenih aplikacija vode kompajler da favorizira vruće puteve koda i depriorizira hladne.
- Rani testovi pokazuju oko 2.1% brže vrijeme pokretanja i oko 4.3% brže pokretanje hladnih aplikacija, uz dodatna poboljšanja učinkovitosti u pozadini.
- AutoFDO se uvodi u LTS granama Android kernela android16-6.12 i android15-6.6, a planira se proširenje na Android 17 i novije verzije.
Android prima niz tihih, niskih promjena kojima je cilj učiniti telefone bržima, a istovremeno produžiti vijek trajanja baterije . Umjesto blještavih novih značajki, Google se usredotočuje na to kako jezgra operativnog sustava donosi odluke svake milisekunde "u podsvijesti".
U središtu ovog napora je tehnika pod nazivom AutoFDO, kratica za Automatic Feedback-Directed Optimization (Automatska optimizacija usmjerena na povratne informacije) primijenjena na Androidovu jezgru . Preoblikovanjem načina na koji se jezgra kompajlira na temelju stvarnih podataka o korištenju, Google pokušava smanjiti neiskorišteni rad CPU-a, smanjiti opterećenje pozadine i dati postojećim uređajima skromno, ali primjetno poboljšanje odziva.
Što AutoFDO zapravo radi u Android kernelu
Tijekom normalnog prevođenja, kompajler mora donijeti tisuće mikro-odluka o tome kako rasporediti i podesiti kod . Pogađa koje su grane vjerojatne, koje funkcije treba ugraditi, kako instrukcije treba rasporediti u memoriji i tako dalje, uglavnom na temelju statičkih savjeta i generičkih heuristika.
Problem je u tome što se ta nagađanja ne poklapaju uvijek s onim što se stvarno događa kada je vaš telefon u upotrebi. Jezgra, koja može činiti oko 40% ukupnog CPU vremena u Androidu , može trošiti cikluse na rijetko korištene kodne puteve, dok oni često korišteni nisu optimizirani tako agresivno kao što bi mogli biti.
AutoFDO mijenja ovaj pristup tako što unosi profile kompajlera izgrađene iz stvarnih obrazaca izvršavanja . Umjesto oslanjanja uglavnom na teoriju, proces izgradnje vodi se time kako se kod zapravo ponaša na uređajima, što omogućuje oblikovanje binarnog koda kernela prema svakodnevnim radnim opterećenjima.
Za korisnike se ovo ne prikazuje kao nova postavka ili izbornik. Suptilno se pojavljuje kao nešto brže reakcije prilikom pokretanja aplikacija ili ponovnog pokretanja telefona te kao manje CPU vremena potrošenog na pozadinske odluke koje korisnici nikada ne vide izravno.
Od statičnih nagađanja do profila izvršenja u stvarnom svijetu
Tradicionalno, optimizacija vođena profilima oslanjala se na instrumentirane binarne datoteke koje su prikupljale podatke tijekom posebnih izvršavanja. To funkcionira, ali može biti nametljivo i možda ne odražava način na koji ljudi zapravo svakodnevno koriste svoje telefone . AutoFDO zauzima lakši put temeljen na uzorkovanju.
Google koristi profiler za uzorkovanje kako bi zabilježio povijest grananja CPU-a i putanje instrukcija dok Android izvršava realna opterećenja . Ovi uzorci otkrivaju koji su dijelovi kernela "vrući" (često se izvršavaju), a koji "hladni" (rijetko se diraju), bez potrebe za ponovnom izgradnjom svega s teškom instrumentacijom.
Što se tiče kernela, podaci se sintetiziraju u laboratorijskom okruženju. Inženjeri reproduciraju reprezentativna opterećenja koja uključuju 100 najpopularnijih Android aplikacija iz paketa za testiranje kompatibilnosti. Ova kombinacija je osmišljena da oponaša stvarnu upotrebu: otvaranje i zatvaranje aplikacija, prebacivanje između njih, sinkronizaciju u pozadini i komunikaciju između procesa.
Nakon prikupljanja, sirovi tragovi prolaze kroz proces agregacije i čišćenja . Podaci iz više prolaza i uređaja spajaju se, pretvaraju u standardni LLVM AutoFDO format profila i filtriraju tako da ostaju samo relevantni simboli i funkcije. Hladne funkcije se često izrezuju iz profila kako bi se vratile konvencionalnoj heuristici kompajlera umjesto da iskrivljuju optimizaciju.
Ovaj odabrani profil zatim vodi novu izgradnju kernela. S točnim informacijama o tome koji su putevi koda najvažniji, kompajler može agresivnije ugraditi kritične rutine, urediti vrući kod da bude prilagođen predmemoriji i smanjiti naglasak na rijetko korištene grane. Rezultat je kernel koji je bolje usklađen s radnim opterećenjima s kojima se Android telefoni zapravo suočavaju.
Koliko brži i učinkovitiji Android može postati?
Prve brojke iz Googleovih internih testova su skromne, ali opipljive. S primjenom AutoFDO-a na jezgru, vrijeme pokretanja uređaja poboljšava se za otprilike 2.1% . To neće pretvoriti spori telefon u raketu, ali može skratiti malo čekanja svaki put kada ponovno pokrenete sustav.
Dobici su nešto izraženiji pri otvaranju aplikacija iz "hladnog" stanja - odnosno kada se već ne nalaze u memoriji. Ovdje AutoFDO donosi oko 4.3% smanjenja vremena hladnog pokretanja , što je posebno korisno za zahtjevnije aplikacije koje se oslanjaju na izvorne komponente i usluge kernela.
Ispod tih jasnih metrika, Google također primjećuje poboljšanja u područjima koja su manje vidljiva, ali i dalje važna : glatkije raspoređivanje u pozadini, manje skokova CPU-a za rutinske zadatke kernela i općenito efikasnije rukovanje operacijama na razini sustava. Sve to doprinosi osjećaju da je uređaj responzivniji, čak i ako je teško ukazati na jednu dramatičnu promjenu.
Budući da kernel može potrošiti veliki udio ukupnog kapaciteta CPU-a, čak i jednoznamenkasti postotni dobici prevode se u oslobođene resurse koje mogu koristiti aplikacije i korisničko sučelje sustava . Istovremeno, uklanjanje nepotrebnog rada CPU-a neizbježno pomaže energetskoj učinkovitosti, pa baterija donekle rasterećuje bez ikakvih promjena hardvera.
Google pažljivo pozicionira ove prednosti kao postupne. Korisnici ne bi trebali očekivati noćnu transformaciju, već stalno poboljšanje u tome kako se Android osjeća i ponaša tijekom vremena , posebno kada se više takvih optimizacija slaže u različitim izdanjima.
Održavanje stabilnosti uz promjenu načina izgradnje kernela
Ponavljajuća zabrinutost kod svake optimizacije vođene profilom je rizik od kršenja očekivanog ponašanja ili uvođenja suptilnih grešaka . U slučaju AutoFDO-a, Google naglašava da tehnika mijenja način na koji kompajler određuje prioritete i rasporeduje kod, a ne samu logiku kernela.
Pristup je opisan kao „konzervativan po zadanim postavkama“. To znači da se funkcije koje nisu dobro predstavljene u visokokvalitetnim podacima profila prepuštaju standardnim strategijama optimizacije umjesto da se agresivno preoblikuju. Hladne ili rijetko izvršavane putanje ponašaju se u biti kao što bi se ponašale u tradicionalnoj izgradnji, što smanjuje mogućnost regresija u nejasnim scenarijima.
Prije nego što se profili prihvate, prolaze kroz višestruke provjere. Inženjeri analiziraju sadržaj profila - aktivne funkcije, broj uzoraka i ukupnu veličinu - i uspoređuju ga s prethodnim verzijama. Zatim se izrađuje nova slika kernela i provode se mjerenja kako bi se osiguralo da su poboljšanja performansi dosljedna i da se latencija ili propusnost neočekivano ne pogoršaju u ključnim radnim opterećenjima.
Ovo nije prva Googleova upotreba AutoFDO-a. Tehnika je već široko primijenjena za osnovne Android biblioteke, ChromeOS komponente, pa čak i internu poslužiteljsku infrastrukturu . To prethodno iskustvo djeluje kao sigurnosna mreža, sugerirajući da je sam stil optimizacije zreo, čak i ako je njegova primjena na Android kernel relativno nova.
Krajnji rezultat je da je integracija kernela AutoFDO-a osmišljena kako bi očuvala funkcionalnu stabilnost, a istovremeno postigla dodatnu učinkovitost . Za krajnje korisnike, promjena bi trebala biti nevidljiva u smislu pouzdanosti, ali tiho korisna u smislu performansi.
Kako se profili osvježavaju i uvode tijekom vremena
Jedan statički profil brzo bi zastario kako se Android, aplikacije i obrasci korištenja razvijaju . Kako bi AutoFDO održao učinkovitost, Google tretira generiranje profila kao kontinuirani proces, a ne kao jednokratni zadatak.
Profili za generičku sliku jezgre (GKI) regeneriraju se prije svakog novog izdanja LTS jezgre . Ažurirana opterećenja temeljena na trenutnim verzijama 100 najpopularnijih aplikacija ponovno se reproduciraju, podaci se ponovno uzorkuju, a profili se rekonstruiraju i validiraju. Ovaj kontinuirani proces pomaže u osiguravanju da novije verzije jezgre prate kako ljudi zapravo koriste Android u tom trenutku.
Zanimljivo je da Google primjećuje da laboratorijski generirana opterećenja pokazuju oko 85% sličnosti s obrascima izvršavanja snimljenim s internih flota uređaja. Ta razina preklapanja sugerira da je sintetizirani pristup dovoljno blizu ponašanju u stvarnom svijetu da bi bio koristan za vođenje optimizacije, a istovremeno ga je lakše kontrolirati i ažurirati.
Budući da ovi profili slijede standardni LLVM AutoFDO format, izravno se uključuju u postojeće alate za analizu poput llvm-profdata . Inženjerski timovi mogu pregledati aktivne funkcije, istražiti obrasce poziva i provjeriti troši li se optimizacijski napor tamo gdje je stvarno važan.
Tijekom više iteracija, ovaj ponovljeni ciklus profiliranja i ponovne izgradnje pretvara AutoFDO u mehanizam kontinuiranog podešavanja kernela , umjesto jednog podešavanja vezanog za jednu verziju Androida.
AutoFDO u Android stogu i alatima
Prelazak na AutoFDO u kernelu nadovezuje se na rad koji se već neko vrijeme odvija drugdje u Android stogu. Podrška za AutoFDO ugrađena je u Android sustav izgradnje koji koristi AOSP , posebno za izvorne module koji se oslanjaju na definicije izgradnje u stilu blueprinta.
Za mnoge biblioteke i binarne datoteke osjetljive na performanse unutar AOSP-a, profili su već prikupljeni sa stvarnih telefona i tableta. Ovi gotovi AutoFDO profili nalaze se uz izvorni kod i mogu se omogućiti jednostavnim uključivanjem odgovarajućih zastavica za izradu, tako da proizvođači uređaja koji blisko prate AOSP nasljeđuju optimizacije uz minimalan dodatni rad.
Androidov okvir za profiliranje može prikupljati podatke na više arhitektura procesora, uključujući x86, x86_64, ARM i ARM64 . Sve dok je radno opterećenje reprezentativno, profil stvoren na jednoj arhitekturi ponekad se može prilagoditi drugoj, što pojednostavljuje implementaciju na heterogenim linijama uređaja.
Razvojnim programerima kojima su potrebne prilagođenije optimizacije - na primjer, prilikom dodavanja vlastitih izvornih komponenti ili izmjene postojećih - preporučuje se prikupljanje profila izravno s razvojnih ili testnih uređaja . Alati poput simpleperfa i srodnih uslužnih programa pomažu u prikupljanju potrebnih uzoraka bez većeg ometanja normalnog rada.
Ukratko, AutoFDO nije samo kernel trik. Uklapa se u širu strategiju u kojoj se najvažniji dijelovi Androida kontinuirano rekompiliraju uz pomoć smjernica iz stvarnih podataka o korištenju , umjesto da se oslanjaju isključivo na statičke pretpostavke o performansama.
Gdje i kada će se pojaviti ova poboljšanja kernela
Google prvo uvodi AutoFDO-vođene kernelske verzije u granama dugoročne podrške (LTS) Android kernela , točnije android16-6.12 i android15-6.6. Ove grane služe kao osnova za mnoge proizvođače, koji zatim dodaju vlastite promjene i prilagodbe specifične za uređaje.
Tvrtka je također predstavila planove za proširenje korištenja AutoFDO-a na buduće GKI verzije kao što je android17-6.18 . Kako se novi uređaji isporučuju s ovim jezgrama - i kako postojeći telefoni primaju ažuriranja koja povlače novije LTS baze - više korisnika trebalo bi početi imati koristi od poboljšanog ponašanja.
Gledajući u budućnost, Google istražuje načine proširenja AutoFDO pokrivenosti izvan glavne vmlinux binarne datoteke . To uključuje uvođenje optimizacija vođenih profilima u GKI module i, na kraju, module dobavljača izgrađene pomoću Driver Development Kit-a. To bi omogućilo hardverskim partnerima da primijene iste tehnike profiliranja na vlastite upravljačke programe, šireći prednosti dublje u ekosustav.
Dugoročna vizija je da se izgradnje pokretane AutoFDO-om dotiču sve većeg dijela kernela i njegovih modula, od koda za raspoređivanje jezgre do komponenti specifičnih za uređaj . Kako taj otisak raste, kumulativni učinak na odzivnost i učinkovitost mogao bi postati izraženiji, čak i ako je svaka pojedinačna promjena suptilna.
Sve se to zbraja u tihu, ali značajnu promjenu u načinu na koji je Android podešen na najnižim razinama. Dopuštajući da stvarni obrasci izvršavanja vode kompajler, Google cilja na telefone koji se osjećaju malo brže, troše manje CPU ciklusa i malo bolje koriste svaki miliamperni sat baterije - sve bez potrebe da korisnici mijenjaju uređaje ili pretražuju postavke.
