Apps für Android programmieren leicht gemacht!

Akku sparend programmieren – Der Tragödie zweiter Teil

Bereits vor einiger Zeit habe ich über Techniken berichtet, um die Akkulaufzeit von Android mittels optimierter Programmierung zu verlängern. Heute möchte ich gerne auf der Tragödie zweiten Teil einsteigen und weiterführende Tipps zur Verfügung stellen.

Powerbanks gibt es inzwischen viele, weil der eigene Handyakku meist nicht mit hervorragender Laufzeit glänzt. Natürlich hängt das von vielen Faktoren ab, wie der Android Anpassung des Herstellers, der Hardware und dem Nutzerverhalten. Was wir als Entwickler aber tun könnten, ist unsere Apps auf die Akkulaufzeit zu optimieren. An vielen Stellen wird bei dieser Art der Optimierung sogar noch eine Performanceverbesserung erreicht, aber an einigen Stellen geht uns vielleicht sogar Performance verloren. Später dazu mehr.

Im letzten Artikel haben wir uns vor allen Dingen auf die effiziente Platzierung und Nutzung von Methoden und Funktionen konzentriert. In diesem Artikel soll es dieses mal vor allem um die Akku sparende Programmierung in Bezug auf die Netzwerkkommunikation und allgemeiner Funktionen gehen, die mit einer Verbindung zur Außenwelt zu tun haben.

 

Netzwerkkommunikation optimieren

Betrachten wir unser Smartphone erst einmal nicht als kleinen Taschencomputer an sich, sondern als kleine Sendeanlage. Meist sind im CPU unseres Smartphones und vermehrt auch in Tablets Chips integriert, die eine Verbindung für die Tele- und allgemeine Netzwerkkommunikation ermöglichen. Diese verbrauchen selbstverständlich ebenfalls Energie und damit Akkuladung. Da wir aber hier über eine hoffentlich genügend große Antenne Daten senden und empfangen, muss ein höherer Energieaufwand betrieben werden, um eine Verbindung aufrecht zu erhalten. Befinden wir uns in Gebäuden oder gar in Kellern, dann steigt selbstverständlich auch die Sendeleistung und damit der Energieverbrauch. Der Trick ist, dass Android automatisch die Verbindung weitestgehend kappt und somit wirklich hardwareseitig dem Chip zu Teilen den Saft abdreht. Natürlich erst nach einer gewissen Zeitspanne.

Wir sollten somit bestrebt seine den Datenaustausch über W-Lan und vor allem über die mobilen Daten zu minimieren und vor allem die Zeitspanne zwischen den Netzwerkanfragen länger werden zu lassen.

Ebenfalls sollten wir für unsere Überlegungen eine vorige Differenzierung zwischen den Zeitpunkten zur Netzwerkanfrage schaffen. Nämlich gibt es einmal die nutzerinitiierten Netzwerkanfragen und dann die automatisierten Netzwerkanfragen.

 

Wann sollten wir Netzwerkanfragen senden?

Nutzerinitiierte Netzwerkanfragen

Ein Nutzer klickt auf den „Refresh“-Button. Was sollten wir nun tun? – Natürlich sofort eine Netzwerkanfrage senden. Kein Nutzer will 2 Minuten warten, bis unsere App die nächste Nertzwerkanfrage triggert. Wir können also getrost auf Akku sparendes programmieren verzichten.

Super, hier erwartet uns also keine Arbeit.

Automatisierte Netzwerkanfragen

Stellen wir uns einmal hypothetisch folgendes Szenario vor: Wir programmieren eine News App und wollen nach Möglichkeit die aktuelle Kommentaranzahl für jeden Artikel anzeigen. Zwar sollten wir das nicht tun, aber wir gehen mal davon aus, dass diese immer möglichst genau sein soll und refreshen daher die Anzahl alle 30 Sekunden.

Da es sich um eine nicht sonderlich kritische Funktion handelt und in den meisten Fällen sogar völlig überflüssig ist, könnten wir überlegen die Refreshzeiten auf 2 Minuten anzuheben.

 

Wie sollten wir mit Netzwerkanfragen umgehen?

Hier gibt es nur eine goldene Grundregel: Sparsam!

Jeder Http-Request kostet Zeit, kostet Energie und kostet den Netzwerkchip die Ruhezeiten.
Wenn wir bei dem Beispiel mit der News App bleiben, dann sollten wir versuchen die Anzahl der Kommentare alle auf einmal zu erhalten. 1 Request + Response + CPU Aufbereitung/Verarbeitung der Daten kostet in der Regel weniger Energie, als das selbe 50 mal, nur mit weniger CPU Rechenaufwand pro Kommentar.

Möglich wäre es sogar, nicht nur die Anzahl der Kommentare, sondern auch den gesamten Newscontent in einem Http-Request zu behandeln. Wir sparen so so spätere Netzwerkanfragen, beim Aufruf von Artikeln.

Hier wären wir dann auch schon wieder bei der Performancefrage. 50 Datensätze zu verarbeiten kostet uns mehr CPU Zeit und könnte damit die App gefühlt etwas verlangsamen. Versucht einen Kompromiss zu finden.

Selbiges gilt übrigens auch in Fällen von Bild Up- und Downloads. Ihr sollt nicht versuchen alle Bilder der News App direkt beim Aufruf des Menüs zu laden, sondern diese zu komprimieren. Sowohl auf dem Server (Download), sondern auch schon vor dem Upload. Dies geht am besten, wenn ihr die Bilder nicht direkt komprimiert, sondern die Größe verändert. Whatsapp löst das ganz gut, indem es Bilder verkleinert und dabei die Bildqualität geringfügig senkt. Das spart Akkuleistung und als kleinen Nebeneffekt auch Datenvolumen und Uploadzeit, wo hingegen die CPU Zeit, zum verkleinern des Bildes, steigt.

 

GPS optimieren

Auch bei dem Prüfen von Standortdaten gilt: Sparsam sein.

Versucht die Aktualisierungsintervalle gering zu halten.
Als kleinen Tipp: Solltet ihr alle 60 Sekunden den Standort des Nutzers erfassen und dieser hat sich seit 10 Minuten kaum von der Stelle bewegt, dann setzt einfach den Aktualisierungsintervall z.B. auf 120 Sekunden hoch. Das spart enorm Akku! Wird eine Bewegung registriert, dann setzt den Intervall einfach wieder herunter.
Eine gute Möglichkeit gibt es in einem meiner älteren Artikel, zur Bestimmung des Standortes über GPS.

Aber mal ganz unter uns. Ich persönlich mag es nicht unbedingt, wenn eine App meinen genauen Standort erfahren will. Würde es nicht auch reichen dass die App den Standort nur ungefähr erfährt?
Solltet ihr nicht unbedingt immer den genauen Standort benötigen, dann versucht gänzlich oder zu Teilen auf einen ungenaueren Standort zurück zu greifen. Die Bestimmung der Position per GPS ist schön genau, aber auch um einiges mehr ein Akkufresser, als die Approximation über Sendemasten und W-Lan Netzwerknamen.

Nutzt am besten sogar die Vorgehensweise in dem Artikel weiter oben. Dieser Artikel baut auf dem Fused Location Provider auf. Einer API, die einmal den Standort bestimmt und dann an die App weiter gibt. Unsere App selber macht dann gar keine Standortabfragen mehr, sondern erhält diese von Android. Meiner Meinung nach der Akku sparenste und vor allem simpelste Weg.

Marvin

Ich bin 23 Jahre jung und studiere zurzeit Wirtschaftsinformatik an der Georg-August-Universität in Göttingen. Ich bin ein Mensch, der sich neben der Programmierung noch für tausend andere Dinge interessiert, die mal mehr und mal weniger verrückt sind. Vor allem aber bin ich Feuer und Flamme mit der Programmierung von eigenen kleinen Apps und Programmen, die mein Leben bereichern.

Kommentar hinzufügen

*Pflichtfeld