Dalvik: ano ito, virtual machine at paano ito gumagana

Ano ang Dalvik?

Dalvik — virtual machine na may rehistro na arkitektura, espesyal na ginawa para sa platform ng Android. Nagsimula ang pag-unlad noong 2005 sa kumpanya ni Dan Bornstein, at noong 2007 ang proyekto ay nakuha ng Google. Ang unang komersyal na bersyon ng Dalvik ay lumitaw kasama ng paglabas ng Android 1.0 noong 2008.

Hindi tulad ng karaniwang Java Virtual Machine (JVM), hindi pinapatakbo ng Dalvik ang Java-bytecode. Ginagawang class file ng Java compiler ang source code, pagkatapos ang utility na dx ay isinasalin ang mga ito sa format na Dalvik Executable (DEX). Ang format na ito ay mas compact kaysa sa mga class file: isang application na 10 MB sa class format ay sumasakop ng humigit-kumulang 6–7 MB sa DEX.

Kasaysayan ng paglikha

Dan Bornstein ay sumulat ng Dalvik bilang isang proyekto para sa mga operating system na may limitadong resources. Ang pangalan ay kinuha mula sa Icelandic village ng Dalvík. Pinili ng Google ang Dalvik sa halip na JVM dahil sa mga limitasyon ng lisensya at ang pangangailangan para sa malalim na pag-optimize para sa mga mobile processor na may ARM architecture. Mabilis na naging popular ang sistema: noong 2012, mahigit 500 milyong Android device ang tumatakbo sa Dalvik.

Papel sa ecosystem ng Android

Bawat Android application ay pinapatakbo sa isang hiwalay na proseso na may sariling instance ng Dalvik VM. Ito ay nagsisiguro ng paghihiwalay ng data at proteksyon mula sa malisyosong code sa antas ng operating system. Ang pamamaraang ito ay pinagsasama ang mga bentahe ng virtualization sa Linux sandbox — ang malware sa isang application ay hindi makakaapekto sa mga kalapit na proseso.

Arkitektura ng Dalvik: rehistro machine at DEX

Arkitekturang rehistro ng Dalvik ay pangunahing naiiba mula sa stack architecture ng JVM. Sa halip na mga operasyon sa tuktok ng stack, gumagana ang Dalvik sa mga rehistro — virtual na mga cell sa loob ng VM. Bawat instruction ay naglalaman ng mga address ng operand registers, na nagbabawas ng bilang ng mga instruction bawat operasyon.

Ang stack machine ng JVM ay gumagamit ng mga instruction tulad ng push, pop at add — para magdagdag ng dalawang numero ay kinakailangan ng tatlong instruction. Dalvik ay nilulutas ang parehong gawain sa isang instruction na add-int na may tatlong rehistro. Ayon sa Android Open Source Project, ang rehistro architecture ng DEX ay nagbabawas ng dami ng bytecode sa average na 30% kumpara sa stack-based class format.

Format ng DEX

Ang DEX file (Dalvik Executable) ay naglalaman ng naka-compress na representasyon ng lahat ng klase ng application. Ang header ng file ay may kasamang checksum, laki ng mga seksyon at offset. Ang mga pangunahing seksyon ay mga pool ng string, uri, prototype ng method, field, method at ang bytecode mismo. Sa isang DEX file ay maaaring mag-imbak ng hanggang 65536 method (ang limitasyong ito ay inalis sa pagpapakilala ng multi-dex sa Android 5.0).

Para sa pag-convert ng mga class file sa DEX ay ginagamit ang utility na dx, na bahagi ng Android SDK Build Tools. Halimbawa ng command: dx --dex --output=classes.dex myapp.jar. Ang mga modernong proyekto ay gumagamit ng D8 — ang kahalili ng dx na may pinabuting pag-optimize at suporta para sa Java 8+ features.

# Conversion ng JAR sa DEX gamit ang dx
dx --dex --output=classes.dex myapp.jar

# Modernong bersyon sa pamamagitan ng D8
d8 --lib android.jar --output dex/ myapp.jar

Zygote: paunang pag-load ng framework

Ang proseso ng Zygote — pinakamahalagang elemento ng arkitektura ng Dalvik. Sa pagsisimula ng system, nilo-load ng Zygote ang lahat ng klase ng Android SDK, binubuksan ang mga shared library at gumagawa ng pool ng preloaded resources. Kapag binuksan ng user ang isang application, kinokopya ng system ang proseso ng Zygote (fork), na gumagawa ng bagong instance ng Dalvik VM na may handa nang framework. Ito ay nagbabawas ng oras ng paglulunsad ng application mula ~2–3 segundo hanggang 300–500 millisecond.

JIT-compilation sa Dalvik

JIT (Just-In-Time) — teknolohiya ng pag-compile ng bytecode sa machine instructions nang direkta sa oras ng pagpapatupad ng application. Sa Dalvik, sinusuri ng JIT compiler ang isinasagawang DEX code, tinutukoy ang mga madalas gamitin (hot) method at ini-compile ang mga ito sa native code para sa CPU.

Ang pagpili ng JIT sa halip ng buong Ahead-Of-Time (AOT) compilation sa mga unang bersyon ng Android ay sinadya. Ang mga mobile device ay may limitadong flash memory (4–16 GB) — ang paunang pag-compile ng lahat ng application ay sasakop ng malaking espasyo. Bukod dito, ang ROM memory sa mga unang device ay mas mabagal kaysa sa RAM, at ang pagbasa ng na-compile nang code ay maaaring magpababa ng performance.

Proseso ng JIT-compilation

Kapag ang application ay inilunsad, ang Dalvik ay nagsisimulang mag-interpret ng DEX-bytecode. Isang espesyal na profiler ang sumusubaybay kung aling mga method ang madalas na tinatawag. Matapos lumampas sa threshold (karaniwang ~200 tawag), ang JIT compiler ay ginagawang machine code ang method at ini-cache ito sa RAM. Ang mga sumusunod na tawag ay gumagamit ng naka-compile nang bersyon nang walang muling pag-compile.

// Halimbawa ng hot method na i-compile ng JIT
public class Calculator {
    public int sumArray(int[] arr) {
        int total = 0;
        for (int i = 0; i < arr.length; i++) {
            total += arr[i];
        }
        return total;
    }
}

Performance ng JIT

Ayon sa Google I/O 2013, ang pagpapatupad ng JIT sa Android 2.2 Froyo ay pinabilis ang pagpapatakbo ng mga application sa average na 2–5 beses kumpara sa purong interpretasyon. Gayunpaman, nagdadagdag ang JIT ng pagkaantala sa unang paglunsad: ang application ay nangangailangan ng 3 hanggang 10 segundo para mag-warm up at mag-compile ng mga hot method. Pagkatapos mag-warm up, ang performance ay nagpapatatag sa antas na malapit sa native code.

Dalvik vs JVM: mga pangunahing pagkakaiba

Dalvik ay naiiba sa JVM sa ilang pangunahing parameter. Una — arkitektura: ang JVM ay stack-based, ang Dalvik ay rehistro-based. Pangalawa — format ng bytecode: ang JVM ay gumagamit ng class file, ang Dalvik ay gumagamit ng DEX. Pangatlo — pamamahala ng memorya: ang Dalvik ay na-optimize para sa limitadong RAM ng mga mobile device.

Ang parehong approach ay may mga kalakasan. Ang stack-based JVM ay nangangailangan ng mas kaunting espasyo para sa pag-imbak ng mga instruction — bawat instruction ay mas maikli dahil ang mga operand ay implicit na kinuha mula sa stack. Ang rehistro-based Dalvik ay nagpapatupad ng mas kaunting instruction bawat operasyon, na nakakatipid ng oras ng processor at nagbabawas ng konsumo ng kuryente. Para sa mga mobile device na pinapagana ng baterya, ito ay kritikal.

Mga aspeto ng lisensya

Ang pagpili ng Dalvik sa halip ng JVM ay dahil din sa lisensya. Ang Oracle ay nagmamay-ari ng mga karapatan sa Java SE at JVM, at sinubukan ng Google na iwasan ang mga bayad sa lisensya. Ang paggawa ng sariling VM na may alternatibong format ng bytecode ay pinayagan ang Android na umunlad nang independyente mula sa Oracle. Ang hindi pagkakaunawaan na ito ay nauwi sa isang multi-taon na legal na proseso Oracle vs Google (2010–2021), na nagtapos sa pabor ng Google.

Format ng DEX at utility na dx

DEX (Dalvik Executable) — binary format na naglalaman ng na-compile na code ng Android application. Bawat DEX file ay nagsisimula sa isang header, na sinusundan ng mga seksyon: string constants (string_ids), uri (type_ids), prototype ng method (proto_ids), field (field_ids), method (method_ids), definition ng klase (class_defs) at area ng data (data).

Ang utility na dx ay nagko-convert ng Java class file sa isa o maramihang DEX file. Ang algorithm ng trabaho ay may kasamang deduplication ng constants — ang magkaparehong string o uri ay iniimbak nang isang beses at tinutukoy sa pamamagitan ng index. Ito ay makabuluhang nagbabawas ng huling sukat. Sa mga modernong proyekto, ang dx ay pinalitan ng D8 (lumitaw sa Android Studio 3.1), na gumagana nang 2–3 beses na mas mabilis at sumusuporta sa Java 8 desugaring.

