DEX: apa itu, struktur dan prinsip kerja bytecode

Apa itu DEX dan mengapa diperlukan

DEX (Dalvik Executable) adalah format bytecode yang dirancang khusus untuk perangkat seluler Android. Tidak seperti bytecode Java standar (file .class), DEX dioptimalkan untuk sumber daya terbatas: memori lebih sedikit, ukuran lebih kecil, dan pemuatan kelas lebih cepat.

Dari Java ke DEX

Kode sumber dalam Java atau Kotlin dikompilasi oleh javac/kotlinc menjadi file .class standar (bytecode Java). Kemudian alat d8 (atau sebelumnya dx) mengonversi .class menjadi satu atau beberapa file DEX. Konversi ini bukan sekadar pengepakan ulang — d8 melakukan optimasi: menggabungkan pool konstanta, menulis ulang instruksi ke arsitektur register, dan menghapus data duplikat.

Fitur arsitektur

DEX menggunakan arsitektur register (berlawanan dengan arsitektur stack JVM). Setiap metode memiliki jumlah register tetap (hingga 65536). Instruksi DEX lebih pendek — rata-rata 2 byte dibandingkan 1–4 byte di JVM. Ini menghasilkan kode yang lebih ringkas: aplikasi tipikal berkurang dari 10–15 MB .class menjadi 4–6 MB .dex.

Struktur file DEX: bagian dan header

File DEX memiliki struktur biner yang ditentukan secara ketat. Setiap file dimulai dengan header dan berisi beberapa bagian yang saling merujuk melalui offset.

Header DEX

Angka ajaib DEX — `dex\n035\0` (versi 035). Versi lain: 036, 037, 038 (untuk Android 8.0+). Header berukuran 0x70 byte berisi checksum SHA-1 dan offset semua bagian. Validasi header — langkah pertama saat memuat DEX oleh mesin virtual.

Pool konstanta

string_ids, type_ids, proto_ids, field_ids, method_ids — adalah tabel yang diindeks. Alih-alih menyimpan nama lengkap dalam kode metode, indeks 4-byte digunakan. Ini adalah optimasi kunci: jika sebuah kelas disebut 100 kali, namanya disimpan satu kali di string_ids. dex2oat saat kompilasi ART lebih lanjut mengoptimalkan tabel-tabel ini.

Proses kompilasi Java dan Kotlin ke DEX

Proses transformasi kode sumber menjadi DEX terdiri dari beberapa tahap. Rantai modern menggunakan kompiler D8, yang menggantikan DX pada tahun 2018 dengan Android Gradle Plugin 3.2.

Tahap 1: Kompilasi ke .class

javac (untuk Java) atau kotlinc (untuk Kotlin) mengkompilasi kode sumber menjadi file .class. Setiap kelas — file .class terpisah dalam bytecode Java. Pada tahap ini dilakukan pemeriksaan tipe, pembuatan metode bridge, dan penanaman konstanta.

Tahap 2: Kompilasi D8

D8 menerima semua file .class dan mengubahnya menjadi bytecode DEX. D8 melakukan beberapa optimasi: menghapus argumen metode yang tidak digunakan, menggabungkan pool konstanta dari berbagai .class menjadi satu pool DEX global, mengonversi instruksi stack JVM menjadi instruksi register Dalvik.

// Kode sumber Kotlin
data class User(
    val name: String,
    val email: String
)

fun greet(user: User): String {
    return "Hello, ${user.name}!"
}

Setelah kompilasi D8, kode ini berubah menjadi instruksi DEX yang ringkas: const-string untuk memuat string, iget-object untuk mengakses field objek, invoke-virtual untuk memanggil StringBuilder.append.

D8 vs DX

D8 bekerja 2–3 kali lebih cepat dari DX, menghasilkan DEX yang lebih ringkas (5–10%) dan lebih mengoptimalkan konstruksi spesifik Kotlin (fungsi inline, lambda). DX dinyatakan deprecated sejak 2018 dan dihapus dari Android Gradle Plugin 8.0.

Dalvik vs ART: bagaimana eksekusi DEX berubah

Eksekusi kode DEX di Android telah melalui dua tahap: mesin virtual Dalvik asli (Android 2.2–4.4) dan Android Runtime ART (Android 5.0+). Perbedaan dalam pendekatan kompilasi sangat mendasar.

Dalvik VM: kompilasi JIT

Dalvik menggunakan kompilasi Just-In-Time (JIT): bytecode DEX diinterpretasikan, dan metode yang sering dipanggil dikompilasi ke kode native dengan cepat. Kelebihan — instalasi cepat. Kekurangan — startup lebih lambat dan beban CPU konstan untuk JIT.

