Schneller, flüssiger, responsiver: Performanceverbesserungen in Android 4.1

Alles in Butter

Arne Limburg, Lars Röwekamp


Warum verhalten sich iOS-Anwendungen deutlich performanter als ihre Android-Pendants? Google hat dafür gleich mehrere Gründe ausgemacht und diese mit Android 4.1 (Jelly Bean) im Rahmen des Projects Butter behoben [1]. Dieses geht vor allem zwei Low-Level-Themen im Android-Kern an: die Animationen und die Touch-Events.

Flüssigere Animationen

Ein Standard-Android-Display läuft mit mindestens 60 Hz, d. h. 60 Bildern pro Sekunde. Die erste Maßnahme, um Android-Animationen flüssiger erscheinen zu lassen, war also, alle Animationen mit 60 Bildern pro Sekunde abspielen zu lassen. Das hat allerdings zur Folge, dass erhöhte Anforderungen an die Erstellung der einzelnen Bilder der Animation gestellt werden: Für jedes bleiben nur 16 Millisekunden. In dieser Zeit muss zunächst die CPU die Bilddaten aufbereiten, damit die GPU sie dann dem Display in einem Grafikbuffer zur Anzeige zur Verfügung stellen kann. Bis das geschehen ist, zeigt das Display einen anderen Buffer mit dem vorherigen Bild an. Diese Technik (also ein Buffer zum Beschreiben und einer zum Anzeigen) nennt man Double Buffering. Damit das Display den angezeigten Buffer erst wechselt, wenn er von der GPU komplett beschrieben ist, wird seit jeher eine Technik namens VSync angewendet, die GPU und Display synchronisiert. Wenn der Zyklus CPU-GPU-Display nicht in das 16-ms-Zeitfenster passt, wird ein Bild ausgelassen, was sich beim Benutzer als leichtes Ruckeln bemerkbar macht. Leider kann die CPU in Ice Cream Sandwich (und in früheren Android-Versionen) jederzeit mit der Berechnung beginnen. Da sind aber in der Regel schon wertvolle Millisekunden von den 16 zur Verfügung stehenden verstrichen, wodurch deutlich weniger Zeit pro Bild für GPU und Display zur Verfügung steht. Es kommt daher häufig zu besagtem Auslassen von Bildern. In Jelly Bean werden jetzt nicht nur Display und GPU, sondern vorgeschaltet auch die CPU via VSync synchronisiert. Das hat zur Folge, dass die CPU immer direkt am Anfang der 16 ms startet und für den Zyklus CPU-GPU-Display die vollen 16 ms verwendet werden können. Ausgelassene Bilder gibt es daher seltener, weil pro Bild mehr Zeit zur Verfügung steht.

Wenn dennoch ein Bild ausgelassen wird, kommt es zu einem weiteren Problem: In diesem Fall findet kein Wechsel der Buffer des Double Bufferings statt, sondern der alte Buffer wird weiterhin angezeigt, während die GPU einen weiteren Zyklus lang den nicht angezeigten Buffer befüllt, um das ausgelassene Bild nachzuholen. Viel schlauer wäre es...

Schneller, flüssiger, responsiver: Performanceverbesserungen in Android 4.1

Alles in Butter

Arne Limburg, Lars Röwekamp


Warum verhalten sich iOS-Anwendungen deutlich performanter als ihre Android-Pendants? Google hat dafür gleich mehrere Gründe ausgemacht und diese mit Android 4.1 (Jelly Bean) im Rahmen des Projects Butter behoben [1]. Dieses geht vor allem zwei Low-Level-Themen im Android-Kern an: die Animationen und die Touch-Events.

Flüssigere Animationen

Ein Standard-Android-Display läuft mit mindestens 60 Hz, d. h. 60 Bildern pro Sekunde. Die erste Maßnahme, um Android-Animationen flüssiger erscheinen zu lassen, war also, alle Animationen mit 60 Bildern pro Sekunde abspielen zu lassen. Das hat allerdings zur Folge, dass erhöhte Anforderungen an die Erstellung der einzelnen Bilder der Animation gestellt werden: Für jedes bleiben nur 16 Millisekunden. In dieser Zeit muss zunächst die CPU die Bilddaten aufbereiten, damit die GPU sie dann dem Display in einem Grafikbuffer zur Anzeige zur Verfügung stellen kann. Bis das geschehen ist, zeigt das Display einen anderen Buffer mit dem vorherigen Bild an. Diese Technik (also ein Buffer zum Beschreiben und einer zum Anzeigen) nennt man Double Buffering. Damit das Display den angezeigten Buffer erst wechselt, wenn er von der GPU komplett beschrieben ist, wird seit jeher eine Technik namens VSync angewendet, die GPU und Display synchronisiert. Wenn der Zyklus CPU-GPU-Display nicht in das 16-ms-Zeitfenster passt, wird ein Bild ausgelassen, was sich beim Benutzer als leichtes Ruckeln bemerkbar macht. Leider kann die CPU in Ice Cream Sandwich (und in früheren Android-Versionen) jederzeit mit der Berechnung beginnen. Da sind aber in der Regel schon wertvolle Millisekunden von den 16 zur Verfügung stehenden verstrichen, wodurch deutlich weniger Zeit pro Bild für GPU und Display zur Verfügung steht. Es kommt daher häufig zu besagtem Auslassen von Bildern. In Jelly Bean werden jetzt nicht nur Display und GPU, sondern vorgeschaltet auch die CPU via VSync synchronisiert. Das hat zur Folge, dass die CPU immer direkt am Anfang der 16 ms startet und für den Zyklus CPU-GPU-Display die vollen 16 ms verwendet werden können. Ausgelassene Bilder gibt es daher seltener, weil pro Bild mehr Zeit zur Verfügung steht.

Wenn dennoch ein Bild ausgelassen wird, kommt es zu einem weiteren Problem: In diesem Fall findet kein Wechsel der Buffer des Double Bufferings statt, sondern der alte Buffer wird weiterhin angezeigt, während die GPU einen weiteren Zyklus lang den nicht angezeigten Buffer befüllt, um das ausgelassene Bild nachzuholen. Viel schlauer wäre es...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang