Ark-kompilator forklart: Hvordan Huawei's app-kompilator kan forbedre ytelsen til Android-apper

Mye av den nylige samtalen rundt Huawei har dreid seg om selskapets uheldige politiske situasjon på grunn av en amerikansk utøvende ordre som begrenset mange selskaper fra å drive forretning med Huawei. Konsekvensene av en slik sentral beslutning er altfor enorme til å ikke ta hensyn. Men i en alternativ virkelighet der denne utøvende ordren ikke eksisterer, ville Huawei vært i rampelyset for den nylig avslørte Ark Compiler, den siste innovasjonen som hevder å bygge bro mellom appens ytelsesgap mellom Android og iOS.

Før vi dykker ned 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 som morsmål. Dette kan da enten kjøres direkte av datamaskinen eller utføres gjennom et annet program (tolk). Denne oversettelsen er nødvendig fordi vi skriver kode på menneskelig lesbare programmeringsspråk (som Java og Kotlin), mens datamaskinen bare forstår morsmål (binær kode i form av 1 og 0). Kompilatoren fungerer således som en bro mellom instruksjonene som et menneske skriver, og maskinens evne til å forstå og utføre instruksjonene. Hvor raskt og effektivt denne konverteringen og den påfølgende tolkningen finner sted, definerer kompilatorens effektivitet, og introduserer dermed en direkte sammenheng mellom kompilatorens effektivitet til kodenes ytelse og effektivitet, og i tillegg apper.

Dalvik VM

I de første dagene av Android benyttet OS seg det som ble kalt Dalvik VM (tolken) sammen med en JIT (just-in-time) kompilator. Denne eldre videoen fra TVs Android Basics 101-serie 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 utføres (derav Just-In-Time). Dette var nødvendig ettersom lagringsplass i telefoner var en reell begrensning den gang, så denne tilnærmingen tillot apper å jobbe med mindre filstørrelser i systemet.

Å sammenstille og tolke apper under kjøretid hadde ulempen med den generelle tregere appytelsen, ettersom samlingen ville skje ved siden av når brukeren bruker appen.

Dalvik hadde også begrensninger med sin søppelinnsamlingsmekanisme. Dalvik holdt oversikt over hver minnetildeling samlet. Når Dalvik bestemmer at et minne ikke lenger blir brukt av programmet, frigjør det dette minnet tilbake til bunken uten inngripen 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, slik at apputviklere ikke får velge når GC-hendelser skal oppstå [selv i ART]. Så hvis en GC-hendelse skjedde midt i en intensiv prosesseringsaktivitet i forgrunnen-appen, ville systemet pause utførelsen av prosessen og begynne GC, og dermed øke behandlingstiden og introdusere en merkbar "jank" for brukerne.

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å installasjonstidspunktet for appen, i stedet for å vente på å gjøre en slik konvertering når appen er i bruk. Denne tilnærmingen økte dermed app-lanseringstider, men introduserte også ulemper i form av tregere installasjonstid og økt diskplassbruk. For å balansere det hele, tok Google i bruk en kombinasjon av AOT, JIT og profilstyrt kompilering med ART på Android 7.0 Nougat, for å sikre at ingen enkelt faktor påvirkes drastisk.

Androids ART-implementering

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

Selv med disse endringene gjennom årene, innebar det grunnleggende forutsetningen for Googles tilnærming å tolke kode under utførelse, mens variasjonen av tidspunktet for kompilering (oversettelse) -elementet. Garbage Collection fortsetter også å være et smertepunkt for apputviklere på grunn av sin iboende avbrytende og kollektive karakter. Det kan hevdes at Android-appens ytelse lider som et resultat av at det fortsetter å være faste kostnader.

Ark Compiler av Huawei

Huawei har jobbet for å utvikle en mer effektiv løsning og har derfor 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, noe som fullstendig fjerner behovet for en tolk. Ark Compiler ble også utviklet med mål om å maksimere driftseffektiviteten for Java og C, så man bør teoretisk sett se de beste resultatene med disse språkene.

Grafisk av Huawei. Tekst oversatt av bruker MyKeyVans.

