Nachdem die Facebook-App ja schon als Akku-Fresser entlarvt ist, habe ich mir noch einige weitere Apps angeschaut. Die meisten verhalten sich zum Glück vernünftig und laufen überhaupt nicht im Hintergrund, benutzen für ihre Benachrichtigungen Apples Push-Notifications.

Offensichtliche Akku-Fresser wie Navigations-Apps habe ich ebenfalls nicht getestet. Da ist klar, dass sie viel Akku brauchen: die ganze Zeit GPS aktiv, Display immer an und dann auch noch Ton ausgeben, das kann ja nur Akku fressen. Bei Spielen dürfte das auch klar sein: Je aufwendiger und hübscher die Grafik, desto schneller ist der Akku leer. Also lieber ein einfaches 2D-Spiel anstatt der 3D-Variante.

Man könnte ja denken: Wenn Facebook so viel Akku braucht, wie sieht es denn dann bei anderen Social-Networks aus?

Die Google+-App verhält sich absolut vorbildlich und läuft nur, wenn sie aktiv im Vordergrund ist – sonst verwendet sie Push-Nachrichten. Auch Twitter läuft nicht im Hintergrund und bietet überhaupt keine Benachrichtigungen an. Wie können diese Apps aber Benachrichtigungen anzeigen, wenn sie überhaupt nicht im Hintergrund aktiv sind? Das liegt an der Art und Weise, wie Apple diese Benachrichtigungen gelöst hat. Dazu muss ich aber erst einmal erklären, wie es normalerweise läuft.

Auf einem Computer gibt es keine Multitasking-Beschränkungen, dort kann jedes Programm alles mögliche im Hintergrund machen – natürlich auch auf das Internet zugreifen. So hat zum Beispiel die Twitter-App eine Verbindung zu den Twitter-Servern und fragt dort nach, ob es neue Tweets gibt. Darüber kann die Twitter-App den Nutzer auf alle erdenklichen Arten informieren: eine Benachrichtigung anzeigen, ein Icon ändern oder auch ein riesiges blinkendes Fenster vor allen anderen öffnen.

Android macht das genauso. Dort laufen die Apps munter im Hintergrund, kommunizieren mit ihren Servern und wenn es etwas Neues gibt, melden sie sich und zeigen eine Benachrichtigung an. Das ist vor allem für die Entwickler von Vorteil, weil es für sie weniger Arbeit ist (der Code ist ja im Prinzip der, der auch sonst für sie Server-Kommunikation verwendet wird). Für den Nutzer aber zeigen sich die Nachteile in Form von reduzierter Akku-Laufzeit und verbrauchtem Datenvolumen.

Apple hat sich da etwas anderes ausgedacht. Bei iOS werden die Benachrichtigungen zentral von Apple an die Geräte geschickt. Damit das funktioniert, muss der Server eines Dienstes Benachrichtigungen an Apple schicken, damit die sie dann an den Nutzer schicken können:

Die Vorteile sind klar: Die Apps müssen nicht laufen, damit der Nutzer benachrichtigt wird, also gibt es keine verringerte Akkulaufzeit und nicht jede App hat eine eigene Verbindung zu ihrem Server. Stattdessen gibt es nur eine einzige Verbindung zu Apples Servern, über die die kleinen Push-Nachrichten geschickt werden. Das spart massiv Datenvolumen.

Der Nachteil liegt hier klar auf der Entwicklerseite, denn diese Art der Benachrichtigungen ist wesentlich komplizierter umzusetzen. Das ist besonders problematisch, wenn einem der Server, mit dem man kommuniziert, nicht gehört. Populäres Beispiel: diverse Twitter-Clients, die natürlich auf Twitters offizielle Server zugreifen, den Nutzer aber trotzdem über neue Tweets informieren wollen. Einzige Lösung: einen eigenen Server betreiben, der anstelle der Twitter-Server die Push-Nachrichten an Apple schickt. Das kann und will natürlich nicht jeder Entwickler leisten.

Seit iOS 4 gibt es auch lokale Benachrichtigungen, die genauso ausssehen wie die Push-Nachrichten. Der Nutzer hat also keine Möglichkeit, die beiden Varianten zu unterscheiden. Lokale Benachrichtigungen wurden eingeführt, damit zum Beispiel Timer-Apps den Nutzer mit einer Benachrichtigung informieren können, dass ihr Tee fertig ist. Früher hätte man die App dafür geöffnet lassen oder eben extra dafür einen Server aufstellen müssen, der dann Push-Nachrichten verschickt.

Eine App-Kategorie, die diese akkuschonende Möglichkeit nicht nutzt, sind VoIP-Apps. Laut Apples Programmier-Richtlinien funktioniert eine VoIP-App unter iOS folgendermaßen: Sie sagt dem System, in welchem Intervall sie aufgeweckt werden will (kleinstes Intervall sind zehn Minuten). Innerhalb dieses Intervalls wird sie dann vom System geweckt und darf maximal zehn Sekunden etwas tun – dann wird sie automatisch wieder eingefroren. Diese Zeit ist vorgesehen, um ein kurzes Lebenszeichen an den VoIP-Server zu senden, damit die Verbindung aktiv bleibt. Außerdem gibt die App einen Socket (eine Serververbindung) an das System ab. iOS überwacht nun diesen Socket, während die App schläft. Werden Daten auf dem Socket empfangen, wird die App geweckt und der Socket an die App zurücktransferiert.

Damit man über eine VoIP-App immer erreichbar ist, startet das System sie direkt nach Systemstart, damit sie ihre Verbindung aufbauen kann. Das heißt nicht nur, dass VoIP-Apps regelmäßig im Hintergrund aktiv sind und potentiell Status-Infos senden, sondern auch, dass das System eine Verbindung zum Server des VoIP-Anbieters aufrechterhält, was sicher auch Datenvolumen verbraucht. Außerdem wird diese Verbindung immer wieder neu aufgebaut, wenn man mal kein Netz hat. Und das verbraucht garantiert Daten.

VoIP-Apps werden automatisch neu gestartet, wenn das System sie wegen Speichermangels beenden muss. Dabei geht auch die Verbindung verloren und muss von der App wiederhergestellt werden. Interessanterweise werden sie nicht neu gestartet, wenn sie vom Nutzer beendet werden. Gut für uns, weil wir sonst überhaupt keine Handhabe gegen solche Apps (außer dem Löschen) hätten.

Immerhin fasst das System mehrere dieser VoIP-Hintergrund-Aktionen zusammen, damit der Prozessor nur kurzzeitig viel zu tun hat und nicht durchgängig immer ein bisschen. Hat man also Skype und Facebook installiert, sind diese gleichzeitig im Hintergrund aktiv. So tritt nicht der Fall ein, dass Facebook immer genau in der Zeit aktiv ist, wo Skype schläft. Also: Hat man erstmal eine VoIP-App installiert, schaden weitere  kaum noch. Natürlich aber ist die Prozessor-Last umso höher, je mehr Apps zur gleichen Zeit im Hintergrund aktiv sind.

Das erklärt auch das Verhalten der Facebook-App aus meinem letzten Test. Sie nutzt die Standard-VoIP-Vorgehensweise, wird dadurch alle zehn Minuten aktiv, nutzt dann die ganzen zehn Sekunden aus und schläft wieder ein. Da sie als offizielle VoIP-App durchgeht, wird sie auch automatisch beim iPhone-Start mitgestartet und läuft ab da im Hintergrund – einzig das harte Beenden hält sie wohl davon ab. Mein Kritikpunkt weiterhin: Macht das konfigurierbar (Die wenigsten werden wohl über Facebook telefonieren) oder löst es mit einer schnöden Push-Nachricht!

Die Vorteile einer solchen Methode würden überwiegen: Sie verbraucht keinen extra Akku und keine extra Daten. Sobald man die App dann über die Push-Nachricht öffnen würde, könnte sie die Verbindung herstellen und alles wäre gut. Eventuell verpasst man dann einige Anrufe, weil das dadurch ein paar Sekunden länger dauert, aber wenn der Akku dadurch länger hält, könnte ich damit leben.

