Leistungstests für Mobilgeräte: Mehr als nur „Ist es schnell?“

Ein umfassender Leitfaden zu Batterieverbrauch, Speicherlecks, Netzwerkeffizienz und dem Aufspüren von Leistungseinbußen im realen Einsatz.

Einführung

Wenn jemand „Performance-Tests“ sagt, denken die meisten an eines: Geschwindigkeit. Wie schnell startet die App? Wie schnell lädt der Bildschirm? Doch bei mobilen Anwendungen ist Geschwindigkeit nur die Spitze des Eisbergs.

Ihre App startet möglicherweise in weniger als einer Sekunde, verbraucht aber unbemerkt 40 % des Akkus innerhalb einer Stunde. Sie rendert womöglich butterweiche Animationen und belegt dabei so viel Speicher, dass das Betriebssystem sie beendet. Im WLAN reagiert sie blitzschnell, ist aber in einem überfüllten U-Bahn-Netz völlig unbrauchbar.

Mobile Performance-Tests stellen eine vielschichtige Herausforderung dar. In diesem Artikel gehen wir über Ladezeiten hinaus und beleuchten die vier Säulen, die die mobile Performance maßgeblich bestimmen: Batterieverbrauch, Speichermanagement, Netzwerkeffizienz und Regressionserkennung—alles basiert auf realen Szenarien.

1. Akku-Entladung: Der stille App-Killer

Warum es wichtig ist

Die Akkulaufzeit gilt bei Smartphone-Nutzern als wichtigstes Kriterium. Apps, die übermäßig viel Akku verbrauchen, werden deinstalliert – egal wie viele Funktionen sie bieten. Sowohl Apple als auch Google bestrafen akkufressende Apps aktiv: Androids App-Standby-Funktion schränkt die Hintergrundaktivität ein, und iOSs Hintergrundaktualisierung kann vom Betriebssystem gedrosselt oder deaktiviert werden.

Was verursacht übermäßigen Batterieverbrauch?

• Unnötige Hintergrunddienste: In der offiziellen Android-Dokumentation wird ausdrücklich davor gewarnt, dass das Ausführen unnötiger Dienste einer der schlimmsten Fehler im Speichermanagement ist, die eine App begehen kann – und dies wirkt sich auch direkt auf die Akkulaufzeit aus.
• Häufige Wake-Locks: Die CPU oder den Bildschirm werden unnötigerweise aktiv gehalten.
• Übermäßiger GPS-Gebrauch: Kontinuierliche Standortabfrage anstelle der Verwendung von APIs für signifikante Standortänderungen.
• Nicht optimierte Netzwerkaufrufe: Häufige Abfragen statt Push-Benachrichtigungen oder WebSockets.
• Speicherfluktuation und Garbage Collection: Wie in den Entwicklerhandbüchern von Android erwähnt, verlangsamen häufige GC-Ereignisse nicht nur Ihre App, sondern entladen auch schnell den Akku.

So testen Sie den Batterieverbrauch

Beginnen Sie mit der Ermittlung eines Ausgangswerts – messen Sie den Akkuverbrauch im Leerlauf der App. Führen Sie anschließend szenariobasierte Tests mit typischen Nutzeraktivitäten wie Surfen, Suchen und Streamen durch und messen Sie dabei den Energieverbrauch. Testen Sie die App außerdem über längere Zeiträume (30, 60 und 120 Minuten) im Hintergrund und vergleichen Sie die Ergebnisse mit festgelegten Grenzwerten, z. B. weniger als 5 % Akkuverbrauch pro Stunde aktiver Nutzung.

Auf Android gibt es Tools wie den Energy Profiler in Android Studio, dumpsys batterystatsBattery Historian ist dabei von unschätzbarem Wert. Unter iOS liefern die Energieauswirkungsanzeige in Xcode und die Energieprotokollvorlage in Instruments ähnliche Einblicke.

2. Speicherlecks: Das schleichende Gift

Warum es wichtig ist

Mobile Geräte verfügen über begrenzten Arbeitsspeicher. Android legt pro App eine feste Heap-Größenbegrenzung fest, die je nach Gerät variiert – wird diese überschritten, erhält man eine Fehlermeldung. OutOfMemoryError Absturz. iOS ist sogar noch aggressiver: Es gibt keine Auslagerungsdatei, und das Betriebssystem beendet Apps, die zu viel Speicher verbrauchen, ohne Vorwarnung.

Häufige Ursachen für Speicherlecks

