DEX: bu nədir, bayt-kodun strukturu və iş prinsipi

DEX nədir və nə üçün lazımdır

DEX (Dalvik Executable) — xüsusi olaraq Android mobil cihazları üçün hazırlanmış bayt-kod formatıdır. Standart Java bayt-kodundan (.class faylları) fərqli olaraq, DEX məhdud resurslar üçün optimallaşdırılıb: az yaddaş, kiçik ölçü və daha sürətli sinif yükləmə.

Java-dan DEX-ə

Java və ya Kotlin-də mənbə kodu javac/kotlinc tərəfindən standart .class fayllarına (Java bayt-kodu) kompilyasiya olunur. Sonra d8 aləti (və ya əvvəllər dx) .class fayllarını bir və ya bir neçə DEX faylına çevirir. Bu çevirmə sadə qablaşdırma deyil — d8 optimallaşdırmalar həyata keçirir: sabit hovuzlarını birləşdirir, təlimatları registr arxitekturasına yazır və təkrarlanan məlumatları silir.

Arxitektura xüsusiyyətləri

DEX registr arxitekturasından istifadə edir (JVM-in yığın arxitekturasından fərqli olaraq). Hər metodun sabit sayda registri var (65536-dək). DEX təlimatları daha qısadır — orta hesabla 2 bayt, JVM-də isə 1–4 bayt. Bu daha yığcam kod verir: tipik tətbiq 10–15 MB .class-dan 4–6 MB .dex-ə qədər azalır.

DEX faylının strukturu: bölmələr və başlıq

DEX faylı ciddi şəkildə müəyyən edilmiş ikili struktura malikdir. Hər fayl başlıqla başlayır və bir-birinə ofsetlər vasitəsilə istinad edən bir neçə bölmə ehtiva edir.

DEX başlığı

Sehrli DEX ədədi — `dex\n035\0` (versiya 035). Digər versiyalar: 036, 037, 038 (Android 8.0+ üçün). 0x70 bayt ölçüsündə başlıq SHA-1 yoxlama məbləği və bütün bölmələrin ofsetlərini ehtiva edir. Başlığın validasiyası — virtual maşın tərəfindən DEX yüklənərkən ilk addımdır.

Sabit hovuzları

string_ids, type_ids, proto_ids, field_ids, method_ids — indeksləşdirilmiş cədvəllərdir. Metod kodunda tam adların saxlanması əvəzinə 4-baytlı indeks istifadə olunur. Bu əsas optimallaşdırmadır: sinif 100 dəfə qeyd olunursa, onun adı string_ids-də bir dəfə saxlanılır. dex2oat ART kompilyasiyası zamanı bu cədvəlləri əlavə optimallaşdırır.

Java və Kotlin-in DEX-ə kompilyasiya prosesi

Proses mənbə kodunun DEX-ə çevrilməsi bir neçə mərhələdən ibarətdir. Müasir zəncir 2018-ci ildə Android Gradle Plugin 3.2 ilə DX-i əvəz edən D8 kompilyatorundan istifadə edir.

Mərhələ 1: .class-a kompilyasiya

javac (Java üçün) və ya kotlinc (Kotlin üçün) mənbə kodunu .class fayllarına kompilyasiya edir. Hər sinif — Java bayt-kodunda ayrıca .class faylı. Bu mərhələdə tip yoxlaması, körpü metodlarının yaradılması və sabitlərin yerləşdirilməsi həyata keçirilir.

Mərhələ 2: D8 kompilyasiyası

D8 bütün .class fayllarını qəbul edir və onları DEX bayt-koduna çevirir. D8 bir neçə optimallaşdırma həyata keçirir: istifadə olunmayan metod arqumentlərini silir, müxtəlif .class fayllarından sabit hovuzlarını bir qlobal DEX hovuzunda birləşdirir, JVM yığın təlimatlarını Dalvik registr təlimatlarına çevirir.

// Kotlin mənbə kodu
data class User(
    val name: String,
    val email: String
)

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

D8 kompilyasiyasından sonra bu kod yığcam DEX təlimatlarına çevrilir: sətir yükləmək üçün const-string, obyekt sahəsinə daxil olmaq üçün iget-object, StringBuilder.append çağırmaq üçün invoke-virtual.

D8 vs DX

D8 DX-dən 2–3 dəfə sürətli işləyir, daha yığcam DEX yaradır (5–10%) və Kotlin-spesifik konstruksiyaları (inline funksiyalar, lambda) daha yaxşı optimallaşdırır. DX 2018-ci ildən deprecated elan edilib və Android Gradle Plugin 8.0-dan silinib.

Dalvik vs ART: DEX-in icrası necə dəyişdi

DEX kodunun Android-də icrası iki mərhələdən keçib: orijinal Dalvik virtual maşını (Android 2.2–4.4) və Android Runtime ART (Android 5.0+). Kompilyasiya yanaşmasında fərq köklüdür.

Dalvik VM: JIT kompilyasiyası

Dalvik Just-In-Time (JIT) kompilyasiyasından istifadə edirdi: DEX bayt-kodu interpretasiya olunur, tez-tez çağırılan metodlar isə nativ koda anında kompilyasiya edilirdi. Üstünlük — sürətli quraşdırma. Çatışmazlıq — daha yavaş başlanğıc və JIT üçün daimi CPU yükü.