Huawei presenterer noen viktige funksjoner i Ark Compiler som nedenfor:

  • Kompileringsteknikker som AOT og JIT kan konvertere noen programmer til maskinkode og kjøre dem direkte på CPU-en, men disse teknikkene klarer ikke helt å løsne seg fra tolk og begrensninger knyttet til denne. Ark-kompilatoren bruker statisk sammenstilling, som lar den løsne seg fra den dynamiske tolken, og åpner muligheten for å øke appytelsen med “ sprang og grenser.
  • Statisk sammenstilling har en potensiell ulempe ved å være for stiv og ikke kunne gjøre justeringer som en dynamisk kompilator kan gjøre under utførelse. Huawei hevder at Ark Compiler sin statiske sammenstilling løser dette “ ved å sømløst oversette de dynamiske funksjonene i programmeringsspråket til maskinkode.
  • Eksisterende samlingsprosesser foregår under eller etter installasjon av app-pakken på den mobile enheten. Ark Compiler er designet for distribusjon under programvareutvikling, som vi antar hjelper til med å fjerne overheadkostnader under installasjon og utførelse. Vi antar at apputviklere vil kunne direkte sammenstille forskjellige språk til egen maskinkode under apputviklingsprosessen, og den resulterende APK kan dermed ikke trenge interaksjon med en tolk eller en virtuell maskin for å fungere. Dette vil teoretisk redusere omkostningene relatert til JNI, for eksempel.
  • Ark Compiler endrer også den kollektive karakteren til Garbage Collection. Det gjør at GC-hendelser kan oppstå separat for forskjellige Java-tråder. Denne kompartmentaliserte tilnærmingen hevder å tilby mindre søppel på forgrunnen-apper.

Som et resultat av disse endringene kan Ark Compiler tilsynelatende forbedre driften av Android-systemet med opptil 24%, svarhastigheten med opptil 44%, og glattheten til tredjepartsapplikasjoner med opptil 60%, og hevder å ha Android-app ytelse på samme nivå som på iOS.

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

Ark Compiler støtter standard Java-bruk, slik at det er mulig å samle direkte tredjepartsapper uten at apputvikleren trenger å foreta noen kodemodifisering. Ark Compiler åpner også for "justeringer av kodestrukturen" for ytterligere forbedringer av ytelse og minne. Huawei har valgt å gjøre Ark Compiler til et open source-system, som vil tillate tredjepartsutviklere å ta i bruk og tilpasse teknologien etter deres behov, og videreføre dens vedtak med apputviklere og mobiltelefonprodusenter.

Selv om Huawei ikke nevner noen ulemper med Ark Compiler, kan man i det minste forvente store appstørrelser, men dette bør ikke utgjøre noen problemer på nåværende generasjonsenheter som har god lagringsplass. Vi forventer også at Ark Compiler ikke vil være tilgjengelig for alle CPU-arkitekturer, ettersom Googles kompatibilitetsproblemer ikke er Huawei's hodepine. Ark Compiler er designet for å brukes under utvikling og ikke under installasjon; Dette gir en indikasjon på at Huawei muligens har endret hvordan apper distribueres og installeres på Android-enheter, og at det også kan ha arbeidet 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 ville bli en standard Android-funksjon, om noen gang.

Å ikke samle på brukerens enhet reiser også et stort spørsmål om optimalisering. ART optimaliserer for tiden per mikro-arkitekturbasis, noe som betyr at den resulterende binæren vil være annerledes for en Snapdragon-enhet kontra en Exynos-enhet, eller til og med for en Snapdragon 845 kontra en Snapdragon 625. Denne tilnærmingen er fornuftig for produsenter som har full kontroll av SoC, som Apple og Huawei. Imidlertid, med resten av Android-verdenen som bruker mange forskjellige SoC-er, vil det å tvinge en generisk optimalisering som skal brukes på tvers av enheter, være en veisperring for standardisering av Ark Compiler, igjen. Følg derfor ikke med at Ark Compiler snart kommer til din favoritt-tilpassede ROM.

For avklaring er Ark Compiler utviklet for å fungere med Android, og Huawei har ikke nevnt noe i forhold til det påståtte hjemmebryggingssystemet og kompatibiliteten med Ark Compiler, så vi har ingen formodninger for 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 hendelser vil ta opp spesifikke open source-problemer relatert til Huawei's Ark Compiler, i et forsøk på å gjøre fordelene med denne teknologien så bredt tilgjengelig som mulig.


Spesiell takk til senior anerkjent bidragsyter Dees_Troy og anerkjent utvikler-arter97 for deres assistanse og innspill.

Merk: Huawei / Honor har sluttet å tilby offisielle opplastingskoder for oppstartslastere for enhetene sine. Derfor kan ikke bootloadersene på enhetene deres låses opp, noe som betyr at brukere ikke kan root eller installere tilpassede ROM-er.