Theory
एक battery पर Java
आप FestConnect Java में लिखते हैं। पर standard Java Virtual Machine desktops और servers के लिए बनाई गई थी, जिनमें ढेर सारी memory और mains power होती है। 2008 में एक phone में उसका बहुत छोटा हिस्सा होता था और एक battery जो जल्दी ख़त्म होती थी।
तो Google ने सादे JVM का इस्तेमाल नहीं किया। इसने अपना ख़ुद का runtime बनाया, Dalvik Virtual Machine (DVM), एक छोटे, battery-powered device के लिए tuned। यह क्यों अलग है, और इसकी जगह क्या आया, यह एक favourite exam topic है।
Theory
एक scooter, truck नहीं
एक delivery truck (JVM) powerful है पर भारी और प्यासा है, एक warehouse के लिए perfect, एक जल्दी वाले city errand के लिए wasteful। एक scooter (Dalvik) एक बार में कम ले जाता है पर fuel कम पीता है और traffic से तेज़ी से निकल जाता है। एक phone के लिए, memory और battery में tight, आप scooter चाहते हैं। Dalvik Google का scooter था: एक leaner VM जो mobile constraints के हिसाब से shaped है, raw server power के लिए नहीं।
Theory
आपका code कैसे चलता है
FestConnect के लिए path:
- Java source Java bytecode (
.class) में compile होता है। - एक tool इसे Dalvik bytecode (`.dex`) में convert करता है, जो छोटा है।
- DVM
.dexको execute करता है।
जो चीज़ें DVM को mobile-friendly बनाती थीं:
- Register-based (JVM stack-based है), जो limited CPUs के लिए फिट है।
- छोटा memory footprint।
- हर app अपने DVM instance / process में चलती है, तो एक crash होने वाली app दूसरी को corrupt नहीं कर सकती (sandboxing)।
Android 5.0 से, ART ने Dalvik की जगह ली।
At a glance
Dalvik बनाम standard JVM
| Aspect | Dalvik VM | Standard JVM |
|---|---|---|
| Architecture | register-based | stack-based |
| चलाता है | .dex bytecode | .class bytecode |
| बनाया गया | low-memory mobiles के लिए | desktops/servers के लिए |
| Per app | अपना VM instance | आमतौर पर shared |
Think first
हर app को अपना VM क्यों दें?
Android पर, FestConnect और एक game हर एक अपने अलग VM instance में चलती है। अगर game में एक बुरा bug हो और यह crash करे, वह isolation आपको क्या देता है? Tap करने से पहले सोचिए।
Show the answer
क्योंकि हर app अपने VM और process में चलती है, game का crash contained रहता है: यह FestConnect, OS, या दूसरी apps को नीचे नहीं गिराता। यह sandboxing security भी बेहतर बनाता है, क्योंकि एक app दूसरी की memory freely नहीं पढ़ सकती। Cost है प्रति app थोड़ा ज़्यादा overhead, पर एक multi-app phone पर stability और safety इसके worth हैं। Isolation एक core Android design choice है।
Quiz
कौन सा pair standard JVM के मुकाबले Dalvik VM को सही describe करता है?
- Dalvik register-based है और .dex चलाता है; JVM stack-based है और .class चलाता है
- Dalvik stack-based है और .class चलाता है; JVM register-based है
- दोनों identical हैं; Dalvik बस JVM का rename है
- Dalvik बिना किसी compilation के सीधे .java source files चलाता है
Show the answer
Dalvik register-based है और .dex चलाता है; JVM stack-based है और .class चलाता है
Dalvik register-based है और .dex bytecode execute करता है, जबकि standard JVM stack-based है और .class bytecode execute करता है (A)। Option B दोनों को swap कर देता है। Dalvik mobile के लिए बनाया एक अलग VM है, JVM का rename नहीं (C)। और कोई भी VM .java source सीधे नहीं चलाता (D): source हमेशा पहले compile होता है (.class में, फिर .dex में convert होता है)। Register-based, .dex facts exam favourites हैं।
Watch out
DVM traps
1. 'Dalvik ही JVM है': नहीं। यह Google का अपना, register-based VM है जो .dex चलाता है, mobile के लिए design किया गया।
2. ART भूलना: Android 5.0 से, ART (Android Runtime) ने Dalvik की जगह ली, install पर तेज़ launches के लिए AOT (ahead-of-time) compilation इस्तेमाल करते हुए। अगर पूछा जाए 'Dalvik की जगह क्या आया?', answer ART है।
3. .class से .dex step skip करना: Java पहले .class में compile होता है, फिर .dex में convert होता है; यह एक step नहीं है।
Theory
आप VM हाथ से नहीं चलाएँगे
अच्छी बात है, आप कभी Dalvik या ART को ख़ुद invoke नहीं करते: Android Studio आपके FestConnect code को automatically compile, convert, और deploy करता है। पर runtime समझना बताता है Android apps Java/Kotlin में क्यों हैं फिर भी native feel करती हैं, और install में एक पल क्यों लग सकता है (ART ahead of time compile कर रहा है)। अगला आप वे tools install करते हैं जो यह सब करते हैं: JDK, Android Studio, और SDK।
Summary
Key takeaways
- Dalvik VM Android apps चलाता था: Java .class में compile होता है, .dex में convert होता है, और Dalvik .dex execute करता है।
- Dalvik register-based है (JVM stack-based है) और इसका छोटा footprint है, low-memory, battery phones के लिए tuned।
- हर app अपने VM instance/process में चलती है, isolation (sandboxing) और stability देते हुए।
- Android 5.0 से ART (Android Runtime) ने Dalvik की जगह ली, ahead-of-time (AOT) compilation इस्तेमाल करते हुए।
- आप कभी VM हाथ से नहीं चलाते; tools compile, convert, और deploy handle करते हैं।
- Memory hook: एक scooter, truck नहीं, register-based और .dex।