Nein, keine Sorge: Ich lasse jetzt nicht den Physiker raushängen und erkläre die Allgemeine Relativitätstheorie (ART). Heute geht es vielmehr um ein etwas weniger anspruchsvolles Feature von Android 4.4 alias Kitkat: Die neue Android Runtime, die zufälligerweise ebenfalls ART abgekürzt wird.

ART kam diesen November etwas überraschend über die Android-Community, denn die neue Runtime wurde nicht groß angekündigt, wenngleich wohl in Googles Hinterzimmern schon seit einer ganzen Weile programmiert. Kein Wunder: ART ist ausdrücklich im Experimental-Stadium. Und wie das heutzutage nun einmal so ist: Man macht uns Nutzer zu Testern.

Das heißt: Soweit man überhaupt in den Genuss des neuen Features kommt. Selbst das "steinalte" 2012er Nexus 7 ist außen vor, von wirklich alten Geräten gar nicht zu reden. Man braucht schon ein aktuelles Nexus-Gerät – oder einen Emulator. Nur dort findet sich in den Entwickler-Optionen der magische Button. Der führt zu einem Neustart, der auf dem aktuellen Emulator leider bis in alle Ewigkeit dauert. Grund ist ein Fehler im Emulator-Grundsystem, für den immerhin bereits ein Patch im Android Open Source Project existiert. Die Bytecode-Konvertierung schlägt nämlich irgendwo fehl und versucht es vernünftigerweise solange erneut, bis der ungeduldige Nutzer den Prozess abschießt. (Mehr dazu hier) Glücklicherweise hat ein hilfsbereiter Bastler das betroffene System Image des Emulators gepatched und stellt es auf einer japanischen Seite zum Download zur Verfügung. Details dazu stehen hier auf StackOverflow.com.

Auf die ART-Art


Kitkat ist nunmehr über vier Wochen alt, deshalb erzähle ich dem geneigten Leser nichts Neues, wenn ich die Merkmale von ART wie folgt zusammenfasse: Beim ersten Start einer App konvertiert ART deren Code in Maschinencode. Just-in-time-Compilation wird also abgelöst durch Precompilation.

Das klingt simpel, hat aber wichtige Folgen: Erstens läuft der erzeugte Maschinencode (im neuen OAT-Format) schneller als der DEX-Bytecode auf der altgedienten Dalvik-VM. Zweitens muss der konvertierte Code irgendwo gespeichert werden – und verbraucht somit zusätzlichen Platz, und zwar laut verschiedener Internet-Quellen im Schnitt um die 20%. Der relative Wert hängt stark ab vom Verhältnis zwischen Programmcode und Ressourcen wie Grafiken oder Sounds, die natürlich nicht mehr Platz brauchen. Drittens dauert der erste Start einer App je nach deren Größe merklich länger, weil sie zunächst übersetzt werden muss.

Damit verbietet sich die Nutzung von ART auf jeden Fall für fleißige Entwickler, die ihre App oft hintereinander neu bauen und auf dem Gerät (oder gar Emulator) installieren: Jedesmal muss ART erneut den Code konvertieren, und die so verbrauchte Zeit ist in der Summe nicht zu vernachlässigen.

Startet das Gerät erstmals mit ART, kommt es ganz schön ins Schwitzen. Wer einen Blick ins Logcat wirft, ist ständig auf dem Laufenden. Zunächst verrät sich der Konverter namens dex2oat:

