ART: یہ کیا ہے، رن ٹائم اور یہ کیسے کام کرتا ہے

ART کیا ہے؟

Android Runtime (ART) ایک ایپلیکیشن رن ٹائم ماحول ہے جو عملدرآمد سے پہلے DEX بائٹ کوڈ کو مقامی مشین کوڈ میں کمپائل کرتا ہے۔ Dalvik کے برعکس، جو عملدرآمد کے دوران Just-In-Time کمپائلیشن استعمال کرتا تھا، ART APK انسٹالیشن کے دوران Ahead-Of-Time (AOT) کمپائلیشن انجام دیتا ہے۔ اس بنیادی تعمیری تبدیلی نے ایپلیکیشنز میں نمایاں تیزی اور کم بجلی کی کھپت فراہم کی۔

ART پہلی بار Android 4.4 KitKat میں ایک تجرباتی آپشن کے طور پر ظاہر ہوا۔ ڈیولپرز ڈیولپر سیٹنگز میں اسے فعال کر کے اپنی ایپلیکیشنز کو جانچ سکتے تھے۔ Android 5.0 Lollipop میں، ART ڈیفالٹ رن ٹائم بن گیا اور Dalvik کو پلیٹ فارم سے مکمل طور پر ہٹا دیا گیا۔ Android 7.0 Nougat کی ریلیز تک، ART کو ہائبرڈ کمپائلیشن موڈ مل گیا۔

ترقی کی تاریخ

Dalvik کو ART سے تبدیل کرنے کا فیصلہ اچانک نہیں تھا۔ نئے رن ٹائم پر کام 2012 میں شروع ہوا جب Google نے JIT طریقہ کار کی حدود کو پہچانا۔ اہم اہداف: ایپ لانچ کو تیز کرنا، CPU بوجھ کم کرنا اور بجلی کی کھپت کم کرنا۔ ترقی کی قیادت Android Runtime Group نے کی، جو پہلے Dalvik کی اصلاح پر کام کر رہا تھا۔

تعمیری تبدیلیاں

ART وہی رجسٹر پر مبنی فن تعمیر استعمال کرتا ہے جیسا Dalvik، لیکن مکمل طور پر دوبارہ ڈیزائن کردہ کمپائلر کے ساتھ۔ انٹرپریٹر اور JIT کمپائلر کے بجائے، ART میں dex2oat AOT کمپائلر شامل ہے، جو انسٹالیشن کے دوران DEX فائلوں کو ELF بائنری میں تبدیل کرتا ہے۔ نتیجتاً، ART پر ایپلیکیشنز وارم اپ مرحلے کے بغیر فوری طور پر مقامی کارکردگی کے ساتھ شروع ہوتی ہیں۔

ART کا فن تعمیر: Dalvik سے نئے رن ٹائم تک

ART نے Dalvik کے اہم اصولوں کو برقرار رکھا: علیحدہ عمل کے ذریعے ایپلیکیشن تنہائی، رجسٹر پر مبنی فن تعمیر اور DEX فارمیٹ سپورٹ۔ تاہم، اندرونی نفاذ مکمل طور پر دوبارہ لکھا گیا۔ Dalvik انٹرپریٹر کے بجائے، ART میں تین عملدرآمد موڈ شامل ہیں: انٹرپریٹر، JIT کمپائلر اور dex2oat AOT کمپائلر۔ موڈ کا انتخاب ایپلیکیشن کے لائف سائیکل مرحلے پر منحصر ہے۔

ART کا اہم جزو dex2oat (dalvik executable to optimized android translator) ہے۔ یہ یوٹیلیٹی ایپلیکیشن انسٹالیشن کے دوران چلتی ہے (Android 7.0 سے — بیک گراؤنڈ آپٹیمائزیشن کے دوران بھی)۔ dex2oat APK سے DEX فائلیں پڑھتا ہے، بائٹ کوڈ کو بہتر بناتا ہے اور ایک OAT فائل — مقامی کوڈ کے ساتھ ELF بائنری — تیار کرتا ہے۔ OAT فائلیں /data/dalvik-cache/ ڈائریکٹری میں محفوظ کی جاتی ہیں۔

