Hvordan Huaweis Ark Compiler kan forbedre ytelsen til Android-appen

Mye av den siste samtalen rundt Huawei har dreid seg om selskapets uheldige politiske situasjon på grunn av en USAs eksekutivordre som begrenset mange selskaper fra å drive forretninger med Huawei. Konsekvensene av en slik sentral beslutning er altfor enorme til å ikke ta hensyn. Men i en alternativ virkelighet der denne eksekutivordren ikke eksisterer, ville Huawei ha vært i rampelyset for sin nylig avslørte Ark Compiler, den siste innovasjonen som hevder å bygge bro over appytelsesgapet mellom Android og iOS.

Før vi dykker inn i hva Ark Compiler er, må vi ta et skritt tilbake og forstå hva en kompilator er og formålet den tjener i Android-systemet.

Kort historie om kompilatorer og tolker på Android

En kompilator er et dataprogram som oversetter kode fra ett språk til et annet språk, ofte et eget maskinspråk. Dette kan da enten utføres direkte av datamaskinen eller utføres gjennom et annet program (tolk). Denne oversettelsen er nødvendig fordi vi skriver kode i programmeringsspråk som kan leses av mennesker (som Java og Kotlin), mens datamaskinen bare forstår innfødt maskinspråk (binær kode i form av 1-er og 0-tallet). Kompilatoren fungerer dermed som en bro mellom instruksjonene som et menneske skriver og maskinens evne til å forstå og deretter utføre disse instruksjonene. Hvor raskt og effektivt denne konverteringen og den påfølgende tolkningen finner sted, definerer kompilatorens effektivitet introdusere en direkte korrelasjon mellom effektiviteten til kompilatoren til ytelsen og effektiviteten til koden, og i forlengelsen, apper.

Dalvik VM

I de tidlige dagene av Android brukte operativsystemet det som ble kalt Dalvik VM (tolken) sammen med en JIT (just-in-time) kompilator. Denne eldre videoen fra XDA TVs Android Basics 101 serien berører Dalvik VM og JIT-oppsettet, som begge tjente behovene til tidlige Android-systemer der minnebegrensninger var rikelig. Dalvik VM tok Java-bytekode og konverterte den til maskinkode når og når koden måtte kjøres (derav Just-In-Time). Dette var nødvendig siden lagringsplass i telefoner var en reell begrensning den gang, så denne tilnærmingen tillot apper å jobbe med mindre filstørrelser i systemet.

Å kompilere og tolke apper under kjøretid hadde ulempen med generelt tregere appytelse, da kompileringen ville foregå samtidig med når brukeren bruker appen.

Dalvik hadde også begrensninger med sin Garbage Collection-mekanisme. Dalvik holdt styr på hver minnetildeling samlet. Når Dalvik fastslår at et stykke minne ikke lenger brukes av programmet, frigjør det dette minnet tilbake til haugen uten noen intervensjon fra programmereren. Denne prosessen kalles Garbage Collection (GC), og den tar sikte på å finne minneobjekter i et program som ikke er tilgjengelig lenger, og deretter gjenvinne ressursene som brukes av disse objektene for å frigjøre minne. Systemet bestemmer når en GC er nødvendig på en kollektiv basis, så apputviklere kan ikke velge når GC-hendelser oppstår [selv i ART]. Så hvis en GC-hendelse skjedde midt i en intensiv behandlingsaktivitet på forgrunnsappen, ville systemet stoppe utførelsen av prosessen og begynne GC, og dermed øke behandlingstiden og introdusere en merkbar "jank" til brukere.

Disse og andre begrensninger presset Google til å utforske alternative tilnærminger for raskere ytelse.

Android Runtime

Med Android 4.4 KitKat introduserte Google ART (Android Runtime) i forhåndsvisningsform med en AOT (Ahead-Of-Time) kompilator, og med Android 5.0 Lollipop, droppet Google Dalvik til fordel for ART som eneste tilgjengelige tolk. ART med AOT konverterte kode til maskinspråk på tidspunktet for installasjon av appen, i stedet for å vente med å gjøre slik konvertering når appen er i bruk. Denne tilnærmingen satte dermed fart på appens lanseringstider, men introduserte også ulemper i form av langsommere installasjonstider og økt bruk av diskplass. For å balansere det hele, Google adoptert en kombinasjon av AOT, JIT og profilveiledet kompilering med ART på Android 7.0 Nougat, for å sikre at ingen enkeltfaktor påvirkes drastisk.

ART jobbet også med å gjøre Garbage Collection mindre påtrengende. GC-prosessen ble optimalisert for å være raskere totalt sett med færre pauser (enkelt kort pause kontra Dalviks to pauser), mindre fragmentering og mindre minnebruk. Googles presentasjon på Google I/O 2014 går i bedre detalj og forklarer begrensningene til Dalviks GC og ARTs forbedringer i den forbindelse.

Selv med disse endringene gjennom årene, innebar det grunnleggende premisset for Googles tilnærming å tolke kode under utførelse samtidig som man varierte tidspunktet for kompilerings- (oversettelses)elementet. Garbage Collection fortsetter også å være et smertepunkt for apputviklere på grunn av dens iboende avbrytende og kollektive natur. Uten tvil lider Androids appytelse som et resultat av at det fortsetter å være kostnader involvert.

Ark Compiler av Huawei

Huawei har jobbet for å utvikle en mer effektiv løsning og har følgelig ansatt hundrevis av eksperter på området. Resultatet av denne innsatsen er Ark Compiler, som Huawei hevder er den første statiske kompilatoren noensinne som gir mulighet for direkte oversettelse til maskinspråk, og fjerner helt behovet for en tolk. Ark Compiler ble også utviklet med mål om å maksimere kjøreeffektiviteten for Java og C, så man bør teoretisk sett se de beste resultatene med disse språkene.

