Dalvik: mi ez, virtuális gép és hogyan működik

Mi az a Dalvik?

Dalvik — regiszteralapú architektúrájú virtuális gép, amelyet kifejezetten az Android platformra hoztak létre. A fejlesztés 2005-ben kezdődött Dan Bornstein cégénél, majd 2007-ben a projektet felvásárolta a Google. A Dalvik első kereskedelmi verziója az Android 1.0 2008-as megjelenésével együtt jelent meg.

Ellentétben a szabványos Java Virtual Machine-nel (JVM), a Dalvik nem hajt végre Java-bájtkódot. A Java-fordító a forráskódot class-fájlokká alakítja, majd a dx segédprogram ezeket lefordítja a Dalvik Executable (DEX) formátumba. Ez a formátum tömörebb, mint a class-fájlok: egy 10 MB-os alkalmazás class formátumban kb. 6–7 MB-ot foglal DEX-ben.

Létrejöttének története

Dan Bornstein a Dalvikot korlátozott erőforrású operációs rendszerekhez készített projektként írta. A nevét az izlandi Dalvík faluról kapta. A Google azért választotta a Dalvikot a JVM helyett, mert licencbeli korlátozások voltak, és mélyreható optimalizálásra volt szükség az ARM architektúrájú mobil processzorokhoz. A rendszer gyorsan népszerűvé vált: 2012-re több mint 500 millió Android-eszköz működött Dalvikon.

Szerep az Android ökoszisztémában

Minden Android-alkalmazás külön folyamatban fut a saját Dalvik VM példányával. Ez biztosítja az adatok elkülönítését és a védelmet a rosszindulatú kóddal szemben az operációs rendszer szintjén. Ez a megközelítés ötvözi a virtualizáció előnyeit a Linux homokozóval — az egyik alkalmazásban lévő kártevő nem befolyásolhatja a szomszédos folyamatokat.

A Dalvik architektúrája: regisztergép és DEX

A Dalvik regiszteralapú architektúrája alapvetően különbözik a JVM veremalapú architektúrájától. Vermek tetejével végzett műveletek helyett a Dalvik regiszterekkel — virtuális cellákkal a VM-en belül — dolgozik. Minden utasítás tartalmazza az operandumregiszterek címeit, ami csökkenti az egy műveletre jutó utasítások számát.

A JVM vermes gépe olyan utasításokat használ, mint a push, pop és add — két szám összeadásához három utasítás szükséges. Dalvik ugyanezt a feladatot egyetlen add-int utasítással oldja meg három regiszterrel. Az Android Open Source Project szerint a DEX regiszteralapú architektúrája átlagosan 30%-kal csökkenti a bájtkód méretét a veremalapú class formátumhoz képest.

DEX formátum

A DEX-fájl (Dalvik Executable) az alkalmazás összes osztályának tömörített ábrázolását tartalmazza. A fájl fejléce tartalmazza az ellenőrző összeget, a szekciók méreteit és eltolásait. A fő szekciók a sztring-, típus-, metódusprototípus-, mező-, metódus- és magának a bájtkódnak a gyűjteményei. Egyetlen DEX-fájlban legfeljebb 65536 metódus tárolható (ezt a korlátozást az Android 5.0-ban bevezetett multi-dex oldotta fel).

A class-fájlok DEX formátumba történő átalakításához a dx segédprogramot használják, amely az Android SDK Build Tools része. Példa parancs: dx --dex --output=classes.dex myapp.jar. A modern projektek a D8-at használják — a dx utódját, javított optimalizálással és Java 8+ funkciók támogatásával.

# JAR átalakítása DEX-re a dx segítségével
dx --dex --output=classes.dex myapp.jar

# Modern verzió D8-on keresztül
d8 --lib android.jar --output dex/ myapp.jar

Zygote: a keretrendszer előzetes betöltése

A Zygote folyamat — a Dalvik architektúra legfontosabb eleme. A rendszer indításakor a Zygote betölti az Android SDK összes osztályát, megnyitja a megosztott könyvtárakat, és létrehoz egy előre betöltött erőforrás- gyűjteményt. Amikor a felhasználó megnyit egy alkalmazást, a rendszer másolja a Zygote folyamatot (fork), így hozva létre egy új Dalvik VM példányt a már kész keretrendszerrel. Ez az alkalmazás indítási idejét ~2–3 másodpercről 300–500 ezredmásodpercre csökkenti.

JIT-fordítás a Dalvikban

JIT (Just-In-Time) — a bájtkód gépi utasításokká történő fordításának technológiája közvetlenül az alkalmazás futása során. A Dalvikban a JIT-fordító elemzi a végrehajtott DEX-kódot, azonosítja a gyakran használt (hot) metódusokat, és ezeket natív kóddá fordítja a CPU számára.

A JIT választása a teljes Ahead-Of-Time (AOT) fordítás helyett az Android korai verzióiban tudatos döntés volt. A mobileszközök korlátozott flash memóriával (4–16 GB) rendelkeztek — az összes alkalmazás előzetes lefordítása jelentős helyet foglalt volna el. Ezenkívül a ROM memória a korai eszközökben lassabban működött, mint a RAM, és az előre lefordított kód olvasása ronthatott a teljesítményen.

A JIT-fordítás folyamata

Amikor az alkalmazás elindul, a Dalvik elkezdi értelmezni a DEX-bájtkódot. Egy speciális profilozó figyeli, hogy mely metódusokat hívják a leggyakrabban. A küszöbérték túllépése után (általában ~200 hívás) a JIT-fordító a metódust gépi kóddá alakítja, és eltárolja a RAM-ban. A későbbi hívások a már lefordított verziót használják újrafordítás nélkül.

// Példa hot metódusra, amelyet a JIT lefordít
public class Calculator {
    public int sumArray(int[] arr) {
        int total = 0;
        for (int i = 0; i < arr.length; i++) {
            total += arr[i];
        }
        return total;
    }
}

A JIT teljesítménye

A Google I/O 2013 adatai szerint a JIT bevezetése az Android 2.2 Froyoban átlagosan 2–5-szörösére gyorsította az alkalmazások végrehajtását a tiszta értelmezéshez képest. A JIT azonban késleltetést ad az első indításhoz: az alkalmazásnak 3–10 másodpercre van szüksége a bemelegítéshez és a hot metódusok lefordításához. Bemelegítés után a teljesítmény a natív kódhoz közeli szinten stabilizálódik.

Dalvik vs JVM: fő különbségek

Dalvik számos alapvető paraméterben különbözik a JVM-től. Első — architektúra: a JVM veremalapú, a Dalvik regiszteralapú. Második — a bájtkód formátuma: a JVM class-fájlokat, a Dalvik DEX-et használ. Harmadik — memóriakezelés: a Dalvik a mobileszközök korlátozott RAM-jára van optimalizálva.

Mindkét megközelítésnek vannak erősségei. A veremalapú JVM kevesebb helyet igényel az utasítások tárolásához — minden utasítás rövidebb, mert az operandusok implicit módon a veremből származnak. A regiszteralapú Dalvik kevesebb utasítást hajt végre műveletenként, ami processzoridőt takarít meg és csökkenti az energiafogyasztást. Az akkumulátorral működő mobileszközök számára ez kritikus.

Licencbeli szempontok

A JVM helyett a Dalvik választását a licencelés is indokolta. Az Oracle birtokolja a Java SE és a JVM jogait, és a Google el akarta kerülni a licencdíjakat. A saját VM létrehozása alternatív bájtkód-formátummal lehetővé tette az Android számára, hogy függetlenül fejlődjön az Oracle-től. Ez a vita évekig tartó jogi eljáráshoz vezetett Oracle kontra Google (2010–2021), amely a Google javára zárult.

DEX formátum és a dx segédprogram

DEX (Dalvik Executable) — bináris formátum, amely az Android-alkalmazás lefordított kódját tartalmazza. Minden DEX-fájl egy fejléccel (header) kezdődik, amelyet szekciók követnek: sztringállandók (string_ids), típusok (type_ids), metódusprototípusok (proto_ids), mezők (field_ids), metódusok (method_ids), osztálydefiníciók (class_defs) és adatterület (data).

A dx segédprogram a Java class-fájlokat egy vagy több DEX-fájllá alakítja át. A munka algoritmusa tartalmazza az állandók deduplikációját — az azonos sztringe-eket vagy típusokat egyszer tárolja, és indexen keresztül hivatkozza őket. Ez jelentősen csökkenti a végső méretet. A modern projektekben a dx-et a D8 váltotta fel (az Android Studio 3.1-ben jelent meg), amely 2–3-szor gyorsabban működik és támogatja a Java 8 desugaringet.

