Android Runtime och Dalvik: Hjärtat i Android Runtime

Senaste uppdateringen: November 11, 2026
Författare: Pixelerad
  • Dalvik arbetade med hjälp av JIT-kompilering och översatte koden medan appen kördes.
  • ART optimerar systemet genom att använda AOT-kompilering, vilket utför processen under installationen.
  • Båda miljöerna använder DEX-filformatet, vilket säkerställer kompatibilitet mellan versioner.
  • Övergången till ART har möjliggjort minskad batteriförbrukning och förbättrad systemflyt.

Närbild av makrovy av komponenter i en elektronisk krets, som representerar hårdvaran där Android Runtime körs.

Om du någonsin undrat vad som egentligen händer under huven på din telefon när du öppnar en app, finns svaret i runtime-miljön. I Android-ekosystemet har vi gått från en arkitektur baserad på den virtuella Dalvik-maskinen till ett mycket mer robust system som kallas Android Runtime, mer känt som ART. I huvudsak ansvarar ART för att översätta den kod som programmerare skriver till instruktioner som din enhets hårdvara kan förstå utan att krascha.

För att förstå detta är det viktigt att veta att Android inte kör Java direkt; istället använder det en anpassad anpassning . Allt börjar med källkoden, som omvandlas till bytekod och hamnar i ett specifikt format som kallas DEX. Beroende på om din Android-version är äldre eller nyare ändras vägen som denna kod tar för att köras drastiskt, vilket påverkar vardagliga saker som batteritid och appens laddningshastighet.

Dalviks arv: Just-in-Time-eran

Smartphone-skärm som visar rader med programmeringskod, som illustrerar konverteringen av bytekod till körbara instruktioner.

Dalvik var en grundläggande pelare från Androids allra första början. Dess mål var tydligt: ​​att tillåta applikationer skrivna i Java att köras på enheter med mycket begränsade resurser . Till skillnad från en vanlig virtuell Java-maskin optimerades Dalvik för att använda mindre minne och köra flera instanser samtidigt, vilket delegerade trådhanteringen till Linuxkärnan.

  Snapseed fotoredigering: en komplett guide för att få ut det mesta

Dalviks nyckelfunktion var Just-In-Time (JIT) -kompilering . Detta innebar att koden översattes till maskinspråk precis när användaren interagerade med appen. För att undvika att upprepa denna tråkiga uppgift varje gång skapade Dalvik filer som heter ODEX (Optimized DEX) , vilka lagrade de redan översatta delarna i en cache. Problemet var att denna konstanta kompileringsprocess förbrukade CPU-cykler och därför använde mer energi.

Android Runtime (ART): Språnget till att vara före sin tid

Smartphone på ett tangentbord som visar batterinivån, med hänvisning till energieffektiviteten hos ART jämfört med Dalvik.

Med början i Android 5.0 Lollipop tog ART över helt och hållet. Den stora skillnaden är att ART implementerar Ahead-Of-Time (AOT) -kompilering . Istället för att vänta på att du ska öppna applikationen gör ART det grova arbetet under installationen. Det använder ett verktyg som heter dex2oat för att konvertera DEX-filer till ELF-körbara filer (Executable and Linkable Format), vilka är inbyggda i Linux.

Tack vare den här metoden behöver systemet inte kompilera någonting när du trycker på en appikon; det läser helt enkelt ELF-filen och kör den. Det betyder att processorn arbetar mindre, batteriet räcker längre och appar känns mycket smidigare. Det finns dock en liten nackdel: appinstallationen tar lite längre tid och de tar upp mer lagringsutrymme än med Dalvik.

Teknisk jämförelse och viktiga förbättringar

Även om båda miljöerna är kompatibla och kör samma DEX-bytekod, har ART introducerat förbättringar som gör systemet otroligt snabbt. En av de viktigaste är garbage collection (GC) . I Dalvik brukade garbage collector orsaka de där irriterande pauserna eller "stöttrarna" i gränssnittet (den ökända laggen). ART har omdesignat detta med ett i huvudsak parallellt system , vilket gör pauserna oberoende av mängden minne som används.

  • Avancerad felsökning: ART låter utvecklare se vilka låstrådar som håller och spåra klassinstanser med mycket större noggrannhet.
  • Noggranna diagnoser: Nu, när en app kraschar, är felrapporterna mycket mer detaljerade, särskilt i fall av NullPointerException.
  • Minneshantering: Till skillnad från Dalvik, som använde en icke-sidbar cache, använder ART RAM-minne som paginering är möjlig, optimerar användningen av hårdvara.
  Wi-Fi 7: Så här använder du det för att förbättra din hemanslutning

Paketeringsprocessen: Från kod till APK

Utvecklingsmiljö med bärbar dator och smartphone, som representerar processen att paketera källkoden upp till APK-filen.

För att någon av dessa miljöer ska fungera måste koden gå igenom ett monteringsband. Först skapar Java-kompilatorn .class-filer, som dex- verktyget sedan konverterar till en enda classes.dex-fil. Denna fil är kärnan i APK:n och är vad ART eller Dalvik kommer att bearbeta.

Verktyg som aapt används för att paketera resurser, och zipalign optimerar datajustering, vilket säkerställer att processorn använder minnet så effektivt som möjligt. När APK-filen når enheten händer magin: om det finns ART genereras ELF-filen ; om det finns Dalvik börjar ODEX-filen genereras direkt.

Intressanta fakta om ROM och deodexingprocessen

I världen av anpassade ROM-skivor används termerna odex och deodex ofta . Eftersom ODEX-filen är hårdvaruberoende och beror på exakt vilket system den skapades på, kan den inte enkelt överföras från en telefon till en annan. För att modifiera en app utan att krascha systemet utför utvecklare en deodexing- process , vilket innebär att den optimerade filen integreras i APK:n för att underlätta dess manipulation.

Android-ekosystemet har utvecklats från en flexibel men energikrävande virtuell maskin till en optimerad runtime-miljö som prioriterar användarupplevelsen. Medan Dalvik fokuserade på mångsidigheten i att översätta kod i realtid, har ART maximerat hårdvaruutnyttjandet genom förkompilering , vilket säkerställer att programvaran är mer stabil, snabbare och mer energieffektiv.