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 कॉल (production में अनुशंसित नहीं)
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 पर, कोई ऐप पहले 3–10 सेकंड के लिए धीमा हो सकता था जबकि JIT हॉट विधियों को कंपाइल करता था। 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।