DEX: یہ کیا ہے، بائٹ کوڈ کا ڈھانچہ اور کام کرنے کا اصول

DEX کیا ہے اور اس کی ضرورت کیوں ہے

DEX (Dalvik Executable) ایک بائٹ کوڈ فارمیٹ ہے جو خاص طور پر Android موبائل آلات کے لیے ڈیزائن کیا گیا ہے۔ معیاری Java بائٹ کوڈ (.class فائلوں) کے برعکس، DEX محدود وسائل کے لیے موزوں ہے: کم میموری، چھوٹا سائز، اور تیز تر کلاس لوڈنگ۔

Java سے DEX تک

Java یا Kotlin میں سورس کوڈ javac/kotlinc کے ذریعے معیاری .class فائلوں (Java بائٹ کوڈ) میں مرتب کیا جاتا ہے۔ پھر d8 ٹول (یا پہلے dx) .class کو ایک یا زیادہ DEX فائلوں میں تبدیل کرتا ہے۔ یہ تبدیلی محض دوبارہ پیکج کرنا نہیں ہے — d8 اصلاح کرتا ہے: مستقل پولز کو ضم کرنا، ہدایات کو رجسٹر فن تعمیر میں دوبارہ لکھنا، اور ڈپلیکیٹ ڈیٹا کو ہٹانا۔

فن تعمیر کی خصوصیات

DEX رجسٹر پر مبنی فن تعمیر استعمال کرتا ہے (اسٹیک پر مبنی JVM کے برعکس)۔ ہر طریقہ میں رجسٹروں کی ایک مقررہ تعداد ہوتی ہے (65536 تک)۔ DEX ہدایات چھوٹی ہوتی ہیں — اوسطاً 2 بائٹ (JVM میں 1–4 بائٹ کے مقابلے)۔ یہ زیادہ کمپیکٹ کوڈ پیدا کرتا ہے: ایک عام ایپلیکیشن 10–15 MB .class سے گھٹ کر 4–6 MB .dex ہو جاتی ہے۔

DEX فائل کا ڈھانچہ: حصے اور سرخی

DEX فائل کا سختی سے متعین بائنری ڈھانچہ ہوتا ہے۔ ہر فائل ایک سرخی سے شروع ہوتی ہے اور کئی حصوں پر مشتمل ہوتی ہے جو آفسیٹ کے ذریعے ایک دوسرے کا حوالہ دیتے ہیں۔

DEX سرخی

DEX کا جادوئی نمبر `dex\n035\0` (ورژن 035) ہے۔ دوسرے ورژن: 036، 037، 038 (Android 8.0+ کے لیے)۔ سرخی 0x70 بائٹ سائز کی ہوتی ہے اور اس میں SHA-1 چیکسم اور تمام حصوں کے آفسیٹ ہوتے ہیں۔ ورچوئل مشین کے ذریعے DEX لوڈ کرتے وقت سرخی کی تصدیق پہلا مرحلہ ہے۔

مستقل پولز

string_ids، type_ids، proto_ids، field_ids، method_ids — یہ ترتیب شدہ جدولیں ہیں۔ طریقہ کوڈ میں مکمل نام ذخیرہ کرنے کے بجائے، 4 بائٹ کا اشاریہ استعمال کیا جاتا ہے۔ یہ ایک اہم اصلاح ہے: اگر کسی کلاس کا 100 بار حوالہ دیا جائے تو اس کا نام string_ids میں ایک بار ذخیرہ ہوتا ہے۔ dex2oat ART ترجمہ کے دوران ان جدولوں کو مزید بہتر بناتا ہے۔

Java اور Kotlin کا DEX میں ترجمہ کرنے کا عمل

سورس کوڈ کو DEX میں تبدیل کرنے کا عمل کئی مراحل پر مشتمل ہے۔ جدید ٹول چین D8 مرتب کرنے والا استعمال کرتی ہے، جس نے 2018 میں Android Gradle Plugin 3.2 کے ساتھ DX کی جگہ لی۔

مرحلہ 1: .class میں ترجمہ

javac (Java کے لیے) یا kotlinc (Kotlin کے لیے) سورس کوڈ کو .class فائلوں میں مرتب کرتا ہے۔ ہر کلاس Java بائٹ کوڈ میں ایک علیحدہ .class فائل ہے۔ اس مرحلے میں، قسم کی جانچ، برج طریقے بنانا، اور مستقل شامل کرنا کیا جاتا ہے۔