// Példa dexdump-pal visszafejtett DEX-bájtkódra
// Forráskód: return a + b;
@Ldalvik/annotation/Code;
    registers: 3
    add-int v0, v1, v2
    return v0

Multi-dex: a 65536-os korlát áthidalása

A DEX formátum 65536 metódusos korlátozása (a 16-bites index korlátja) komoly problémává vált a nagy alkalmazások számára. A megoldás az Android 5.0-ban érkezett meg: a multi-dex támogatása lehetővé teszi, hogy az alkalmazás több DEX-fájlt tartalmazzon. A fő classes.dex tartalmazza a belépési pontokat, a kiegészítő classes2.dex, classes3.dex és így tovább pedig a többi kódot. A multi-dex konfigurálása a build.gradle fájlban a multiDexEnabled true sorral történik.

Memóriakezelés és szemétgyűjtés

A szemétgyűjtés a Dalvikban generációs (generational) gyűjtőként van megvalósítva, megjelöléssel és tisztítással (mark-and-sweep). A memória két fő területre oszlik: Heap (halom) az objektumok számára és Stack (verem) a primitívek és referenciák számára. Amikor a Heap megtelik, a Dalvik felfüggeszti az összes szálat (STW — Stop-The-World), megjelöli az elérhető objektumokat, és felszabadítja az elérhetetleneket.

Android 2.2-ig a Dalvik egyszálú gyűjtőt használt, legfeljebb 100–200 ms-es szünetekkel. Az Android 2.3 Gingerbread-ben megjelent egy párhuzamos gyűjtő, amely a tipikus szüneteket 5–10 ms-ra csökkentette. Az Android 4.0 Ice Cream Sandwich-ben pedig hozzáadtak egy növekményes (inkrementális) tisztítású gyűjtőt — a Concurrent Mark and Sweep-et (CMS).

Memóriaszivárgás

A Dalvik-alkalmazások tipikus problémája — memóriaszivárgás statikus referenciákon keresztül Activity-re. Ha egy statikus mező referenciát tárol egy Context-re vagy View-ra, a szemétgyűjtő nem tudja felszabadítani az Activity-t a képernyő bezárása után sem. Az olyan eszközök, mint az Eclipse MAT és a LeakCanary, segítenek az ilyen szivárgások észlelésében: elemzik a Heap dumpot és megmutatják az objektumot megtartó referencialáncokat.

// Példa memóriaszivárgásra statikus referencián keresztül
public class Utils {
    private static Context context;

    public static void init(Context ctx) {
        context = ctx; // Megtartja az Activity-t a finish() után
    }
}

A Dalvik korlátai és áttérés az ART-ra

A siker ellenére a Dalvik számos hátránnyal rendelkezett. A JIT-fordításnak időre volt szüksége a bemelegítéshez — az alkalmazás első másodpercei lassabbak voltak. Ezenkívül a JIT processzorenergiát fogyasztott a fordítás során, ami csökkentette az akkumulátor élettartamát. A mobileszközök teljesítményének növekedésével és a beépített memória kapacitásának bővülésével a JIT iránti igény csökkent.

Az Android 4.4 KitKat-ben a Google bemutatta az ART-ot (Android Runtime) a Dalvik kísérleti helyettesítőjeként. Android 5.0 Lollipoptól kezdve az ART lett az egyetlen futási környezet. A fő különbség — az AOT-fordítás: a futás közbeni fordítás helyett az összes alkalmazás a telepítéskor fordítódik le gépi kóddá. Ez megszüntette a bemelegítési késleltetéseket és javította az energiahatékonyságot.

Visszafelé kompatibilitás

A Dalvikról ART-ra való áttérés átlátható volt a fejlesztők számára: mindkét környezet ugyanazt a DEX-bájtkódot hajtja végre. A Dalvikra épített alkalmazások újrafordítás nélkül működnek ART-on — a system_server telepítéskor lefordítja őket natív kóddá. Kivételt képez a reflektáló kód, amely a Dalvik VM belső tagjaihoz fér hozzá: az ilyen kód összetörhet ART-on a belső architektúra változása miatt.