DEX: co to jest, struktura i zasada działania bajtkodu

Co to jest DEX i do czego służy

DEX (Dalvik Executable) to format bajtkodu zaprojektowany specjalnie dla urządzeń mobilnych Android. W przeciwieństwie do standardowego bajtkodu Java (pliki .class), DEX jest zoptymalizowany pod kątem ograniczonych zasobów: mniej pamięci, mniejszy rozmiar i szybsze ładowanie klas.

Od Java do DEX

Kod źródłowy w Java lub Kotlin jest kompilowany przez javac/kotlinc do standardowych plików .class (bajtkod Java). Następnie narzędzie d8 (lub wcześniej dx) konwertuje .class na jeden lub kilka plików DEX. Ta konwersja to nie zwykłe przepakowanie — d8 wykonuje optymalizacje: łączy pulę stałych, przepisuje instrukcje do architektury rejestrowej i usuwa zduplikowane dane.

Cechy architektoniczne

DEX wykorzystuje architekturę rejestrową (w przeciwieństwie do stosowej JVM). Każda metoda ma stałą liczbę rejestrów (do 65536). Instrukcje DEX są krótsze — średnio 2 bajty wobec 1–4 bajtów w JVM. Daje to bardziej kompaktowy kod: typowa aplikacja zmniejsza się z 10–15 MB .class do 4–6 MB .dex.

Struktura pliku DEX: sekcje i nagłówek

Plik DEX ma ściśle określoną binarną strukturę. Każdy plik zaczyna się od nagłówka i zawiera kilka sekcji, które odwołują się do siebie poprzez przesunięcia.

Nagłówek DEX

Magiczna liczba DEX — `dex\n035\0` (wersja 035). Inne wersje: 036, 037, 038 (dla Androida 8.0+). Nagłówek o rozmiarze 0x70 bajtów zawiera sumę kontrolną SHA-1 i przesunięcia wszystkich sekcji. Walidacja nagłówka — pierwszy krok przy ładowaniu DEX przez maszynę wirtualną.

Pule stałych

string_ids, type_ids, proto_ids, field_ids, method_ids — to indeksowane tabele. Zamiast przechowywania pełnych nazw w kodzie metody używany jest 4-bajtowy indeks. To kluczowa optymalizacja: jeśli klasa jest wymieniana 100 razy, jej nazwa jest przechowywana raz w string_ids. dex2oat podczas kompilacji ART dodatkowo optymalizuje te tabele.

Proces kompilacji Java i Kotlin do DEX

Proces przekształcania kodu źródłowego w DEX składa się z kilku etapów. Nowoczesny łańcuch używa kompilatora D8, który zastąpił DX w 2018 roku wraz z Android Gradle Plugin 3.2.

Etap 1: Kompilacja do .class

javac (dla Java) lub kotlinc (dla Kotlin) kompilują kod źródłowy do plików .class. Każda klasa — osobny plik .class w bajtkodzie Java. Na tym etapie wykonywane jest sprawdzanie typów, generowanie metod bridge i osadzanie stałych.

Etap 2: Kompilacja D8

D8 przyjmuje wszystkie pliki .class i przekształca je w bajtkod DEX. D8 wykonuje kilka optymalizacji: usuwa nieużywane argumenty metod, łączy pule stałych z różnych .class w jedną globalną pulę DEX, konwertuje instrukcje stosowe JVM na rejestrowe instrukcje Dalvik.

// Kod źródłowy Kotlin
data class User(
    val name: String,
    val email: String
)

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

Po kompilacji D8 ten kod zamienia się w kompaktowe instrukcje DEX: const-string do załadowania ciągu, iget-object do dostępu do pola obiektu, invoke-virtual do wywołania StringBuilder.append.

D8 vs DX

D8 działa 2–3 razy szybciej niż DX, generuje bardziej kompaktowy DEX (o 5–10%) i lepiej optymalizuje konstrukcje specyficzne dla Kotlin (funkcje inline, lambda). DX został oznaczony jako deprecated od 2018 roku i usunięty z Android Gradle Plugin 8.0.

Dalvik vs ART: jak zmieniło się wykonywanie DEX

Wykonywanie kodu DEX w Androidzie przeszło dwa etapy: oryginalna maszyna wirtualna Dalvik (Android 2.2–4.4) i Android Runtime ART (Android 5.0+). Różnica w podejściu do kompilacji jest kardynalna.

Dalvik VM: kompilacja JIT

Dalvik używała kompilacji Just-In-Time (JIT): bajtkod DEX był interpretowany, a często wywoływane metody były kompilowane do kodu natywnego na bieżąco. Plus — szybka instalacja. Minus — wolniejszy start i stałe obciążenie CPU przez JIT.

