Akku-Killer: Welche iOS-Apps zu viel Strom verbrauchen

Läuft Ihr iPhone oder iPad ungewohnt schnell leer, steckt vermutlich eine App dahinter, die mehr Dinge im Hintergrund erledigt als sie soll. Fortgeschrittene Nutzer kommen solchen Kandidaten auf die Schliche.

vorlesen Druckansicht 21 Kommentare lesen
Lesezeit: 19 Min.
Von
Inhaltsverzeichnis

Leseprobe aus Mac & i Heft 1/2014

Manchmal reicht ein Ausflug in den App Store, und einige neu installierte Apps später hält der iPhone-Akku nicht mehr ganz so lange durch wie zuvor. Oft ist es aber schwer, den oder die tatsächlich Schuldigen zu finden, denn iOS bietet keine Möglichkeit an, gezielt den Stromverbrauch einzelner Apps zu ermitteln. Nicht ganz trivial ist die Analyse dann, wenn wild gewordene Apps im Hintergrund ihr Unwesen treiben, dabei aber nicht auf sich aufmerksam machen – anders als etwa GPS- oder Audio-Apps, die ein entsprechendes Symbol in der Menüleiste anzeigen oder diese einfärben.

Wir haben für diesen Beitrag zunächst gut 50 weitverbreitete Apps mit Apples Analysewerkzeug Instruments auf ihren Stromverbrauch untersucht. Dabei zeigte sich schnell, dass VoIP-Dienste (Voice-over-IP) wie joyn, Viber oder Skype besonders stark am Akku zehren. Zwar nicht so viel wie Navigations-Apps, die den GPS-Chip nutzen – der verbraucht nach dem Display am meisten Energie –, aber doch bemerkbar. Auch die Facebook-App registriert sich unnötigerweise als VoIP-Dienst im Hintergrund und saugt damit verhältnismäßig stark am Akku.

Die App des sozialen Netzwerks Facebook (in Version 6.8) aktivierte in unserem Test spätestens alle 15 Minuten einen Hintergrund-Task – selbst im Ruhezustand des Gerätes. Da half es auch nichts, die Hintergrundaktualisierung in den System-Einstellungen für Facebook abzuschalten. Zusätzlich hält die App eine bestehende WLAN-Verbindung auf dem iOS-Gerät auch nach 30 Minuten Inaktivität aufrecht anstatt sie zu deaktivieren, wie es sonst normalerweise der Fall ist. Ob die Facebook-App das alles braucht und nutzt, ist eher unwahrscheinlich. Im Ergebnis wird so beständig Energie verbraucht, auch wenn das vom Anwender gar nicht beabsichtigt ist. Leider gibt es in der App selbst nur eine Möglichkeit, das Hintergrundverhalten ganz abzustellen: ein Klick auf Abmelden. Das ist nervig, ließ im Test aber die Hintergrund-Tasks verstummen. Der einzige andere Ansatzpunkt scheint die Ortsabfrage zu sein, die der Nutzer Facebook explizit erlauben muss und auch jederzeit in den iOS-Einstellungen unter Datenschutz/Ortungsdienste widerrufen kann. So spart man sich wenigstens die ebenfalls ressourcenfressende GPS-Nutzung. Der übermäßige Energieverbrauch, den wir in der Redaktion mit früheren Versionen der App beobachten konnten, war jedoch nicht mehr nachvollziehbar. Offenbar hat der Hersteller mittlerweile die Fehler in seiner Software beseitigt, die dafür verantwortlich waren.

Mit Apples kostenlosem Hilfsprogramm Instruments, Bestandteil des Xcode-Pakets, kann man iOS-Apps auf die Finger schauen. Templates erleichtern den Umgang damit enorm.

