Dalvik: یہ کیا ہے، ورچوئل مشین اور کیسے کام کرتی ہے

Dalvik کیا ہے؟

Dalvik رجسٹر ٹیبہ فنری کے ساتھ ایک ورچوئل مشین ہے، خاص طور پر Android پلیٹ فارم کے لیے تیار کیا گیا۔ ترقی 2005 میں ڈین بورنسٹائن کی کمپنی نے شروع کی، اور 2007 میں Google نے اس منصوبۙ کو خرید لیا۔ Dalvik کا پہلا تجارتی ورزن 2008 میں Android 1.0 کے اجرائے کے ساتھ سامنے آیا۔

معیاری جاوا ورچوئل مشین (JVM) کے برعکس، Dalvik جاوا بائٹ کوڈ نہیں چلاتی۔ جاوا مرتب سورس کوڈ کو class فائلوں میں تبدیل کرتا ہے، اور پھر dx یوٹیلٹی انہیں Dalvik Executable (DEX) فارمیٹ میں ترجمہ کرتی ہے۔ یہ فارمیٹ class فائلوں سے زیادہ کمپیکٹ ہے: class فارمیٹ میں 10 MB کی ایپلیکیشن DEX میں تقریبنا 6–7 MB لےتی ہے۔

تخلیق کی تاریخ

ڈین بورنسٹائن نے Dalvik کو محدود وسائل والے آپریٹنگ سسٹم کے لیے ایک منصوبۙ کے طور پر لکھا۔ نام آئس لینڈ کے گاءں ڈالویک سے لیا گیا۔ Google نے لائسنسنگ پابندیوں اور ARM فنری ساختار والے موبائل پروسیسروں کے لیے گہرے اور بہتر کرنے کی ضرورت کے سبب JVM کے بجائے Dalvik کو چونا۔ سیسٹم نے جلدی مقبولیت حاصل کی: 2012 تک، 500 ملیون سے زیادہ Android آلات Dalvik پر چل رہے تھ۔۔

Android ایکوسسٹم میں کردار

ہر Android ایپلیکیشن اپنے Dalvik VM انسٹنس کے ساتھ ایک علیحدہ عمل میں چلتی ہے۔ یہ آپریٹنگ سسٹم کی سطح پر ڈیٹا کے علیحدگی اور بد نیت کوڈ سے تحفظ کو یقینی بناتا ہے۔ یہ طریقہ ورچوئلائزیشن کے فوائد کو Linux سینڈ باکس کے ساتھ یکہ کرتا ہے — ایک ایپلیکیشن میں مالویئر پڑوسی عملیوں کو متاثر نہیں کر سکتا۔

Dalvik کا فنری کی ساختار: رجسٹر مشین اور DEX

Dalvik کا رجسٹر ٹیبہ فنری ساختار JVM کے اسٹاک ٹیبہ فنری ساختار سے بنیادی طور پر مختلف ہے۔ اسٹاک کی چوٹی پر عمل کرنے کے بجائے، Dalvik رجسٹروں — VM کے اندر ورچوئل سلز — کے ساتھ کام کرتی ہے۔ ہر ہدایت میں عمل کرنے والے رجسٹروں کے پتے ہوتے ہیں، جو فیکری عمل کے لیے ہدایات کی تعداد کم کرتا ہے۔

JVM اسٹاک مشین push، pop اور add جیسی ہدایات استعمال کرتی ہے — دو نمبروں کو جمع کرنے کے لیے تین ہدایات درکار ہیں۔ Dalvik تین رجسٹروں کے ساتھ ایک add-int ہدایت سے ایک ہی کام کو حل کرتی ہے۔ Android Open Source Project کے مطابق، رجسٹر ٹیبہ DEX فنری ساختار اسٹاک ٹیبہ class فارمیٹ کے مقابلۙ بائٹ کوڈ کے حجم کو اوسط 30% کم کرتا ہے۔

DEX فارمیٹ

ایک DEX فائل (Dalvik Executable) میں ایپلیکیشن کے تمام کلاسوں کی ایک کمپریشد نمائندگی ہوتی ہے۔ فائل ہیڈر میں چیکسم، سیکشن کے حجم اور آفسیٹ شامل ہیں۔ اہم سیکشنز سٹرنگز، اقسام، طریقۙ پروٹوٹائپز، فیلڈز، اور خود بائٹ کوڈ کے پول ہیں۔ ایک DEX فائل 65,536 تک طریقۙ محفوظ کر سکتی ہے (Android 5.0 میں multi-dex متعارف کرانے کے ساتھ یہ پابندی ہٹا دی گئی)۔

