Google I/O 2009, Chris Pruett

Threads + sauberer Code

Zwei wichtige Punkte habe ich “glücklicherweise” von Anfang an richtig gemacht: der gesamte für das Spiel relevante Code (Physik-Berechnungen, Zeichnen, Spiel-Logik) war in einem gesonderten Thread (sodass ein langsames Spiel nicht die Anwendung selbst bremst und unbedienbar macht), und mein Code war recht sauber gegliedert: getrennte Methoden für Physik/Zeichnen/Benutzereingabe/… sowie eine vernünftige Unterteilung der Spielelemente (Spielfeld, Spielelemente) in entsprechende Klassen. Vor allem letzteres erleichtert jeglichen Umgang mit dem Code natürlich ungemein – sollte aber ja auch bei jedem Programmierer Standard sein
Die weiteren Ausführungen beziehen sich jetzt stets auf den Teil des Spiels, der in erwähntem Thread läuft, sprich zigmal pro Sekunde abgearbeitet wird. Im Einzelnen also die Berechnung der Position der Objekte auf dem Spielfeld/des Spielers, Kollisionsberechnungen, das Zeichnen von Spielfeld/Spieler/Objekten usw.

Messbarer Erfolg?

Als ersten Schritt habe ich einen Zähler eingebaut, der die Zeit misst, die pro Frame zum Berechnen und Zeichnen benötigt wird, und diese Info alle paar Sekunden über die Debug-Konsole ausgibt ( Log.d(<String tag>, <String message>); ). Mit diesem Zähler war nun das Messinstrument für den Erfolg oder Misserfolg aller kommenden Optimierungen geschaffen.
Eine Ausgabe innerhalb des Spiels selbst (etwa als Text, der auf die Zeichenoberfläche geschrieben wird) ist übrigens nicht empfehlenswert, da man sonst mit dieser Messung das Ergebnis ja bereits verfälschen würde.

Speicherallokation und der Garbage Collector (GC)

Der GC ist ein echter Zeitfresser

Das widerspricht grundsätzlich erstmal jedem guten Programmierstil, schließlich büßt man dadurch Übersichtlichkeit und Flexibilität ein. Doch das Opfer lohnt sich, denn der Garbage Collector ist häufig die größte Performancebremse.
Bei Graviturn habe ich beispielsweise bei der Kollisionsberechnung (Ball -> Wand) sehr häufig mit Point-Objekten gearbeitet (zur Verarbeitung von x/y-Koordinaten), die in jedem Durchlauf bei Bedarf lokal erzeugt wurden. Das hat dazu geführt, dass etwa alle 1-2 Sekunden der Garbage Collector aktiv wurde, und diese Objekte freigegeben hat. Durch Nutzung von globalen Variablen oder simplen Datentypen (etwa zwei int für x und y) konnte dies drastisch reduziert werden.

Allokationstracker bei Graviturn

Traceview verwenden (Android Profiler)!

Traceview der Zeichenroutine von Graviturn

Noch ein paar allgemeine Tipps

• Methodenaufrufe wenn möglich vermeiden
  Da Methodenaufrufe immer zusätzlich Zeit kosten, sollte man beispielsweise Variablen einer Klasse lieber public machen, anstatt get- und set-Methoden zu verwenden. Zwar “unsauber”, aber schneller.
• Gleitkommazahlen (float) vermeiden.
  Je nach benötigter Genauigkeit könnten skalierte integer den entscheidenden Geschwindigkeitsvorteil bringen. Allerdings setze ich zugunsten der Flexibilität weiterhin Gleitkommazahlen ein.
• statische Methoden verwenden so oft es geht
• Keine Iteratoren verwenden
  So praktisch und hübsch sie auch sein mögen, für die Performance sind sie leider schlecht. Mit einer simplen Schleife oder dergleichen lässt sich dasselbe sparsamer erreichen.

Die Liste lässt sich schier beliebig erweitern (hier sei nochmal auf das Video verwiesen), genannt habe ich nur die Punkte, die ich selbst erfolgreich angewandt habe.

Fazit

Es macht Sinn, sich schon frühzeitig Gedanken über die Performance eines Spiels zu machen, um sich zeitraubende Nachbesserungen und Korrekturen am Ende der Entwicklung zu sparen. Gerade weil Android auf einer Vielzahl von unterschiedlichen Endgeräten laufen kann, ist es bei der Spieleentwicklung wichtig, stets ein Maximum an Optimierung herauszuholen, um auch auf schwächerer Hardware ein flüssiges und angenehmes Spielgefühl zu wahren.
Im Fall von Graviturn konnte ich mit den hier aufgezählten Tipps die Framerate von ca. 20 Frames pro Sekunde auf über 50 steigern, was genug Puffer darstellt, um auf allen gängigen Geräten befriedigend zu laufen.

