ART: Was ist das, die Laufzeitumgebung und wie es funktioniert

Was ist ART?

Android Runtime (ART) ist eine Laufzeitumgebung für Anwendungen, die den DEX-Bytecode vor dem Start in nativen Maschinencode kompiliert. Im Gegensatz zu Dalvik, das während der Ausführung die Just-In-Time-Kompilierung nutzte, führt ART die Ahead-Of-Time-Kompilierung (AOT) bei der Installation der APK durch. Diese grundlegende Änderung der Architektur führte zu einer deutlichen Beschleunigung von Apps und einer geringeren Energieaufnahme.

Erstmals erschien ART als experimentelle Option in Android 4.4 KitKat. Entwickler konnten sie in den Entwickleroptionen aktivieren und ihre Apps testen. In Android 5.0 Lollipop wurde ART zur Standard-Laufzeitumgebung, und Dalvik wurde vollständig aus der Plattform entfernt. Bis zur Veröffentlichung von Android 7.0 Nougat erhielt ART einen hybriden Kompilierungsmodus.

Entwicklungsgeschichte

Die Entscheidung, Dalvik durch ART zu ersetzen, war nicht plötzlich. Die Arbeit an der neuen Umgebung begann im Jahr 2012, als Google die Einschränkungen des JIT-Ansatzes erkannte. Die Hauptziele: schnellere App-Starts, geringere CPU-Last und weniger Energieverbrauch. Die Entwicklung wurde vom Team Android Runtime Group geleitet, das zuvor an den Optimierungen von Dalvik gearbeitet hatte.

Architekturänderungen

ART verwendet dieselbe Registerarchitektur wie Dalvik, jedoch mit einem vollständig überarbeiteten Compiler. Anstelle eines Interpreters und JIT-Compilers enthält ART den AOT-Compiler dex2oat, der die DEX-Dateien bei der Installation in ELF-Binaries umwandelt. Dadurch startet die App auf ART sofort mit nativer Leistung, ohne Aufwärmphase.

Die Architektur von ART: von Dalvik zur neuen Umgebung

ART hat die wichtigsten Prinzipien von Dalvik beibehalten: die Isolierung von Apps in separaten Prozessen, die Registerarchitektur und die Unterstützung des DEX-Formats. Die interne Implementierung wurde jedoch vollständig neu geschrieben. Statt des Dalvik-Interpreters umfasst ART drei Ausführungsmodi: den Interpreter, den JIT-Compiler und den AOT-Compiler dex2oat. Die Wahl des Modus hängt von der Phase im Lebenszyklus der App ab.

Ein Schlüsselbestandteil von ART ist dex2oat (dalvik executable to optimized android translator). Dieses Dienstprogramm wird bei der Installation der App ausgeführt (ab Android 7.0 auch während der Hintergrundoptimierung). dex2oat liest die DEX-Dateien aus der APK, optimiert den Bytecode und erzeugt eine OAT-Datei – eine ELF-Binary mit nativem Code. OAT-Dateien werden im Verzeichnis /data/dalvik-cache/ gespeichert.

# OAT-Dateien auf dem Gerät prüfen
adb shell ls -la /data/dalvik-cache/arm64/

# Erzwungene Neukompilierung der App
adb shell cmd package compile -m speed com.example.app

Komponenten von ART

Das ART-System besteht aus mehreren miteinander verbundenen Modulen. Der Compiler dex2oat ist für die Erzeugung des nativen Codes verantwortlich. Der Garbage Collector (GC) verwaltet die Freigabe von Speicher. Der Interpreter führt selten aufgerufenen Code ohne Kompilierung aus. Der Profiler verfolgt Hot Methods für die hybride Kompilierung. Jedes Modul kann unabhängig arbeiten, was ART flexibel und skalierbar macht.

Hybride Kompilierung: JIT + AOT + Profilerstellung