Als positives Beispiel möchte ich hier Google-Hangouts anführen. Die App erlaubt zwar das Telefonieren (inklusive Video), läuft dafür aber nicht ständig im Hintergrund, sondern nutzt exakt das eben beschriebene Verfahren. Skype als wohl bekannteste und beliebteste VoIP-App ist leider kein ganz so positives Beispiel, aber immerhin besser als die Facebook-App. Sie ist genau wie Facebook alle zehn Minuten im Hintergrund aktiv. Im Gegensatz zu Facebook kann man aber in der App „Offline“ gehen und damit die Hintergrund-Aktivität ausschalten.

Viber, ein Messenger wie WhatsApp, über den man aber auch telefonieren kann, verhält sich als VoIP-App ähnlich wie Facebook – mit dem kleinen, aber bedeutenden Unterschied, dass Viber nicht alle zehn Minuten im Hintergrund aktiv ist, wie es vorgesehen ist, sondern alle drei Minuten!

Die App umgeht dabei keine von Apples Vorgaben, sondern benutzt einen völlig legalen Trick. Erinnern wir uns daran, dass das System Apps aufweckt, sobald Daten über den Socket ankommen. Eigentlich ist das so gedacht, dass dort eingehende Anrufe signalisiert werden. Viber aber sendet offensichtlich alle drei Minuten ein kleines Datenpaket vom Server aus über diesen Socket. Das merkt iOS und startet die App. Und schon kann die alle drei statt alle zehn Minuten aktiv sein.

Um das herauszufinden, bedurfte es einer Traffic-Analyse mit Wireshark. Wireshark ist ein Tool um Netzwerkverkehr aufzuzeichnen und auszuwerten. Das funktioniert auf einem Computer sehr einfach, da man dort vollen Zugriff auf alle Netzwerk-Interfaces hat – auf dem iPhone geht das nicht. Das Smartphone von Apple ist abgeschottet und erlaubt Apps keinen Zugriff darauf, sodass es auch kein Wireshark unter iOS gibt. Die einzige offensichtliche Möglichkeit ist, einen HTTP-Proxy in den WLAN-Einstellungen des iPhones einzutragen.

Das war auch mein erster Versuch. Man installiert sich einen Proxy-Server wie Burp auf seinem Rechner, erlaubt dort den Zugriff auch von anderen Rechnern und trägt dann die IP-Adresse des Rechners, auf dem Burp läuft, in den WLAN-Einstellungen des iPhones ein. Damit kann man sich dann wunderbar den Verkehr des iPhones anzeigen lassen und mit einem hier beschriebenen Verfahren sogar SSL-verschlüsselten Verkehr anzeigen. Das Problem dabei: Viber taucht dort nicht auf, weil es nicht per HTTP kommuniziert, sondern ein eigenes Protokoll verwendet. Burp aber ist ein reiner HTTP-Proxy. Und selbst, wenn Burp mehr könnte, gäbe es auf dem iPhone keine Möglichkeit, etwas anderes als einen HTTP-Proxy einzutragen.

Da kommt Wireshark ins Spiel. Zum Glück bietet Mac OS X von Haus eine einfache Lösung für das Problem: die Internet-Freigabe. Dabei wird die Internet-Verbindung (die in dem Fall über eine andere Schnittstelle als WLAN erfolgen muss), über WLAN freigegeben. Dafür bietet der Mac dann ein WLAN an, in das man sich vom iPhone aus einloggen kann. Nun läuft der gesamte Netzwerkverkehr über die WLAN-Schnittstelle des Macs. Diese Schnittstelle kann man jetzt in Wireshark auswählen und aufzeichnen lassen. Dann erhält man diese Liste:

In der linken Spalte sieht man die Uhrzeit, zu der etwas gesendet wurde. Die weiteren Spalten zeigen Absender, Empfänger und Art der Datenpakete an. Dort kann man dann sehr schön sehen, dass (fast) immer zu dem Zeitpunkt, zu dem Viber im Hintergrund aktiv ist, ein TCP-Paket vom Viber-Server (54.225.248.253) an das iPhone (192.168.2.2) gesendet wird. Daraufhin sendet Viber auf dem iPhone etwas zurück, was dann noch vom Viber-Server bestätigt wird. Hieran kann man gut sehen, dass es der Server ist, der zuerst sendet. So umgeht Viber also die Einschränkung, nur alle zehn Minuten aktiv sein zu dürfen.

Hier kann man nun wieder die gleiche Methode anwenden, die auch bei Facebook half: die App komplett beenden. Dass man das getan hat, merkt Viber beim nächsten Start und präsentiert einem diese hübsche Meldung:

Das ist glatt gelogen! Die App verbraucht sehr wohl Akku (und zwar mehr als nötig) und Speicher verbraucht sie natürlich auch. So kann man seine Nutzer auch für dumm verkaufen. Und wie bei Facebook gibt es in der App keine Möglichkeit, das abzustellen. Angespornt durch diesen Fund hab ich mir noch weitere Messenger angeschaut.

Zuerst die positiven Beispiele: Threema, Hike, LINE und ChatON sind harmlos, denn sie laufen überhaupt nicht im Hintergrund. Alles wird mit normalen Push-Nachrichten gelöst. imo, KakaoTalk und joyn laufen alle fünf Minuten im Hintergrund. Die joyn-App hingegen ist eine richtige Akku-Sau, beziehungsweise ziemlich „kaputt“. joyn läuft normalerweise auch alle fünf beziehungsweise zehn Minuten im Hintergrund.

Manchmal verhält sie sich aber auch komplett merkwürdig und läuft wesentlich öfter. Ich habe mehrmals beobachtet, dass joyn sofort, nachdem sie nicht mehr aktiv ist, sofort wieder neu startet und wild mit seinem Server kommuniziert, was natürlich viel CPU-Last erzeugt.

Die App ist dann merkwürdigerweise manchmal auch länger als die erlaubten zehn Sekunden aktiv. Wie sie das bewerkstelligt, ist unklar. Es ist aber logisch, dass häufige Aktivität mit hoher CPU-Last eine kürzere Akku-Laufzeit bedeutet. Und so sieht der CPU-Time-Graph auch noch extremer aus als bei der Facebook App.

Es ist also nicht nur wichtig, wie oft eine App im Hintergrund aktiv ist, sondern auch, was sie dort macht, also wie rechenintensiv ihre Aktivität ist. Da joyn leider nicht mehr funktioniert, wenn man die App manuell beendet, kann man daher wohl nur sagen: Schmeißt die App von eurem iPhone!

Mit dem im Herbst erscheinenden iOS 7 erhalten die Push-Nachrichten eine praktische Aufwertung. Aktuell ist es so, dass eine Push-Nachricht empfangen wird und dem Nutzer angezeigt wird. Erst, wenn der Nutzer die Nachricht öffnet, startet die App und kann neue Inhalte (wie zum Beispiel die letzten Chat-Nachrichten) runterladen. Das kostet natürlich Zeit und ist nervig für den Nutzer.

iOS 7 bringt stumme Push-Nachrichten. Sie werden an das iPhone geliefert, aber nicht angezeigt. Stattdessen startet im Hintergrund automatisch die App und darf für kurze Zeit Daten runterladen. Danach könnte sie den Nutzer mit einer lokalen Benachrichtigung informieren. Startet man nun die App, muss nichts mehr geladen werden und alles ist aktuell. Vielleicht hält das manche Messenger-Hersteller ja dann davon ab, ständig als VoIP-App im Hintergrund aktiv zu sein.

Und welche App habt ihr im Verdacht, ein Akkukiller zu sein? Diskutiert mit – in den Kommentaren!

Sebastian Düvel ist iOS- und Mac-Entwickler und Blog-Urgestein – seinen Blog findet ihr unter blog.hagga.net. Hauptberuflich ist er Azubi zum Anwendungsentwickler bei t3n.

• Facebook-Apps für iPhone und iPad als Akkukiller [Update] – t3n News
• WhatsApp-Alternativen – Ein Blick über den Tellerrand – t3n News
• Kostenlose Apps entpuppen sich als Akkukiller – Mac Life

Bildnachweis für die Newsübersicht: © hocus-focus – iStockphoto.com