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 में मल्टी-डेक्स की शुरुआत के साथ सीमा हटा दी गई)।

Android SDK Build Tools में शामिल dx उपयोगिता, class फ़ाइलों को DEX में बदलने के लिए उपयोग की जाती है। कमांड का उदाहरण: dx --dex --output=classes.dex myapp.jar. आधुनिक प्रोजेक्ट D8 का उपयोग करते हैं, जो बेहतर अनुकूलन और Java 8+ सुविधाओं के समर्थन के साथ dx का उत्तराधिकारी है।

# 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 कोड का विश्लेषण करता है, बार-बार उपयोग की जाने वाली (हॉट) विधियों की पहचान करता है और उन्हें 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 उपयोगिता जावा 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

मल्टी-डेक्स: 65536 सीमा को पार करना

65,536 विधियों (16-बिट इंडेक्स सीमा) की DEX प्रारूप सीमा बड़े एप्लिकेशन के लिए एक गंभीर समस्या बन गई। समाधान Android 5.0 के साथ आया: मल्टी-डेक्स समर्थन एक एप्लिकेशन को कई DEX फ़ाइलें रखने की अनुमति देता है। मुख्य classes.dex में प्रवेश बिंदु होते हैं, जबकि अतिरिक्त classes2.dex, classes3.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 पर टूट सकता है।