موبائل ڈویلپمنٹ میں Runtime: یہ کیا ہے، runtime سسٹم اور یہ کیسے کام کرتا ہے

موبائل ڈویلپمنٹ میں Runtime کیا ہے؟

Runtime وہ بنیادی ڈھانچہ ہے جو پروگرام کے شروع ہونے کے بعد اس کے نفاذ کو یقینی بناتا ہے۔ موبائل ڈویلپمنٹ کے سیاق و سباق میں، runtime میں کلاس لوڈر، میموری مختص کنندہ، کچرا جمع کرنے والا، میتھڈ ڈسپیچر اور مستثنی ہینڈلر شامل ہیں۔ اس درمیانی تہہ کے بغیر، آپریٹنگ سسٹم Dalvik بائٹ کوڈ یا Objective-C پیغامات پر عمل نہیں کر سکتا۔

موبائل پلیٹ فارم مختلف runtime نفاذ استعمال کرتے ہیں۔ Android ہائبرڈ AOT/JIT کمپائل کے ساتھ ART (Android Runtime) استعمال کرتا ہے۔ iOS Objective-C Runtime استعمال کرتا ہے — جو میسج پاسنگ اور SEL شناخت کنندگان پر مبنی ایک متحرک نظام ہے۔ دونوں طریقے ایک ہی مسئلہ حل کرتے ہیں: ڈویلپر کے کوڈ کو کسی مخصوص ڈیوائس پر زیادہ سے زیادہ کارکردگی کے ساتھ عمل میں لانا۔

Google I/O 2024 کے مطابق، Android Runtime دنیا بھر کے ڈیوائسز پر روزانہ 10 بلین سے زیادہ میتھڈ پراسیس کرتا ہے۔ Runtime کارکردگی براہ راست ایپلیکیشن شروع ہونے کی رفتار، اینیمیشن کی ہمواری اور بیٹری کی کھپت کو متاثر کرتی ہے۔ ہر میتھڈ کال، ہر میموری مختص اور ہر کچرا جمع کرنے کا چکر runtime تہہ سے گزرتا ہے۔

Runtime سسٹم: یہ کن اجزاء پر مشتمل ہے

Runtime سسٹم پانچ اہم اجزاء پر مشتمل ہے: کلاس لوڈر، میموری مینیجر، مفسر یا مرتب کنندہ، میتھڈ ڈسپیچر اور سیکیورٹی سسٹم۔ ہر جزو کوڈ پر عملدرآمد کے عمل میں ایک سختی سے متعین کردہ کام انجام دیتا ہے۔

کلاس لوڈر اور تصدیق

جب صارف کوئی ایپلیکیشن شروع کرتا ہے، ClassLoader DEX فائلیں (Android) یا Mach-O بائنری (iOS) RAM میں لوڈ کرتا ہے۔ Android میں، اس مرحلے میں بائٹ کوڈ کی تصدیق شامل ہے: runtime چیک کرتا ہے کہ کوڈ میں کوئی غیر محفوظ ہدایات نہیں ہیں، صفوں کی حدوں سے باہر نہیں جاتا اور اقسام کی پابندی کرتا ہے۔ تصدیق ایک اہم حفاظتی قدم ہے جو بدنیتی پر مبنی کوڈ پر عملدرآمد کو روکتا ہے۔

میموری مینیجر اور کچرا جمع کرنے والا

میموری مینیجر آبجیکٹس کے لیے میموری مختص اور آزاد کرتا ہے۔ Android ART میں، نسلی جمع آوری (generational collection) کے ساتھ ایک ہم وقت کچرا جمع کرنے والا استعمال ہوتا ہے: نوجوان آبجیکٹس زیادہ کثرت سے چیک کیے جاتے ہیں، بوڑھے کم کثرت سے۔ Objective-C Runtime خودکار حوالہ گنتی (ARC) استعمال کرتا ہے، جہاں مرتب کنندہ خود بخود retain/release کالز داخل کرتا ہے۔

میتھڈ ڈسپیچر اور ورچوئل ٹیبل

میتھڈ ڈسپیچر یہ طے کرتا ہے کہ میتھڈ کا کون سا نفاذ پکارا جائے گا۔ جامد زبانوں (Kotlin, Swift) میں، ڈسپیچ vtable — ایک ورچوئل میتھڈ ٹیبل کے ذریعے کیا جاتا ہے۔ متحرک زبانوں (Objective-C) میں، پیغام objc_msgSend سے گزرتا ہے، جو کلاس اور اس کی سپر کلاسز میں نفاذ تلاش کرتا ہے۔ نتیجہ بار بار کال کو تیز کرنے کے لیے method cache میں محفوظ کیا جاتا ہے۔

Android پر ART کیسے کام کرتا ہے

Android Runtime (ART) ایک ورچوئل مشین ہے جو Android ایپلیکیشنز کے DEX بائٹ کوڈ پر عمل کرتی ہے۔ ART نے Android 5.0 Lollipop میں Dalvik کی جگہ لے لی، AOT کمپائل متعارف کرایا: ایپلیکیشن انسٹالیشن کے دوران ایک بار مشین کوڈ میں مرتب ہوتی ہے۔ اس نے ہر شروع پر JIT کمپائل کا اضافی بوجھ ختم کر دیا۔

Android 7.0 Nougat سے، ART ایک ہائبرڈ طریقہ استعمال کرتا ہے۔ انسٹالیشن کے دوران، JIT کمپائل صرف کثرت سے استعمال ہونے والے میتھڈ (hot methods) کے لیے کیا جاتا ہے، باقی کوڈ کی تشریح کی جاتی ہے۔ ایک پس منظر کا عمل (profile-guided optimization) تجزیہ کرتا ہے کہ کون سے میتھڈ سب سے زیادہ پکارے جاتے ہیں اور ڈیوائس کے خالی وقت میں انہیں AOT مرتب کرتا ہے۔ یہ اعلی کارکردگی کو یقینی بناتے ہوئے انسٹالیشن کا وقت کم کرتا ہے۔

ART میں ایک AOT مرتب کنندہ (dex2oat) بھی شامل ہے جو DEX فائلوں کو ARM64 مشین کوڈ کے ساتھ ELF بائنری میں تبدیل کرتا ہے۔ کمپائل تین اصلاحی سطحوں کے ساتھ کیا جاتا ہے: quicken (تیز)، optimize (درمیانی) اور everything (مکمل)۔ ڈیفالٹ طور پر، Android optimize استعمال کرتا ہے، جو کمپائل کی رفتار اور کوڈ کی کارکردگی کے درمیان توازن رکھتا ہے۔

class RuntimeExample {
    fun measureExecutionTime() {
        val start = System.nanoTime()
        // ART کے ذریعے مرتب کردہ میتھڈ کال
        processData()
        val end = System.nanoTime()
        println("عملدرآمد کا وقت: ${end - start} ns")
    }
}

اوپر دی گئی مثال میں، System.nanoTime() ایک مقامی میتھڈ ہے جس کی کال ART runtime کے ذریعے Linux کرنل میں ڈسپیچ ہوتی ہے۔ ART Kotlin بائٹ کوڈ کو ARM64 ہدایات میں تبدیل کرتا ہے جو ڈیوائس کے پروسیسر کے ذریعے عمل میں آتی ہیں۔ یہ عمل ڈویلپر کے لیے شفاف ہے، لیکن اس کی اصلاح Android Platform ٹیم کا ایک اہم کام ہے۔

Profile-Guided Optimization (PGO)

Profile-guided optimization ایک ART میکانزم ہے جو میتھڈ استعمال کے پروفائلز جمع کرتا ہے۔ فائل profiles/.primary.prof میں hot میتھڈ کی فہرست ہوتی ہے جو AOT مرتب ہوتے ہیں۔ Android Performance Team کے مطابق، PGO پروفائل جمع ہونے کے بعد کئی دنوں کے استعمال کے بعد ایپلیکیشن شروع ہونے کو 15–30% تیز کرتا ہے۔

ڈویلپر اپنے Gradle پروجیکٹ میں baseline profiles فعال کر سکتا ہے۔ یہ دستی تشریحات ہیں جو ART کو بتاتی ہیں کہ انسٹالیشن کے فوراً بعد کن میتھڈ کو AOT مرتب کرنا ہے۔ Baseline profiles پس منظر پروفائلنگ کا انتظار کیے بغیر پہلی بار شروع ہونے کو 40% کم کرتے ہیں۔

iOS پر Objective-C Runtime کیسے کام کرتا ہے

Objective-C Runtime ایک متحرک لائبریری ہے جو iOS اور macOS پر Objective-C کوڈ پر عملدرآمد فراہم کرتی ہے۔ اس کا مرکز objc_msgSend فنکشن ہے، جو میسج پاسنگ کو نافذ کرتا ہے: براہ راست میتھڈ کال کے بجائے، آبجیکٹ ایک سلیکٹر کے ساتھ پیغام بھیجتا ہے، اور runtime طے کرتا ہے کہ کون سا نفاذ عمل میں آنا چاہیے۔

ہر Objective-C آبجیکٹ میں اپنی کلاس کے لیے ایک isa پوائنٹر ہوتا ہے، اور کلاس کے پاس ایک dispatch table ہوتی ہے جو سلیکٹرز (SEL) کو نفاذ (IMP) سے جوڑتی ہے۔ جب کوئی میتھڈ پکارا جاتا ہے، objc_msgSend سلسلہ: کلاس → سپرکلاس → NSObject کو اس وقت تک عبور کرتا ہے جب تک IMP نہ مل جائے۔ اگر کوئی نفاذ نہ ملے تو runtime forwarding mechanism کو پکارتا ہے، جو پیغام کو روک سکتا ہے یا مستثنی پیدا کر سکتا ہے۔

Objective-C Runtime method swizzling کو بھی سپورٹ کرتا ہے — رن ٹائم پر موجود سلیکٹر کے IMP کو تبدیل کرنا۔ یہ ایک طاقتور میکانزم ہے جو AOP لائبریریوں اور نگرانی کے اوزاروں میں استعمال ہوتا ہے، لیکن پوری ایپلیکیشن پر اس کے اثرات کی وجہ سے احتیاط کی ضرورت ہے۔

@interface RuntimeDemo : NSObject
- (void)printClassInfo;
@end

@implementation RuntimeDemo
- (void)printClassInfo {
    // objc_getClass — runtime فنکشن
    Class cls = objc_getClass("RuntimeDemo");
    unsigned int count;
    Method *methods = class_copyMethodList(cls, &count);
    NSLog("میتھڈ کی تعداد: %d", count);
}
@end

کوڈ Objective-C Runtime API تک براہ راست رسائی ظاہر کرتا ہے: objc_getClass نام سے کلاس آبجیکٹ حاصل کرتا ہے، class_copyMethodList تمام میتھڈ کی فہرست نکالتا ہے۔ یہ عمل میں عکاسی (reflection) ہے — رن ٹائم پر کلاس میٹا ڈیٹا تک رسائی۔ یہ طریقہ XCTest میں متحرک ٹیسٹ رجسٹریشن کے لیے استعمال ہوتا ہے۔

isa پوائنٹر اور ٹیگ شدہ پوائنٹرز

isa پوائنٹر ہر آبجیکٹ کے پہلے 8 بائٹس میں محفوظ آبجیکٹ کی کلاس کا پوائنٹر ہے۔ iOS 12 سے شروع کرتے ہوئے، Apple نے اصلاح کے لیے isa-swizzling متعارف کرایا: isa کے نچلے بٹس آبجیکٹ کی حالت کے بارے میں اضافی معلومات انکوڈ کرتے ہیں۔ ٹیگ شدہ پوائنٹرز ایک اور اصلاح ہے جہاں 60 بٹ تک کی قدریں (NSNumber, NSDate) ہیپ پر آبجیکٹ مختص کیے بغیر براہ راست پوائنٹر میں محفوظ کی جاتی ہیں۔ یہ میموری مینیجر کے بوجھ کو 30% کم کرتا ہے۔

JIT بمقابلہ AOT کمپائل: طریقوں کا موازنہ

JIT (Just-In-Time) اور AOT (Ahead-Of-Time) بائٹ کوڈ کو مشین کوڈ میں مرتب کرنے کے دو طریقے ہیں۔ JIT ایپلیکیشن کے نفاذ کے دوران کوڈ مرتب کرتا ہے، گرم مقامات کا تجزیہ کرتا ہے اور انہیں موقع پر بہتر کرتا ہے۔ AOT تمام کوڈ پہلے سے مرتب کرتا ہے — ایپلیکیشن انسٹالیشن کے دوران یا ڈویلپر کی طرف سے۔

ART ہائبرڈ طریقہ (Android 7+) بہترین سمجھا جاتا ہے: ایپلیکیشن شاذ و نادر ہی پکارے جانے والے میتھڈ کے لیے مفسر، hot میتھڈ کے لیے JIT اور profile-guided optimization سے میتھڈ کے لیے AOT استعمال کرتی ہے۔ iOS، اس کے برعکس، LLVM کے ذریعے سخت AOT استعمال کرتا ہے: Swift اور Objective-C Xcode میں بلڈ مرحلے کے دوران مشین کوڈ میں مرتب ہوتے ہیں۔

