© Ferenczi Gyorgy, 123RF

Schon bald soll die neue Android Runtime, kurz ART genannt, die alte Dalvik-Laufzeitumgebung von Android ablösen. Für den Endbenutzer verspricht Google schnellere Programme. Was sich für den Entwickler ändert, behandelt dieser Artikel.

Das ursprüngliche Java-Versprechen “Compile once, run everywhere” wurde noch nie eingehalten. Die Spezifikation der virtuellen Maschine, auch Java Runtime Environment (JRE) genannt, ist einfach zu komplex, als das alle Hersteller alle Details genau gleich implementieren könnten – oder wollten. Der Autor erinnert sich noch an stundenlanges Remote-Debugging von Webapplikationen, die sich unter Sun/Windows, Sun/Linux und IBM/Linux jeweils anders verhielten. Da ging es um Feinheiten an den Grenzen der jeweiligen JRE.

Als Google dann für Android mit Dalvik eine eigene, definitiv nicht kompatible Runtime ins Rennen schickte, war die Java-Vision endgültig beerdigt. Auch wenn die Programmiersprache für Android weiterhin Java war, der Bytecode war es nicht mehr. Mit Oracle als aktuellem Patentinhaber gab und gibt es deshalb viel Ãrger, für Entwickler blieben die Auswirkungen gering. Fremde, vorkompilierte Jar-Dateien funktionierten aber eventuell nicht und der Compiler des Developer-Kits musste den Bytecode für Dalvik umwandeln. Da Android auch nicht alle Standardklassen von Java nutzt, war manchmal eine Anpassung des Quellcodes notwendig. All das war mühsam, aber ein einmaliger Aufwand.

Zeit für einen Wechsel

Mehrere Jahren Android machen klar, dass Dalvik trotz aller Optimierungen immer noch Performance-Engpässe produziert. Zusammen mit den Lizenzproblemen und dem mehr gefühlten als gemessenen Performance-Vorsprung von I-OS war es also Zeit für einen Wechsel. Denn wie so oft in der Software-Entwicklung kommt irgendwann der Punkt, an dem eine Neuentwicklung sinnvoller ist als die Pflege alten Codes.

Mit Kitkat erschien die erste Android-Version, die auf ausgewählten Geräten einen temporären Wechsel zur neuen Android Runtime (ART) erlaubt. Mit Android L (siehe Abbildung 1) wird dann der endgültige Umstieg auf ART als standardmäßiger Laufzeitumgebung passieren. Für Entwickler ist das also ein ausreichender Vorlauf, um sich auf die neue Rahmenbedingung einzustellen.

Abbildung 1: Android L wirft mit der Developer Preview seine Schatten voraus.

Die Botschaft von Google wiederholt dabei eine alte Java-Maxime: Bestehende Anwendungen laufen ohne Probleme auf der neuen Runtime. Natürlich darf niemand dieser Marketingbotschaft unkritisch Glauben schenken.

Fallen in ART

Eine echte Falle innerhalb von Java resultiert aus einem Fehler in Dalvik. Der Bug erlaubte es Programmierern, Methoden mit der Sichtbarkeit »package-private« in anderen Packages zu überschreiben. Das ist sowieso schlechter Stil, so etwas kommt daher eher ungewollt vor, niemand hat alle Methoden einer Klasse im Kopf. Der Compiler für ART gibt daher eine entsprechende Warnung aus.

Die zweite Änderung im Objektmodell betrifft »java.lang.Object« . Die Wurzelklasse der gesamten Klassenhierarchie hat jetzt private Felder. Damit funktionieren nun Algorithmen nicht mehr, die sich per »getSuperclass()« die Klassenhierarchie hochhangeln, per Reflection die Felder der Klassen abfragen und erst stoppen, wenn die Methode »null« liefert. Statt gegen den Null-Wert muss der Entwickler künftig das Ergebnis von »getSuperclass()« auf »java.lang.Object« prüfen und somit eine Ebene in der Hierarchie früher stoppen – oder mit bisher nicht geworfenen Exceptions umgehen können.

Grenzverstöße

Wer heute das letzte aus Android rausholen will oder muss oder auf spezielle Bibliotheken angewiesen ist, die noch nicht auf Java portiert sind, verwendet das Java Native Interface (kurz JNI, siehe [1] – den allererste Artikel, den der Autor bereits vor 16 Jahren für das Linux-Magazin geschrieben hat). Damit kann der Entwickler C/C++-Code aus Java heraus ausführen. Obwohl das Programm damit die Grenzen des Bytecode-Interpreters verlässt, läuft das Programm nach wie vor im selben Prozess der Runtime-Umgebung.

Ist JNI im Spiel, gilt das Java-Versprechen nicht mehr. Und auch klassische Java-Eigenschaften wie die automatische Speicherverwaltung gelten nicht für Objekte, die das Programm über das JNI-Interface erzeugt. Das ist an sich nicht neu, aber mit der neuen ART-Runtime gibt es Programmkonstrukte, die unter Dalvik noch funktioniert haben, jetzt aber Probleme bereiten.

