Aktuelle Informationen über troido und die Netzwelt!


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

Droid Full
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@%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da8%%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da9%%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da10%Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da11%%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da12%This e-mail address is being protected from spambots. You need JavaScript enabled to view it%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da13%@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@%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da14%%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da15%%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da16%Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da17%%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da18%This e-mail address is being protected from spambots. You need JavaScript enabled to view it%MINIFYHTML8cef71c4dc6ea620bf676f849049e6da19%@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.

Today troido acquired Holland9, an international Android expert company experienced in high and low level Android development and trainings and also a founder & organiser of droidcon Amsterdam, a large 2 day technical conference organised for Android developers.
We are extremely excited about this transaction because the acquisition of Holland9 enhances all three elements of our growth strategy: technological innovation, a unique customer value proposition and expansion in geographical markets.
Read the press release here: press release


Die Überraschung der Google I/O 2013 war weder die 5er-Version von Android noch der Auftritt von Boss Larry Page: Es war das Android Studio, das Stunden später in einer ersten Version für Entwickler zum Download zur Verfügung stand. Zwar bemühte man sich, den Entwicklungsstand nicht zu beschönigen, Tatsache aber ist: Das Ding läuft stabil. Stabiler als Platzhirsch Eclipse.


Lassen wir mal Spekulationen beiseite, den Google-Entwicklern höchstselbst sei Eclipse dermaßen auf die Nüsse gegangen, dass sie für Abhilfe gesorgt haben. Uns muss auch nicht interessieren, ob Geldbeträge geflossen sind zwischen Google und JetBRAINS, dem Hersteller der IntelliJ IDEA, auf der Android Studio basiert. Die Frage, die sich stellt, lautet vielmehr: Sind die Tage von Eclipse als de-facto-Standard für Android-Entwicklung gezählt?
Bereits während des Talks von Tor Norbye und Xavier Ducrohet (zu sehen hier) wurde anhand der »ahs« und »ohs« aus dem Publikum deutlich, dass Google mit Android Studio ins Schwarze trifft. Bei der Präsentation eines bestimmten Features gab es gar Szenenapplaus, den man sonst nur aus Fußballstadien kennt: Android Studio vermag Layouts in mehreren Geräten gleichzeitig anzuzeigen, und zwar inklusive der Geräte.
Android Studio Device Previews
Android Studio bietet aber nicht nur Eye Candy, sondern alle Entwicklerhilfen, die IntelliJ mitbringt, und das sind eine ganze Menge. Zwar erreichen Flamewars zwischen Eclipse-Enthusiasten einerseits und IntelliJ-Befürwortern andererseits gerne mal das Niveau des Glaubenskrieges zwischen Apple und Android, Windows und Linux, oder Schalke und Dortmund. Unbestreitbar aber ist, dass man mit IntelliJ mindestens genauso schnell und effizient coden kann wie mit Eclipse.
Es sind die Kleinigkeiten (die jeder unterschiedlich bewertet), die den Ausschlag geben. Ein paar Beispiele: Wenn Sie mit dem Windows-Explorer oder per Kommandozeile eine Datei in ein Projektverzeichnis kopieren, müssen Sie in Eclipse den Refresh-Button drücken, damit das File auftaucht. Android Studio bemerkt die Änderung von allein. Eclipse kann nur per Tastenkürzel oder beim Speichern Imports organisieren, Android Studio bzw. IntelliJ tun das stillschweigend, während Sie Code eintippen. Die automatische Codevervollständigung von IntelliJ fügt (meistens) ein Semikolon am Ende einer Zeile ein, Eclipse nicht. Der Platzhirsch kompiliert dafür im Hintergrund und macht Folgefehler in anderen Klassen schneller sichtbar.
Fans von Refactoring und Regular Expressions werden IntelliJ lieben. Auf den ersten Blick irritierend (aber abschaltbar) ist das Code Folding, das sogar getString(resId)-Aufrufe gegen die zugehörigen Strings aus der strings.xml vertauscht. Verwendet man im Code eine Referenz auf eine Farbreferenz (R.color.irgendwas), erscheint ernsthaft am linken Rand der Zeile ein Quadrat in dieser Farbe. Ähnliches gilt für Grafiken (R.drawable.irgendwas), funktioniert aber anscheinend nicht immer. Im Fall von Ninepatch-PNGs führt ein Klick übrigens direkt in den zugehörigen Pixel-Editor. Das wird man selten benötigen, nötigt dem Entwickler aber trotzdem ein zufriedenes Kopfnicken ab. Nicht quantifizierbar ist freilich ein viel wichtigerer Aspekt, die Stabilität: »Gefühlt« hängt sich mein Eclipse alle paar Tage auf, gibt mehr oder weniger unverständliche Fehlermeldungen von sich oder sieht Syntax-Fehler, wo keine sind, bis man das Projekt neu baut oder schließt und wieder öffnet. Mag sein, dass dergleichen auf Fehlkonfigurationen zurückzuführen ist oder dass das Problem vor der Tastatur sitzt, aber Android Studio scheint deutlich seltener solche Schwierigkeiten zu machen.
Als diese Zeilen entstehen, trägt Android Studio die Versionsnummer 0.1.8, Updates kommen alle paar Tage und lassen sich per Knopfdruck installieren. Erfreulicherweise sind die Updates bloß kleine Deltas, man muss nicht immer das ganze 180-MB-Paket runterladen. Grundsätzlich macht das Studio bereits einen guten Eindruck. Noch fehlen einige Funktionen, vor allem im Layout-Editor. Empfindliche Einschränkungen sind mir bisher allerdings noch nicht untergekommen, so dass nichts dagegen spricht, Android Studio einem ernsthaften Praxistest zu unterziehen. Ich würde sogar dringend dazu raten, denn je früher man eine neue Technologie kennenlernt, desto besser. Denn auch wenn sich Google bezüglich der künftigen Unterstützung von Eclipse neutral ausdrückt: Wenn die irgendwann in mittelfristiger Zukunft eingestellt wird, dürfte sich niemand groß wundern. Es steht zu vermuten, dass Android Studio auch als Version 1.0 gratis bleiben wird. Kosten fallen also nur in Form von zeitlichen Aufwänden für die Umstellung an. Ob sich das rentiert, ist eine Frage, die jeder selbst beantworten muss.
Für Neueinsteiger stellt sich die Frage »Eclipse oder Android Studio« nicht. Wer einmal seine Entwicklungsumgebung mit Eclipse eingerichtet hat, weiß: Erstmal muss das Android-Plugin installiert werden, dann folgen diverse weitere Downloads, und ein paar Stunden später kann man loslegen. Wer Subversion zur Quellcodeverwaltung benötigt, ist an dieser Stelle längst noch nicht fertig. Android Studio dagegen bringt alles mit. Installieren, starten, arbeiten. Offen gesagt ist diese Tatsache Argument genug, um Einsteigern in die Android-Entwicklung von Eclipse rundweg abzuraten. Ich weiß wovon ich rede, denn in meinem Android-Buch gehen für die Beschreibung der Eclipse-Installation eine ganze Reihe Seiten drauf – und die Leser-Rückfragen, die es diesbezüglich gibt, zähle ich schon nicht mehr.