Seit Android 7.0 Nougat verwendet ART einen hybriden Ansatz für die Kompilierung, der die Vorteile von JIT und AOT vereint. Bei der Installation führt ART keine vollständige AOT-Kompilierung mehr durch – stattdessen startet die App im interpretierten Modus mit JIT-Kompilierung der Hot Methods. Dadurch verkürzen sich die Installationszeit und der benötigte Speicherplatz.

Parallel arbeitet der Hintergrundprofiler (background profiler). Er sammelt Ausführungsstatistiken: welche Methoden am häufigsten aufgerufen werden, welche Codezweige ausgeführt werden, welche Klassen geladen werden. Nachdem genügend Daten gesammelt wurden (meist nach 2–3 App-Starts), startet ART dex2oat im Hintergrund und kompiliert nur die profilierten Hot Methods in nativen Code.

Kompilierungsmodi

ART unterstützt mehrere Kompilierungsmodi, die über system_server gesteuert werden. Der Modus „speed" kompiliert alle Methoden per AOT (maximale Leistung, lange Installation). Der Modus „speed-profile" kompiliert nur die profilierten Hot Methods (ausgewogenes Verhältnis von Geschwindigkeit und Größe). Der Modus „verify" prüft den Bytecode nur ohne Kompilierung (minimaler Speicherbedarf, Interpretation). Standardmäßig wird speed-profile verwendet – optimal für die meisten Apps.

Der ART-Profiler

Der Profiler sammelt Ausführungsdaten in speziellen .prof-Dateien. Jede App speichert ihr Profil in /data/misc/profiles/. Sobald ein Schwellenwert erreicht ist (meist 1000 Stichproben), startet der Profiler dex2oat, um die erkannten Hot Methods zu kompilieren. Die Profile bleiben zwischen App-Updates erhalten, wodurch die erneute Optimierung nach OTA-Systemupdates beschleunigt wird.

Garbage Collection in ART

Die Garbage Collection in ART wurde im Vergleich zu Dalvik grundlegend verbessert. Statt des einthreadigen Concurrent Mark and Sweep (CMS) verwendet ART einen generationalen Collector mit mehreren Optimierungen: Moving Collector (Heap-Verdichtung), Large Object Space (getrennte Speicherung großer Objekte) und Concurrent Compaction (parallele Verdichtung).

Eine typische GC-Pause in ART beträgt 2–3 ms gegenüber 5–10 ms in Dalvik. Möglich wurde das durch mehrere Mechanismen. Erstens verwendet ART Read Barriers anstelle von Stop-the-World für die Concurrent-Phasen. Zweitens verarbeitet der generationale Collector in den meisten Zyklen nur die junge Generation der Objekte, ohne den gesamten Heap zu berühren. Drittens wird der Large Object Space (LOS) getrennt belegt und nimmt nicht an normalen GC-Zyklen teil.

// GC-Logs für die Fehlersuche aktivieren
System.logV("ART", "GC trigger: allocation failed");

// GC erzwungen aufrufen (in Production nicht empfohlen)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

Speicherlecks in der ART-Ära

Trotz des verbesserten GC bleiben Speicherlecks ein relevantes Problem. Eine ART-spezifische Ursache ist das Laden nativer Bibliotheken über JNI ohne korrekte Freigabe. Wenn nativer Code Speicher über malloc belegt, aber free nicht aufruft, kann ART diesen Speicher nicht freigeben – er liegt außerhalb des verwalteten Heaps. Das Tool AddressSanitizer im Android NDK hilft, solche Lecks zu erkennen.

ART vs. Dalvik: Vergleichsanalyse

ART und Dalvik sind zwei grundlegend verschiedene Implementierungen derselben Aufgabe: der Ausführung von Android-Apps. Die Unterschiede betreffen alle Ebenen: von der Kompilierung bis zur Speicherverwaltung. Nachfolgend ein Vergleich anhand der wichtigsten Leistungs- und Kompatibilitätsparameter.

