Android Runtime og Dalvik: Hjertet i Android Runtime

Sidste ændring: 11 november 2026
Forfatter: Pixeleret
  • Dalvik arbejdede ved hjælp af JIT-kompilering og oversatte koden, mens appen kørte.
  • ART optimerer systemet ved hjælp af AOT-kompilering, der udfører processen under installationen.
  • Begge miljøer bruger DEX-filformatet, hvilket sikrer kompatibilitet mellem versioner.
  • Overgangen til ART har reduceret batteriforbruget og forbedret systemets flydende egenskaber.

Nærbillede af komponenterne i et elektronisk kredsløb, der repræsenterer den hardware, hvor Android Runtime kører.

Hvis du nogensinde har spekuleret på, hvad der egentlig sker under din telefons motorhjelm, når du åbner en app, ligger svaret i runtime-miljøet. I Android-økosystemet er vi gået fra en arkitektur baseret på den virtuelle Dalvik-maskine til et langt mere robust system kaldet Android Runtime, bedre kendt som ART. ART er i bund og grund ansvarlig for at oversætte den kode, programmører skriver, til instruktioner, som din enheds hardware kan forstå uden at gå ned.

For at forstå dette er det vigtigt at vide, at Android ikke kører Java som standard; i stedet bruger det en brugerdefineret tilpasning . Det hele starter med kildekoden, som transformeres til bytecode og ender i et specifikt format kaldet DEX. Afhængigt af om din Android-version er ældre eller nyere, ændres den vej, denne kode tager for at udføre, drastisk, hvilket påvirker hverdagens ting som batterilevetid og app-indlæsningshastighed.

Dalviks arv: Just-in-Time-æraen

Smartphone-skærm, der viser linjer med programmeringskode, der illustrerer konverteringen af ​​bytekode til eksekverbare instruktioner.

Dalvik var en fundamental søjle lige fra Androids begyndelse. Dens mål var klart: at tillade applikationer skrevet i Java at køre på enheder med meget begrænsede ressourcer . I modsætning til en standard Java virtuel maskine var Dalvik optimeret til at bruge mindre hukommelse og køre flere instanser samtidigt, hvilket delegerede trådhåndtering til Linux-kernen.

  Snapseed-fotoredigering: en komplet guide til at få mest muligt ud af det

Dalviks nøglefunktion var Just-In-Time (JIT) kompilering . Dette betød, at koden blev oversat til maskinsprog præcis når brugeren interagerede med appen. For at undgå at gentage denne kedelige opgave hver gang, oprettede Dalvik filer kaldet ODEX (Optimized DEX) , som gemte de allerede oversatte dele i en cache. Problemet var, at denne konstante kompileringsproces forbrugte CPU-cyklusser og derfor brugte mere energi.

Android Runtime (ART): Springet til at være forud for tiden

Smartphone på et tastatur, der viser batteriniveauet med henvisning til energieffektiviteten af ​​ART versus Dalvik.

Fra og med Android 5.0 Lollipop tog ART fuldstændig over. Den store forskel er, at ART implementerer Ahead-Of-Time (AOT) kompilering . I stedet for at vente på, at du åbner applikationen, klarer ART det hårde arbejde under installationen. Det bruger et værktøj kaldet dex2oat til at konvertere DEX-filer til ELF (Executable and Linkable Format) eksekverbare filer, som er native til Linux.

Takket være denne tilgang behøver systemet ikke at kompilere noget, når du trykker på et appikon; det læser blot ELF-filen og udfører den. Det betyder, at processoren arbejder mindre, batteriet holder længere , og apps føles meget mere jævnt. Der er dog en lille ulempe: appinstallation tager lidt længere tid, og de optager mere lagerplads end med Dalvik.

Teknisk sammenligning og vigtige forbedringer

Selvom begge miljøer er kompatible og kører den samme DEX-bytekode, har ART introduceret forbedringer, der gør systemet utrolig hurtigt. En af de mest betydningsfulde er garbage collection (GC) . I Dalvik forårsagede garbage collectoren tidligere de irriterende pauser eller "hakkende" hastigheder i brugerfladen (den berygtede forsinkelse). ART har redesignet dette med et primært samtidig system , der gør pauser uafhængige af mængden af ​​brugt hukommelse.

  • Avanceret debugging: ART giver udviklere mulighed for at se, hvilke låse-tråde der holder, og spore klasseinstanser med langt større nøjagtighed.
  • Præcise diagnoser: Når en app går ned, er fejlrapporterne nu meget mere detaljerede, især i tilfælde af NullPointerException.
  • Hukommelseshåndtering: I modsætning til Dalvik, som brugte en ikke-pageable cache, bruger ART RAM-hukommelse, der Paginering er mulig, optimering af brugen af ​​hardware.
  Wi-Fi 7: Sådan bruger du det til at forbedre din hjemmeforbindelse

Pakkeprocessen: Fra kode til APK

Udviklingsmiljø med bærbar computer og smartphone, der repræsenterer processen med at pakke kildekoden op til APK-filen.

For at et af disse miljøer kan fungere, skal koden gå gennem et samlebånd. Først opretter Java-compileren .class-filer, som dex- værktøjet derefter konverterer til en enkelt classes.dex-fil. Denne fil er kernen i APK'en, og det er det, ART eller Dalvik behandler.

Værktøjer som aapt bruges til at pakke ressourcer, og zipalign optimerer datajustering og sikrer, at processoren tilgår hukommelsen så effektivt som muligt. Når APK'en når enheden, sker magien: Hvis der er ART, genereres ELF-filen ; hvis der er Dalvik, begynder ODEX-filen at blive genereret på stedet.

Interessante fakta om ROM'er og deodexing-processen

I verden af ​​brugerdefinerede ROM'er bruges udtrykkene odex og deodex almindeligvis . Da ODEX-filen er hardwareafhængig og afhænger af det præcise system, hvor den blev oprettet, kan den ikke nemt overføres fra en telefon til en anden. For at ændre en app uden at få systemet til at gå ned, udfører udviklere en deodexing- proces , som involverer at integrere den optimerede fil i APK'en for at lette dens manipulation.

Android-økosystemet har udviklet sig fra en fleksibel, men energikrævende virtuel maskine til et optimeret runtime-miljø, der prioriterer brugeroplevelsen. Mens Dalvik fokuserede på alsidigheden ved at oversætte kode i realtid, har ART maksimeret hardwareudnyttelsen gennem prækompilering , hvilket sikrer, at softwaren er mere stabil, hurtigere og mere energieffektiv.