• Statische Verweise auf Aktivitäten oder Kontexte: In der Android-Dokumentation wird dies ausdrücklich als häufigste Ursache für Speicherlecks genannt.
• Nicht registrierte Zuhörer und Rückrufe: Zuhörer von Veranstaltungen, Empfänger von Rundfunksendungen oder Beobachter, die nie bereinigt werden.
• Fehlverwaltung von Bitmaps und Bildern: Das Laden von Bildern in voller Auflösung, obwohl Miniaturansichten ausreichen würden.
• Beibehaltene Fragmente und Ansichtsreferenzen: Beibehalten von UI-Referenzen nach der Zerstörung einer Ansicht.
• Aufblähung von Drittanbieterbibliotheken: Wie die offiziellen Richtlinien von Android warnen, ist externer Bibliothekscode oft nicht für mobile Umgebungen geschrieben und kann ineffizient sein.

Wie man Speicherlecks aufspürt

Der effektivste Ansatz ist der NavigationstestÖffnen und schließen Sie denselben Bildschirm mindestens 20 Mal und prüfen Sie, ob der Speicherverbrauch jedes Mal auf den Ausgangswert zurückkehrt. Ergänzen Sie dies durch Langzeittests, bei denen Sie die App mindestens 30 Minuten lang ununterbrochen mit verschiedenen Aktionen nutzen und den stetigen Speicherverbrauch beobachten. Unter Android eignen sich Rotationstests (schnelles Drehen des Geräts auf komplexen Bildschirmen) hervorragend, um Speicherlecks aufzudecken. Auch das Wechseln zwischen Vorder- und Hintergrund – die App mindestens 50 Mal in den Hintergrund und wieder in den Vordergrund zu bringen – kann Speicherlecks aufdecken.

Der Memory Profiler von Android Studio und LeakCanary (eine Bibliothek von Square zur automatisierten Erkennung von Speicherlecks) sind unverzichtbare Werkzeuge. Unter iOS erfüllen die Instruments-Tools von Xcode mit den Vorlagen „Leaks“ und „Allocations“ sowie der Memory Graph Debugger denselben Zweck.

3. Netzwerkeffizienz: Gestaltung für die reale Welt

Warum es wichtig ist

Labortests finden häufig über schnelles, zuverlässiges WLAN statt. Ihre Nutzer hingegen nutzen oft überlastete LTE-Netze, 3G-Netze in ländlichen Gebieten oder WLAN mit unzuverlässiger Verbindung in fahrenden Zügen. Googles Untersuchungen haben gezeigt, dass 53 % der Besuche mobiler Websites abgebrochen werden, wenn eine Seite länger als 3 Sekunden zum Laden benötigt. Dasselbe Prinzip gilt auch für native Apps.

Zu testende reale Netzwerkbedingungen

Denken Sie über „verbunden“ und „nicht verbunden“ hinaus. Sie müssen ein breites Spektrum testen: schnelles WLAN, gutes LTE (ca. 20 Mbit/s mit 30 ms Latenz), schlechtes 3G (750 kbit/s mit 200 ms Latenz), überlastete Netze (500 kbit/s mit 500 ms Latenz und Paketverlust), nahezu Offline-Bedingungen (50 kbit/s mit 2 Sekunden Latenz) und vollständige Trennung.

Was zu testen

• Timeout-Behandlung: Kann die App Anfragen, die länger als 30 Sekunden dauern, problemlos verarbeiten?
• Wiederholungslogik: Wiederholt die App fehlgeschlagene Anfragen mit exponentiellem Backoff?
• Nutzlastgröße: Übertragen Sie unnötige Daten? Sind die Bilder optimiert?
• Zwischenspeichern: Nutzt die App ein ordnungsgemäßes HTTP-Caching, um redundante Downloads zu vermeiden?
• Offline-Modus: Können Benutzer auch ohne Internetverbindung auf die Kernfunktionen zugreifen?
• Netzwerkübergänge: Was passiert, wenn der Nutzer während einer Anfrage von WLAN auf Mobilfunk umschaltet?

Wie man Netzwerkbedingungen simuliert

Unter iOS bietet Apple den Network Link Conditioner (verfügbar über die Xcode-Entwicklereinstellungen) mit vordefinierten Profilen für 3G, Edge, LTE, WLAN und 100 % Paketverlust. Unter Android können Sie Tools wie Charles Proxy oder Toxiproxy verwenden, um den Netzwerkverkehr zu steuern. Mit diesen Tools lassen sich künstliche Latenz, Bandbreitenbeschränkungen und Paketverluste erzeugen, um reale Bedingungen während automatisierter Testläufe zu simulieren.

4. Tests von Einsteigergeräten: Die vergessene Mehrheit

Warum es wichtig ist

Laut Counterpoint Research liegt der durchschnittliche Verkaufspreis von Smartphones weltweit unter 300 US-Dollar. Ein erheblicher Teil Ihrer Nutzerbasis verwendet Geräte mit 2–3 GB RAM, älteren Prozessoren und begrenztem Speicherplatz. Wenn Sie ausschließlich auf Flaggschiff-Geräten testen, bleiben Ihnen die Erfahrungen der meisten Ihrer Nutzer verborgen.

