Unterschiede zwischen JVM und Dalvik VM
Programmiersprachen unterscheidet man normalerweise zwischen interpretierten und kompilierten Sprachen. C++ ist ein typisches Beispiel für eine Compiler-Sprache: Sie erstellen Ihren Quellcode und der Compiler wandelt diesen in für den PC ausführbaren Maschinen-Code um. Letzterer wird dann ausgeführt, wenn Sie beispielsweise unter Windows eine .exe-Datei starten. Das geht dann sehr schnell. Bei PHP, einer typischen Interpreter-Sprache, wird dagegen nichts vorab kompiliert, sondernd der Quellcode wird zur Laufzeit (also während der Ausführung) vom Interpreter abgearbeitet. Deshalb dauert die Ausführung eines derartigen Programmes etwas länger.
Java (und auch die Microsoft .Net-Framework-Programmiersprache C#) gehen anders vor. Java kompiliert zunächst den Quellcode und erstellt daraus einen Bytecode (bei C+ heißt dieser Zwischencode Common Intermediate Language). Dieser Bytecode wird dann zur Laufzeit (also bei der Ausführung des Programms) in der Java-Laufzeitumgebung ausgeführt und von der Java Virtual Machine (die Bestandteil der Java-Runtime ist) interpretiert. Die viel gelobte Plattform-Unabhängigkeit von Java wird dadurch möglich, dass für alle gängigen Betriebssysteme eine Java-Runtime mit JVM existiert.
Die konkrete Vorgehensweise bei der Entstehung eines Java-Programmes sieht also folgendermaßen aus: Der Programmierer erstellt mit einem Editor Quelltext (diese Datei hat die Endung .java) und kompiliert den Quelltext zu Bytecode (diese Datei trägt die Endung .class, weil es sich dabei immer um Klassen handelt - ein Java-Programm besteht, da Java eine streng objektorientierte Programmiersprache ist, immer aus Klassen, mindestens aus einer einzigen). Diese .class-Dateien werden dann gestartet und interpretiert (daneben gibt es aus Performance-Gründen auch die Möglichkeit, Bytecode sofort zu kompilieren: Die so genannte HotSpot-Technik). Soweit zur Vorgehensweise beim "typischen" Java auf einem Desktop-PC, einem Notebook oder einem Server (wobei bei der Serverprogrammierung wieder spezielle Begriffe wie Servlets oder Java Server Pages hinzukommen).
Bei Android sieht die Entwicklung von Programmiercode folgendermaßen aus: Der Developer erstellt Quellcode (.java), der dann mit einem normalen Java-Compiler (javac) in Byte-Code kompiliert wird (.class). Diese Klassen werden dann durch das dx-Tool aus dem Android SDK vom .class-Format in das .dex-Format ("Dalvik Executable") umgewandelt, es handelt sich beim Bytecode, den die Dalvik VM im Anschluss ausführt, also nicht mehr um Java-Bytecode, sondern um Dalvik-Bytecode. Dieser Vorgang heißt Cross-Compiling. Die Dalvik VM führt dann zur Laufzeit den Dalvik-Bytecode aus.
Um Speicherplatz zu sparen, werden dabei mehrere .class-Dateien zu einer einzigen .dex-Datei zusammengefasst. Diese .dex-Dateien werden dann in .apk-Dateien (Android Package) gepackt und ein Manifest hinzugefügt. Diese apk-Dateien werden schließlich auf dem Android-Smartphone installiert und die App dann ausgeführt.
Ein weiterer Unterschied zwischen einer JVM, wie sie auf dem Desktop-PC zum Einsatz kommt, und der Dalvik VM: Die klassische Java VM basiert auf einem Kellerautomaten und nutzt damit nicht die Tatsache aus, dass Prozessoren in der Regel Register haben. Die Dalvik VM ist dagegen eine Registermaschine und damit optimiert für die Architektur heutiger Prozessoren wie die ARM-CPUs, die eben Registermaschinen sind. Solche Registermaschinen besitzen eigene besonders schnell zugreifbare Speicherzellen (die Register), es handelt sich also um Mikroprozessoren mit Zwischenspeicher direkt im Prozessor.
Der Bytecode der Dalvik VM ist nicht kompatibel zu Bytecode von JVM. Seit Android 2.2 besitzt die Dalvik VM zudem einen JIT-Compiler ("Just In Time"). Ein Just-in-time-Compiler übersetzt zur Laufzeit und erst bei Bedarf den Bytecode direkt in Maschinen-Code. Das bietet gegenüber dem Interpreter einen Geschwindigkeitsvorteil.