ART: vad är det, körningsmiljö och hur det fungerar

Vad är ART?

Android Runtime (ART) — körningsmiljön som kompilerar DEX-bytekod till inbyggd maskinkod före körning. Till skillnad från Dalvik, som använde Just-In-Time-kompilering under körning, utför ART Ahead-Of-Time (AOT)-kompilering vid APK-installation. Denna fundamentala arkitekturförändring ledde till betydande acceleration av appar och minskad energiförbrukning.

ART dök först upp som ett experimentellt alternativ i Android 4.4 KitKat. Utvecklare kunde aktivera det i utvecklarinställningarna och testa sina appar. I Android 5.0 Lollipop blev ART standardkörningsmiljön och Dalvik togs helt bort från plattformen. I samband med Android 7.0 Nougat fick ART hybridkompileringsläge.

Utvecklingshistoria

Beslutet att ersätta Dalvik med ART var inte plötsligt. Arbetet med den nya miljön började 2012 när Google insåg begränsningarna med JIT-metoden. Huvudmål: påskynda appstart, minska processorbelastning och minska energiförbrukning. Utvecklingen leddes av teamet Android Runtime Group, som tidigare arbetat med Dalvik-optimeringar.

Arkitekturförändringar

ART använder samma registerarkitektur som Dalvik, men med en helt omdesignad kompilator. Istället för tolk och JIT-kompilator innehåller ART AOT-kompilatorn dex2oat, som konverterar DEX-filer till ELF-binärer vid installation. Som ett resultat startar en app på ART omedelbart med inbyggd prestanda, utan uppvärmningsfas.

ARKITEKTUR: från Dalvik till ny miljö

ART behöll Dalviks nyckelprinciper: appisolering genom separata processer, registerarkitektur och stöd för DEX-formatet. Den interna implementeringen skrevs dock om helt. Istället för Dalvik-tolken innehåller ART tre körningslägen: tolk, JIT-kompilator och AOT-kompilatorn dex2oat. Valet av läge beror på appens livscykelfas.

Nyckelkomponenten i ART — dex2oat (dalvik executable to optimized android translator). Detta verktyg startas vid appinstallation (från Android 7.0 — även vid bakgrundsoptimering). dex2oat läser DEX-filer från APK, optimerar bytekod och genererar en OAT-fil — en ELF-binär med inbyggd kod. OAT-filer lagras i katalogen /data/dalvik-cache/.

# Kontrollera OAT-filer på enheten
adb shell ls -la /data/dalvik-cache/arm64/

# Tvingad omkompilering av appen
adb shell cmd package compile -m speed com.example.app

ARTs komponenter

ART-systemet består av flera sammankopplade moduler. Kompilatorn dex2oat ansvarar för att generera inbyggd kod. Skräpinsamlaren (GC) hanterar minnesfrigöring. Tolken exekverar sällan anropad kod utan kompilering. Profileraren spårar heta metoder för hybridkompilering. Varje modul kan arbeta oberoende, vilket gör ART flexibelt och skalbart.

Hybridkompilering: JIT + AOT + profilering

Från och med Android 7.0 Nougat använder ART ett hybridsätt för kompilering som kombinerar fördelarna med JIT och AOT. Vid appinstallation utför ART inte längre full AOT-kompilering — istället startar appen i tolkat läge med JIT-kompilering av heta metoder. Detta minskar installationstiden och det använda utrymmet.

Parallellt arbetar en bakgrundsprofilerare (background profiler). Den samlar in körningsstatistik: vilka metoder som anropas oftast, vilka kodgrenar som exekveras, vilka klasser som laddas. Efter att tillräckligt med data samlats in (vanligtvis efter 2–3 appstarter) startar ART dex2oat i bakgrunden och kompilerar endast profilerade heta metoder till inbyggd kod.

Kompileringslägen

ART stöder flera kompileringslägen som hanteras via system_server. Läget "speed" kompilerar alla metoder till AOT (maximal prestanda, lång installation). Läget "speed-profile" kompilerar endast profilerade heta metoder (balans mellan hastighet och storlek). Läget "verify" verifierar endast bytekod utan kompilering (minimalt utrymme, tolkning). Som standard används speed-profile — optimalt för de flesta appar.

ART-profileraRen

ProfileraRen samlar in körningsdata i särskilda .prof-filer. Varje app lagrar sin profil i /data/misc/profiles/. När tröskeln nås (vanligtvis 1000 prover) startar profileraren dex2oat för att kompilera identifierade heta metoder. Profiler bevaras mellan appuppdateringar, vilket påskyndar omoptimering efter OTA-systemuppdateringar.

Skräpinsamling i ART

Skräpinsamling i ART har förbättrats radikalt jämfört med Dalvik. Istället för enkeltrådad Concurrent Mark and Sweep (CMS) använder ART en generationsinsamlare med flera optimeringar: moving collector (heap-kompaktering), large object space (separat lagring av stora objekt) och concurrent compaction (parallell kompaktering).