# ڈیوائس پر OAT فائلیں چیک کرنا
adb shell ls -la /data/dalvik-cache/arm64/

# ایپلیکیشن کی لازمی دوبارہ کمپائلیشن
adb shell cmd package compile -m speed com.example.app

ART کے اجزاء

ART نظام کئی باہم جڑے ہوئے ماڈیولز پر مشتمل ہے۔ dex2oat کمپائلر مقامی کوڈ کی تخلیق کا ذمہ دار ہے۔ کوڑا کرکٹ جمع کرنے والا (GC) میموری ڈی لوکیشن کا انتظام کرتا ہے۔ انٹرپریٹر کمپائلیشن کے بغیر کم کال کردہ کوڈ پر عملدرآمد کرتا ہے۔ پروفائلر ہائبرڈ کمپائلیشن کے لیے ہاٹ میتھڈز کو ٹریک کرتا ہے۔ ہر ماڈیول آزادانہ طور پر کام کر سکتا ہے، جس سے ART لچکدار اور قابل توسیع بنتا ہے۔

ہائبرڈ کمپائلیشن: JIT + AOT + پروفائلنگ

Android 7.0 Nougat سے شروع کرتے ہوئے، ART کمپائلیشن کے لیے ایک ہائبرڈ طریقہ کار استعمال کرتا ہے، جو JIT اور AOT کے فوائد کو یکجا کرتا ہے۔ ایپلیکیشن انسٹالیشن کے دوران، ART اب مکمل AOT کمپائلیشن نہیں کرتا — اس کے بجائے، ایپ ہاٹ میتھڈز کے JIT کمپائلیشن کے ساتھ انٹرپریٹڈ موڈ میں چلتی ہے۔ اس سے انسٹالیشن کا وقت اور اسٹوریج کی جگہ کم ہوتی ہے۔

ایک بیک گراؤنڈ پروفائلر متوازی طور پر کام کرتا ہے۔ یہ عملدرآمد کے اعدادوشمار جمع کرتا ہے: کن میتھڈز کو سب سے زیادہ کال کیا جاتا ہے، کوڈ کی کون سی شاخیں عملدرآمد ہوتی ہیں، کون سی کلاسز لوڈ ہوتی ہیں۔ کافی ڈیٹا جمع ہونے کے بعد (عام طور پر 2–3 ایپ لانچ کے بعد)، ART بیک گراؤنڈ میں dex2oat چلاتا ہے اور صرف پروفائل شدہ ہاٹ میتھڈز کو مقامی کوڈ میں کمپائل کرتا ہے۔

کمپائلیشن موڈز

ART system_server کے ذریعے منظم کئی کمپائلیشن موڈز کو سپورٹ کرتا ہے۔ “speed” موڈ تمام میتھڈز کو AOT سے کمپائل کرتا ہے (زیادہ سے زیادہ کارکردگی، سست انسٹالیشن)۔ “speed-profile” موڈ صرف پروفائل شدہ ہاٹ میتھڈز کو کمپائل کرتا ہے (رفتار اور حجم کا توازن)۔ “verify” موڈ کمپائلیشن کے بغیر صرف بائٹ کوڈ کی تصدیق کرتا ہے (کم سے کم جگہ، تشریح)۔ ڈیفالٹ طور پر، speed-profile استعمال ہوتا ہے — زیادہ تر ایپلیکیشنز کے لیے بہترین۔

ART پروفائلر

پروفائلر خصوصی .prof فائلوں میں عملدرآمد کا ڈیٹا جمع کرتا ہے۔ ہر ایپلیکیشن اپنا پروفائل /data/misc/profiles/ میں محفوظ کرتی ہے۔ جب حد تک پہنچ جاتا ہے (عام طور پر 1000 نمونے)، پروفائلر شناخت شدہ ہاٹ میتھڈز کو کمپائل کرنے کے لیے dex2oat شروع کرتا ہے۔ پروفائلز ایپلیکیشن اپ ڈیٹس کے درمیان محفوظ رہتے ہیں، OTA سسٹم اپ ڈیٹس کے بعد دوبارہ اصلاح کو تیز کرتے ہیں۔

ART میں کوڑا کرکٹ جمع کرنا

