Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Gadgets & Lifestyle

Android KitKat: Das Geheimnis hinter der superschnellen Google-Runtime

Android: Unser Starter-Guide erleichtert euch den Einstieg in das Betriebssystem. (Bild: Tama Leaver / Flickr Lizenz: CC BY 2.0)

Mit ART bekommt Android KitKat eine zweite Runtime-Engine. Noch handelt es sich um ein experimentelles Feature, aber langfristig könnte sie Apps deutlich beschleunigen.

Android KitKat: Eine neue Runtime sorgt für schneller ausgeführte Apps. (Bild: Google)
Android KitKat: Eine neue Runtime sorgt für schneller ausgeführte Apps. (Bild: Google)

Android KitKat: Neue Runtime könnte Dalvik ersetzen

Versteckt in Android KitKat findet sich eine Neuerung, mit der Googles Betriebssystem in Sachen Geschwindigkeit einen großen Schritt nach vorne machen könnte. Bisher wurden Apps von der Dalvik-Virtual-Machine ausgeführt. Mit ART gibt es jetzt eine experimentelle Alternative.

ART, was wohl für „Android Runtime“ steht, führt Anwendungen auf eine fundamental andere Art und Weise als Dalvik aus. Letzteres bedient sich der Just-in-time-Kompilierung, das bedeutet, dass ein Programm erst bei der Laufzeit in den Maschinencode übersetzt wird, den euer Smartphone oder Tablet verstehen kann. So wird sichergestellt, dass Android-Apps auf allen möglichen Systemen laufen, ohne sie vorher anpassen zu müssen. Dieser Vorgang wird erst bei Bedarf ausgeführt – also dann, wenn ihr eine App auch wirklich nutzt.

Android KitKat: ART setzt auf Ahead-of-time-Kompilierung

ART wiederum setzt auf die Ahead-of-time-Methode. Android übersetzt die Apps in dem Fall also direkt bei der Installation in native Apps. Diese sollten zumindest theoretisch deutlich schneller laufen. Android-Police berichtet beispielsweise, dass die neue Runtime die Ausführungszeit von Apps auf die Hälfte verkürzt. Auch könnten Apps die vorhandene Hardware besser ausnutzen, was in gewissen Grenzen zu einer längeren Akkulaufzeit führen könnte.

Natürlich gibt es auch Nachteile bei der Methode, die aber in den meisten Fällen zu vernachlässigen sein dürften. So wird der vollständig kompilierte Maschinencode mehr Speicher benötigen als der bisher verwendete Bytecode. Zwar reden wir hier von einem bis zu 20 Prozent höherem Platzbedarf, allerdings sollte man nicht vergessen, dass nur ein Teil der Größe einer App tatsächlich von dem Code abhängt.

ART: Die Nachteile im Überblick

Außerdem wird die Installation einer App mehr Zeit in Anspruch nehmen. Bei einer App dürfte das die meisten Nutzern wenig stören, würde man aber auf einmal alle installierten Apps nacheinander kompilieren, müsste man sich auf eine spürbare Wartezeit einstellen. Andererseits führt der so optimierte Code letztlich auch zu den beschriebenen Vorteilen, was den Zeitaufwand zu einer durchaus lohnenden Investition machen würde.

ART ist derzeit ein experimentelles Feature für Entwickler und Hardware-Hersteller. Google selbst gibt auf der ART-Webseite an, dass Dalvik unbedingt die Standard-Runtime bleiben muss, wenn man nicht das Risiko eingehen will, die Drittanbieter-Apps und sogar die Android-Implementation unbenutzbar zu machen. Trotzdem zeigt es, dass wir in nicht allzu ferner Zukunft einen echten Performance-Anstieg erwarten können – und zwar ohne den Einsatz besserer Hardware.

Bitte beachte unsere Community-Richtlinien

Eine Reaktion
Optimierte Binaries

.NET macht das ja auch wie ART wenn ich das damals richtig verstanden habe.
LLVM ist ja der Standard bei iOS und MacOS und die gelten ja nicht als lahme Schnecken. Sowas kann also durchaus funktionieren.

Da viele Handies Multicores haben und man beim Installieren von Apps vermutlich 99% Hintergrundbilder, Multimediakrams und andere niemals benötigten Inhalte sind, soltle sich der Mehraufwand in Grenzen halten.

Die CPU und Grafikchip werden normalerweise ja nicht gewechselt.
Von Intel gabs auch mal einige DLLs die auf Intel optimiert waren und womit man einige Windows-DLLs gegen optimierte Versionen ersetzen konnte.
So falsch ist Anpassung auf die Zielplattform ja nicht. Für manche Mediaplayer unter Android gibts ja auch Plugins um bestimmte ARM/GPU-Kombinationen optimierter abspielen lassen zu können.
Wichtig wäre das die originalen Binaries auch erhalten bleiben weil es (RaspBerry, Beagleboard(?), Cubietruck usw.) auch Android-Installationen gibt die man vielleicht an mehreren Geräten einsetzen will und von SD-Karte bootet oder die Apps auf SD-Karte lagert.

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Finde einen Job, den du liebst