// Halimbawa ng na-decompile na DEX-bytecode sa pamamagitan ng dexdump
// Source code: return a + b;
@Ldalvik/annotation/Code;
    registers: 3
    add-int v0, v1, v2
    return v0

Multi-dex: paglampas sa limitasyon ng 65536

Ang limitasyon ng DEX format sa 65536 method (limitasyon ng 16-bit index) ay naging malubhang problema para sa malalaking application. Ang solusyon ay dumating sa Android 5.0: suporta para sa multi-dex ay nagpapahintulot sa application na maglaman ng maraming DEX file. Ang pangunahing classes.dex ay naglalaman ng mga entry point, at ang mga karagdagang classes2.dex, classes3.dex at iba pa ay naglalaman ng natitirang code. Ang configuration ng multi-dex ay naka-enable sa build.gradle sa pamamagitan ng linya multiDexEnabled true.

Pamamahala ng memorya at pagtitipon ng basura

Pagtitipon ng basura sa Dalvik ay ipinatupad bilang isang generational collector na may mark-and-sweep. Ang memorya ay nahahati sa dalawang pangunahing lugar: Heap (tambak) para sa mga bagay at Stack (salansan) para sa mga primitive at reference. Kapag napuno ang Heap, pinipigilan ng Dalvik ang lahat ng thread (STW — Stop-The-World), minamarkahan ang mga naaabot na bagay at pinapalaya ang mga hindi naaabot.

Hanggang sa Android 2.2, ang Dalvik ay gumamit ng single-threaded collector na may mga pause hanggang 100–200 ms. Sa Android 2.3 Gingerbread lumitaw ang isang concurrent collector, na nagbawas ng tipikal na mga pause sa 5–10 ms. At sa Android 4.0 Ice Cream Sandwich ay idinagdag ang isang collector na may incremental na paglilinis — Concurrent Mark and Sweep (CMS).

Pagtagas ng memorya

Isang tipikal na problema ng Dalvik applications — pagtagas ng memorya sa pamamagitan ng static na reference sa Activity. Kung ang isang static na field ay nag-iimbak ng reference sa Context o View, hindi mapapalaya ng garbage collector ang Activity kahit na matapos isara ang screen. Ang mga tool tulad ng Eclipse MAT at LeakCanary ay tumutulong sa pagtuklas ng mga naturang pagtagas: sinasuri nila ang Heap dump at ipinapakita ang mga chain ng reference na humahawak sa bagay.

// Halimbawa ng pagtagas ng memorya sa pamamagitan ng static reference
public class Utils {
    private static Context context;

    public static void init(Context ctx) {
        context = ctx; // Hinahawakan ang Activity pagkatapos ng finish()
    }
}

Mga limitasyon ng Dalvik at paglipat sa ART

Sa kabila ng tagumpay, ang Dalvik ay may ilang mga kakulangan. Ang JIT-compilation ay nangangailangan ng oras para mag-warm up — ang mga unang segundo ng pagpapatakbo ng application ay mas mabagal. Bukod dito, ang JIT ay kumokonsumo ng enerhiya ng processor sa panahon ng pag-compile, na nagpapaikli ng buhay ng baterya. Sa pagtaas ng performance ng mga mobile device at paglaki ng kapasidad ng built-in memory, ang pangangailangan para sa JIT ay bumaba.

Sa Android 4.4 KitKat, ipinakilala ng Google ang ART (Android Runtime) bilang isang eksperimental na kapalit para sa Dalvik. Simula sa Android 5.0 Lollipop, ang ART ay naging tanging runtime environment. Ang pangunahing pagkakaiba — AOT compilation: sa halip na mag-compile habang tumatakbo, lahat ng application ay ini-compile sa machine code sa oras ng pag-install. Ito ay nag-alis ng mga pagkaantala sa pag-warm up at nagpabuti ng energy efficiency.

Backward compatibility

Ang paglipat mula Dalvik patungong ART ay transparent para sa mga developer: parehong environment ay nagpapatakbo ng parehong DEX-bytecode. Ang mga application na binuo para sa Dalvik ay tumatakbo sa ART nang walang muling pag-compile — ang system_server ay nag-compile sa kanila sa native code sa oras ng pag-install. Ang exception ay code na gumagamit ng reflection para ma-access ang mga internal na miyembro ng Dalvik VM: ang naturang code ay maaaring masira sa ART dahil sa pagbabago ng internal architecture.