Es gab bereits in Android 2.x Hardwarebeschleunigung
Wer ein Android-Smartphone oder Tablet besitzt, wird das Ruckeln kennen. Es tritt beim Scrollen auf einer Website auf, oder selbst beim Wechsel von einem Homescreen zu nächsten. Diese Ruckelei hat sich zwar bereits etwas gebessert, in Android 2.3 und seinen Vorgängern tritt es dennoch auf und selbst Android 3.x Honeycomb sind Reste davon zu bemerken.
Hackborn betont, dass in älteren Android-Versionen vor Android 3.0 und 4.0 zwar bereits teilweise Hardwarebeschleunigung aktiviert gewesen sei, dennoch wurde bisher ein Großteil der Animationen der Nutzeroberfläche per Softwareoptimierung erreicht. Diese wurde mittels des Prozessors und nicht per dedizierter Grafikeinheit berechnet, was ein recht ineffizienter Weg sei, flüssige Animationen und Übergänge zu erreichen. Laut Hackborn sei dies allerdings nicht der einzige Grund für das Ruckeln – denn auch mit einer Portion softwareseitiger Optimierung könne man gute Resultate erzielen, sofern der Prozessor schnell genug sei. Seit Android 3.0 Honeycomb habe man die Hardwarebeschleunigung vollständig in das System implementiert, mit Android 4.0 habe sich dies nicht geändert. Allerdings habe man in der letzten Version eine Standardeinstellung verändert, sodass bei Apps, die speziell für Ice Cream Sandwich entwickelt wurden, automatisch die Hardwarebeschleunigung aktiviert sei und alles runder laufe.
Allein auf Hardwarebeschleunigung zu setzen, sei allerdings kein Wundermittel. Denn diese Technologie hätte auch ihre Nachteile, denn die Treiber des PVR-Grafikchips, die beispielsweise im Nexus S und den Galaxy Nexus zum Einsatz kommen, beginnen auf OpenGL zu setzen, was 8MB RAM in Anspruch nehme. Dies klingt nach relativ wenig, ist es aber nicht, denn der Process Overhead beträgt lediglich 2MB. Dieser Speicher fehle laut Hackborn bei Hintergrund-Prozessen und App-Switching.
Allein durch Aktivierung der Hardwarebeschleunigung sei Google bei der Entwicklung eines ruckelfreien Android nicht weiter gekommen. Man habe im ganzen System an diversen Schrauben gedreht, um eine flüssig laufende Nutzeroberfläche zu erreichen. Nicht zu unterschätzende Komponenten seien zudem ein schneller Grafikprozessor und der Memory Bus.
Andrew Munn: „Android wird niemals flüssig laufen“
Andrew Munn, ein Informatik-Student der ein Praktikum in Googles Android-Team absolvierte, veröffentlichte auf Google+ eine umfangreiche Antwort auf Hackborns Erklärung. Seiner Meinung nach werde Android niemals so flüssig laufen wie Apples iOS oder Microsofts Windows Phone. Er schreibt, dass Prozesse in Android noch nach dem Verfahren der Bilddarstellung eines PC arbeite, iOS im Unterschied verfüge über einen separaten Thread, der für das Rendering der UI zuständig und Echtzeit-priorisiert sei.
Seiner Meinung sei es schwierig das Rendering Framework von Android vollständig neu zu entwickeln, da ältere Software nicht mehr kompatibel sein würde. Er zitiert in diesem Kontext Android-Entwickler Romain Guy:
…a lot of the work we have to do today is because of certain choices made years ago… …having the UI thread handle animations is the biggest problem. We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing, possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to this also.
Würde Google das Framework komplett neu entwickeln, würden sich daraus seiner Ansicht nach folgende Probleme ergeben: Alle Apps müssten neu programmiert werden, damit sie mit dem Framework kompatibel sind. Android würde einen Modus benötigen, durch den ältere Apps weiterhin unterstützt würden, überdies könnte die Entwicklung neuer Android-Features durch die Umstrukturierung ins Stocken geraten.
Ob Munn mit seinen Thesen korrekt liegt, ist für mich als Nicht-Entwickler nicht leicht zu beantworten. Dass Ice Cream Sandwich dank der erweiterten Hardware-Unterstützung weit besser läuft, kann ich allerdings bestätigen. Sein Artikel über Android ist auf Google+ zu finden.
„Softwarebeschleunigung“ … das Wort des Monats ;)
Eine Softwarebeschleunigung gibt es nicht. Denn über die Software etwas zu berechnen, egal ob es sich um eine GUI oder um irgendwelche Berechnungen handelt, ist die letzte Möglichkeit die einem zur Verfügung steht. Wenn man keine passende Hardware für die benötigen Berechnungen zur Verfügung hat, muss man es zwangsweise per Software (auf der CPU) machen. Aber eine Beschleunigung per Software gibt es nicht, da die Software die „Quelldaten“ ja überhaupt erst erzeugt. Man kann höchstens den Code optimieren, damit die Berechnungen schneller vonstatten gehen.
Ich kann bestätigen dass die GUI sich mit Android 4.0 deutlich flüssiger anfühlt.
Naja…
muss eine Oberfläche schneller laufen, als ein Mensch sie bedienen kann?
Aktuelle Leistungsfähige Androiden laufen so flüssig und schnell, das man ohne Störung damit Arbeiten kann.
Also ich bin vor zwei Wochen vom iPad auf ASUS eee Pad Transformer umgestiegen und könnte nicht behaupten das es ruckelt oder hackt, außer es laufen im Hintergrund zu viele Programme, das Problem hat man aber auf jedem PC/Mac.
Wenn man eine gewisse Hardwareleistung für ein OS benötigt darf man sich nicht aufregen wenn das OS ruckelt wenn man diese eben nicht hat. (aber vielleicht habe ich ja auch gerade das eine Android Tablet wo es nicht ruckelt? ^^)
Eine einfache, nicht schöne, aber gangbare Lösung ist es, zu dem neuen UI-Framework einen Wrapper für alte Anwendungen zu bauen, welche die alte Logik in das neue Framework zur Laufzeit übersetzt. Der Wrapper wird implizit über die API-Aufrufe der alten Anwendungen verwendet.
Nachteile sind klar eine schlechtere Performance, welche aber bei alten Anwendungen nicht unbedingt – gerade auf neueren Geräten – auffallen würde. Neue Anwendungen könnten dann direkt von einem neuen komplett beschleunigten UI profitieren und alte laufen immer noch.
So eine Wrapper-Struktur ist gängige Praxis. Wenn dies bei Andoid nicht machbar ist, hat Google wahrscheinich noch andere größere Patzer im System, welche wohl ein größeres Software-Redesign erfordert.