Dalvik: apa itu, mesin virtual dan cara kerjanya

Apa itu Dalvik?

Dalvik — mesin virtual dengan arsitektur register, dibuat khusus untuk platform Android. Pengembangan dimulai pada tahun 2005 di perusahaan Dan Bornstein, dan pada tahun 2007 proyek ini diakuisisi oleh Google. Versi komersial pertama Dalvik hadir bersama rilis Android 1.0 pada tahun 2008.

Tidak seperti Java Virtual Machine standar (JVM), Dalvik tidak menjalankan Java-bytecode. Kompiler Java mengubah kode sumber menjadi file class, kemudian utilitas dx menerjemahkannya ke dalam format Dalvik Executable (DEX). Format ini lebih kompak daripada file class: aplikasi berukuran 10 MB dalam format class memakan sekitar 6–7 MB dalam DEX.

Sejarah penciptaan

Dan Bornstein menulis Dalvik sebagai proyek untuk sistem operasi dengan sumber daya terbatas. Nama ini diambil dari desa Dalvík di Islandia. Google memilih Dalvik daripada JVM karena batasan lisensi dan kebutuhan optimasi mendalam untuk prosesor seluler dengan arsitektur ARM. Sistem ini dengan cepat meraih popularitas: pada tahun 2012, lebih dari 500 juta perangkat Android berjalan di Dalvik.

Peran dalam ekosistem Android

Setiap aplikasi Android dijalankan dalam proses terpisah dengan instance Dalvik VM sendiri. Ini memastikan isolasi data dan perlindungan dari kode berbahaya di tingkat sistem operasi. Pendekatan ini menggabungkan keuntungan virtualisasi dengan sandbox Linux — malware di satu aplikasi tidak dapat memengaruhi proses tetangga.

Arsitektur Dalvik: mesin register dan DEX

Arsitektur register Dalvik secara fundamental berbeda dari arsitektur stack JVM. Alih-alih operasi dengan puncak stack, Dalvik bekerja dengan register — sel virtual di dalam VM. Setiap instruksi berisi alamat register operand, yang mengurangi jumlah instruksi per operasi.

Mesin stack JVM menggunakan instruksi seperti push, pop, dan add — untuk menjumlahkan dua angka diperlukan tiga instruksi. Dalvik menyelesaikan tugas yang sama dengan satu instruksi add-int dengan tiga register. Menurut Android Open Source Project, arsitektur register DEX mengurangi volume bytecode rata-rata 30% dibandingkan dengan format class berbasis stack.

Format DEX

File DEX (Dalvik Executable) berisi representasi terkompresi dari semua kelas aplikasi. Header file mencakup checksum, ukuran seksi, dan offset. Seksi utama adalah pool string, tipe, prototipe metode, field, metode, dan bytecode itu sendiri. Dalam satu file DEX dapat disimpan hingga 65536 metode (batasan ini dihapus dengan diperkenalkannya multi-dex di Android 5.0).

Untuk mengonversi file class ke DEX digunakan utilitas dx, yang merupakan bagian dari Android SDK Build Tools. Contoh perintah: dx --dex --output=classes.dex myapp.jar. Proyek modern menggunakan D8 — penerus dx dengan optimasi yang ditingkatkan dan dukungan untuk fitur Java 8+.

# Konversi JAR ke DEX menggunakan dx
dx --dex --output=classes.dex myapp.jar

# Versi modern melalui D8
d8 --lib android.jar --output dex/ myapp.jar

Zygote: pra-memuat framework

Proses Zygote — elemen terpenting dari arsitektur Dalvik. Saat sistem dijalankan, Zygote memuat semua kelas Android SDK, membuka perpustakaan bersama, dan membuat pool sumber daya yang dimuat sebelumnya. Ketika pengguna membuka aplikasi, sistem menyalin proses Zygote (fork), membuat instance Dalvik VM baru dengan framework yang sudah siap. Ini mengurangi waktu peluncuran aplikasi dari ~2–3 detik menjadi 300–500 milidetik.