Android SDK Build Tools میں شامل dx یوٹیلٹی، class فائلوں کو DEX میں تبدیل کرنے کے لیے استعمال ہوتی ہے۔ کمانڈ کی مثال: dx --dex --output=classes.dex myapp.jar۔ جدید منصوبے بھتر اور بہتر کرنے اور Java 8+ فیچرز کی حمایت کے ساتھ dx کے جانشین D8 استعمال کرتے ہیں۔

# dx کا استعمال کرکے JAR کو DEX میں تبدیل کرنا
dx --dex --output=classes.dex myapp.jar

# D8 کے ذریعۙ جدید ورزن
d8 --lib android.jar --output dex/ myapp.jar

Zygote: فریم ورک کو پھلے سے لاد کرنا

Zygote عمل Dalvik فنری ساختار کا ایک اہم عنصر ہے۔ جب سیسٹم شروع ہوتا ہے، Zygote تمام Android SDK کلاسز کو لاد کرتا ہے، مشترکہ لائبریریز کھولتا ہے، اور پھلے سے لاد کردہ وسائل کا ایک پول بناتا ہے۔ جب کوئی صارف ایک ایپلیکیشن کھولتا ہے، سیسٹم Zygote عمل کو فارک کرتا ہے، پھلے سے شروع کردہ فریم ورک کے ساتھ ایک نئا Dalvik VM انسٹنس بناتا ہے۔ یہ ایپلیکیشن کے آغاز کے وقت کو ~2–3 سیکنڈ سے گھٹا کر 300–500 ملی سیکنڈ کر دیتا ہے۔

Dalvik میں JIT ترتیب

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

ابتدائی Android ورزنوں میں مکمل Ahead-Of-Time (AOT) ترتیب کے بجائے JIT کا انتخاب جان بوجہ تھا۔ موبائل آلات میں محدود فلیش اسٹوریج (4–16 GB) تھا — تمام ایپلیکیشنز کو پھلے سے ترتیب دینے سے کافی جگہ گھر ہوتی۔ مزید برتاں، ابتدائی آلات میں ROM میمری RAM سے آہسطہ تھی اور پھلے سے ترتیب یافتہ کوڈ پڑھنا کارکردگی کو کم کر سکتا تھا۔

JIT ترتیب کا عمل

جب ایک ایپلیکیشن شروع ہوتی ہے، Dalvik DEX بائٹ کوڈ کی تشریح شروع کرتی ہے۔ ایک خاص پروفائلر ٹریک کرتا ہے کہ کون سے طریقۙ سب سے زیادہ بلائے جاتے ہیں۔ ایک حد (عمومن ~200 کالز) کو پار کرنے کے بعد، JIT مرتب طریقۙ کو مشین کوڈ میں تبدیل کرتا ہے اور اسے RAM میں کیش کرتا ہے۔ بعد والے کالز شمل دوبارہ ترتیب کے بغیر پہلے سے ترتیب یافتہ ورزن استعمال کرتے ہیں۔

// ایک ہوٹ طریقۙ کی مثال جسے JIT ترتیب دے گا
public class Calculator {
    public int sumArray(int[] arr) {
        int total = 0;
        for (int i = 0; i < arr.length; i++) {
            total += arr[i];
        }
        return total;
    }
}

JIT کی کارکردگی

Google I/O 2013 کے مطابق، Android 2.2 Froyo میں JIT کے تعارف نے خالص تشریح کے مقابلۙ ایپلیکیشن نفاذ کو اوسط 2–5 گنا تیز کر دیا۔ تاہم، JIT پہلی لانچ میں تاخیر کا سبب بنتا ہے: ایک ایپلیکیشن کو گرم ہونے اور ہوٹ طریقۙ کو ترتیب دینے کے لیے 3 سے 10 سیکنڈ درکار ہیں۔ گرم ہونے کے بعد، کارکردگی مقامی کوڈ کے قریب سطح پر مستحکم ہو جاتی ہے۔

Dalvik بمقابلۙ JVM: اہم فرق