Huawei presenterer noen nøkkelfunksjoner i Ark Compiler som nedenfor:

• Kompileringsteknikker som AOT og JIT kan konvertere noen programmer til maskinkode og kjøre dem direkte på CPU, men disse teknikkene er ikke i stand til å løsne seg fullstendig fra tolken og begrensninger knyttet til denne. Ark-kompileren bruker statisk kompilering, som lar den koble seg fra den dynamiske tolken, og åpner muligheten for å øke appytelsen ved å "sprang og grenser."
• Statisk kompilering har en potensiell ulempe ved å være for rigid og ikke kunne gjøre justeringer som en dynamisk kompilator kan gjøre under utførelse. Huawei hevder at Ark Compilers statiske kompilering løser dette "ved sømløst å oversette de dynamiske funksjonene i programmeringsspråket til maskinkode."
• Eksisterende kompileringsprosesser finner sted under eller etter installasjon av apppakken på mobilenheten. Ark Compiler er designet for distribusjon under programvareutvikling, som vi antar bidrar til å fjerne tidsutgifter under installasjon og utførelse. Vi antar at apputviklere vil være i stand til å kompilere forskjellige språk direkte til egen maskinkode under appen utviklingsprosessen, og den resulterende APK-en kunne dermed ikke trenge interaksjon med en tolk eller en virtuell maskin for å funksjon. Dette vil teoretisk sett redusere de faste kostnadene knyttet til JNI, for eksempel.
• Ark Compiler endrer også den kollektive karakteren til Garbage Collection. Det gjør det mulig for GC-hendelser å skje separat for forskjellige Java-tråder. Denne oppdelte tilnærmingen hevder å tilby mindre krangel på forgrunnsapper.

Som et resultat av disse endringene kan Ark Compiler tilsynelatende forbedre Android-systemets betjeningsflyt med opptil 24 %, responshastigheten med opptil 44 % og jevnheten til tredjepartsapplikasjonene med opptil 60 %, og hevder å bringe ytelsen til Android-appen på samme nivå som på iOS.

Ark-kompileren er for tiden kompilert og optimalisert for ARM-brikkearkitektur. Huawei håper at samarbeidende maskinvare- og programvaredesign i fremtiden vil jobbe for å maksimere Kirin-brikkefunksjonene.

Ark Compiler støtter standard Java-bruk, noe som muliggjør direkte kompilering av tredjepartsapper uten at apputvikleren trenger å gjøre noen kodemodifikasjoner. Ark Compiler tillater også "justeringer av kodestrukturen" for ytterligere forbedringer av ytelse og minne. Huawei har valgt å gjøre Ark Compiler til et åpen kildekodesystem, som vil tillate tredjepartsutviklere å ta i bruk og tilpasse teknologien til deres behov, og fremme bruken av den med apputviklere og mobiltelefon produsenter.

Selv om Huawei ikke nevner noen ulemper med Ark-kompileren, kan man forvente store appstørrelser helt i det hele tatt minst, men dette bør ikke utgjøre noen problemer på nåværende generasjons enheter som kommer med rikelig Oppbevaring. Vi forventer også at Ark Compiler ikke vil være tilgjengelig for alle CPU-arkitekturer, siden Googles kompatibilitetsproblemer ikke er Huaweis hodepine. Ark Compiler er designet for å brukes under utvikling og ikke under installasjon; Dette gir en indikasjon på at Huawei muligens kan ha endret hvordan apper distribueres og installeres på Android-enheter, og også kan ha jobbet med sin egen APK-design. Hvis riktig, kan dette utgjøre et stort kompatibilitetsproblem i økosystemet, og det vil ta lang tid før dette blir en standard Android-funksjon, om noen gang.

Å ikke kompilere på en brukers enhet reiser også et stort spørsmål om optimalisering. ART optimerer for tiden på en per-mikro-arkitektur basis, noe som betyr at den resulterende binære filen ville være forskjellig for en Snapdragon-enhet kontra en Exynos-enhet, eller til og med for en Snapdragon 845 versus en Snapdragon 625. Denne tilnærmingen gir mening for produsenter som har full kontroll over SoC, som Apple og Huawei. Men med resten av Android-verdenen som bruker mange forskjellige SoC-er, vil det å tvinge en generisk optimalisering til bruk på tvers av enheter være en veisperring for standardiseringen av Ark Compiler, igjen. Forvent derfor ikke at Ark Compiler kommer til din favoritt tilpassede ROM når som helst snart.

For avklaring er Ark Compiler utviklet for å fungere med Android, og Huawei har ikke nevnt noe i forhold til det angivelig hjemmebrygget OS og dens kompatibilitet med Ark Compiler, så vi gjør ingen antagelser om dette.

Huawei planlegger å holde to store konferanser dedikert til utviklere og det større økosystemet. Dette er Huawei Device China Developers Conference og Green Alliance China Developers Conference. Begge arrangementene vil ta for seg spesifikke åpen kildekode-problemer knyttet til Huaweis Ark Compiler, i et forsøk på å gjøre fordelene med denne teknologien så allment tilgjengelig som mulig.

---

Spesiell takk til XDA Senior Recognized Contributor Dees_Troy og anerkjent utvikler arter97 for deres hjelp og innspill.

Merk: Huawei/Honor har sluttet å tilby offisielle opplåsingskoder for oppstartslasteren for enhetene sine. Derfor kan ikke bootloaderne til enhetene låses opp, noe som betyr at brukere ikke kan rote eller installere egendefinerte ROM-er.