Die Akkulaufzeit der aktuellen Android-Smartphones ist ja nach wie vor ein heiß diskutiertes Thema. Es kursieren die wildesten Gerüchte, welche Funktionen besonders viel Strom brauchen oder dass bestimmte Anwendungen gar eine Hauptschuld an der recht kurzen Akkulaufzeit haben.
Angeregt durch diesen Thread im Android-Hilfe.de-Forum habe ich mir vorgenommen, der Sache genauer auf den Grund zu gehen und die Vermutungen und Gerüchte durch eine fundierte Messung zu überprüfen.

“Versuchsaufbau”

Ich wollte dazu einen Spannungsmesser zwischen Akku und Galaxy einbauen um darüber den Stromverbrauch zu messen (via eingebautem Widerstand im Stromkreis). Das stellte sich als nicht ganz so einfach heraus, da das Galaxy extrem feinfühlig ist, was seine Stromversorgung angeht. Alleine durch die Verkabelung sank die angezeigte Akkuladung um 50%, sobald ein Widerstand (1Ohm) eingebaut war, wollte es gar nicht mehr starten oder schaltete sich bei der ersten Belastung aus. Meine Tests fielen deshalb leider nicht so ausführlich aus, da ich die Probleme mit meinem bescheidenen Equipment nicht vollständig beseitigen konnte. Aufgrund der Ungenauigkeit der Messungen sind die folgenden Werte relativ zueinander zu betrachten. Größenordnungsmäßig befinden sich fast alle Angaben im Bereich von 20-80mA.

Stromverbrauch der versch. Modi

Die verschiedenen Betriebsmodi

Nun aber zu den nicht ganz uninteressanten Ergebnissen. Zuerst einmal habe ich den Stromverbrauch beim Starten, auf dem Homescreen direkt nach dem Start und mit eingeschaltetem Airplane-Modus (keinerlei Funkverbindung) gemessen. Wie man im Schaubild rechts sieht, benötigt der Bootvorgang mit Abstand am meisten Strom (~60mA), bereits etwa eine Minute fällt er um etwa 20% ab. Deaktiviert man alle Funkverbindungen, senkt sich der Stromverbrauch um weitere 30% – was eigentlich nicht viel ist, wenn man bedenkt, dass das Handy nun praktisch unbrauchbar ist.

Verschiedene Displayhelligkeiten

Displayhelligkeit

Doch was verbraucht dann so viel Strom? Um dieser Frage nachzugehen, habe ich als nächstes die Auswirkung der Displayhelligkeit getestet. Die Ergebnisse sind erstmal nicht überraschend: Je heller der Bildschirm, um so höher der Stromverbrauch. Der Unterschied zwischen dunkelster und hellster Einstellung beträgt jedoch nur 25%. Die mittlere Helligkeitsstufe kostet gar nur 10% mehr Strom.
Offenbar sind AMOLED-Bildschirme also tatsächlich recht sparsam (wenngleich ich das Display nicht komplett deaktivieren konnte für eine echte Messung).
Man kann also in Zukunft das Display ruhigen Gewissens etwas heller einstellen, der Akku wird es verzeihen.

Weitere Ergebnisse

Am Schluss nun noch drei interessante Werte, danach schaltete sich das Galaxy beim Aktivieren der internen Kamera leider ab und wollte auch nicht mehr wirklich weiterarbeiten. Die Tests von WLAN, GPS, aktivem Internet etc. fehlen daher leider erstmal. Falls jemand mit besserer Elektronikausrüstung diesbezüglich selbst Versuche durchführen möchte, würde ich mich natürlich sehr freuen
Den höchsten Stromverbrauch habe ich beim Login in’s Handynetz gemessen (nach Eingabe der PIN). Der Wert ist dabei auf das Dreifache des Normalverbrauchs (Homescreen) gestiegen. Der niedrigste Stromverbrauch ergab sich erwartungsgemäß im Airplane-Modus bei aktivierter Tastensperre. Hier war keinerlei Verbrauch mehr messbar, was sich auch mit bekannten Beobachtungen deckt (hiermit könnten wohl die von der Werbung versprochenen 450 Stunden Standby-Zeit erreicht werden).
Ganz beachtlich ist hingegen der enorme Anstieg des Verbrauchs von über 40% bei voller CPU-Last (die beiden Säulen ganz rechts). Dieser Wert hängt natürlich sicher auch immer von der Art der Auslastung bzw. den Randbedingungen ab, doch wer Akkulaufzeit sparen will, sollte hier wohl am ehesten ansetzen (jedoch nicht unbedingt durch wahlloses Abschießen von Prozessen).

Fazit

Alles in allem finde ich die Ergebnisse wirklich interessant und bin natürlich umso enttäuschter, dass ich nicht noch mehr Sachen überprüfen konnte. Vielleicht ergibt sich da ja noch was, dann folgt natürlich ein Teil 2.

Teil 2 gibts hier!