Apple Developer Documentation, 2024 کے مطابق، Swift runtime ایپلیکیشن کے سائز میں تقریباً 15 MB کا اضافہ کرتا ہے۔ Flutter اپنی Dart VM استعمال کرتا ہے، جہاں JIT کمپائل ہاٹ ریلوڈ کے لیے ڈیبگ موڈ میں اور AOT زیادہ سے زیادہ کارکردگی کے لیے ریلیز موڈ میں کام کرتا ہے۔ React Native Hermes استعمال کرتا ہے — AOT کمپائل کے ساتھ ایک JavaScript انجن جو شروع ہونے کا وقت 50% کم کرتا ہے۔

ARM64 Runtime اور مشین کوڈ

ARM64 Runtime وہ سطح ہے جس پر مشین کوڈ ڈیوائس کے پروسیسر کے ساتھ تعامل کرتا ہے۔ زیادہ تر جدید موبائل ڈیوائسز ARM64 (aarch64) پروسیسرز پر چلتی ہیں۔ Runtime بائٹ کوڈ یا مقامی کالوں کو ARM64 ہدایات میں ترجمہ کرتا ہے جو CPU عمل میں لاتا ہے۔

Runtime کے ذریعے استعمال کردہ اہم ARM64 رجسٹر: x0–x7 (فنکشن پیرامیٹرز)، x8 (بالواسطہ نتیجہ)، x30 (واپسی کا پتہ)، sp (اسٹیک پوائنٹر)، fp (فریم پوائنٹر)۔ ART ARM64 Procedure Call Standard پر عمل کرنے والا کوڈ تیار کرتا ہے: تمام میتھڈ کالز پروسیسر آرکیٹیکچر کے ذریعے متعین کردہ پروٹوکول سے گزرتی ہیں۔

ARM64 ABI کو سمجھنا کارکردگی کی اصلاح کے لیے اہم ہے: ان لائن کیشنگ، برانچ پیشن گوئی اور میموری میں کوڈ کی صف بندی براہ راست runtime کی رفتار کو متاثر کرتی ہے۔ پروفائلنگ ٹولز (Android Studio Profiler, Instruments) دکھاتے ہیں کہ کوڈ کے کون سے حصے runtime میں سب سے زیادہ وقت گزارتے ہیں — ان کو بہتر بنانا سب سے بڑی بہتری لاتا ہے۔

// ART کے ذریعے تیار کردہ ARM64 اسمبلی کی مثال
// دو پیرامیٹرز کے ساتھ میتھڈ کال

mov    x0, x23            // self (this)
mov    x1, x24            // param1
mov    x2, x25            // param2
bl     methodEntryPoint   // runtime کے ذریعے کال
str    x0, [sp, #8]      // نتیجہ محفوظ کریں

اس مثال میں، ARM64 ہدایات mov دلائل کو رجسٹر x0–x2 میں منتقل کرتی ہیں، bl میتھڈ کے اندراج کے مقام کو پکارتی ہے، اور str واپسی کی قدر محفوظ کرتی ہے۔ Runtime ہر میتھڈ کال کے لیے ایسی ہدایات تیار کرتا ہے، devirtualization اور inlining کے ذریعے ترتیب کو بہتر بناتا ہے۔

کارکردگی پر Runtime کا اثر

Runtime اوور ہیڈ متحرک ڈسپیچ کی ناگزیر قیمت ہے۔ Runtime کے ذریعے ہر میتھڈ کال کے لیے درکار ہے: dispatch table میں نفاذ کی تلاش، قسم کی جانچ، IMP کو پکارنا اور نتیجہ واپس کرنا۔ پیمائش سے پتہ چلتا ہے کہ runtime Objective-C میں فی کال 10–50 نینو سیکنڈ اور ART میں 5–20 نینو سیکنڈ کا اضافہ کرتا ہے۔

اوور ہیڈ کو کم کرنے کے لیے، ڈویلپر monomorphic inlining (ART) اور method caching (Objective-C) استعمال کرتے ہیں۔ Kotlin/Native اور Swift براہ راست ARM64 میں مرتب ہوتے ہیں، runtime کی تہہ کو مکمل طور پر ختم کرتے ہیں، لیکن متحرک صلاحیتوں — عکاسی (reflection)، swizzling، متحرک کلاس لوڈنگ کو کھو دیتے ہیں۔