مرحلہ 2: D8 ترجمہ

D8 تمام .class فائلوں کو لے کر انہیں DEX بائٹ کوڈ میں تبدیل کرتا ہے۔ D8 کئی اصلاحیں کرتا ہے: غیر استعمال شدہ طریقہ دلائل ہٹانا، مختلف .class فائلوں سے مستقل پولز کو ایک عالمی DEX پول میں ضم کرنا، اور JVM اسٹیک ہدایات کو Dalvik رجسٹر ہدایات میں تبدیل کرنا۔

// Kotlin سورس کوڈ
data class User(
    val name: String,
    val email: String
)

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

D8 ترجمہ کے بعد، یہ کوڈ کمپیکٹ DEX ہدایات میں بدل جاتا ہے: سٹرنگ لوڈ کرنے کے لیے const-string، آبجیکٹ فیلڈ تک رسائی کے لیے iget-object، StringBuilder.append کو کال کرنے کے لیے invoke-virtual۔

D8 بمقابلہ DX

D8 DX سے 2–3 گنا تیز ہے، زیادہ کمپیکٹ DEX پیدا کرتا ہے (5–10% چھوٹا)، اور Kotlin مخصوص تعمیرات (inline فنکشنز، lambda) کو بہتر طور پر بہتر بناتا ہے۔ DX کو 2018 میں فرسودہ قرار دیا گیا تھا اور Android Gradle Plugin 8.0 سے ہٹا دیا گیا۔

Dalvik بمقابلہ ART: DEX پر عملدرآمد کیسے بدلا

Android میں DEX کوڈ کا عملدرآمد دو مراحل سے گزرا: اصل Dalvik ورچوئل مشین (Android 2.2–4.4) اور Android Runtime ART (Android 5.0+)۔ ترجمہ کرنے کے طریقہ کار میں فرق بنیادی ہے۔

Dalvik VM: JIT ترجمہ

Dalvik Just-In-Time (JIT) ترجمہ استعمال کرتی تھی: DEX بائٹ کوڈ کی تشریح کی جاتی تھی، اور بار بار بلائے جانے والے طریقوں کو موقع پر مقامی کوڈ میں مرتب کیا جاتا تھا۔ فائدہ — تیز تنصیب۔ نقصان — سست آغاز اور JIT کے لیے مسلسل CPU خرچ۔

ART: AOT ترجمہ

ART (Android Runtime) dex2oat کے ذریعے ایپلیکیشن کی تنصیب کے دوران DEX کو مقامی کوڈ میں مرتب کرتا ہے۔ یہ Ahead-Of-Time (AOT) طریقہ ہے: تنصیب میں زیادہ وقت لگتا ہے، لیکن آغاز تیز ہے اور بجلی کی کھپت کم ہے۔ Android 7.0 سے، ART ایک ہائبرڈ طریقہ استعمال کرتا ہے — AOT + JIT + پروفائل گائیڈڈ آپٹیمائزیشن۔

dex2oat: تنصیب کے دوران تبدیلی

dex2oat ٹول ایپلیکیشن کی تنصیب یا اپ ڈیٹ کے وقت چلتا ہے۔ یہ DEX کو ڈیوائس فن تعمیر کے لیے مقامی کوڈ والی ELF فائل میں مرتب کرتا ہے۔ نتیجہ — /data/dalvik-cache/ ڈائریکٹری میں .oat اور .art فائلیں۔ Google مسلسل dex2oat کو بہتر بنا رہا ہے: Android 14 میں فولڈیبل آلات کے لیے اصلاحیں شامل کی گئیں۔

Multidex: 64K طریقوں کی حد کو عبور کرنا

فی DEX فائل 65536 طریقوں کی حد Dalvik فن تعمیر کی وراثت ہے۔ DEX سرخی میں method_ids فیلڈ 4 بائٹ لیتا ہے، جو زیادہ سے زیادہ 2^16 = 65536 منفرد حوالے دیتا ہے۔ Google Play Services، Firebase اور دیگر SDK والی جدید ایپلیکیشنز آسانی سے اس حد کو پار کر جاتی ہیں۔

Multidex طریقہ کار

Multidex کوڈ کو متعدد DEX فائلوں میں تقسیم کرنے کا ایک طریقہ کار ہے۔ مرکزی classes.dex میں داخلے کے مقامات (Application کلاس، مرکزی Activity) ہوتے ہیں، باقی classes2.dex، classes3.dex وغیرہ ہیں۔ آغاز پر، اضافی DEX سے کلاسیں DexClassLoader کے ذریعے لوڈ کی جاتی ہیں۔

