DEX: ano ito, istraktura at prinsipyo ng bytecode

Ano ang DEX at bakit ito kailangan

DEX (Dalvik Executable) ay isang bytecode format na espesyal na idinisenyo para sa Android mobile devices. Hindi tulad ng standard na Java bytecode (.class files), ang DEX ay optimized para sa limitadong resources: mas kaunting memory, mas maliit na sukat, at mas mabilis na pag-load ng mga klase.

Mula Java papuntang DEX

Ang source code sa Java o Kotlin ay nico-compile ng javac/kotlinc sa standard na .class files (Java bytecode). Pagkatapos, ang tool na d8 (o dati ay dx) ay nagco-convert ng .class sa isa o maramihang DEX files. Ang conversion na ito ay hindi simpleng repackaging — gumagawa ang d8 ng mga optimization: pinagsasama ang constant pools, nire-rewrite ang mga instruction sa register architecture, at nagtatanggal ng mga duplicate na data.

Mga tampok ng arkitektura

Gumagamit ang DEX ng register architecture (salungat sa stack-based na JVM). Ang bawat method ay may fixed na bilang ng registers (hanggang 65536). Mas maikli ang DEX instructions — average na 2 bytes kumpara sa 1–4 bytes sa JVM. Ito ay nagbibigay ng mas compact na code: ang tipikal na application ay bumababa mula 10–15 MB .class tungo sa 4–6 MB .dex.

Istraktura ng DEX file: mga seksyon at header

Ang DEX file ay may mahigpit na tinukoy na binary structure. Bawat file ay nagsisimula sa header at naglalaman ng ilang seksyon na nagre-reference sa isa't isa sa pamamagitan ng offsets.

Header ng DEX

Ang magic number ng DEX — `dex\n035\0` (bersyon 035). Iba pang bersyon: 036, 037, 038 (para sa Android 8.0+). Ang header na may sukat na 0x70 bytes ay naglalaman ng SHA-1 checksum at offsets ng lahat ng seksyon. Ang validation ng header — unang hakbang sa pag-load ng DEX ng virtual machine.

Constant pools

Ang string_ids, type_ids, proto_ids, field_ids, method_ids — ay mga naka-index na talaan. Sa halip na mag-imbak ng buong pangalan sa code ng method, ginagamit ang 4-byte na index. Ito ang pangunahing optimization: kung ang isang klase ay binanggit ng 100 beses, ang pangalan nito ay iniimbak nang isang beses sa string_ids. dex2oat sa compilation ng ART ay karagdagang nag-o-optimize ng mga talaang ito.

Proseso ng compilation ng Java at Kotlin papuntang DEX

Ang proseso ng pagbabago ng source code sa DEX ay binubuo ng ilang yugto. Ang modernong chain ay gumagamit ng D8 compiler, na pumalit sa DX noong 2018 kasama ang Android Gradle Plugin 3.2.

Yugto 1: Compilation sa .class

javac (para sa Java) o kotlinc (para sa Kotlin) ay nagco-compile ng source code sa .class files. Bawat klase — hiwalay na .class file sa Java bytecode. Sa yugtong ito, ginagawa ang type checking, pagbuo ng bridge methods, at pag-embed ng constants.

Yugto 2: D8 compilation

D8 ay tumatanggap ng lahat ng .class files at ginagawa itong DEX bytecode. Gumagawa ang D8 ng ilang optimization: nagtatanggal ng hindi ginagamit na method arguments, pinagsasama ang constant pools mula sa iba't ibang .class sa iisang global DEX pool, nagco-convert ng JVM stack instructions sa Dalvik register instructions.

// Kotlin source code
data class User(
    val name: String,
    val email: String
)

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

Pagkatapos ng D8 compilation, ang code na ito ay nagiging compact na DEX instructions: const-string para mag-load ng string, iget-object para ma-access ang field ng object, invoke-virtual para tawagin ang StringBuilder.append.

D8 vs DX

D8 ay 2–3 beses na mas mabilis kaysa sa DX, gumagawa ng mas compact na DEX (5–10%) at mas mahusay na nag-o-optimize ng Kotlin-specific constructs (inline functions, lambda). Ang DX ay idineklarang deprecated mula 2018 at tinanggal mula sa Android Gradle Plugin 8.0.

Dalvik vs ART: paano nagbago ang pag-execute ng DEX

Ang pag-execute ng DEX code sa Android ay dumaan sa dalawang yugto: ang orihinal na Dalvik virtual machine (Android 2.2–4.4) at Android Runtime ART (Android 5.0+). Ang pagkakaiba sa approach sa compilation ay malaki.

Dalvik VM: JIT compilation

Dalvik ay gumamit ng Just-In-Time (JIT) compilation: ang DEX bytecode ay ini-interpret, at ang madalas na tinatawag na method ay nico-compile sa native code on-the-fly. Bentahe — mabilis na pag-install. Disbentahe — mas mabagal na startup at patuloy na CPU load para sa JIT.

ART: AOT compilation