Der VoIP-Dienst Viber tritt in Facebooks Spuren und erwacht mindestens alle zwanzig Minuten aus dem Schlafzustand. Damit ist sich die App auch nicht zu schade, den Ruhezyklus des iOS-Geräts zu unterbrechen. Wir haben Fälle beobachtet, in denen die nächste Reaktivierung gerade mal eine Minute entfernt war. Besonders schlimm trieb es joyn: So oft wie die Chat-App wachte sonst kaum eine von uns untersuchte App im Hintergrund auf, um der Gegenstelle zu signalisieren, dass sie noch aktiv ist. Und obwohl sich die App als VoIP-fähig im System anmeldet, scheiterten wir im Test daran, die (auch in der App-Store-Beschreibung versprochene) Live-Videoübertragung hinzubekommen – aufgebaut wurde lediglich eine normale Telefonverbindung. Parallel dazu wurden die iPhones beider Gesprächspartner unangenehm heiß. Ein Blick auf die Prozessorauslastung bestätigte die Vermutung: Der App-Prozess krallte sich die gesamte verfügbare Rechenleistung; oft auch dann, wenn die App nicht mehr aktiv war.

Allen genannten Apps ist gemein, dass sie, einmal installiert und gestartet, im Hintergrund und bei Ruhezustand Energie verbrauchen. VoIP-Dienste genießen nämlich eine privilegierte Stellung: Selbst wenn der Nutzer solche Apps manuell beendet oder das System sie wegen Speichermangels terminiert, hält iOS die Netzwerk-Verbindung zur jeweiligen Gegenstelle aufrecht und reaktiviert die Apps selbsttätig, sobald sich die Lage entspannt. Auch ein Neustart des Gerätes kann ihnen nichts anhaben. Sofern eine entsprechende App die Option überhaupt bietet, bleibt bloß ein regelmäßiges Abmelden als Ausweg. Aber selbst dann ist nicht sichergestellt, dass die App anschließend Ruhe gibt, wie der Yahoo Messenger zeigt.

Aber es gibt auch vorbildliche Anwendungen. Die offizielle Twitter-App und die soziale Netzwerk-App Socialcast kamen bei uns im Test gänzlich ohne Hintergrundaktivität aus, ebenso wenig machten die E-Mail-Clients AltaMail, Gmail und Seed von wiederkehrenden Tasks Gebrauch. Stattdessen nutzen diese Apps normale Push-Nachrichten, um etwa auf eine neue E-Mail aufmerksam zu machen.

Diese stromsparende Technik kann aber nicht alle Anwendungsfälle abdecken. Wenn zum Beispiel für eine App neue Inhalte im Netz bereitstehen, dann schaute man vor iOS 7 durch die Finger und musste sich selbst um den Download kümmern. Mit der neuen Hintergrundaktualisierung können Apps nun von sich aus tätig werden und etwa frische Podcasts herunterladen. Der Client Castro arbeitet so, ebenso Apples eigene Podcast-App. Auch der „Lies-mich-später“-Dienst Instapaper sieht regelmäßig nach, ob es neue Artikel gibt, die noch nicht in der Offline-Leseliste gespeichert sind, und holt das gegebenenfalls nach. Die Tagebuch-App Day One wiederum aktualisiert auf diese Art in der Dropbox gespeicherte Einträge.

Einer anderen Variante der Hintergrundaktualisierung bedient sich die in Deutschland populäre SMS-Alternative WhatsApp: Sobald eine neue Nachricht eintrifft, lädt die App sie zunächst im Hintergrund herunter und macht erst anschließend darauf aufmerksam. Öffnet der Nutzer die App, wartet die Nachricht bereits auf ihn. Dankenswerterweise verbraucht diese Methode in der Praxis nicht sonderlich viel Energie, wobei es allerdings auf die Anzahl der empfangenen Nachrichten ankommt. Ähnlich verhält sich etwa auch der Notizen-Synchronisierer Evernote, allerdings mit einem Clou: Die App nutzt sogenannte „stille Benachrichtigungen“. Erstellt man beispielsweise über das Web-Interface eine neue Notiz, wacht wenige Sekunden später die iOS-App auf und lädt diese ­herunter. Bestimmte Szenarien lassen sich mit dem Dienst und der zugehörigen App IFTTT (If this, then that) kombinieren: Seit dem neuesten Update unterstützt sie das stromsparende Geofencing und kann zum Beispiel eine neue Evernote-Notiz erstellen, sobald das System sie über eine gröbere Positionsänderung informiert.

Versteckte Verbraucher entlarvt die CPU-Time-Ansicht, obwohl die schuldige App aktuell brav im Hintergrund schlummert.

Das alles passiert im Hintergrund, ohne dass die Apps gesondert darauf aufmerksam machen. Bei häufigen Aktualisierungen und großen Dateien kann sich dieses Verhalten klar auf die Akku-Laufzeit auswirken, bei moderatem Einsatz überwiegt jedoch die Tauglichkeit in der Praxis: Wer in einem Funkloch gefangen ist, kann dennoch auf die zuletzt übertragenen Notizen, Mails oder Podcasts zugreifen, ohne weiter darüber nachzudenken. Hier scheint Apple einen guten Kompromiss zwischen Benutzerfreundlichkeit und Ressourcen-Verwaltung gefunden zu haben. Möchte man aber ein paar Prozentpunkte Akku gewinnen und kann auf den Komfort verzichten, lässt sich Apps dieses Verhalten über die Einstellung „Hintergrundaktualisierung“ abgewöhnen.

Generell ist es bei vielen verwendeten Apps jedoch schwierig, intuitiv den Schuldigen ausfindig zumachen. Um der Problematik auf den Grund gehen zu können, hilft es zu verstehen, wie es zu unterschiedlichem Energieverbrauch aufgrund der genutzten Apps kommen kann.

Apple hat nicht nur seine mobilen Geräte, sondern insbesondere auch iOS und seine App-Schnittstellen von Grund auf darauf ausgelegt, möglichst wenig Energie zu verbrauchen. Frühe iOS-Versionen kannten in dieser Hinsicht keine Kompromisse, zumindest bei Software aus dem App Store: Ein Drücken auf den Home-Knopf beendete die gerade geöffnete App rücksichts- und restlos. Auf diese Art ließ sich zwar hervorragend Strom sparen, viele Dienste wie das Ermitteln des aktuellen Standortes im Hintergrund waren dadurch jedoch nicht realisierbar. Erst mit iOS 4 hat Apple Apps die Möglichkeit eingeräumt, unter gewissen Auflagen im Hintergrund aktiv zu bleiben und beispielsweise Internetradio zu empfangen.

Dabei ist Multitasking kein neues Konzept, sondern auf Macs schon seit Zeiten des ursprünglichen OS X gang und gäbe. Allerdings gibt es in der iOS-Implementierung für den Nutzer mindestens zwei wichtige Unterschiede: iOS gönnt sich die Freiheit, Apps nach eigenem Gutdünken zu beenden – und in bestimmten Fällen auch wieder im Hintergrund zu reaktivieren. Das greift beispielsweise dann, wenn eine App auf eingehende Telefonate wartet, ohne dabei geöffnet zu sein.

Das forcierte Beenden soll einerseits dafür sorgen, dass genug Speicher für gerade genutzte Anwendungen zur Verfügung steht. Andererseits soll es im Umfeld der sparsamen Mobilprozessoren verhindern, dass eine App im Hintergrund den Prozessor (zu) stark belastet. Apple schreibt genau das auch seinen Entwicklern vor: Wenn eine App in den Hintergrund wechselt, soll sie sich schon einmal darauf gefasst machen, Tasks möglichst schnell zu beenden. Ganze fünf Sekunden hat die App dafür im besten Fall noch Zeit. Mit einem speziellen Aufruf kann sie noch eine letzte Nachfrist von etwa 10 Minuten erzielen – Amazon Cloud Drive oder Dropbox nutzen das beispielsweise, um schnell noch Daten im Hintergrund hochzuladen. Hält sich eine App nicht an diese Vorgaben oder wagt es gar, OpenGL-ES-Code auszuführen, setzt es einen mit der Bratpfanne: iOS suspendiert die App sofort und gönnt ihr nicht einmal die paar Sekunden Hintergrund-Aktivität.

„Manage Flags…” heißt der Befehl im Window-Menü von Instruments, über den sich alle Ereignisse einer App schnell heraussuchen lassen.

Tatsächlich durchläuft eine App, die gerade im Vordergrund war, bei einem App-Wechsel zwei Zustände: Der gerade beschriebene Hintergrund-Zustand ist nämlich eigentlich nur ein kurzzeitiger Übergang in den Suspend-Zustand. Dieser ist sozusagen der wirkliche Schlafmodus: Wer hier landet, hat nicht mehr viel zu melden. Wird Speicher benötigt, entfernt iOS den größten Verbraucher im Hintergrund. Das Prozedere wird Purging – im übertragenen Sinne Aufräumen – genannt. Eine Hintertür hat Apple jedoch offen gelassen: Wenn es einen besonderen Grund gibt, dann dürfen Apps mit guten Argumenten im Hintergrund weiterlaufen oder sich regelmäßig reaktivieren lassen. Apps, die zum Beispiel Audio abspielen oder aufnehmen, die Geo-Position bestimmen, über Bluetooth oder VoIP kommunizieren oder als Kiosk-Anwendung Magazin-Inhalte herunterladen, erfüllen Apples Vorgaben für den Dauerbetrieb.

Mit iOS 7 sind noch zwei weitere Techniken hinzugekommen, die den Hintergrundbetrieb beziehungsweise ein Aufwecken einer App bei Bedarf rechtfertigen: „Fetch“ kommt zum Einsatz, wenn Apps regelmäßig Datenhäppchen aus dem Netz nachladen wollen, weil neue Inhalte anstehen. Apples hauseigene Wetter-App beispielsweise bedient sich dieser Methode. Die „remote-notification“ behandelt einen ähnlichen Fall, nämlich wenn das Eintreffen einer Push-Nachricht einen Download im Hintergrund erforderlich macht. Das könnte zum Beispiel ein neu gepostetes Foto in einem sozialen Netzwerk sein oder eine neue Notiz in Evernote. Die App erhält dann Gelegenheit, den Download abzuschließen, bevor der Anwender die Push-Nachricht zu sehen bekommt: Der Inhalt wartet dann bereits auf den Nutzer, wenn dieser die App öffnet.

Die Info.plist-Datei gibt Aufschluss darüber, ob sich eine App überhaupt für den Hintergrund-Betrieb qualifizieren will. Ausschlaggebend ist der Schlüssel „UIBackgroundModes”.

Besonders dabei ist, dass iOS mit dem Nutzer mit lernt und regelmäßig benutzte Apps bevorzugt behandelt. Diese dürfen dann öfter aufwachen und Daten nachladen. Ferner bevorzugt das System Apps, die kleine Datenhäppchen anfordern. Dabei versucht iOS zusätzlich Strom zu sparen, indem es in der Regel mehrere solcher Apps auf einmal aufweckt, um Funk- und andere Komponenten möglichst selten zu strapazieren. Selten verwendete Apps bleiben hingegen dauerhaft inaktiv, selbst wenn sie diese Methode unterstützen sollten.

Bevor Entwickler diese Ausnahmen in ihren Projekten nutzen können, müssen sie den gewünschten Hintergrund-Modus (UIBackgroundModes) in einer speziellen Datei namens Info.plist deklarieren (mehr dazu gleich). Insgesamt stellt Apple neun dieser Methoden zur Verfügung: Eine Übersicht der UIBackgroundModes finden Sie, wenn Sie unserem Webcode folgen.

Die Facebook-App beispielsweise gönnt sich gleich vier UIBackgroundModes – nämlich audio, voip, location und fetch – sowie zusätzlich einen bejahenden Eintrag im Schlüssel UIRequiresPersistentWiFi. Eben dieser sorgt dafür, dass das iOS-Gerät eine bestehende WLAN-Verbindung auch nach 30 Minuten Inaktivität nicht aufgibt. Der alleinstehende (Facebook) Messenger gibt sich mit den Schlüsseln voip und audio etwas genügsamer, machte sich aber dennoch – wie Facebook – etwa alle 10 bis 15 Minuten bemerkbar.

(Video-)Telefonie-Apps, die diese Dienste auch tatsächlich nutzen, registrieren sich in der Regel mit voip und audio. Problematisch ist an diesen Apps, dass sie eine beständige Netzwerk-Verbindung zur Gegenstelle aufrechterhalten müssen. Den Umweg über Apples Server, den Push-Nachrichten gehen (wodurch nur eine einzige, gemeinsam genutzte Verbindung aktiv ist), können Anbieter dieser Dienste nicht nehmen. Damit aber zumindest die Apps nicht permanent laufen müssen, überwacht iOS die Netzwerk-Sockets, die die jeweiligen Apps zur Kommunikation aufgebaut haben. Trifft ein Anruf ein, weckt das System die schlafende App und reicht die Anfrage nahtlos weiter. So lässt sich zumindest ein wenig Strom sparen – aktive Netzwerkverbindungen sind aber dennoch übermäßig teuer. In der Praxis ist also zu erwarten, dass Telefonie-Apps, die im Hintergrund laufen, als besonders stromfressend auffallen.

Im Panel „App Activity” verrät das Hilfsprogramm Instruments, wenn sich der Multitasking-Zustand einer App ändert.

Dennoch gibt es Unterschiede in den einzelnen Implementationen: Skype etwa meldet wie erwartet audio und voip an und meldet sich anschließend regelmäßig in der Prozessliste. Vorbildhaft ist dabei aber, dass Skype dem Nutzer die Wahl lässt und ein Abmelden nach einer bestimmten Zeitspanne ermöglicht – das System kappt die Netzwerkverbindung zu Skypes Servern, und anschließend verstummt die App und verbraucht keinen Strom mehr. Viber hingegen bietet keine entsprechende Option in den Einstellungen und wacht so lange in regelmäßigen Abständen auf, bis man die App manuell beendet. Den Mittelweg beschreitet ­Yahoos Messenger, der ein manuelles Abmelden ermöglicht. Dumm nur, dass das die App nicht daran hindert, sich trotzdem in regelmäßigen Abständen bemerkbar zu machen. Die App verbrauchte zwar überraschend wenig CPU-Ressourcen. Dennoch kann man sie als potenziellen Verbraucher einstufen, denn jede Aktivierung kostet Energie, und über einen längeren Zeitraum kommt einiges zusammen.

Leider bedeutet ein gesetzter UIBackgroundMode aber keineswegs automatisch, dass eine App diesen auch nutzt. Die Youtube-App beispielsweise ist notorisch dafür bekannt, keine Musik im Hintergrund abspielen zu können – wobei entsprechende Einträge in ihrer Info.plist darauf hinweisen, dass sie darauf eigentlich vorbereitet ist. Auch Dropbox konnten wir im Test nicht dazu bewegen, selbsttätig Inhalte zu synchronisieren, obwohl der fetch-Eintrag vorhanden ist. Was die App allerdings sehr wohl kann, ist im Hintergrund Audio abzuspielen und für ein paar Minuten im Hintergrund Fotos hochzuladen – auch wenn man beides nicht unbedingt von ihr erwarten würde.

Wer mehr als ein Gerät mit Instruments einsetzt, sollte bei Fehlermedlungen ins Target-Menü schauen und dort das Zielgerät überprüfen.

Gerne wachen auch regelmäßig Apps auf, die auf einem ­iPhone 5s M7-Daten auslesen. In der Regel bedienen sie sich dabei der relativ stromsparenden Methode „significant change location service“, die nur auf Geräten mit Mobilfunk-Chip zur Verfügung steht. Das Betriebssystem registriert den Wechsel einer Funkzelle und schließt daraus, dass sich der Nutzer mehr bewegt haben muss als bloß ein paar Meter. Apps, die sich in dieses Framework einklinken, bekommen ein Aufwach-Signal gesendet und pflegen die gesammelten Schritte in ihre Datenbank ein. Wer viele solcher Apps installiert hat – wenn auch nur zum Ausprobieren –, sollte sich bewusst sein, dass auf diese Art regelmäßig Hintergrundaktivität stattfindet, obwohl der GPS-Chip dabei vielleicht ruht. Diese Schnittstelle benutzen unter anderem auch die Google- und die Foursquare-App.

Für den Anwender bedeutet das Multitasking-Konzept, dass er sich ohne weiteres nie sicher sein kann, ob eine App noch läuft oder nicht. Selbst das manuelle Beenden einer App oder gar ein Neustart des Gerätes müssen nicht zwangsläufig bedeuten, dass anschließend im Hintergrund Ruhe herrscht.

Wer das eigene iPhone auf gefräßige Apps durchsuchen möchte, muss selbst Hand anlegen. Eine erste Analyse funktioniert allerdings nur mit Apps aus dem App Store – an die mitgelieferten Standard-Anwendungen kommt man mit dieser Methode ohne Jailbreak nicht heran. Zunächst benötigen Sie Apples Entwicklungsumgebung Xcode, die kostenlos im Mac App Store zum Download bereitsteht. Als zweiten Schritt installieren Sie ein Tool, mit dem sich das eigene iOS-Gerät am Mac als Volume mounten lässt. Das kostenlose Programm iFunBox reicht dazu aus (alle Downloads siehe Webcode). Bei verbundenem iOS-Gerät zeigt das Werkzeug die App-Verzeichnisse unter dem Menüpunkt „User Applications“ an. In denen verbirgt sich jeweils ein .app-Ordner, der nicht unbedingt denselben Namen wie die App haben muss. Bei InfinityBlade heißt der Ordner zum Beispiel SwordGame.app. Darin wiederum findet sich auf oberster Ebene die bereits erwähnte Datei Info.plist. Ein Doppelklick darauf öffnet Xcodes Plist-Editor, der die XML-Datei anschaulich darstellt: Auf der linken Seite listet der Editor die jeweiligen Schlüssel (Key) auf, während in der ganz rechten Spalte die dazugehörigen Schlüsselwerte (Value) auftauchen. Das Objekt der Begierde sind die beiden oben genannten Schlüssel, UIRequiresPersistentWiFi und UIBackgroundModes. Unter ihrem „offiziellen“ Namen tauchen sie allerdings nur dann auf, wenn im Menüpunkt „Editor“ der Haken bei „Show Raw Keys & Values“ gesetzt ist – sonst werden sie als „Application uses Wi-Fi“ respektive „Required Background Modes“ bezeichnet. Je nach Ansicht ändern sich auch die entsprechenden Werte. So wird aus dem simplen Schlüsselwert „voip“ der Fließtext „App provides Voice over IP services“.

Das Network-Template in Instruments verrät, mit welcher Gegenstelle sich iOS-Apps eigentlich verbinden.

Sind die Schlüssel vorhanden und gesetzt, ist schon einmal klar, dass sich die WiFi-Verbindung nicht schlafen legt und wohl vermutlich auch regelmäßige Reaktivierungen der untersuchten App im Hintergrund stattfinden. Als ersten Schritt können Sie so also überprüfen, ob diese App als möglicher Stromfresser im Hintergrund überhaupt in Betracht kommt – eine App, die keine Hintergrund-Tasks anfordert, ist schließlich auch nicht im Hintergrund aktiv. joyn zum Beispiel meldet hier den VoIP-Bedarf an. Doch selbst wenn entsprechende Werte gesetzt sind, bleibt die Gesamtverbrauchsbelastung einer App dennoch im Dunklen. Gerade die CPU-Auslastung lässt sich so nicht feststellen, und auch eine Einschätzung der Häufigkeit der Reaktivierungen ist nicht möglich. Dazu bedarf es etwas mehr Handarbeit.

Lesen Sie den vollständigen Artikel "Energisch einschreiten" in Mac & i Heft 1/2014, um zu erfahren, wie Sie mit Hilfe des kostenlosen Tools Instruments Ihre Apps präzise auf den Stromverbrauch analysieren können und worauf es dabei zu achten gilt. Sie können Heft 1/2014 im Einzelhandel kaufen, im Heise-Shop bestellen oder in der iPad-App von Mac & i lesen. Mac & i gibt es natürlich auch im Abo. (tru)