Der Hauptvorteil von ART ist die Beseitigung der JIT-Aufwärmphase. Auf Dalvik konnte die App in den ersten 3–10 Sekunden verzögern, während der JIT Hot Methods kompilierte. Auf ART sind alle Methoden bereits in nativen Code kompiliert (oder werden im Hintergrund kompiliert). Besonders sichtbar ist das in Spielen und Apps mit anspruchsvoller UI: Der FPS-Unterschied kann zugunsten von ART 15–20% betragen.

Kompatibilität

Alle für Dalvik geschriebenen Apps laufen auf ART ohne Änderungen. Google garantiert vollständige Abwärtskompatibilität auf der Ebene des DEX-Bytecodes. Eine Ausnahme bildet Code, der die Dalvik-spezifische interne API über Reflexion verwendet: Mitglieder der Klassen dalvik.system.DexFile, die im Android SDK mit @hide markiert sind. Solcher Code sollte auf die Verwendung der öffentlichen APIs umgestellt werden.

Java 8 Unterstützung und Desugaring

ART war die erste Android-Laufzeitumgebung mit nativer Unterstützung für Java 8 Funktionen. Ab Android 7.0 enthält ART Desugaring – den Prozess der Umwandlung von Java 8 Konstrukten (Lambdas, Method References, Stream API) in äquivalenten Java 7 Code. Dadurch kann moderne Syntax verwendet werden, ohne die Kompatibilität mit älteren Geräten zu verlieren.

Das Desugaring wird vom Compiler D8 durchgeführt und funktioniert wie folgt. Der Quellcode mit einem Lambda wird in eine synthetische Methode innerhalb derselben Klasse umgewandelt, und das Lambda wird durch einen invoke-custom-Aufruf ersetzt. Die ART-Laufzeitumgebung enthält Unterstützung für die Anweisung invoke-custom, die speziell für Java 8 hinzugefügt wurde. Auf Geräten mit Android 6.0 und älter werden Lambdas in anonyme Klassen desugared.

// Java 8 Lambda – Desugaring in ART
button.setOnClickListener(v -> handleClick(v));

// Nach dem Desugaring (Äquivalent in Java 7)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

Einschränkungen des Desugaring

Nicht alle Java 8 Funktionen werden vom Desugaring unterstützt. Die java.time API (Datum und Uhrzeit) ist nur über desugar_jdk_libs verfügbar – eine zusätzliche Bibliothek, die in build.gradle hinzugefügt wird. Auch die Stream API erfordert desugar_jdk_libs. java.util.function und Optional funktionieren ohne zusätzliche Abhängigkeiten. Vollständige Java 8 Unterstützung ist auf Geräten mit Android 8.0 und neuer ohne Desugaring verfügbar.

App-Optimierung für ART

Obwohl ART abwärtskompatibel ist, verbessern einige Optimierungspraktiken die Leistung gerade in dieser Umgebung. Die wichtigste Empfehlung lautet, Reflexion zu minimieren. ART kompiliert Methoden, die zum Kompilierungszeitpunkt sichtbar sind, zu direkten Maschinencode-Aufrufen. Reflexion zwingt ART dazu, zusätzliche Stubs zu erzeugen, was die Ausführung um 10–15% verlangsamt.

Ab Android 9.0 bietet ART Unterstützung für die App Startup Optimization. Der Entwickler kann Initialisierungsklassen im Manifest über <initialization> markieren, und ART lädt sie beim App-Start vorab. Dadurch verkürzt sich die Startzeit um 5–15% für Apps mit vielen Plugins oder Bibliotheken.

<!-- App Startup Optimization in AndroidManifest.xml -->
<application>
    <profileable
        android:shell="true"
        android:enable="true" />
</application>

Leistungsüberprüfung

Zur Leistungsmessung auf ART verwenden Sie systrace und perfetto. Systrace zeigt die Kompilierungszeit von dex2oat, die GC-Häufigkeit und die Bildrate beim Rendering. Perfetto liefert detailliertere Informationen: Thread-Verteilung, Zeit für JNI-Übergänge und das Laden nativer Bibliotheken. Start: adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm.