मोबाइल डेवलपमेंट में 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} नैनोसेकंड")
    }
}

उपरोक्त उदाहरण में, 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 सभी मेथड की सूची निकालता है। यह क्रिया में रिफ्लेक्शन है — रनटाइम पर क्लास मेटाडेटा तक पहुँच। इस दृष्टिकोण का उपयोग XCTest में डायनामिक टेस्ट रजिस्ट्रेशन के लिए किया जाता है।

isa पॉइंटर और tagged pointers

isa पॉइंटर प्रत्येक ऑब्जेक्ट के पहले 8 बाइट्स में संग्रहीत ऑब्जेक्ट की क्लास का पॉइंटर है। iOS 12 से शुरू करके, Apple ने अनुकूलन के लिए isa-swizzling शुरू किया: isa के निचले बिट्स ऑब्जेक्ट की स्थिति के बारे में अतिरिक्त जानकारी एन्कोड करते हैं। Tagged pointers एक और अनुकूलन है जहाँ 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 कम्पाइलेशन hot reload के लिए डीबग मोड में काम करता है, और 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 परत को पूरी तरह से समाप्त करते हैं, लेकिन डायनामिक क्षमताओं — रिफ्लेक्शन, swizzling, डायनामिक क्लास लोडिंग को खो देते हैं।