ART: kompilasi AOT

ART (Android Runtime) mengkompilasi DEX ke kode native saat instalasi aplikasi melalui dex2oat. Ini adalah pendekatan Ahead-Of-Time (AOT): instalasi lebih lama, tetapi startup lebih cepat dan konsumsi daya lebih rendah. Sejak Android 7.0 ART menggunakan pendekatan hibrida — AOT + JIT + Profile Guided Optimization.

dex2oat: konversi saat instalasi

Alat dex2oat dijalankan saat instalasi atau pembaruan aplikasi. Ia mengkompilasi DEX menjadi file ELF dengan kode native untuk arsitektur perangkat. Hasilnya — file .oat dan .art di direktori /data/dalvik-cache/. Google terus meningkatkan dex2oat: pada Android 14 ditambahkan optimasi untuk perangkat lipat.

Multidex: mengatasi batas 64K metode

Batas 65536 metode per satu file DEX — warisan dari arsitektur Dalvik. Field method_ids di header DEX memakan 4 byte, yang memberikan maksimum 2^16 = 65536 referensi unik. Aplikasi modern dengan Google Play Services, Firebase, dan SDK lain dengan mudah melampaui batas ini.

Mekanisme Multidex

Multidex adalah mekanisme pembagian kode menjadi beberapa file DEX. File utama classes.dex berisi titik masuk (kelas Application, Activity utama), sisanya — classes2.dex, classes3.dex dan seterusnya. Saat startup, kelas dari DEX tambahan dimuat melalui DexClassLoader.

// build.gradle.kts — mengaktifkan multidex
android {
    defaultConfig {
        multiDexEnabled = true
    }
}

// Kelas Application dengan dukungan multidex
class MyApp : Application() {
    override fun attachBaseContext(base: Context) {
        super.attachBaseContext(base)
        MultiDex.install(this)
    }
}

Masalah Multidex

Pemuatan DEX tambahan pada tahap startup aplikasi dapat menyebabkan ANR (Application Not Responding) pada perangkat dengan Android hingga 5.0. Rekomendasi — gunakan multidex hanya jika diperlukan dan minimalkan dependensi agar tidak melampaui batas.

Optimasi DEX: ProGuard, R8 dan obfuskasi

Optimasi DEX — tahap standar pembuatan versi rilis aplikasi Android. Alat R8 dan ProGuard mengurangi ukuran DEX, mengobfus kasi kode, dan menghapus kelas yang tidak digunakan.

R8 vs ProGuard

R8 — penerus ProGuard, terintegrasi dalam Android Gradle Plugin sejak 2019. R8 melakukan minifikasi, obfuskasi, dan optimasi dalam satu lintasan, sedangkan ProGuard memerlukan dua tahap: ProGuard → D8. ProGuard masih didukung, tetapi Google merekomendasikan R8 untuk proyek baru.

R8 menghapus kelas, metode, dan field yang tidak digunakan, mengganti namanya dengan nama pendek (a, b, c), menanam fungsi inline, dan membuang kode mati. Hasilnya — DEX berkurang 20–40% tanpa kehilangan fungsionalitas.

Aturan R8

Konfigurasi R8 ditentukan dalam file proguard-rules.pro. Pengembang dapat menentukan kelas mana yang tidak boleh diganti namanya (misalnya, untuk refleksi atau serialisasi Gson). Firebase dan SDK lain menyediakan aturan mereka sendiri dalam dependensi mereka.

Dekompilasi DEX: alat dan perlindungan

DEX dapat didekompilasi kembali menjadi kode Java. Ini adalah masalah keamanan utama aplikasi Android: tanpa obfuskasi, kode dipulihkan hingga tingkat yang mendekati aslinya.

Alat dekompilasi

JADX — dekompiler DEX ke Java yang paling populer. Ia memulihkan nama kelas, metode, field, dan sebagian besar logika. apktool mendekompilasi DEX menjadi kode smali (assembler Dalvik) — representasi tingkat rendah yang dekat dengan instruksi asli. Bytecode Viewer menggabungkan beberapa dekompiler dalam satu antarmuka.

Metode perlindungan

Obfuskasi R8/ProGuard — garis pertahanan pertama: nama kelas dan metode menjadi tidak terbaca. DexGuard — alat komersial dengan metode tambahan: enkripsi string, pemeriksaan integritas, anti-tamper. Obfuskasi pada tingkat Control Flow (O-LLVM) mengubah struktur kode, mempertahankan fungsionalitasnya, tetapi membuat analisis jauh lebih sulit.