Theory
Battery પર Java
તમે FestConnect ને Java માં લખો છો. પણ પ્રમાણભૂત Java Virtual Machine એ પુષ્કળ memory અને વીજળીના જોડાણવાળાં desktops અને servers માટે બંધાયું હતું. 2008 ના ફોન પાસે એનો અંશ જ હતો અને એવી battery હતી જે ઝડપથી ખાલી થતી.
એટલે Google એ સામાન્ય JVM વાપર્યું નહીં. એણે પોતાનું runtime બાંધ્યું, Dalvik Virtual Machine (DVM), જે નાના, battery પર ચાલતા ઉપકરણ માટે ગોઠવાયેલું હતું. એ કેમ જુદું છે અને એની જગ્યા શું આવ્યું એ જાણવું પરીક્ષાનો પ્રિય વિષય છે.
Theory
Scooter, truck નહીં
પહોંચાડવાની truck (JVM) શક્તિશાળી છે પણ ભારે અને બળતણ પીનારી, જે ગોદામ માટે સંપૂર્ણ છે અને શહેરના ઝડપી કામ માટે નકામી. Scooter (Dalvik) એકસાથે ઓછું લઈ જાય છે પણ બળતણ ચૂસકીથી પીએ છે અને ટ્રાફિકમાંથી સરકી જાય છે. Memory અને battery માં તંગ ફોન માટે તમને scooter જ જોઈએ. Dalvik એ Google નું scooter હતું: mobile ની મર્યાદાઓ પ્રમાણે ઘડાયેલું વધુ પાતળું VM, server ની કાચી શક્તિ માટે નહીં.
Theory
તમારો code કેવી રીતે ચાલે છે
FestConnect નો રસ્તો:
- Java નો સ્રોત Java ના bytecode (
.class) માં compile થાય છે. - એક ઓજાર એને Dalvik ના bytecode (`.dex`) માં ફેરવે છે, જે નાનું છે.
- DVM એ
.dexચલાવે છે.
DVM ને mobile માટે અનુકૂળ શું બનાવતું હતું:
- Register આધારિત (JVM એ stack આધારિત છે), જે મર્યાદિત CPU ને બંધબેસે છે.
- નાનો memory નો વ્યાપ.
- દરેક app પોતાના DVM માં અને પોતાની પ્રક્રિયામાં ચાલે છે, એટલે તૂટી પડતી એક app બીજીને બગાડી શકતી નથી (sandboxing).
Android 5.0 થી ART એ Dalvik ની જગ્યા લીધી.
At a glance
Dalvik સામે પ્રમાણભૂત JVM
| પાસું | Dalvik VM | પ્રમાણભૂત JVM |
|---|---|---|
| રચના | register આધારિત | stack આધારિત |
| શું ચલાવે છે | .dex નું bytecode | .class નું bytecode |
| કોના માટે બંધાયું | ઓછી memory વાળા mobiles | desktops/servers |
| App દીઠ | પોતાનું VM | સામાન્ય રીતે વહેંચાયેલું |
Think first
દરેક app ને પોતાનું VM કેમ આપવું?
Android પર FestConnect અને એક રમત, દરેક પોતાના અલગ VM માં ચાલે છે. જો રમતમાં ખરાબ bug હોય અને એ તૂટી પડે, તો એ અલગ રહેવાથી તમને શું મળે છે? Tap કરતાં પહેલાં વિચારો.
Show the answer
દરેક app પોતાના VM અને પોતાની પ્રક્રિયામાં ચાલતી હોવાથી, રમતનું તૂટવું ત્યાં જ સમાઈ જાય છે: એ FestConnect, OS, કે બીજી apps ને પાડતું નથી. આ sandboxing સલામતી પણ સુધારે છે, કારણ કે એક app બીજીની memory છૂટથી વાંચી શકતી નથી. કિંમત છે દરેક app દીઠ થોડો વધારાનો બોજ, પણ અનેક app વાળા ફોન પર સ્થિરતા અને સલામતી એની કિંમત ચૂકવવા લાયક છે. અલગ રહેવું એ Android ની રચનાની મુખ્ય પસંદગી છે.
Quiz
પ્રમાણભૂત JVM સામે Dalvik VM ને કઈ જોડ બરાબર વર્ણવે છે?
- Dalvik register આધારિત છે અને .dex ચલાવે છે; JVM stack આધારિત છે અને .class ચલાવે છે
- Dalvik stack આધારિત છે અને .class ચલાવે છે; JVM register આધારિત છે
- બંને એકસરખાં છે; Dalvik એ ફક્ત JVM નું નવું નામ છે
- Dalvik કોઈ compilation વગર .java ના સ્રોતની files સીધી ચલાવે છે
Show the answer
Dalvik register આધારિત છે અને .dex ચલાવે છે; JVM stack આધારિત છે અને .class ચલાવે છે
Dalvik register આધારિત છે અને .dex નું bytecode ચલાવે છે, જ્યારે પ્રમાણભૂત JVM stack આધારિત છે અને .class નું bytecode ચલાવે છે (A). વિકલ્પ B બંને અદલાબદલ કરે છે. Dalvik એ mobile માટે બંધાયેલું અલગ VM છે, JVM નું નવું નામ નહીં (C). અને કોઈ VM .java નો સ્રોત સીધો ચલાવતું નથી (D): સ્રોત હંમેશા પહેલાં compile થાય છે (.class માં, પછી .dex માં ફેરવાય છે). Register આધારિત અને .dex ની હકીકતો પરીક્ષાની પ્રિય છે.
Watch out
DVM ના ફાંદા
1. 'Dalvik એ JVM છે': ના. એ Google નું પોતાનું, register આધારિત VM છે જે .dex ચલાવે છે અને mobile માટે રચાયું છે.
2. ART ભૂલી જવું: Android 5.0 થી ART (Android Runtime) એ Dalvik ની જગ્યા લીધી, અને એ ઝડપી શરૂઆત માટે install વખતે AOT (પહેલેથી) compilation વાપરે છે. જો પુછાય કે 'Dalvik ની જગ્યા શું આવ્યું?', તો જવાબ છે ART.
3. .class થી .dex નું પગલું છોડી દેવું: Java પહેલાં .class માં compile થાય છે, પછી .dex માં ફેરવાય છે; એ એક જ પગલું નથી.
Theory
તમે VM હાથે ચલાવવાના નથી
સદ્ભાગ્યે, તમે Dalvik કે ART ને જાતે ક્યારેય બોલાવતા નથી: Android Studio તમારો FestConnect નો code આપોઆપ compile કરે છે, ફેરવે છે, અને મૂકે છે. પણ runtime સમજવાથી ખબર પડે છે કે Android ની apps Java/Kotlin ની હોવા છતાં કેમ મૂળભૂત જેવી લાગે છે, અને install માં કેમ થોડી વાર લાગે છે (ART પહેલેથી compile કરે છે). આગળ તમે એ ઓજારો સ્થાપો છો જે આ બધું કરે છે: JDK, Android Studio, અને SDK.
Summary
Key takeaways
- Dalvik VM એ Android ની apps ચલાવતું હતું: Java એ .class માં compile થાય છે, .dex માં ફેરવાય છે, અને Dalvik એ .dex ચલાવે છે.
- Dalvik register આધારિત છે (JVM stack આધારિત) અને એનો વ્યાપ નાનો છે, જે ઓછી memory અને battery વાળા ફોન માટે ગોઠવાયેલો છે.
- દરેક app પોતાના VM અને પ્રક્રિયામાં ચાલે છે, જે અલગપણું (sandboxing) અને સ્થિરતા આપે છે.
- Android 5.0 થી ART (Android Runtime) એ Dalvik ની જગ્યા લીધી, અને એ પહેલેથી (AOT) compilation વાપરે છે.
- તમે VM ને ક્યારેય હાથે ચલાવતા નથી; ઓજારો compile, ફેરવવું, અને મૂકવાનું સંભાળે છે.
- Memory hook: scooter, truck નહીં, register આધારિત અને .dex.