Wichtigste Unterschiede bei Einsteigergeräten

Einsteigergeräte verfügen über weniger Arbeitsspeicher, wodurch das Betriebssystem Hintergrundanwendungen häufiger beendet. Langsamere Prozessoren verursachen Ruckler bei Animationen und längere Berechnungszeiten. Begrenzter Speicherplatz kann zu Fehlern bei der Installation und Aktualisierung von Apps führen. Ältere Betriebssystemversionen unterstützen möglicherweise nicht alle APIs, und Bildschirme mit niedrigerer Auflösung können Layout- und Darstellungsprobleme offenbaren.

Teststrategie für Low-End-Geräte

Halten Sie ein Gerätelabor bereit, das neben Ihren Flaggschiffmodellen mindestens zwei bis drei Budgetgeräte umfasst. Definieren Sie gestaffelte Leistungsbudgets: beispielsweise App-Start unter 1 Sekunde auf dem Flaggschiffmodell, unter 2 Sekunden auf dem Mittelklassemodell und unter 3 Sekunden auf dem Einsteigermodell. Führen Sie Ihre vollständige Regressionssuite auf allen Stufen Ihrer CI/CD-Pipeline aus und profilieren Sie die Speicher- und CPU-Auslastung speziell auf leistungsschwächeren Geräten.

5. Aufbau eines Frameworks zur Leistungsregression

Der Tor

Performanceprobleme sind heimtückisch – sie schleichen sich allmählich ein. Eine Verschlechterung von 50 ms pro Release löst zunächst keine Alarme aus, doch nach zehn Releases ist Ihre Anwendung 500 ms langsamer. Die Lösung: automatisierte Performance-Regressionstests, integriert in Ihre CI/CD-Pipeline.

Funktionsweise

Die Architektur ist einfach: Ihr CI/CD-System (z. B. Jenkins) startet einen Test-Runner (z. B. Appium), der Performance-Szenarien auf realen Geräten oder Emulatoren ausführt. Der Test-Runner erfasst Metriken – Startzeiten, Speichernutzung, Akkuverbrauch, Frameraten, Netzwerk-Payload-Größen – und speichert sie in einem Metrik-Speicher wie Prometheus. Grafana-Dashboards visualisieren Trends im Zeitverlauf, und Benachrichtigungen informieren das Team per Slack oder E-Mail, sobald eine Metrik einen Schwellenwert überschreitet.

Welche Kennzahlen sollten verfolgt werden?

Zu den wichtigsten zu überwachenden Kennzahlen gehören die Startzeiten von Apps (sowohl im Kalt- als auch im Warmstart), die Bildschirmübergangszeiten, der Speicherverbrauch im Normalbetrieb und nach längerer Nutzung, der Akkuverbrauch pro Stunde aktiver Nutzung, die Größe der Netzwerkdaten pro Bildschirm, die Framerate-Einbrüche und die Absturzrate. Für jede Kennzahl sollte ein klarer Schwellenwert definiert sein, z. B. ein Kaltstart unter 2 Sekunden (95. Perzentil), ein Speicherverbrauch unter 150 MB im Normalbetrieb und ein Akkuverbrauch unter 8 % pro Stunde aktiver Nutzung.

Trends beobachten, nicht nur absolute Zahlen.

Die wahre Stärke eines Regressions-Frameworks liegt in der Trendanalyse. Ein einzelner Datenpunkt mag akzeptabel erscheinen, doch wenn die Speichernutzung in den letzten sechs Releases mit jeder Version um 5 % gestiegen ist, besteht Handlungsbedarf. Grafana-Dashboards mit historischen Daten machen diese Trends sichtbar und ermöglichen es, entsprechende Maßnahmen zu ergreifen.

6. Alles zusammenfügen: Ein reales Szenario

Betrachten wir ein realistisches Beispiel. Stellen Sie sich vor, Sie testen eine App für die Essenslieferung.

Das Szenario: Ein Nutzer gibt an einem überfüllten Freitagabend eine Bestellung auf.

Die Bedingungen: Ein günstiges Samsung Galaxy A14 (4 GB RAM, Android 13), überlastetes LTE (2 Mbit/s Download, 500 ms Latenz) und noch 30 % Akku.

Der Benutzerablauf: App öffnen → Restaurants durchsuchen → Speisekarte ansehen → Artikel in den Warenkorb legen → Zur Kasse gehen → Bestellung verfolgen.