I/art﹕ GenerateImage: /system/bin/dex2oat --image=/data/dalvik-cache/system@%MINIFYHTML797e18b6efdfe809564bf906374c4af87%%MINIFYHTML797e18b6efdfe809564bf906374c4af88%%MINIFYHTML797e18b6efdfe809564bf906374c4af89%Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!%MINIFYHTML797e18b6efdfe809564bf906374c4af810%%MINIFYHTML797e18b6efdfe809564bf906374c4af811%This e-mail address is being protected from spambots. You need JavaScript enabled to view it%MINIFYHTML797e18b6efdfe809564bf906374c4af812%@classes.dex 
--runtime-arg -Xms64m --runtime-arg -Xmx64m 
--dex-file=/system/framework/core-libart.jar --dex-file=/system/framework/conscrypt.jar 
--dex-file=/system/framework/okhttp.jar --dex-file=/system/framework/core-junit.jar 
--dex-file=/system/framework/bouncycastle.jar --dex-file=/system/framework/ext.jar 
--dex-file=/system/framework/framework.jar --dex-file=/system/framework/framework2.jar 
--dex-file=/system/framework/telephony-common.jar --dex-file=/system/framework/voip-common.jar 
--dex-file=/system/framework/mms-common.jar --dex-file=/system/framework/android.policy.jar 
--dex-file=/system/framework/services.jar --dex-file=/system/framework/apache-xml.jar 
--dex-file=/system/framework/webviewchromium.jar 
--oat-file=/data/dalvik-cache/system@%MINIFYHTML797e18b6efdfe809564bf906374c4af813%%MINIFYHTML797e18b6efdfe809564bf906374c4af814%%MINIFYHTML797e18b6efdfe809564bf906374c4af815%Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!%MINIFYHTML797e18b6efdfe809564bf906374c4af816%%MINIFYHTML797e18b6efdfe809564bf906374c4af817%This e-mail address is being protected from spambots. You need JavaScript enabled to view it%MINIFYHTML797e18b6efdfe809564bf906374c4af818%@classes.oat --base=0x60000000 
--image-classes-zip=/system/framework/framework.jar --image-classes=preloaded-classes
Wie die geloggte Kommandozeile zeigt, muss das ganze Framework von DEX nach OAT konvertiert werden. Weitere Zeilen geben Auskunft über den Fortschritt, zum Beispiel:
W/dex2oat﹕ Compilation of void com.android.org.conscrypt.OpenSSLProvider.() took 225.251614ms


Diese Warnung erscheint nur, wenn eine einzelne Funktion länger als 100 Millisekunden im Konverter steckt (was auf dem Emulator häufig passiert). Der Gesamtvorgang umfasst natürlich auch Funktionen, die sich nicht im Logcat bemerkbar machen und dauert je nach Anzahl installierter Apps mehrere Minuten.

Wer kein Entwickler ist, muss zum Glück nur einmal nach Aktivieren von ART Geduld aufbringen, bis nämlich alle Apps einmal konvertiert sind. Der etwas höhere Zeitverbrauch, wenn man mal eine neue App installiert, fällt nicht weiter ins Gewicht.

Aber bringt ART wirklich einen Performance-Vorteil?

Natürlich lautet die Antwort: »Kommt drauf an.«

Je mehr echte Rechenaufgaben eine App tatsächlich ausführt, umso mehr sollte sie vom schnelleren Code profitieren. Aber für welche Art von Apps gilt denn das? Die meisten verbringen ihre Zeit damit, auf die nächste Eingabe zu warten, am Himmel nach einem Satelliten Ausschau zu halten, Monster-Texturen an die GPU zu schicken oder die nächste Werbeanzeige aus dem Internet runterzuladen. Nichts davon wird von ART nennenswert beschleunigt. In den meisten Anwendungsfällen kann also von einer spürbaren Beschleunigung keine Rede sein.

Anders sieht es natürlich mit rechenintensiven Anwendungen aus. Paradebeispiel ist Kryptographie: Wenn ich einen Schlüssel generiere oder Daten chiffriere, ist der Prozessor tatsächlich eine Weile unter Strom. Nehmen wir als Beispiel die ECC-Demo-App aus meinem letzten Artikel: Mit Dalvik dauert es auf meinem Emulator etwa 1,2 Sekunden, um ein 256-Bit-Schlüsselpaar zu erzeugen. ART benötigt für dieselbe Aufgabe nur 0,9 Sekunden. Das ist ordentlich – aber wie häufig ist ein solcher Anwendungsfall?

Nimmt man einzelne Inkompatibilitäten hinzu – Whatsapp läuft beispielsweise nicht auf ART – so bleibt als Fazit:

ART wird früher oder später sicher Dalvik ersetzen. Aber angesichts der eher geringen Beschleunigung und der durchaus merklichen Nachteile ist ART im Moment keine Revolution, sondern eine Art Große Koalition, die erst noch zeigen muss, zu was sie imstande ist.