Hur Huaweis Ark-kompilator kan förbättra Android-appens prestanda

Mycket av det senaste samtalet kring Huawei har kretsat kring företagets olyckliga politiska situation på grund av en USA: s verkställande order som begränsade många företag från att göra affärer med Huawei. Konsekvenserna av ett sådant avgörande beslut är alldeles för enorma för att inte uppmärksammas. Men i en alternativ verklighet där denna verkställande order inte existerar, skulle Huawei ha varit i rampljuset för sin nyligen avslöjade Ark Compiler, den senaste innovationen som påstår sig överbrygga appens prestandagap mellan Android och iOS.

Innan vi dyker in i vad Ark Compiler är måste vi ta ett steg tillbaka och förstå vad en kompilator är och syftet den tjänar i Android-systemet.

Kort historia om kompilatorer och tolkar på Android

En kompilator är ett datorprogram som översätter kod från ett språk till ett annat språk, ofta som ett inhemskt maskinspråk. Detta kan sedan antingen exekveras direkt av datorn eller exekveras via ett annat program (tolk). Denna översättning är nödvändig eftersom vi skriver kod i programmeringsspråk som kan läsas av människor (som Java och Kotlin), medan datorn bara förstår inhemskt maskinspråk (binär kod i form av 1:or och 0:or). Kompilatorn fungerar alltså som en brygga mellan instruktionerna som en människa skriver och maskinens förmåga att förstå och sedan utföra dessa instruktioner. Hur snabbt och effektivt denna konvertering och efterföljande tolkning sker definierar kompilatorns effektivitet införa en direkt korrelation mellan kompilatorns effektivitet och kodens prestanda och effektivitet, och i förlängningen, appar.

Dalvik VM

I Androids tidiga dagar använde operativsystemet det som kallades Dalvik VM (tolken) tillsammans med en JIT (just-in-time) kompilator. Denna äldre video från XDA TV: s Android Basics 101 serien berör Dalvik VM och JIT-installationen, som båda tjänade behoven hos tidiga Android-system där minnesbegränsningar var rikliga. Dalvik VM tog Java bytecode och konverterade den till maskinkod när och när koden behövde exekveras (därav Just-In-Time). Detta var nödvändigt eftersom lagringsutrymme i telefoner var en verklig begränsning då, så detta tillvägagångssätt gjorde det möjligt för appar att arbeta med mindre filstorlekar i systemet.

Att kompilera och tolka appar under körning hade nackdelen med överlag långsammare appprestanda eftersom kompileringen skulle ske samtidigt som användaren använder appen.

Dalvik hade också begränsningar med sin Garbage Collection-mekanism. Dalvik höll koll på varje minnestilldelning kollektivt. När Dalvik fastställer att en bit minne inte längre används av programmet, frigör det detta minne tillbaka till högen utan någon inblandning från programmeraren. Denna process kallas Garbage Collection (GC), och den syftar till att hitta minnesobjekt i ett program som inte nås längre och sedan återta resurserna som används av dessa objekt för att frigöra minne. Systemet bestämmer när en GC behövs på en kollektiv basis, så apputvecklare får inte välja när GC-händelser inträffar [även i ART]. Så om en GC-händelse inträffade mitt i någon intensiv bearbetningsaktivitet på förgrundsappen, skulle systemet pausa exekveringen av processen och påbörja GC, vilket ökar bearbetningstiden och introducerar en märkbar "skräp" till användare.

Dessa och andra begränsningar fick Google att utforska alternativa metoder för snabbare prestanda.

Android Runtime

Med Android 4.4 KitKat introducerade Google ART (Android Runtime) i förhandsvisningsform med en AOT-kompilator (Ahead-Of-Time) och med Android 5.0 Lollipop släppte Google Dalvik till förmån för ART som den enda tillgängliga tolken. ART med AOT konverterade kod till maskinspråk vid tidpunkten för installationen av appen, istället för att vänta på att göra en sådan konvertering när appen används. Detta tillvägagångssätt påskyndade alltså appens starttider men introducerade också nackdelar i form av långsammare installationstider och ökad användning av diskutrymme. För att balansera det hela, Google antagits en kombination av AOT, JIT och profilstyrd kompilering med ART på Android 7.0 Nougat, för att säkerställa att ingen enskild faktor påverkas drastiskt.

ART arbetade också med att göra Garbage Collection mindre påträngande. GC-processen optimerades för att vara snabbare totalt sett med färre pauser (enkel kort paus jämfört med Dalviks två pauser), mindre fragmentering och mindre minnesanvändning. Googles presentation på Google I/O 2014 går in i detalj och förklarar begränsningarna i Dalviks GC och ART: s förbättringar i detta syfte.

Även med dessa förändringar under åren innebar den grundläggande premissen för Googles tillvägagångssätt att tolka kod under exekvering samtidigt som man varierade tidpunkten för kompilerings- (översättnings)elementet. Garbage Collection fortsätter också att vara en smärtpunkt för apputvecklare på grund av dess inneboende avbrytande och kollektiva karaktär. Förmodligen lider Androids appprestanda som ett resultat eftersom det fortsätter att vara omkostnader involverade.

Ark Compiler från Huawei

Huawei har arbetat för att utveckla en mer effektiv lösning och har därför anställt hundratals experter på området. Resultatet av denna ansträngning är Ark Compiler, som Huawei hävdar är den första statiska kompilatorn någonsin som möjliggör direkt översättning till maskinspråk, vilket helt tar bort behovet av en tolk. Ark Compiler utvecklades också med målet att maximera körningseffektiviteten för Java och C, så man bör teoretiskt sett se de bästa resultaten med dessa språk.

Huawei presenterar några nyckelfunktioner i Ark Compiler enligt nedan:

• Kompileringstekniker som AOT och JIT kan konvertera vissa program till maskinkod och köra dem direkt på CPU, men dessa tekniker är oförmögna att helt frigöra sig från tolken och de därtill knutna begränsningarna. Ark-kompilatorn använder statisk kompilering, som låter den frigöra sig från den dynamiska tolken, vilket öppnar möjligheten att öka appens prestanda genom att "stormsteg."
• Statisk kompilering har en potentiell nackdel att vara för stel och inte kunna göra justeringar som en dynamisk kompilator kan göra under exekvering. Huawei hävdar att Ark Compilers statiska kompilering löser detta "genom att sömlöst översätta de dynamiska funktionerna i programmeringsspråket till maskinkod."
• Befintliga kompileringsprocesser sker under eller efter installation av apppaketet på den mobila enheten. Ark Compiler är designad för driftsättning under mjukvaruutveckling, vilket vi antar hjälper till att ta bort tidskostnader under installation och exekvering. Vi antar att apputvecklare skulle kunna direkt kompilera olika språk till inbyggd maskinkod under appen utvecklingsprocessen, och den resulterande APK-filen kunde således inte behöva interaktion med en tolk eller en virtuell maskin för att fungera. Detta skulle teoretiskt sett minska de allmänna omkostnaderna relaterade till JNI, till exempel.
• Ark Compiler förändrar också den kollektiva karaktären hos Garbage Collection. Det tillåter GC-händelser att inträffa separat för olika Java-trådar. Det här uppdelade tillvägagångssättet påstår sig erbjuda mindre skräp på förgrundsappar.

Som ett resultat av dessa förändringar kan Ark Compiler till synes förbättra Android-systemets funktionsförmåga med upp till 24 %, svarshastigheten med upp till 44 % och smidigheten i tredjepartsapplikationerna med upp till 60 %, som hävdar att prestanda för Android-appen är på samma nivå som på iOS.

Ark-kompilatorn är för närvarande kompilerad och optimerad för ARM-chiparkitektur. Huawei hoppas att samverkande hårdvaru- och mjukvarudesign i framtiden kommer att arbeta för att maximera Kirin-chipets kapacitet.

Ark Compiler stöder standard Java-användning, vilket möjliggör direkt kompilering av appar från tredje part utan att apputvecklaren behöver göra någon kodändring. Ark Compiler tillåter också "justeringar av kodstrukturen" för ytterligare förbättringar av prestanda och minne. Huawei har valt att göra Ark Compiler till ett system med öppen källkod, vilket skulle göra det möjligt för tredjepartsutvecklare att ta till sig och anpassa tekniken efter deras behov, vilket främjar dess användning med apputvecklare och mobiltelefon tillverkare.

Medan Huawei inte nämner några nackdelar med Ark Compiler, kan man förvänta sig stora appstorlekar i början åtminstone, men detta bör inte innebära några problem på nuvarande generations enheter som kommer med gott om lagring. Vi förväntar oss också att Ark Compiler inte kommer att vara tillgänglig för alla CPU-arkitekturer, eftersom Googles kompatibilitetsproblem inte är Huaweis huvudvärk. Ark Compiler är designad för att användas under utveckling och inte under installation; detta ger en indikation på att Huawei möjligen kan ha modifierat hur appar distribueras och installeras på Android-enheter, och även kan ha arbetat med sin egen APK-design. Om det stämmer kan detta utgöra ett stort kompatibilitetsproblem i ekosystemet, och det skulle ta lång tid innan detta skulle bli en standard Android-funktion, om någonsin.

Att inte kompilera på en användares enhet väcker också en stor fråga om optimering. ART optimerar för närvarande på en per-mikro-arkitektur basis, vilket innebär att den resulterande binära filen skulle vara annorlunda för en Snapdragon-enhet jämfört med en Exynos-enhet, eller till och med för en Snapdragon 845 jämfört med en Snapdragon 625. Detta tillvägagångssätt är vettigt för tillverkare som har full kontroll över SoC, som Apple och Huawei. Men med resten av Android-världen som använder många olika SoC: er, kommer det att tvinga fram en generisk optimering att användas över enheter en vägspärr för standardiseringen av Ark Compiler, igen. Förvänta dig därför inte att Ark Compiler kommer till din favorit-ROM när som helst snart.

För förtydligande är Ark Compiler utvecklad för att fungera med Android, och Huawei har inte nämnt något i relation till dess påstådda hemmabryggt OS och dess kompatibilitet med Ark Compiler, så vi gör inga antaganden om detta.

Huawei planerar att hålla två stora konferenser dedikerade till utvecklare och det större ekosystemet. Dessa är Huawei Device China Developers Conference och Green Alliance China Developers Conference. Båda evenemangen kommer att ta upp specifika frågor med öppen källkod relaterade till Huaweis Ark Compiler, i ett försök att göra fördelarna med denna teknik så allmänt tillgängliga som möjligt.

---

Särskilt tack till XDA Senior Recognized Contributor Dees_Troy och erkänd utvecklare arter97 för deras hjälp och insatser.

Obs: Huawei/Honor har slutat tillhandahålla officiella upplåsningskoder för bootloader för sina enheter. Därför kan startladdare för deras enheter inte låsas upp, vilket innebär att användare inte kan rota eller installera anpassade ROM.