- Dalvik arbeitete mit JIT-Kompilierung und übersetzte den Code während der Laufzeit der Anwendung.
- ART optimiert das System durch die Verwendung der AOT-Kompilierung und führt diesen Prozess während der Installation durch.
- Beide Umgebungen verwenden das DEX-Dateiformat, wodurch die Kompatibilität zwischen den Versionen gewährleistet wird.
- Der Übergang zu ART hat den Batterieverbrauch reduziert und die Systemflüssigkeit verbessert.
Haben Sie sich jemals gefragt, was genau im Hintergrund Ihres Smartphones passiert, wenn Sie eine App öffnen? Die Antwort liegt in der Laufzeitumgebung. Im Android-Ökosystem haben wir uns von einer Architektur, die auf der Dalvik Virtual Machine basierte , zu einem deutlich robusteren System namens Android Runtime (ART) weiterentwickelt. ART ist im Wesentlichen dafür verantwortlich, den von Programmierern geschriebenen Code in Anweisungen zu übersetzen, die die Hardware Ihres Geräts ohne Abstürze verarbeiten kann.
Um das zu verstehen, ist es wichtig zu wissen, dass Android Java nicht nativ ausführt, sondern eine angepasste Version verwendet . Alles beginnt mit dem Quellcode, der in Bytecode umgewandelt und schließlich in einem speziellen Format namens DEX gespeichert wird. Je nachdem, ob Sie eine ältere oder neuere Android-Version verwenden, ändert sich der Ausführungspfad dieses Codes drastisch, was sich auf alltägliche Dinge wie Akkulaufzeit und App-Ladezeit auswirkt.
Das Vermächtnis von Dalvik: Die Just-in-Time-Ära
Dalvik war von Anfang an ein grundlegender Bestandteil von Android. Sein Ziel war klar: Java-Anwendungen sollten auch auf Geräten mit sehr begrenzten Ressourcen ausgeführt werden können. Im Gegensatz zur Standard-Java Virtual Machine war Dalvik darauf optimiert, weniger Speicher zu verbrauchen und mehrere Instanzen gleichzeitig auszuführen, wobei die Thread-Verwaltung dem Linux-Kernel überlassen wurde.
Dalviks Hauptmerkmal war die Just-in-Time -Kompilierung (JIT) . Das bedeutete, dass der Code genau dann in Maschinensprache übersetzt wurde, wenn der Benutzer mit der Anwendung interagierte. Um diese aufwendige Aufgabe nicht jedes Mal wiederholen zu müssen, erstellte Dalvik sogenannte ODEX-Dateien (Optimized DEX) , in denen die bereits übersetzten Teile zwischengespeichert wurden. Das Problem war, dass dieser ständige Kompilierungsprozess CPU-Zyklen verbrauchte und somit mehr Energie benötigte.
Android Runtime (ART): Der Sprung zu Ahead-of-Time
Ab Android 5.0 Lollipop übernahm ART die Kompilierung vollständig. Der größte Unterschied besteht darin, dass ART die Ahead-of-Time-Kompilierung (AOT) implementiert . Anstatt zu warten, bis die Anwendung geöffnet wird, erledigt ART die rechenintensive Arbeit während der Installation. Es verwendet das Tool dex2oat , um DEX-Dateien in ELF-Dateien (Executable and Linkable Format) zu konvertieren, die nativ unter Linux verfügbar sind.
Dank dieses Ansatzes muss das System beim Antippen eines App-Symbols nichts kompilieren; es liest einfach die ELF-Datei und führt sie aus. Dadurch wird der Prozessor weniger beansprucht, der Akku hält länger und Apps laufen deutlich flüssiger. Allerdings gibt es einen kleinen Nachteil: Die Installation von Apps dauert etwas länger und sie benötigen mehr Speicherplatz als mit Dalvik.
Technischer Vergleich und wichtigste Verbesserungen
Obwohl beide Umgebungen kompatibel sind und denselben DEX-Bytecode ausführen, hat ART Verbesserungen eingeführt, die das System enorm beschleunigen. Eine der wichtigsten ist die automatische Speicherbereinigung (Garbage Collection, GC) . In Dalvik verursachte die Speicherbereinigung früher die lästigen Pausen oder Ruckler in der Benutzeroberfläche (die berüchtigte Verzögerung). ART hat dies mit einem primär parallelen System neu gestaltet , wodurch Pausen unabhängig vom verwendeten Speicher auftreten.
- Erweitertes Debugging: ART ermöglicht es Entwicklern, zu sehen, welche Sperren Threads halten, und Klasseninstanzen mit viel höherer Genauigkeit zu verfolgen.
- Genaue Diagnosen: Wenn eine App abstürzt, sind die Fehlerberichte nun wesentlich detaillierter, insbesondere in Fällen von NullPointerException.
- Speicherverwaltung: Im Gegensatz zu Dalvik, das einen nicht auslagerbaren Cache verwendete, nutzt ART RAM-Speicher, der Seitennummerierung ist möglich, Optimierung der Hardwarenutzung.
Der Verpackungsprozess: Vom Code zur APK
Damit eine dieser Umgebungen funktioniert, muss der Code einen Montageprozess durchlaufen. Zuerst erstellt der Java-Compiler .class-Dateien, die das dex- Tool anschließend in eine einzige classes.dex-Datei umwandelt. Diese Datei bildet den Kern der APK und wird von ART oder Dalvik verarbeitet.
Tools wie aapt werden verwendet , um Ressourcen zu paketieren, und zipalign optimiert die Datenausrichtung, um einen möglichst effizienten Speicherzugriff des Prozessors zu gewährleisten. Sobald die APK auf dem Gerät ankommt, geschieht die eigentliche Magie: Bei Vorhandensein von ART wird die ELF-Datei generiert; bei Vorhandensein von Dalvik wird die ODEX-Datei dynamisch erstellt .
Interessante Fakten über ROMs und den Deodexing-Prozess
In der Welt der Custom-ROMs sind die Begriffe ODEX und Deodex weit verbreitet . Da die ODEX-Datei hardwareabhängig ist und vom jeweiligen System abhängt, auf dem sie erstellt wurde, lässt sie sich nicht ohne Weiteres von einem Telefon auf ein anderes übertragen. Um eine App zu modifizieren, ohne das System zum Absturz zu bringen, führen Entwickler einen Deodexing- Prozess durch . Dabei wird die optimierte Datei in die APK integriert, um deren Bearbeitung zu erleichtern.
Das Android-Ökosystem hat sich von einer flexiblen, aber energieintensiven virtuellen Maschine zu einer optimierten Laufzeitumgebung entwickelt, die die Benutzerfreundlichkeit in den Vordergrund stellt. Während Dalvik den Fokus auf die Vielseitigkeit der Echtzeit-Codeübersetzung legte, maximiert ART die Hardwareauslastung durch Vorkompilation und sorgt so für stabilere, schnellere und energieeffizientere Software.
Index