ART: kompilacja AOT

ART (Android Runtime) kompiluje DEX do kodu natywnego podczas instalacji aplikacji przez dex2oat. To podejście Ahead-Of-Time (AOT): instalacja trwa dłużej, ale uruchomienie jest szybsze i zużycie energii mniejsze. Od Androida 7.0 ART używa hybrydowego podejścia — AOT + JIT + Profile Guided Optimization.

dex2oat: konwersja podczas instalacji

Narzędzie dex2oat uruchamia się podczas instalacji lub aktualizacji aplikacji. Kompiluje DEX do pliku ELF z kodem natywnym dla architektury urządzenia. Rezultat — pliki .oat i .art w katalogu /data/dalvik-cache/. Google stale ulepsza dex2oat: w Androidzie 14 dodano optymalizację dla urządzeń składanych.

Multidex: przezwyciężenie limitu 64K metod

Ograniczenie do 65536 metod na jeden plik DEX — pozostałość po architekturze Dalvik. Pole method_ids w nagłówku DEX zajmuje 4 bajty, co daje maksymalnie 2^16 = 65536 unikalnych odwołań. Nowoczesne aplikacje z Google Play Services, Firebase i innymi SDK łatwo przekraczają ten limit.

Mechanizm Multidex

Multidex — to mechanizm podziału kodu na kilka plików DEX. Główny classes.dex zawiera punkty wejścia (klasę Application, główne Activity), pozostałe — classes2.dex, classes3.dex i tak dalej. Podczas uruchamiania klasy z dodatkowych DEX są ładowane przez DexClassLoader.

// build.gradle.kts — włączenie multidex
android {
    defaultConfig {
        multiDexEnabled = true
    }
}

// Klasa Application z obsługą multidex
class MyApp : Application() {
    override fun attachBaseContext(base: Context) {
        super.attachBaseContext(base)
        MultiDex.install(this)
    }
}

Problemy Multidex

Ładowanie dodatkowych DEX na etapie startu aplikacji może powodować ANR (Application Not Responding) na urządzeniach z Androidem do 5.0. Zalecenie — używać multidex tylko w razie konieczności i minimalizować zależności, aby nie przekraczać limitu.

Optymalizacja DEX: ProGuard, R8 i zaciemnianie

Optymalizacja DEX — standardowy etap budowania wersji release aplikacji Android. Narzędzia R8 i ProGuard zmniejszają rozmiar DEX, zaciemniają kod i usuwają nieużywane klasy.

R8 vs ProGuard

R8 — następca ProGuarda, wbudowany w Android Gradle Plugin od 2019 roku. R8 wykonuje minifikację, zaciemnianie i optymalizację w jednym przejściu, podczas gdy ProGuard wymagał dwóch etapów: ProGuard → D8. ProGuard jest nadal wspierany, ale Google zaleca R8 dla nowych projektów.

R8 usuwa nieużywane klasy, metody i pola, zmienia ich nazwy na krótkie (a, b, c), osadza funkcje inline i wyrzuca martwy kod. Rezultat — DEX zmniejsza się o 20–40% bez utraty funkcjonalności.

Reguły R8

Konfiguracja R8 jest zadawana w pliku proguard-rules.pro. Deweloper może wskazać, których klas nie wolno zmieniać (na przykład dla refleksji lub serializacji Gson). Firebase i inne SDK dostarczają własne reguły w swoich zależnościach.

Dekomplacja DEX: narzędzia i ochrona

DEX można dekompilować z powrotem do kodu Java. To kluczowe zagadnienie bezpieczeństwa aplikacji Android: bez zaciemniania kod jest odtwarzany do poziomu bliskiego oryginałowi.

Narzędzia dekompilacji

JADX — najpopularniejszy dekompilator DEX do Java. Odtwarza nazwy klas, metody, pola i większość logiki. apktool dekompiluje DEX do kodu smali (asembler Dalvik) — niskopoziomową reprezentację bliską oryginalnym instrukcjom. Bytecode Viewer łączy kilka dekompilatorów w jednym interfejsie.

Metody ochrony

Zaciemnianie R8/ProGuard — pierwsza linia obrony: nazwy klas i metod stają się nieczytelne. DexGuard — komercyjne narzędzie z dodatkowymi metodami: szyfrowanie ciągów, sprawdzanie integralności, anty-tamper. Obfuscation na poziomie Control Flow (O-LLVM) zmienia strukturę kodu, zachowując jego funkcjonalność, ale znacznie utrudniając analizę.