ART (Android Runtime) ay nagco-compile ng DEX sa native code kapag ini-install ang application sa pamamagitan ng dex2oat. Ito ay Ahead-Of-Time (AOT) approach: mas matagal ang pag-install, ngunit mas mabilis ang startup at mas mababa ang energy consumption. Mula Android 7.0, ang ART ay gumagamit ng hybrid approach — AOT + JIT + Profile Guided Optimization.

dex2oat: conversion kapag nag-install

Ang tool na dex2oat ay tumatakbo kapag nag-i-install o nag-a-update ng application. Ito ay nagco-compile ng DEX sa ELF file na may native code para sa architecture ng device. Resulta — .oat at .art files sa direktoryo /data/dalvik-cache/. Google ay patuloy na pinapabuti ang dex2oat: sa Android 14 ay idinagdag ang optimization para sa mga foldable device.

Multidex: paglampas sa limitasyon ng 64K method

Ang limitasyon ng 65536 method sa isang DEX file — legacy mula sa Dalvik architecture. Ang field na method_ids sa header ng DEX ay sumasakop ng 4 bytes, na nagbibigay ng maximum na 2^16 = 65536 na unique na reference. Ang mga modernong application na may Google Play Services, Firebase, at iba pang SDK ay madaling lumampas sa limitasyong ito.

Mekanismo ng Multidex

Multidex ay isang mekanismo ng paghahati ng code sa maraming DEX files. Ang pangunahing classes.dex ay naglalaman ng entry points (Application class, pangunahing Activity), ang iba — classes2.dex, classes3.dex at iba pa. Sa startup, ang mga klase mula sa karagdagang DEX ay nilo-load sa pamamagitan ng DexClassLoader.

// build.gradle.kts — pag-enable ng multidex
android {
    defaultConfig {
        multiDexEnabled = true
    }
}

// Application class na may suporta sa multidex
class MyApp : Application() {
    override fun attachBaseContext(base: Context) {
        super.attachBaseContext(base)
        MultiDex.install(this)
    }
}

Mga problema sa Multidex

Ang pag-load ng karagdagang DEX sa yugto ng startup ay maaaring magdulot ng ANR (Application Not Responding) sa mga device na may Android hanggang 5.0. Rekomendasyon — gamitin lamang ang multidex kung kinakailangan at i-minimize ang dependencies upang hindi lumampas sa limitasyon.

Optimization ng DEX: ProGuard, R8 at obfuscation

Optimization ng DEX — standard na yugto ng pagbuo ng release version ng Android application. Ang mga tool na R8 at ProGuard ay nagpapaliit ng DEX, nag-o-obfuscate ng code, at nagtatanggal ng hindi ginagamit na mga klase.

R8 vs ProGuard

R8 — kahalili ng ProGuard, naka-embed sa Android Gradle Plugin mula 2019. Ginagawa ng R8 ang minification, obfuscation, at optimization sa isang pass, samantalang ang ProGuard ay nangangailangan ng dalawang yugto: ProGuard → D8. ProGuard ay suportado pa rin, ngunit inirerekomenda ng Google ang R8 para sa mga bagong proyekto.

Tinatanggal ng R8 ang hindi ginagamit na mga klase, method, at field, pinapalitan ang kanilang mga pangalan ng maiikling pangalan (a, b, c), ini-embed ang inline functions, at itinatapon ang dead code. Resulta — ang DEX ay nababawasan ng 20–40% nang walang pagkawala ng functionality.

Mga panuntunan ng R8

Ang configuration ng R8 ay itinakda sa file na proguard-rules.pro. Maaaring tukuyin ng developer kung aling mga klase ang hindi dapat palitan ng pangalan (halimbawa, para sa reflection o Gson serialization). Firebase at iba pang SDK ay nagbibigay ng sarili nilang mga panuntunan sa kanilang mga dependencies.

Decompilation ng DEX: mga tool at proteksyon

Ang DEX ay maaaring i-decompile pabalik sa Java code. Ito ay pangunahing isyu sa seguridad ng Android applications: walang obfuscation, ang code ay naibabalik sa antas na malapit sa orihinal.

Mga tool sa decompilation

JADX — ang pinakasikat na decompiler ng DEX papuntang Java. Ito ay nagpapanumbalik ng mga pangalan ng klase, method, field, at karamihan sa logic. apktool ay nagde-decompile ng DEX sa smali code (Dalvik assembler) — low-level na representasyon na malapit sa orihinal na mga instruction. Bytecode Viewer ay pinagsasama ang ilang decompiler sa isang interface.

Mga paraan ng proteksyon

Obfuscation ng R8/ProGuard — unang linya ng depensa: ang mga pangalan ng klase at method ay nagiging hindi nababasa. DexGuard — komersyal na tool na may karagdagang pamamaraan: encryption ng string, integrity check, anti-tamper. Obfuscation sa antas ng Control Flow (O-LLVM) ay nagbabago sa structure ng code, pinapanatili ang functionality nito, ngunit pinapahirap ang analysis.