ART: AOT kompilyasiyası

ART (Android Runtime) tətbiq quraşdırılması zamanı dex2oat vasitəsilə DEX-i nativ koda kompilyasiya edir. Bu Ahead-Of-Time (AOT) yanaşmasıdır: quraşdırma uzun çəkir, lakin başlanğıc daha sürətli və enerji sərfiyyatı azdır. Android 7.0-dan ART hibrid yanaşma — AOT + JIT + Profile Guided Optimization istifadə edir.

dex2oat: quraşdırma zamanı konversiya

dex2oat aləti tətbiq quraşdırılması və ya yenilənməsi zamanı işə düşür. O, DEX-i cihaz arxitekturası üçün nativ kodla ELF faylına kompilyasiya edir. Nəticə — /data/dalvik-cache/ qovluğunda .oat və .art faylları. Google dex2oat-ı daim təkmilləşdirir: Android 14-də qatlanan cihazlar üçün optimallaşdırma əlavə edilib.

Multidex: 64K metod limitinin aşılması

Bir DEX faylında 65536 metod məhdudiyyəti — Dalvik arxitekturasından qalma mirasdır. DEX başlığında method_ids sahəsi 4 bayt tutur, bu da maksimum 2^16 = 65536 unikal istinad verir. Google Play Services, Firebase və digər SDK-ları olan müasir tətbiqlər bu limiti asanlıqla keçir.

Multidex mexanizmi

Multidex — kodun bir neçə DEX faylına bölünməsi mexanizmidir. Əsas classes.dex giriş nöqtələrini (Application sinifi, əsas Activity) ehtiva edir, qalanları — classes2.dex, classes3.dex və s. İşə salınma zamanı əlavə DEX-lərdən siniflər DexClassLoader vasitəsilə yüklənir.

// build.gradle.kts — multidex-in qoşulması
android {
    defaultConfig {
        multiDexEnabled = true
    }
}

// Multidex dəstəyi ilə Application sinifi
class MyApp : Application() {
    override fun attachBaseContext(base: Context) {
        super.attachBaseContext(base)
        MultiDex.install(this)
    }
}

Multidex problemləri

Əlavə DEX-lərin tətbiq startı mərhələsində yüklənməsi Android 5.0-dək cihazlarda ANR (Application Not Responding) səbəb ola bilər. Tövsiyə — multidex-i yalnız zəruri olduqda istifadə edin və limiti keçməmək üçün asılılıqları minimallaşdırın.

DEX optimallaşdırması: ProGuard, R8 və obfuskasiya

DEX optimallaşdırması — release Android tətbiqi qurulmasının standart mərhələsidir. R8 və ProGuard alətləri DEX ölçüsünü azaldır, kodu obfuskiasiya edir və istifadə olunmayan sinifləri silir.

R8 vs ProGuard

R8 — ProGuard-ın varisi, 2019-cu ildən Android Gradle Plugin-ə daxildir. R8 minifikasiya, obfuskasiya və optimallaşdırmanı bir keçiddə yerinə yetirir, ProGuard isə iki mərhələ tələb edirdi: ProGuard → D8. ProGuard hələ də dəstəklənir, lakin Google yeni layihələr üçün R8-i tövsiyə edir.

R8 istifadə olunmayan sinifləri, metodları və sahələri silir, onların adlarını qısa adlarla (a, b, c) əvəz edir, inline funksiyaları yerləşdirir və ölü kodu atır. Nəticə — DEX funksionallığı itirmədən 20–40% azalır.

R8 qaydaları

R8 konfiqurasiyası proguard-rules.pro faylında verilir. Tərtibatçı hansı siniflərin adlarının dəyişdirilməməsini göstərə bilər (məsələn, refleksiya və ya Gson seriyalaşdırması üçün). Firebase və digər SDK-lar öz asılılıqlarında öz qaydalarını təqdim edir.

DEX dekompilyasiyası: alətlər və qorunma

DEX geri Java koduna dekompilyasiya oluna bilər. Bu Android tətbiqlərinin təhlükəsizliyinin əsas məsələsidir: obfuskasiya olmadan kod orijinala yaxın səviyyədə bərpa olunur.

Dekompilyasiya alətləri

JADX — DEX-in Java-ya ən məşhur dekompilyatoru. Sinif adlarını, metodları, sahələri və logikanın çox hissəsini bərpa edir. apktool DEX-i smali koduna (Dalvik assembler) dekompilyasiya edir — orijinal təlimatlara yaxın aşağı səviyyəli təsvir. Bytecode Viewer bir neçə dekompilyatoru bir interfeysdə birləşdirir.

Qorunma metodları

R8/ProGuard obfuskasiyası — ilk müdafiə xətti: sinif və metod adları oxunmaz olur. DexGuard — əlavə metodlarla kommersiya aləti: sətir şifrələmə, bütövlük yoxlaması, anti-tamper. Control Flow səviyyəsində obfuskasiya (O-LLVM) kodun strukturunu dəyişir, funksionallığı saxlayır, lakin analizi xeyli çətinləşdirir.