ART میں کوڑا کرکٹ جمع کرنا Dalvik کے مقابلے میں ڈرامائی طور پر بہتر ہوا ہے۔ سنگل تھریڈڈ Concurrent Mark and Sweep (CMS) کے بجائے، ART کئی اصلاحات کے ساتھ نسلی جمع کرنے والا استعمال کرتا ہے: متحرک جمع کرنے والا (ہیپ کمپیکشن)، بڑی آبجیکٹ اسپیس (بڑی اشیاء کے لیے علیحدہ اسٹوریج) اور متوازی کمپیکشن (ہم عصر کمپیکشن)۔

ART میں ایک عام GC وقفہ 2–3 ms ہے جبکہ Dalvik میں 5–10 ms تھا۔ یہ کئی میکانزم کے ذریعے ممکن ہوا۔ پہلا، ART ہم عصر مراحل کے لیے stop-the-world کے بجائے read-barrier استعمال کرتا ہے۔ دوسرا، نسلی جمع کرنے والا زیادہ تر چکروں میں پورے ہیپ کو چھوئے بغیر صرف اشیاء کی نوجوان نسل پر کارروائی کرتا ہے۔ تیسرا، بڑی آبجیکٹ اسپیس (LOS) علیحدہ طور پر مختص کی جاتی ہے اور عام GC چکروں میں حصہ نہیں لیتی۔

// ڈیبگنگ کے لیے GC لاگز فعال کرنا
System.logV("ART", "GC trigger: allocation failed");

// لازمی GC کال (پروڈکشن میں تجویز نہیں کی جاتی)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

ART دور میں میموری لیک

بہتر GC کے باوجود، میموری لیک ایک متعلقہ مسئلہ بنی ہوئی ہے۔ ART کی مخصوص وجہ مناسب ڈی لوکیشن کے بغیر JNI کے ذریعے مقامی لائبریریاں لوڈ کرنا ہے۔ اگر مقامی کوڈ malloc کے ذریعے میموری مختص کرتا ہے لیکن free کو کال نہیں کرتا، تو ART اس میموری کو آزاد نہیں کر سکتا — یہ زیر انتظام ہیپ سے باہر ہے۔ Android NDK میں AddressSanitizer ٹول ایسی لیک کی نشاندہی کرنے میں مدد کرتا ہے۔

ART بمقابلہ Dalvik: تقابلی تجزیہ

ART اور Dalvik ایک ہی کام کے دو بنیادی طور پر مختلف نفاذ ہیں: Android ایپلیکیشنز پر عملدرآمد۔ فرق تمام سطحوں کو متاثر کرتا ہے: کمپائلیشن سے لے کر میموری مینجمنٹ تک۔ ذیل میں اہم کارکردگی اور مطابقت کے پیرامیٹرز کا موازنہ ہے۔

ART کا بنیادی فائدہ JIT وارم اپ کا خاتمہ ہے۔ Dalvik پر، JIT ہاٹ میتھڈز کو کمپائل کرتے ہوئے ایپ پہلے 3–10 سیکنڈ کے لیے سست ہو سکتی تھی۔ ART پر، تمام میتھڈز پہلے سے مقامی کوڈ میں کمپائل ہیں (یا بیک گراؤنڈ میں کمپائل ہوں گی)۔ یہ خاص طور پر گیمز اور بھاری UI والی ایپس میں نمایاں ہے: fps فرق ART کے حق میں 15–20% تک پہنچ سکتا ہے۔

مطابقت

Dalvik کے لیے لکھی گئی تمام ایپلیکیشنز بغیر تبدیلی کے ART پر کام کرتی ہیں۔ Google DEX بائٹ کوڈ کی سطح پر مکمل پسماندہ مطابقت کی ضمانت دیتا ہے۔ مستثنیٰ ریفلیکشن کے ذریعے Dalvik کی مخصوص داخلی API استعمال کرنے والا کوڈ ہے: Android SDK میں @hide سے نشان زد dalvik.system.DexFile کلاس کے ممبران۔ ایسے کوڈ کو عوامی API استعمال کرنے کے لیے اپ ڈیٹ کیا جانا چاہیے۔