Kompilasi JIT di Dalvik

JIT (Just-In-Time) — teknologi kompilasi bytecode menjadi instruksi mesin secara langsung selama eksekusi aplikasi. Di Dalvik, kompiler JIT menganalisis kode DEX yang dijalankan, mengidentifikasi metode yang sering digunakan (hot) dan mengompilasinya menjadi kode native untuk CPU.

Pemilihan JIT daripada kompilasi Ahead-Of-Time (AOT) penuh di versi awal Android adalah keputusan yang disengaja. Perangkat seluler memiliki memori flash terbatas (4–16 GB) — kompilasi awal semua aplikasi akan memakan ruang yang signifikan. Selain itu, memori ROM di perangkat awal bekerja lebih lambat daripada RAM, dan membaca kode yang sudah dikompilasi sebelumnya dapat menurunkan kinerja.

Proses kompilasi JIT

Ketika aplikasi dijalankan, Dalvik mulai menafsirkan DEX-bytecode. Profiler khusus melacak metode mana yang paling sering dipanggil. Setelah melebihi ambang batas (biasanya ~200 panggilan), kompiler JIT mengubah metode menjadi kode mesin dan menyimpannya di RAM. Panggilan berikutnya menggunakan versi yang sudah dikompilasi tanpa kompilasi ulang.

// Contoh metode hot yang akan dikompilasi oleh 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;
    }
}

Kinerja JIT

Menurut Google I/O 2013, penerapan JIT di Android 2.2 Froyo mempercepat eksekusi aplikasi rata-rata 2–5 kali dibandingkan dengan interpretasi murni. Namun JIT menambahkan penundaan pada peluncuran pertama: aplikasi membutuhkan 3 hingga 10 detik untuk pemanasan dan kompilasi metode hot. Setelah pemanasan, kinerja stabil pada tingkat yang mendekati kode native.

Dalvik vs JVM: perbedaan utama

Dalvik berbeda dari JVM dalam beberapa parameter fundamental. Pertama — arsitektur: JVM berbasis stack, Dalvik berbasis register. Kedua — format bytecode: JVM menggunakan file class, Dalvik menggunakan DEX. Ketiga — manajemen memori: Dalvik dioptimalkan untuk RAM terbatas perangkat seluler.

Kedua pendekatan memiliki kelebihan masing-masing. JVM berbasis stack membutuhkan lebih sedikit ruang untuk menyimpan instruksi — setiap instruksi lebih pendek karena operand secara implisit diambil dari stack. Dalvik berbasis register menjalankan lebih sedikit instruksi per operasi, yang menghemat waktu prosesor dan mengurangi konsumsi daya. Untuk perangkat seluler bertenaga baterai, ini sangat penting.

Aspek lisensi

Pemilihan Dalvik daripada JVM juga disebabkan oleh lisensi. Oracle memiliki hak atas Java SE dan JVM, dan Google berusaha menghindari biaya lisensi. Membuat VM sendiri dengan format bytecode alternatif memungkinkan Android berkembang secara independen dari Oracle. Perselisihan ini berujung pada proses hukum bertahun-tahun Oracle vs Google (2010–2021), yang berakhir dengan kemenangan Google.

Format DEX dan utilitas dx

DEX (Dalvik Executable) — format biner yang berisi kode yang dikompilasi dari aplikasi Android. Setiap file DEX dimulai dengan header, diikuti oleh seksi: konstanta string (string_ids), tipe (type_ids), prototipe metode (proto_ids), field (field_ids), metode (method_ids), definisi kelas (class_defs) dan area data (data).

Utilitas dx mengonversi file Java class menjadi satu atau beberapa file DEX. Algoritma kerja mencakup deduplikasi konstanta — string atau tipe yang identik disimpan sekali dan dirujuk melalui indeks. Ini secara signifikan mengurangi ukuran akhir. Dalam proyek modern, dx telah digantikan oleh D8 (muncul di Android Studio 3.1), yang bekerja 2–3 kali lebih cepat dan mendukung desugaring Java 8.