Dalvik کئی بنیادی معاملات میں JVM سے مختلف ہے۔ پہلا — فنری ساختار: JVM اسٹاک ٹیبہ ہے، Dalvik رجسٹر ٹیبہ۔ دوسرا — بائٹ کوڈ فارمیٹ: JVM class فائلیں استعمال کرتی ہے، Dalvik DEX استعمال کرتی ہے۔ تیسرا — میمری کا انتظام: Dalvik موبائل آلات کی محدود RAM کے لیے بہتر کی گئی ہے۔

دونوں طریقوں کی اپنی طاقتیں ہیں۔ اسٹاک ٹیبہ JVM کو ہدایات محفوظ کرنے کے لیے کم جگہ درکار ہے — ہر ہدایت چھوٹی ہوتی ہے کیونکہ عمل کرنے والے اسٹاک سے تکلفی لیے جاتے ہیں۔ رجسٹر ٹیبہ Dalvik فیکری عمل کے لیے کم ہدایات چلاتی ہے، جو CPU کا وقت بچاتا ہے اور بجلی کی کھپت کو کم کرتا ہے۔ بیٹری سے چلنے والے موبائل آلات کے لیے یہ بہت اہم ہے۔

لائسنسنگ کے پہلوئے

JVM کے بجائے Dalvik کا انتخاب لائسنسنگ کے ذریعۙ بھی ہوا تھا۔ Oracle کے پاس Java SE اور JVM کے حقوق ہیں، اور Google لائسنس فیس سے بچنا چاہتا تھا۔ متبادل بائٹ کوڈ فارمیٹ کے ساتھ اپنا VM بنانے نے Android کو Oracle سے آزاد طور پر ترقی کرنے کی اجازت دی۔ یہ تنازع ایک طویل قانونی جنگ میں بدل گیا، Oracle بمقابلۙ Google (2010–2021)، جو Google کے حق میں ختم ہوا۔

DEX فارمیٹ اور dx یوٹیلٹی

DEX (Dalvik Executable) ایک بائنری فارمیٹ ہے جس میں Android ایپلیکیشن کا ترتیب یافتہ کوڈ ہوتا ہے۔ ہر DEX فائل ایک ہیڈر سے شروع ہوتی ہے، جس کے بعد سیکشنز آتے ہیں: سٹرنگ کنسٹنٹس (string_ids)، اقسام (type_ids)، طریقۙ پروٹوٹائپز (proto_ids)، فیلڈز (field_ids)، طریقۙ (method_ids)، کلاس تعریفات (class_defs)، اور ایک ڈیٹا علاقہ۔

dx یوٹیلٹی Java class فائلوں کو ایک یا زائد DEX فائلوں میں تبدیل کرتی ہے۔ الگورتہم میں کنسٹنٹ ڈی ڈیپلیکیشن شامل ہے — ایک جیسی سٹرنگز یا اقسام ایک بار محفوظ ہوتی ہیں اور انڈیکس سے حوالہ دیا جاتا ہے۔ یہ حتمی حجم کو کافی کم کرتا ہے۔ جدید منصوبوں میں، dx کی جگہ D8 (Android Studio 3.1 میں متعارف) نے لے لی ہے، جو 2–3 گنا تیز ہے اور Java 8 ڈی شگرنگ کی حمایت کرتا ہے۔

// dexdump کے ذریعۙ ڈی کمپائل شدہ DEX بائٹ کوڈ کی مثال
// سورس کوڈ: return a + b;
@Ldalvik/annotation/Code;
    registers: 3
    add-int v0, v1, v2
    return v0

Multi-dex: 65536 کی حد کو پار کرنا

65,536 طریقۙ کی DEX فارمیٹ حد (16 بٹ انڈیکس حد) بڑے ایپلیکیشنز کے لیے ایک سنگین مسئلہ بن گئی۔ حل Android 5.0 کے ساتھ آیا: multi-dex حمایت ایک ایپلیکیشن کو کئی DEX فائلیں شامل کرنے کی اجازت دیتی ہے۔ مرکزی classes.dex میں داخلی نقاط ہوتے ہیں، جبکہ اضافی classes2.dex، classes3.dex اور آگے باقی کوڈ هوتا ہے۔ Multi-dex ترتیب build.gradle میں multiDexEnabled true سطر سے فعال کیا جاتا ہے۔

میمری کا انتظام اور کوڑا کٹھرا

Dalvik میں کوڑا کٹھرا مارک اینڈ سویپ کے ساتھ ایک جینریشنل کلیکٹر کے طور پر نفاذ کیا گیا ہے۔ میمری دو اہم علاقوں میں تقسیم ہے: آبجیکٹ کے لیے Heap اور پریمیٹو اور حوالوں کے لیے Stack۔ جب Heap بھر جاتا ہے، Dalvik تمام دھاگوں کو معطل کر دیتی ہے (STW — Stop-The-World)، قابل رسائی آبجیکٹس کو مارک کرتی ہے اور ناقابل رسائی کو آزاد کرتی ہے۔

Android 2.2 سے پہلے، Dalvik 100–200 ms تک رکنے کی مدت کے ساتھ ایک تہردھاگہ کلیکٹر استعمال کرتی تھی۔ Android 2.3 Gingerbread نے ایک متضمن کلیکٹر متعارف کرایا جس نے عام رکنے کو 5–10 ms تک کم کر دیا۔ اور Android 4.0 Ice Cream Sandwich نے تزیدی صفائی کے ساتھ ایک کلیکٹر شامل کیا — Concurrent Mark and Sweep (CMS)۔

میمری لیک

Dalvik ایپلیکیشنز کا ایک عام مسئلہ Activity کے ستاٹک حوالوں کے ذریعۙ میمری لیک ہے۔ اگر ایک ستاٹک فیلڈ Context یا View کا حوالہ رکھتا ہے، تو کوڑا کٹھرنے والا سکرین بند ہونے کے بعد بھی Activity کو آزاد نہیں کر سکتا۔ Eclipse MAT اور LeakCanary جیسے آلات ایسے لیکز کو دریافت کرنے میں مدد کرتے ہیں: وہ Heap ڈمپ کا تجزیۙ کرتے ہیں اور آبجیکٹ کو رکھنے والی حوالہ زنجیریں دیڥاتے ہیں۔

// ستاٹک حوالہ کے ذریعۙ میمری لیک کی مثال
public class Utils {
    private static Context context;

    public static void init(Context ctx) {
        context = ctx; // finish() کے بعد Activity کو رکھتا ہے
    }
}

Dalvik کی حدود اور ART میں منتقل

کامیابی کے باوجود، Dalvik میں کئی خامیاں تھیں۔ JIT ترتیب کو گرم ہونے کا وقت درکار تھا — ایپلیکیشن کے آپریشن کے پہلے چند سیکنڈ آہستہ تھ۔ مزید برتاں، JIT ترتیب کے دوران CPU بجل استعمال کرتا تھا، جس سے بیٹری کی زندگی کم ہو جاتی تھی۔ جیسے جیسے موبائل آلات کی کارکردگی بڑھی اور بیلٹ ان سٹوریج میں اضافہ ہوا، JIT کی ضرورت کم ہوتی گئی۔

Android 4.4 KitKat میں، Google نے Dalvik کے تجرباتی متبادل کے طور پر ART (Android Runtime) متعارف کرایا۔ Android 5.0 Lollipop سے شروع کرکے، ART ایکمالختص ران ٹائم ماحول بن گیا۔ بنیادی فرق AOT ترتیب ہے: عمل کے دوران ترتیب دینے کے بجائے، تمام ایپلیکیشنز انسٹلیشن کے دوران مشین کوڈ میں ترتیب پاتے ہیں۔ اس نے گرم ہونے کی تاخیروں کو ختم کر دیا اور قابلیت میں بہتری کی۔

پشت مطابقت

Dalvik سے ART میں منتقل ڈیویلپرز کے لیے شفاف تھا: دونوں ران ٹائم ایک ہی DEX بائٹ کوڈ چلاتے ہیں۔ Dalvik کے لیے ترتیب یافتہ ایپلیکیشنز شمل دوبارہ ترتیب کے بغیر ART پر چلتے ہیں — system_server انسٹیلیشن کے دوران انہیں مقامی کوڈ میں ترتیب دیتا ہے۔ مستثنیہ وہ کوڈ ہے جو Dalvik VM کے اندرونی ارکان تک رسائی کے لیے ریفلیکشن استعمال کرتا ہے: ایسا کوڈ اندرونی فنری ساختار میں تبدیلیوں کے سبب ART پر ٹوٹ سکتا ہے۔