// build.gradle.kts — multidex فعال کرنا
android {
    defaultConfig {
        multiDexEnabled = true
    }
}

// Multidex سپورٹ کے ساتھ Application کلاس
class MyApp : Application() {
    override fun attachBaseContext(base: Context) {
        super.attachBaseContext(base)
        MultiDex.install(this)
    }
}

Multidex مسائل

ایپلیکیشن شروع کرنے کے دوران اضافی DEX کی لوڈنگ Android 5.0 سے پہلے کے آلات پر ANR (Application Not Responding) کا سبب بن سکتی ہے۔ سفارش — صرف ضرورت پڑنے پر multidex استعمال کریں اور حد سے تجاوز نہ کرنے کے لیے انحصار کو کم سے کم کریں۔

DEX اصلاح: ProGuard، R8 اور مبہم کاری

DEX کی اصلاح ریلیز Android ایپلیکیشن بنانے کا ایک معیاری مرحلہ ہے۔ R8 اور ProGuard اوزار DEX کا سائز کم کرتے ہیں، کوڈ کو مبہم کرتے ہیں اور غیر استعمال شدہ کلاسز کو ہٹاتے ہیں۔

R8 بمقابلہ ProGuard

R8 ProGuard کا جانشین ہے، 2019 سے Android Gradle Plugin میں شامل ہے۔ R8 ایک ہی پاس میں چھوٹا کرنا، مبہم کرنا اور اصلاح کرتا ہے، جبکہ ProGuard کو دو مراحل کی ضرورت تھی: ProGuard → D8۔ ProGuard اب بھی تعاون یافتہ ہے، لیکن Google نئے منصوبوں کے لیے R8 تجویز کرتا ہے۔

R8 غیر استعمال شدہ کلاسز، طریقوں اور فیلڈز کو ہٹاتا ہے، انہیں چھوٹے ناموں (a، b، c) میں بدلتا ہے، inline فنکشنز شامل کرتا ہے اور مردہ کوڈ کو ہٹاتا ہے۔ نتیجہ — فعالیت کھوئے بغیر DEX 20–40% کم ہو جاتا ہے۔

R8 قواعد

R8 ترتیب proguard-rules.pro فائل میں متعین کی جاتی ہے۔ ڈیولپر بتا سکتا ہے کہ کن کلاسز کا نام نہیں بدلا جا سکتا (مثال کے طور پر، ریفلیکشن یا Gson سیریلائزیشن کے لیے)۔ Firebase اور دیگر SDK اپنے انحصار میں اپنے قواعد فراہم کرتے ہیں۔

DEX ڈی کمپائل: اوزار اور تحفظ

DEX کو واپس Java کوڈ میں ڈی کمپائل کیا جا سکتا ہے۔ یہ Android ایپلیکیشنز کے لیے ایک اہم سیکیورٹی سوال ہے: مبہم کاری کے بغیر، کوڈ اصل کے قریب کی سطح پر بحال ہو جاتا ہے۔

ڈی کمپائل کے اوزار

JADX سب سے مقبول DEX سے Java ڈی کمپائلر ہے۔ یہ کلاس کے نام، طریقے، فیلڈز اور زیادہ تر منطق بحال کرتا ہے۔ apktool DEX کو smali کوڈ (Dalvik اسمبلر) میں ڈی کمپائل کرتا ہے — اصل ہدایات کے قریب ایک نچلی سطح کا اظہار۔ Bytecode Viewer ایک انٹرفیس میں متعدد ڈی کمپائلرز کو یکجا کرتا ہے۔

تحفظ کے طریقے

R8/ProGuard کے ساتھ مبہم کاری دفاع کی پہلی لائن ہے: کلاس اور طریقہ کے نام ناقابل مطالعہ ہو جاتے ہیں۔ DexGuard اضافی طریقوں والا ایک تجارتی آلہ ہے: سٹرنگ خفیہ کاری، سالمیت کی جانچ، چھیڑ چھاڑ مخالف۔ کنٹرول فلو مبہم کاری (O-LLVM) فعالیت کو برقرار رکھتے ہوئے کوڈ کا ڈھانچہ تبدیل کرتا ہے، جس سے تجزیہ زیادہ مشکل ہو جاتا ہے۔