Med den senaste I/O-konferensen har Google äntligen tillkännagett sina planer för sin nya körtid på Android. Android RunTime, ART, är efterträdaren och ersättningen för Dalvik, den virtuella maskinen på vilken Android Java-kod exekveras. Vi har haft spår och förhandsvisningar av det tillgängliga med KitKat-enheter sedan i höstas, men det fanns inte mycket information när det gäller tekniska detaljer och riktningen Google var på väg med den.
I motsats till andra mobila plattformar som iOS, Windows eller Tizen, som kör mjukvara som kompileras inbyggt efter deras specifika hårdvaruarkitektur, är majoriteten av Android-programvaran baserad på ett generiskt kodspråk som omvandlas från “byte-kod” till inbyggda instruktioner för hårdvara på själva enheten.
Under åren och från de tidigaste Android-versionerna började Dalvik som en enkel VM med liten komplexitet. Med tiden kände Google dock behovet av att ta itu med prestandaproblem och att kunna hänga med i branschens hårdvaruframsteg. Google lade så småningom till en JIT-kompilator till Dalvik med Androids 2.2-utgåva, lade till flertrådsfunktioner och försökte generellt förbättra bit för bit.
Men under de senaste åren hade ekosystemet gått snabbare än Dalviks utveckling, så Google försökte bygga något nytt för att fungera som en solid grund för framtiden, där det kunde skalas med prestandan hos dagens och framtidens 8-kärniga enheter, stora lagringsmöjligheter och stora arbetsminnen.
Så föddes ART.
Arkitektur
För det första är ART designad för att vara helt kompatibel med Dalviks befintliga byte-kodformat, “dex” (Dalvik körbar). Som sådan, ur ett utvecklares perspektiv, finns det inga förändringar alls när det gäller att behöva skriva applikationer för den ena eller andra körtiden och du behöver inte oroa dig för kompatibilitet.
Det stora paradigmskiftet som ART för med sig är att istället för att vara en Just-in-Time (JIT) kompilator, kompilerar den nu applikationskod Ahead-of-Time (AOT). Körtiden går från att behöva kompilera från bytekod till inbyggd kod varje gång du kör ett program, till att det bara ska göras en gång, och varje efterföljande exekvering från den tidpunkten och framåt görs från den befintliga kompilerade inbyggda koden.
Naturligtvis tar dessa inhemska översättningar av applikationerna utrymme, och denna nya metod är något som har gjorts möjligt idag bara på grund av de enorma ökningarna av tillgängligt lagringsutrymme på dagens enheter, ett stort skifte från Android-enheternas tidiga början.
Denna förändring öppnar upp för en stor mängd optimeringar som inte var möjliga tidigare; eftersom koden är optimerad och kompilerad endast en gång, är det värt att optimera den riktigt bra den ena gången. Google hävdar att man nu kan uppnå optimeringar på högre nivå över hela en applikationskodbas, eftersom kompilatorn har en överblick över kodens helhet, i motsats till den nuvarande JIT-kompilatorn som bara gör optimeringar i lokal/metod bitar. Overhead som undantagskontroller i kod tas till stor del bort, och metod- och gränssnittsanrop påskyndas avsevärt. Processen som gör detta är den nya “dex2oat”-komponenten, som ersätter den “dexopt” Dalvik-motsvarigheten. Odex-filer (optimerad dex) försvinner också i ART, ersatta av ELF-filer.
Eftersom ART kompilerar en ELF-körbar, kan kärnan nu hantera sidhantering av teckentabeller – detta resulterar i möjligen mycket bättre minneshantering och mindre minnesanvändning också. Jag är nyfiken på vad effekten av KSM (Kernel same-page merging) har på ART, det är definitivt något att hålla ett öga på.
Konsekvenserna för batterilivslängden är också betydande – eftersom det inte finns mer tolkning eller JIT-arbete att göra under en apps körningstid, vilket resulterar i direkta besparingar av CPU-cykler och därmed strömförbrukning.
Den enda nackdelen med allt detta är att denna engångskompilering tar längre tid att slutföra. En enhets första uppstart och en applikations första start kommer att öka betydligt jämfört med ett motsvarande Dalvik-system. Google hävdar att detta inte är alltför dramatiskt, eftersom de förväntar sig att den färdiga leveranstiden ska vara likvärdig eller till och med snabbare än Dalvik i dessa aspekter.
Prestandavinsterna över Dalvik är betydande, som bilden ovan; vinsterna är ungefär en 2x förbättring av hastigheten för kod som körs på den virtuella datorn. Google hävdade att applikationer som Chessbench som representerar en nästan 3x ökning är en mer representativ projicering av verkliga vinster som kan förväntas när den slutliga versionen av Android L görs tillgänglig.