Gradle
Android Studio bringt ein neues Build-System für Android-Apps mit: Gradle (http://www.gradle.org). Vorweg: Es ist nicht erforderlich, Gradle einzusetzen. Ant-basierte Projekte, die bislang unter Eclipse entwickelt wurden, können einfach mit Android Studio weiter bearbeitet und gebaut werden. Legt man allerdings ein neues Projekt in Android Studio an, wird es automatisch als Gradle-Build angelegt. Ferner bietet das Eclipse-Plugin eine neue Option, um ein Projekt ins Gradle-Format zu konvertieren. Das allerdings will gut überlegt sein: Denn dabei ändert sich die Ordnerstruktur, so dass die Standard-Ant-Skripts nicht mehr funktionieren. Da Gradle sich in vielerlei Hinsicht an Maven orientiert, gibt es einen Verzeichnisbaum src/main mit Unterverzeichnissen java und res. Ein typisches Buildfile sieht beispielsweise wie folgt aus:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:0.4'
    }
}
apply plugin: 'android'

dependencies {
    compile files('libs/android-support-v4.jar')
}

android {
    compileSdkVersion 17
    buildToolsVersion "17.0.0"

    defaultConfig {
        minSdkVersion 7
        targetSdkVersion 16
    }
}

Warum Gradle? Nun, böse Zungen könnten Ant als furchtbar altmodisch bezeichnen, und das ist nicht nur für breite Krawatten ein KO-Kriterium. Mehr als einmal hatte ich das Vergnügen, Ant-Projekte auf Maven umzustellen, um hinterher effizienter arbeiten zu können, beispielsweise was die Verwaltung von Abhängigkeiten angeht. Meist stimmte das, unter Android gab es aber selten einen praxisrelevanten Grund, auf Maven zu wechseln.
Auch Gradle bringt eine Abhängigkeitsverwaltung mit und kann sich automatisch Maven-Artefakte beschaffen, wenn sie benötigt werden. Die Google-Entwickler selbst führen eine ganze Reihe an Gründen für den Umstieg an: Die Domain Specific Language, die Möglichkeit, Groovy-Skripte zu integrieren, die Flexibilität und die gute Integration in die IDE. Nichts davon wirkt auf den ersten Blick wie ein Killerfeature. Tatsache ist aber, dass mit zunehmender Komplexität von Android-Projekten auch die Anforderungen an das Build-System steigen. Man denke beispielsweise an leicht unterschiedliche APKs für verschiedene Geräte oder Versionen (Demo/Premium).
Das Android-Gradle-Plugin kann das Manifest manipulieren. Im oben gezeigten Beispiel werden minSdkVersion und targetSdkVersion im Manifest überschrieben. Auch versionCode oder versionName lassen sich auf diese Weise setzen. Und an dieser Stelle wird es spannend: Wir könnten einen dieser Werte dynamisch setzen. Etwa so:

defaultConfig {
    versionName getVersion()
}

def getVersion() {
...
}

Die Groovy-Funktion getVersion() könnte beispielsweise die aktuelle Revision aus dem Sourcecode-Repository ermitteln, um diese in die Versionsnummer der App zu schreiben.
Normalerweise erzeugt das Android-Gradle-Plugin Debug- und Release-Version der App gleichzeitig. Erstere wird automatisch mit dem üblichen Debug-Zertifikat signiert, letztere erstmal gar nicht. Build Types lassen sich zusätzlich konfigurieren:

buildTypes {
       debug {
             packageNameSuffix ".debug"
       }
}

Dieser kurze Code sorgt dafür, dass alle Java-Packages der Debug-Version mit .debug garniert werden. Ergebnis: Man kann Debug- und Release-Version auf einem Gerät installieren.
Auf ähnliche Weise darf das Buildskript pro Build Type unterschiedliche, zusätzliche Source-Verzeichnisse angeben. So kann unterschiedlicher Code einkompiliert werden, beispielsweise in einem Spiel eine Gott-Funktion, die nur in der Debug-Version existiert. Mit Ressourcen funktioniert das ähnlich, ebenso mit ProGuard-Konfigurationen.
Weitere Details zum Build-System würden den Rahmen dieses Artikels sprengen, daher sei der interessierte Leser auf die offizielle Dokumentation verwiesen (http://tools.android.com/tech-docs/new-build-system), wo es sogar den zugehörigen Talk von der Google I/O 2013 zu bestaunen gibt.

Fazit: Android Studio gehört die Zukunft.

Uwe Post ist Diplom-Physiker, Chefentwickler einer Firma für Smartphone-Spiele und Autor von Fachbüchern und Romanen. Uwe ist langjähriger Freund und Unterstützer von troido und bloggt exklusiv für uns über Android, Elektronik und Hyperraumantriebe. Homepage: uwepost.de, Twitter: @uwepost


Seite 1 von 3