DEX: nedir, bayt kodunun yapısı ve çalışma prensibi

DEX Nedir ve Neden Gereklidir

DEX (Dalvik Executable), özellikle Android mobil cihazlar için tasarlanmış bir bayt kodu formatıdır. Standart Java bayt kodundan (.class dosyaları) farklı olarak DEX, sınırlı kaynaklar için optimize edilmiştir: daha az bellek, daha küçük boyut ve daha hızlı sınıf yükleme.

Java'dan DEX'e

Java veya Kotlin dilindeki kaynak kod, javac/kotlinc tarafından standart .class dosyalarına (Java bayt kodu) derlenir. Ardından d8 aracı (veya daha önce dx) .class dosyalarını bir veya daha fazla DEX dosyasına dönüştürür. Bu dönüşüm basit bir yeniden paketleme değildir — d8 optimizasyonlar gerçekleştirir: sabit havuzlarını birleştirme, talimatları kayıt mimarisine yeniden yazma ve yinelenen verileri kaldırma.

Mimari Özellikler

DEX, kayıt tabanlı bir mimari kullanır (yığın tabanlı JVM'nin aksine). Her yöntemin sabit sayıda kaydı vardır (65536'ya kadar). DEX talimatları daha kısadır — ortalama 2 bayt (JVM'de 1–4 bayta karşılık). Bu, daha kompakt kod üretir: tipik bir uygulama 10–15 MB .class'tan 4–6 MB .dex'e düşer.

DEX Dosyasının Yapısı: Bölümler ve Başlık

Bir DEX dosyasının kesin olarak tanımlanmış bir ikili yapısı vardır. Her dosya bir başlıkla başlar ve ofsetler aracılığıyla birbirine referans veren birden çok bölüm içerir.

DEX Başlığı

DEX'in sihirli numarası `dex\n035\0` (sürüm 035) şeklindedir. Diğer sürümler: 036, 037, 038 (Android 8.0+ için). Başlık 0x70 bayt boyutundadır ve bir SHA-1 sağlama toplamı ile tüm bölümlerin ofsetlerini içerir. Sanal makine bir DEX yüklerken ilk adım başlık doğrulamasıdır.

Sabit Havuzları

string_ids, type_ids, proto_ids, field_ids, method_ids — bunlar indekslenmiş tablolardır. Yöntem kodunda tam adları saklamak yerine 4 baytlık bir indeks kullanılır. Bu önemli bir optimizasyondur: bir sınıf 100 kez referans alınırsa, adı string_ids'te bir kez saklanır. dex2oat, ART derlemesi sırasında bu tabloları daha da optimize eder.

Java ve Kotlin'in DEX'e Derlenme Süreci

Kaynak kodunu DEX'e dönüştürme süreci birkaç aşamadan oluşur. Modern araç zinciri, 2018'de Android Gradle Plugin 3.2 ile DX'in yerini alan D8 derleyicisini kullanır.

Aşama 1: .class'a Derleme

javac (Java için) veya kotlinc (Kotlin için), kaynak kodu .class dosyalarına derler. Her sınıf, Java bayt kodunda ayrı bir .class dosyasıdır. Bu aşamada tür denetimi, köprü yöntem oluşturma ve sabit içerme gerçekleştirilir.

Aşama 2: D8 Derlemesi

D8, tüm .class dosyalarını alır ve bunları DEX bayt koduna dönüştürür. D8 birkaç optimizasyon gerçekleştirir: kullanılmayan yöntem argümanlarını kaldırma, farklı .class dosyalarındaki sabit havuzlarını tek bir küresel DEX havuzunda birleştirme ve JVM yığın talimatlarını Dalvik kayıt talimatlarına dönüştürme.

// Kotlin kaynak kodu
data class User(
    val name: String,
    val email: String
)

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

D8 derlemesinden sonra bu kod, kompakt DEX talimatlarına dönüşür: dizeleri yüklemek için const-string, nesne alanına erişmek için iget-object, StringBuilder.append'i çağırmak için invoke-virtual.

D8 vs DX

D8, DX'ten 2–3 kat daha hızlıdır, daha kompakt DEX üretir (%5–10 daha küçük) ve Kotlin'e özgü yapıları (inline fonksiyonlar, lambda) daha iyi optimize eder. DX, 2018'de kullanımdan kaldırıldı ve Android Gradle Plugin 8.0'den kaldırıldı.

Dalvik vs ART: DEX Yürütmesi Nasıl Değişti

Android'de DEX kodunun yürütülmesi iki aşamadan geçti: orijinal Dalvik sanal makinesi (Android 2.2–4.4) ve Android Runtime ART (Android 5.0+). Derleme yaklaşımındaki fark temeldir.

Dalvik VM: JIT Derlemesi

Dalvik, Just-In-Time (JIT) derlemesi kullanıyordu: DEX bayt kodu yorumlanır ve sık çağrılan yöntemler anında yerel koda derlenirdi. Avantaj — hızlı kurulum. Dezavantaj — daha yavaş başlatma ve JIT için sürekli CPU tüketimi.

ART: AOT Derlemesi

ART (Android Runtime), uygulama kurulumu sırasında dex2oat aracılığıyla DEX'i yerel koda derler. Bu bir Ahead-Of-Time (AOT) yaklaşımıdır: kurulum daha uzun sürer, ancak başlatma daha hızlı ve güç tüketimi daha düşüktür. Android 7.0'dan itibaren ART, hibrit bir yaklaşım kullanır — AOT + JIT + Profil Güdümlü Optimizasyon.

dex2oat: Kurulum Sırasında Dönüşüm

dex2oat aracı, bir uygulama kurulduğunda veya güncellendiğinde çalışır. DEX'i cihaz mimarisi için yerel kod içeren bir ELF dosyasına derler. Sonuç — /data/dalvik-cache/ dizininde .oat ve .art dosyaları. Google, dex2oat'ı sürekli olarak iyileştirmektedir: Android 14'te katlanabilir cihazlar için optimizasyonlar eklendi.

Multidex: 64K Yöntem Sınırını Aşmak

DEX dosyası başına 65536 yöntem sınırı, Dalvik mimarisinin bir mirasıdır. DEX başlığındaki method_ids alanı 4 bayt kaplar ve maksimum 2^16 = 65536 benzersiz referans sağlar. Google Play Services, Firebase ve diğer SDK'lara sahip modern uygulamalar bu sınırı kolayca aşar.

Multidex Mekanizması

Multidex, kodu birden çok DEX dosyasına bölmek için bir mekanizmadır. Ana classes.dex, giriş noktalarını (Application sınıfı, ana Activity) içerir, diğerleri classes2.dex, classes3.dex vb. şeklindedir. Başlatma sırasında, ek DEX'lerdeki sınıflar DexClassLoader aracılığıyla yüklenir.

// build.gradle.kts — multidex etkinleştirme
android {
    defaultConfig {
        multiDexEnabled = true
    }
}

// Multidex desteği ile Application sınıfı
class MyApp : Application() {
    override fun attachBaseContext(base: Context) {
        super.attachBaseContext(base)
        MultiDex.install(this)
    }
}

Multidex Sorunları

Uygulama başlatma sırasında ek DEX'lerin yüklenmesi, Android 5.0 öncesi cihazlarda ANR'ye (Application Not Responding) neden olabilir. Öneri — yalnızca gerektiğinde multidex kullanın ve sınırı aşmamak için bağımlılıkları en aza indirin.

DEX Optimizasyonu: ProGuard, R8 ve Karartma

DEX optimizasyonu, bir sürüm Android uygulaması oluşturmanın standart bir adımıdır. R8 ve ProGuard araçları DEX boyutunu azaltır, kodu karartır ve kullanılmayan sınıfları kaldırır.

R8 vs ProGuard

R8, ProGuard'ın halefidir, 2019'dan beri Android Gradle Plugin'e yerleşiktir. R8, tek geçişte küçültme, karartma ve optimizasyon gerçekleştirirken, ProGuard iki aşama gerektiriyordu: ProGuard → D8. ProGuard hâlâ desteklenmektedir, ancak Google yeni projeler için R8'i önermektedir.

R8, kullanılmayan sınıfları, yöntemleri ve alanları kaldırır, bunları kısa adlarla (a, b, c) yeniden adlandırır, işlev içi yöntemleri ekler ve ölü kodu kaldırır. Sonuç — işlevsellik kaybı olmadan DEX %20–40 oranında küçülür.

R8 Kuralları

R8 yapılandırması proguard-rules.pro dosyasında belirtilir. Geliştirici, hangi sınıfların yeniden adlandırılamayacağını belirtebilir (örneğin, yansıma veya Gson serileştirmesi için). Firebase ve diğer SDK'lar, bağımlılıklarında kendi kurallarını sağlar.

DEX Tersine Derleme: Araçlar ve Koruma

DEX, Java koduna geri tersine derlenebilir. Bu, Android uygulamaları için önemli bir güvenlik sorunudur: karartma olmadan, kod orijinaline yakın bir düzeyde geri yüklenir.

Tersine Derleme Araçları

JADX, en popüler DEX'ten Java'ya tersine derleyicidir. Sınıf adlarını, yöntemleri, alanları ve mantığın çoğunu geri yükler. apktool, DEX'i smali koduna (Dalvik assembler) tersine derler — orijinal talimatlara yakın düşük seviyeli bir temsil. Bytecode Viewer, birden çok tersine derleyiciyi tek bir arayüzde birleştirir.

Koruma Yöntemleri

R8/ProGuard ile karartma ilk savunma hattıdır: sınıf ve yöntem adları okunamaz hale gelir. DexGuard, ek yöntemlere sahip ticari bir araçtır: dize şifreleme, bütünlük denetimi, kurcalama önleme. Kontrol Akışı Karartması (O-LLVM), işlevselliği korurken kod yapısını değiştirir ve analizi çok daha zor hale getirir.