In jedem Schritt wird etwas anderes gemessen: Kaltstartzeit beim App-Start, Renderzeit der Liste und Performance beim verzögerten Laden von Bildern beim Browsen, Speichernutzung beim Anzeigen eines Menüs, Reaktionsfähigkeit der Benutzeroberfläche (Aussetzer von Frames) beim Hinzufügen von Artikeln, API-Antwortzeit und Wiederholungsverhalten bei langsamer Netzwerkverbindung an der Kasse, Akkuverbrauch und WebSocket-Verbindungsverhalten während 15 Minuten Bestellverfolgung sowie die Frage, ob der Speicherverbrauch nach der Rückkehr zum Startbildschirm wieder auf den Ausgangswert zurückkehrt.

Ein Fehlerbericht aus solchen Tests ist äußerst aussagekräftig. Statt einer vagen Aussage wie „Die App fühlt sich langsam an“ erhält man präzise Daten: Der Kaltstart war im Vergleich zur letzten Version um 40 % langsamer, der Speicherverbrauch beim Bezahlvorgang überstieg 200 MB, und der Speicherverbrauch normalisierte sich nach der Navigation nicht – ein Hinweis auf ein Speicherleck. Gleichzeitig wurden Akkuverbrauch, Wiederholungslogik, Offline-Warenkorbspeicherung und Bildwiederholrate einwandfrei getestet. Genau solche Signale ermöglichen es Entwicklerteams, Probleme schnell zu lokalisieren und zu beheben.

7. Wie Digital.ai Tests können helfen

Die in diesem Artikel beschriebenen Verfahren – CPU-, Speicher- und Akku-Profiling, Netzwerksimulation und Regressionsverfolgung – sind zwar leistungsstark, erfordern aber erhebliche Investitionen in die entsprechenden Werkzeuge, um sie in großem Umfang einzusetzen. Hier setzt die Problematik an. Digital.ai Die Tests beginnen.

Digital.ai Tests wurde speziell entwickelt, um Teams bei der Entwicklung von Apps zu unterstützen, die unter realen Bedingungen einwandfrei funktionieren. Digital.aiSie können die CPU-, Speicher-, Akku- und Netzwerknutzung auf echten iOS- und Android-Geräten messen, um Leistungsengpässe frühzeitig zu erkennen, bevor sie Ihre Benutzer erreichen.

Zu den wichtigsten Funktionen gehören:

📱 Leistungstransaktionen auf realen Geräten aufzeichnen und wiedergeben — um sicherzustellen, dass Ihre Tests die tatsächlichen Nutzerabläufe widerspiegeln.

📊 Erfassen Sie den CPU-, Speicher- und Akkuverbrauch für jeden Datenfluss. — wodurch Sie die für jeden Bildschirm erforderliche Transparenz erhalten, um Regressionen genau zu identifizieren.

🌐 Simulieren Sie gedrosselte Netzwerkbedingungen — versteckte Engpässe aufdecken, die nur bei langsamen oder überlasteten Netzwerken auftreten

Egal ob Sie native, hybride oder mobile Web-Apps testen, Digital.ai Bietet eine umfassende Leistungsabdeckung für Ihre gesamte Testsuite – nahtlos integriert in Ihre CI/CD-Pipeline.

👉 Mehr erfahren unter digital.ai/mobile-performance-testing

Wichtige Erkenntnisse

1. Geschwindigkeit ist nur eine Dimension. Batterie, Speicher, Netzwerk und Gerätevielfalt sind gleichermaßen entscheidend.
2. Test unter realen Bedingungen. Langsame Netzwerke, minderwertige Geräte und niedrige Akkustände offenbaren Probleme, die Labortests niemals aufdecken würden.
3. Automatisieren und verfolgen. Integrieren Sie Leistungskennzahlen in Ihre CI/CD-Pipeline mit Tools wie Appium, Prometheus und Grafana.
4. Setzen Sie Budgets, nicht nur Zielvorgaben. Definieren Sie Schwellenwerte pro Metrik für verschiedene Geräteebenen.
5. Beobachten Sie Trends, nicht nur absolute Zahlen. Eine 5%ige Regression pro Freisetzung verbindet sich schnell.
6. Nutzen Sie offizielle Profiling-Tools. Android Studio Profiler, Xcode Instruments und LeakCanary sind deine besten Freunde.

Ressourcen

• Android: App-Speicher verwalten — Offizielle Android-Dokumentation zum Speichermanagement
• Apple: Die Leistung Ihrer App verbessern — Apples Leitfaden zur Leistungsoptimierung
• Android-Energieprofiler — Akkuprofilierung in Android Studio
• LeakCanary— Automatisierte Speicherleckerkennung für Android
• Appium-Dokumentation— Framework für die mobile Testautomatisierung

Geschrieben für mobile Testingenieure, QA-Leiter und alle, die der Meinung sind, dass Leistung mehr ist als nur eine Zahl auf einer Stoppuhr.