Java 8 سپورٹ اور ڈی شوگرنگ

ART مقامی Java 8 خصوصیات کے ساتھ پہلا Android رن ٹائم بن گیا۔ Android 7.0 سے شروع کرتے ہوئے، ART میں ڈی شوگرنگ شامل ہے — Java 8 تعمیرات (لیمبڈا، میتھڈ ریفرنسز، Stream API) کو مساوی Java 7 کوڈ میں تبدیل کرنے کا عمل۔ یہ پرانے آلات کے ساتھ مطابقت کھوئے بغیر جدید نحو استعمال کرنے کی اجازت دیتا ہے۔

ڈی شوگرنگ D8 کمپائلر کے ذریعے انجام دی جاتی ہے اور اس طرح کام کرتی ہے۔ لیمبڈا والا سورس کوڈ اسی کلاس کے اندر ایک مصنوعی میتھڈ میں تبدیل ہوتا ہے اور لیمبڈا کو invoke-custom کال سے بدل دیا جاتا ہے۔ ART کے رن ٹائم میں خاص طور پر Java 8 کے لیے شامل کردہ invoke-custom ہدایت کی سپورٹ شامل ہے۔ Android 6.0 اور اس سے نیچے کے آلات پر، لیمبڈا کو گمنام کلاسز میں ڈی شوگر کیا جاتا ہے۔

// Java 8 لیمبڈا — ART میں ڈی شوگرنگ
button.setOnClickListener(v -> handleClick(v));

// ڈی شوگرنگ کے بعد (Java 7 کے مساوی)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

ڈی شوگرنگ کی حدود

تمام Java 8 خصوصیات ڈی شوگرنگ کے ذریعے تعاون یافتہ نہیں ہیں۔ java.time API (تاریخیں اور وقت) صرف desugar_jdk_libs — build.gradle میں شامل کردہ ایک اضافی لائبریری — کے ذریعے دستیاب ہے۔ Stream API کو بھی desugar_jdk_libs کی ضرورت ہے۔ java.util.function اور Optional اضافی انحصار کے بغیر کام کرتے ہیں۔ مکمل Java 8 سپورٹ ڈی شوگرنگ کے بغیر Android 8.0 اور اس سے اوپر کے آلات پر دستیاب ہے۔

ART کے لیے ایپلیکیشن آپٹیمائزیشن

اگرچہ ART پسماندہ مطابقت رکھتا ہے، کچھ اصلاحی مشقیں خاص طور پر اس رن ٹائم پر کارکردگی بہتر کرتی ہیں۔ بنیادی سفارش ریفلیکشن کو کم سے کم کرنا ہے۔ ART کمپائل ٹائم پر نظر آنے والی میتھڈز کو براہ راست مشین کوڈ کالز میں کمپائل کرتا ہے۔ ریفلیکشن ART کو اضافی stubs پیدا کرنے پر مجبور کرتی ہے، جس سے عملدرآمد 10–15% سست ہو جاتا ہے۔

Android 9.0 سے شروع کرتے ہوئے، ART نے App Startup Optimization کے لیے سپورٹ متعارف کرائی۔ ڈیولپر مینی فیسٹ میں <initialization> کے ذریعے ابتدائیہ کلاسز کو نشان زد کر سکتا ہے اور ART انہیں ایپ اسٹارٹ اپ پر پری لوڈ کرے گا۔ یہ بہت سے پلگ ان یا لائبریریوں والی ایپلیکیشنز کے لیے لانچ کا وقت 5–15% کم کرتا ہے۔

<!-- AndroidManifest.xml میں App Startup Optimization -->
<application>
    <profileable
        android:shell="true"
        android:enable="true" />
</application>

کارکردگی کی جانچ

ART پر کارکردگی کی پیمائش کرنے کے لیے، systrace اور perfetto استعمال کریں۔ Systrace dex2oat کمپائلیشن کا وقت، GC تعدد اور فریم رینڈرنگ کی رفتار دکھاتا ہے۔ Perfetto مزید تفصیلی معلومات فراہم کرتا ہے: تھریڈ کی تقسیم، JNI منتقلی کا وقت، مقامی لائبریری لوڈنگ۔ لانچ: adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm۔