Dalviks Speichermanagement gab Objekte zwar während der Garbage Collection frei, langte aber dabei verbleibende Objekte im Speicher nicht an. Mit ART ist das zwar momentan noch immer so, doch ist eine gravierende Änderung im Garbage Collector am Horizont sichtbar. Dieser wird dann Objekte im Speicher verschieben – das Ziel sind große, zusammenhängende Speicherbereiche. Gerade kleine, kurzlebige Java-Objekte hinterlassen aktuell viele kleine Löcher im Speicherbereich des Prozesses, das ist also eine sinnvolle Änderung.

Damit funktionieren aber der Zugriff und die Änderung von nativen Objekten nicht mehr so einfach. Ändern native Methoden jetzt Werte im Speicher, müssen sie das explizit der Runtime per Commit mitteilen (oder die Änderung per Abort verwerfen). Auch funktioniert Pointer-Arithmetik beim Zugriff auf Arrays nicht mehr ohne Weiteres.

Goodies

Zum Glück gibt es neben den Fallen auch noch einzelne Goodies, die das Leben des Entwicklers vereinfachen. So unterstützt ART jetzt einen Profiler, der im Gegensatz zum Dalvik-Pendant keinen signifikanten Overhead erzeugt und auch die Laufzeitperformance nicht so negativ beeinflusst. Ebenfalls neu sind einige Debugging-Features wie die Abfrage von Sperren oder die Anzahl von Instanzen einer Klasse. Nützlich ist auch das Überschreiben des von Methoden zurückgegebenen Wertes – beim Debuggen möchte man manchmal künstlich Situationen erzeugen, die der Emulator so nicht hergibt.

Darüber hinaus ist ART gesprächiger bei Exceptions und Crashes. Bei Nullpointer-Exceptions schreibt ART zum Beispiel noch die Methode beziehungsweise das Feld in die Fehlermeldung, auf die das Null-Objekt versucht hat zuzugreifen.

Hausaufgaben machen

Entwickler sollten daher für eine detaillierte Beschreibung der Änderungen unbedingt [2] lesen. Der Artikel verlinkt auch auf weitergehende Blogeinträge. Auch per Google-Suche finden Interessierte viele nützliche Beiträge.

Ein weiterer Punkt auf der To-do-Liste ist die Installation einer aktualisierten Entwicklungsumgebung mit ART-Unterstützung. Wie üblich gibt es entsprechende Pakete auf den Entwicklerseiten von Android [3]. Aus einer vorhandenen Umgebung heraus starten Neugierige den SDK-Manager (im Menü »Windows« ), fahren ein Update aller Tools, starten den SDK-Manager erneut und laden dann die verfügbare Android L Developer Preview herunter (Abbildung 2). Im Gegensatz zum alten Android, das einen Java-6-Compiler benötigt, setzt Android L zwingend Java 7 voraus.

Abbildung 2: Download der Entwicklungstools für Android L.

Wer in seinem Entwicklungsprozess Tools von Fremdherstellern nutzt, muss eventuell upgraden. Insbesondere Tools wie etwa Code-Obfuscators greifen auf Bytecode-Ebene ein, und da ART hier strenger als Dalvik ist, braucht es eventuell eine neuere Version des entsprechenden Tools.

Als letzter Punkt bleibt die Prüfung des Ergebnisses auf echter Hardware. Der Autor weiß aus eigener leidvoller Erfahrung, dass selbst Apps ohne besondere Tricks nicht notwendigerweise auf echter Hardware laufen, obwohl sie im entsprechenden Emulatormodell funktionieren.

Einige Nexus-Geräte mit aktueller Firmware bringen schon experimentelle ART-Unterstützung mit (Nexus 4, 5, 7). Dalvik ist dort zwar noch die Standard-Runtime, per Option (»Einstellungen | Entwickleroptionen« ) kann jeder aber temporär die Runtime auf ART ändern. Google stellt auch für einige Geräte eine komplette Firmware mit der Android L Preview bereit. Diese ist aber eher für Entwickler gedacht, die ihre Anwendung auf das neue Look & Feel von Android L anpassen möchten.

Fazit

Wie im PC-Bereich sind Spiele auch auf Smartphones und Tablets die Innovationstreiber: Bessere Hardware mit immer mehr und schnelleren Kernen bedienen vor allem Spieler und Redakteure von Fachzeitschriften mit ihren Benchmarks. Normale Benutzer kommen mit der Leistung eines mehrere Jahre alten höherwertigen Smartphones noch immer über die Runden.

Dementsprechend ist auch der Wechsel der Runtime von Dalvik nach ART eher eine Marketingaktion als von breiter praktischer Bedeutung – die Hardwareperformance steigt so schnell, dass für den normalen Gebrauch alle Dalvik-Nachteile unbedeutend sind.

Zum Glück ändert sich deshalb für die Programmierer von “normalen” Anwendungen mit ART auch fast nichts. Eine aktualisierte Entwicklungsumgebung ist nötig, aber das ist sowieso Alltag von Android-Version zu Android-Version. Wer allerdings aus der Hardware alles rausholen muss und deshalb schon zu Dalvik-Zeiten alle verfügbaren Tricks einsetzte, der hat mit dem Umstieg auf ART etwas Arbeit. Als Belohnung winkt aber eine zusätzliche Performancesteigerung – der Aufwand ist also nicht umsonst.