// Contoh DEX-bytecode yang didekompilasi melalui dexdump
// Kode sumber: return a + b;
@Ldalvik/annotation/Code;
    registers: 3
    add-int v0, v1, v2
    return v0

Multi-dex: mengatasi batas 65536

Batasan format DEX hingga 65536 metode (batas indeks 16-bit) menjadi masalah serius untuk aplikasi besar. Solusinya muncul di Android 5.0: dukungan untuk multi-dex memungkinkan aplikasi berisi beberapa file DEX. File utama classes.dex berisi titik masuk, dan file tambahan classes2.dex, classes3.dex dan seterusnya berisi kode lainnya. Konfigurasi multi-dex diaktifkan di build.gradle dengan baris multiDexEnabled true.

Manajemen memori dan pengumpulan sampah

Pengumpulan sampah di Dalvik diimplementasikan sebagai pengumpul generasional (generational) dengan penandaan dan pembersihan (mark-and-sweep). Memori dibagi menjadi dua area utama: Heap (tumpukan) untuk objek dan Stack (tumpukan) untuk primitif dan referensi. Saat Heap penuh, Dalvik menghentikan semua utas (STW — Stop-The-World), menandai objek yang dapat dijangkau, dan membebaskan yang tidak dapat dijangkau.

Hingga Android 2.2, Dalvik menggunakan pengumpul utas tunggal dengan jeda hingga 100–200 ms. Di Android 2.3 Gingerbread muncul pengumpul konkuren, mengurangi jeda tipikal menjadi 5–10 ms. Dan di Android 4.0 Ice Cream Sandwich ditambahkan pengumpul dengan pembersihan inkremental — Concurrent Mark and Sweep (CMS).

Kebocoran memori

Masalah tipikal aplikasi Dalvik — kebocoran memori melalui referensi statis ke Activity. Jika field statis menyimpan referensi ke Context atau View, pengumpul sampah tidak dapat membebaskan Activity bahkan setelah layar ditutup. Alat seperti Eclipse MAT dan LeakCanary membantu mendeteksi kebocoran semacam itu: mereka menganalisis dump Heap dan menunjukkan rantai referensi yang menahan objek.

// Contoh kebocoran memori melalui referensi statis
public class Utils {
    private static Context context;

    public static void init(Context ctx) {
        context = ctx; // Menahan Activity setelah finish()
    }
}

Keterbatasan Dalvik dan transisi ke ART

Meskipun sukses, Dalvik memiliki sejumlah kekurangan. Kompilasi JIT membutuhkan waktu untuk pemanasan — detik-detik pertama aplikasi berjalan lebih lambat. Selain itu, JIT mengonsumsi energi prosesor selama kompilasi, yang memperpendek masa pakai baterai. Dengan meningkatnya kinerja perangkat seluler dan bertambahnya kapasitas memori internal, kebutuhan akan JIT berkurang.

Di Android 4.4 KitKat, Google memperkenalkan ART (Android Runtime) sebagai pengganti eksperimental untuk Dalvik. Mulai Android 5.0 Lollipop, ART menjadi satu-satunya lingkungan runtime. Perbedaan utama — kompilasi AOT: alih-alih kompilasi saat runtime, semua aplikasi dikompilasi ke kode mesin saat instalasi. Ini menghilangkan penundaan pemanasan dan meningkatkan efisiensi energi.

Kompatibilitas mundur

Transisi dari Dalvik ke ART transparan bagi pengembang: kedua lingkungan menjalankan DEX-bytecode yang sama. Aplikasi yang dibangun untuk Dalvik berjalan di ART tanpa kompilasi ulang — system_server mengompilasinya ke kode native saat instalasi. Pengecualian adalah kode yang menggunakan refleksi untuk mengakses anggota internal Dalvik VM: kode semacam itu bisa rusak di ART karena perubahan arsitektur internal.