En typisk GC-paus i ART är 2–3 ms jämfört med 5–10 ms i Dalvik. Detta blev möjligt tack vare flera mekanismer. För det första använder ART read-barrier istället för stop-the-world för samtidiga faser. För det andra behandlar generationsinsamlaren i de flesta cykler endast den unga generationen objekt utan att påverka hela heapen. För det tredje allokeras large object space (LOS) separat och deltar inte i vanliga GC-cykler.

// Aktivera GC-loggar för felsökning
System.logV("ART", "GC trigger: allocation failed");

// Tvingat GC-anrop (rekommenderas inte i produktion)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

Minnesslöseri i ART-eran

Trots förbättrad GC förblir minnesslöseri ett aktuellt problem. En ART-specifik orsak — inläsning av inbyggda bibliotek via JNI utan korrekt frigöring. Om inbyggd kod allokerar minne via malloc men inte anropar free, kan ART inte frigöra detta minne — det ligger utanför den hanterade heapen. Verktyget AddressSanitizer i Android NDK hjälper till att upptäcka sådana läckor.

ART vs Dalvik: jämförande analys

ART och Dalvik — två fundamentalt olika implementationer av samma uppgift: att köra Android-appar. Skillnaderna påverkar alla nivåer: från kompilering till minneshantering. Nedan finns en jämförelse baserad på viktiga prestanda- och kompatibilitetsparametrar.

Den främsta fördelen med ART — eliminering av JIT-uppvärmning. På Dalvik kunde en app sakta ner de första 3–10 sekunderna medan JIT kompilerade heta metoder. På ART är alla metoder redan kompilerade till inbyggd kod (eller kommer att kompileras i bakgrunden). Detta är särskilt märkbart i spel och appar med tungt UI: skillnaden i fps kan nå 15–20% till ART:s fördel.

Kompatibilitet

Alla appar skrivna för Dalvik fungerar på ART utan ändringar. Google garanterar full bakåtkompatibilitet på DEX-bytekodnivå. Undantag — kod som använder Dalvik-specifikt internt API via reflektion: medlemmar av klassen dalvik.system.DexFile markerade med @hide i Android SDK. Sådan kod bör uppdateras för att använda offentliga API:er.

Java 8-stöd och avsockring

ART blev den första Android-körningsmiljön med inbyggt stöd för Java 8-funktioner. Från och med Android 7.0 innehåller ART avsockring (desugaring) — processen att omvandla Java 8-konstruktioner (lambdor, method references, Stream API) till motsvarande Java 7-kod. Detta möjliggör användning av modern syntax utan att förlora kompatibilitet med äldre enheter.

Avsockring utförs av kompilatorn D8 och fungerar på följande sätt. Källkod med en lambd omvandlas till en syntetisk metod inom samma klass, och lambden ersätts med ett invoke-custom-anrop. ARTs körningsmiljö stöder invoke-custom-instruktionen som lades till specifikt för Java 8. På enheter med Android 6.0 och lägre avsockras lambdor till anonyma klasser.

// Java 8-lambda — avsockring i ART
button.setOnClickListener(v -> handleClick(v));

// Efter avsockring (motsvarighet i Java 7)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

Begränsningar med avsockring

Alla Java 8-funktioner stöds inte av avsockring. java.time-API:et (datum och tid) är endast tillgängligt via desugar_jdk_libs — ett extra bibliotek som läggs till i build.gradle. Stream API kräver också desugar_jdk_libs. java.util.function och Optional fungerar utan extra beroenden. Fullt Java 8-stöd finns på enheter med Android 8.0 och senare utan avsockring.

Appoptimering för ART

Även om ART är bakåtkompatibelt förbättrar vissa optimeringsmetoder prestanda just i denna miljö. Huvudrekommendationen — minimera reflektion. ART kompilerar metoder som är synliga i kompileringsfasen till direkt maskinkodsanrop. Reflektion tvingar ART att generera ytterligare stubbar, vilket saktar ner exekveringen med 10–15%.

Från och med Android 9.0 fick ART stöd för App Startup Optimization. Utvecklaren kan markera initialiseringsklasser i manifestet via <initialization>, och ART kommer att förladda dem vid appstart. Detta minskar starttiden med 5–15% för appar med många plugin-program eller bibliotek.

<!-- App Startup Optimization i AndroidManifest.xml -->
<application>
    <profileable
        android:shell="true"
        android:enable="true" />
</application>

Prestandamätning

För prestandamätning på ART, använd systrace och perfetto. Systrace visar kompileringstid för dex2oat, GC-frekvens och bilduppdateringshastighet. Perfetto ger mer detaljerad information: trådfördelning, JNI-övergångstid, inläsning av inbyggda bibliotek. Start: adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm.