API‑Design zur Verbesserung der Akkulaufzeit auf Mobilgeräten: Lerne Batching, Caching‑Header und Payload‑Reduktion, um Funk‑Weckungen zu reduzieren, Bildschirme zu beschleunigen und Stromverbrauch zu senken.
Eine „chattige“ API lässt eine App viele kleine Anfragen absetzen, um einen einzigen Bildschirm zu bauen. Auf dem Papier sieht jede Anfrage harmlos aus, aber auf einem Telefon summieren sie sich schnell.
Der größte Akku‑Verbrauch entsteht oft durch das Funkmodul. Mobilfunk‑ und Wi‑Fi‑Chips wechseln in stromintensive Zustände, um Daten zu senden und zu empfangen. Wenn eine App viele Anfragen kurz hintereinander absendet, weckt das Funkmodul immer wieder auf und bleibt länger aktiv. Selbst wenn jede Antwort klein ist, kosten wiederholte Weckungen echte Energie.
Es fällt auch CPU‑Arbeit an. Jede Anfrage bedeutet Header‑Aufbau, TLS‑Handshakes, JSON‑Parsing, Cache‑Updates und App‑Code, der Ergebnisse zusammenführt. Fällt eine Verbindung aus, wiederholt sich die Vorarbeit.
Chattiness macht die UI außerdem langsamer. Anstatt eines vorhersehbaren Ladevorgangs wartet der Bildschirm auf eine Kette von Aufrufen. Das führt zu längeren Ladeanzeigen, inkrementellen Rendern, die hin und her springen, und mehr Timeouts bei schlechtem Netz. Hintergrund‑Refreshs verschlechtern sich auf ähnliche Weise: mehr Retries, mehr Weckungen, mehr Akkuverbrauch.
Eine praktische Denkweise für API‑Design zur Verbesserung der mobilen Akkulaufzeit ist einfach: zeige dieselbe UI mit weniger Roundtrips, weniger Bytes und weniger Hintergrundarbeit.
Man kann den Erfolg an konkreten Änderungen messen:
Verbessern diese Kennzahlen, verbessern sich meist Reaktionsfähigkeit und Akkulaufzeit gleichzeitig.
Bevor du batching oder Caching‑Tweaks einbaust, verschaffe dir ein klares Bild davon, was die App heute macht. Die schnellsten Erfolge kommen meist vom Beheben einiger wiederkehrender Übeltäter, die du aber nur findest, wenn du echte Bildschirme und Flows misst (nicht nur einen Happy‑Path‑Testlauf).
Für einige stark frequentierte Bildschirme logge Basisdaten: wie viele Requests pro Ladevorgang, welche Endpunkte aufgerufen werden, gesendete und empfangene Bytes (Header plus Body), Retry‑ und Timeout‑Raten und wie lange es dauert, bis die UI nutzbar erscheint. Wenn möglich, trenne Fehlerraten nach Netztyp (Wi‑Fi vs. Mobilfunk). Diese Aufteilung zeigt oft Probleme, die auf einer stabilen Verbindung verborgen bleiben.
Trenne Vordergrund‑ von Hintergrund‑Traffic. Ein Bildschirm kann ruhig aussehen, während das Telefon im Hintergrund mit Refresh, Push‑Sync, Analytics‑Uploads oder „just in case“ Prefetches beschäftigt ist. Messe das getrennt, damit du nicht das Falsche optimierst.
Hotspots sammeln sich meist an ein paar Momenten: App‑Start, Home/Feed, Detailbildschirme, die in viele Aufrufe aufsplitten, und Pull‑to‑Refresh. Wähle einen davon und messe Ende‑zu‑Ende.
Setze ein Baseline‑Budget, damit das Team sich darauf einigen kann, was „gut“ ist. Zum Beispiel: „Ein kalter Ladevorgang des Bestell‑Tracking‑Bildschirms darf nicht mehr als 6 Requests auslösen und darf vor der Statusanzeige nicht mehr als 250 KB herunterladen."
Wenn du eine einfache KPI‑Kombination suchst, starte mit (1) Requests pro Bildschirmladevorgang und (2) Retry‑Rate. Das Reduzieren von Retries spart oft mehr Akku als erwartet, weil wiederholte Versuche das Funkmodul länger aktiv halten.
Chattige APIs entstehen leicht aus Versehen. Jedes Widget lädt „seine“ Daten, und ein Bildschirm löst ein Dutzend kleine Aufrufe aus. Die Lösung ist meist nicht kompliziert: identifiziere, was immer zusammen geladen wird, und liefere es in weniger Aufrufen.
Beginne damit, einen hoch frequentierten Bildschirm (Home, Inbox, Bestellliste) zu kartieren. Notiere, was „above the fold“ erscheint und verfolge jedes UI‑Element zurück zur Anfrage, die es versorgt. Du findest oft Duplikate (z. B. das gleiche Nutzerprofil zweimal) und Aufrufe, die immer zusammen passieren (Profil plus Berechtigungen plus ungelesene Anzahl).
Gruppiere dann Aufrufe, die zuverlässig zusammen stattfinden. Im Allgemeinen hast du zwei Optionen:
Halte Batches bildschirmbasiert und begrenzt, damit sie leicht zu cachen, zu überwachen und zu debuggen sind.
Ein paar Regeln verhindern, dass Batching zur Unordnung wird. Gib nur zurück, was der Bildschirm gerade braucht, nicht komplette Objekte „für alle Fälle“. Wenn Teile optional sind, mache das explizit, damit die UI die wichtigen Teile schnell rendern kann. Entwerfe außerdem die Antwort so, dass partielle Fehler nicht einen vollständigen Retry erzwingen. Es ist deutlich günstiger, nur das Fehlgeschlagene erneut anzufordern, als den ganzen Batch neu zu senden.
Caching ist eine Akku‑Funktion. Jede Anfrage weckt das Funkmodul, hält die CPU beschäftigt und löst Parsing und App‑Logik aus. Gute Caching‑Header verwandeln viele Refreshes in leichte Prüfungen.
Der größte Gewinn ist die bedingte Anfrage. Anstatt dieselben Daten neu herunterzuladen, fragt die App „Hat sich das geändert?“ Wenn nicht, antwortet der Server mit einer kleinen 304 Not Modified.
Setze ETag auf Antworten, die eine Version einer Ressource repräsentieren, und lasse den Client beim nächsten Abruf If-None-Match senden. Falls das Erzeugen eines ETag schwierig ist, funktioniert Last-Modified mit If-Modified-Since gut für einfache "updated at"‑Ressourcen.
Für Daten, die selten ändern, mache die Cache‑Entscheidung explizit. Cache-Control sollte der Realität entsprechen. Eine kurze max-age für Benutzerprofile kann in Ordnung sein, während App‑Konfigurationen, Referenzlisten und Feature‑Flags oft länger gecached werden können.
Auf der Client‑Seite behandle 304 als schnellen Pfad. Parse kein JSON (gibt es ja nicht), baue Modelle nicht neu und lasse die UI nicht flackern. Behalte, was bereits auf dem Bildschirm ist, und aktualisiere nur Indikatoren.
Beispiel: Ein Order‑Tracking‑Bildschirm pollt den Bestellstatus alle 15 Sekunden. Wenn die Antwort ein ETag enthält, können die meisten Prüfungen 304 zurückgeben. Die App behält den letzten Status und macht echte Arbeit nur, wenn sich der Status ändert (z. B. von „Packed“ zu „Shipped").
Sei absichtlich bei sensiblen Daten. Caching ist nicht automatisch unsicher, braucht aber klare Regeln. Vermeide Caching von Antworten mit personenbezogenen Details oder Tokens, außer Produktanforderungen erlauben es. Verwende kurze Lebenszeiten für benutzerspezifische Daten und verhindere, dass Shared‑Caches private Antworten speichern (Cache-Control: private wenn nötig).
Jedes zusätzliche Byte kostet auf Mobilgeräten mehr als nur Bandbreite. Es hält das Funkmodul länger wach und lässt die App CPU‑Zeit für das Dekodieren von JSON und das Aktualisieren von Models aufwenden. Wenn du versuchst, die API‑Chattiness zu reduzieren, ist das Kürzen von Payloads oft der schnellste Gewinn.
Beginne mit einem Audit der Payloads pro Bildschirm. Wähle einen Bildschirm (z. B. den Home‑Feed), protokolliere Antwortgrößen und schaue Feld für Feld: rendert der Client das Feld oder nutzt er es, um anzuzeigen, was zu tun ist? Wenn nicht, entferne es aus diesem Endpoint.
Für Listen genügt meist eine kleine „Summary“‑Form. Eine Listenzeile braucht oft eine id, einen Titel, einen Status und einen Zeitstempel. Keine ausführlichen Beschreibungen, keine langen Notizen oder tief verschachtelte Objekte. Lade Details nur, wenn der Nutzer ein Element öffnet.
Einige Maßnahmen, die Payloads schnell verkleinern:
Kompression kann helfen, besonders in langsamen Netzen, aber teste den CPU‑Tradeoff auf echten Geräten. Gzip oder Brotli reduzieren oft die Transfergröße stark, aber ältere Telefone können beim Dekomprimieren sehr großer Antworten spürbar arbeiten. Der beste Gewinn bleibt, von vornherein weniger Daten zu senden.
Behandle Antwortformen wie einen Vertrag. Wenn Feldnamen und Typen konsistent bleiben, braucht die App weniger Fallbacks und defensive Logik, was die UI‑Smoothness und den Akkuverbrauch verbessert.
Eine mobile App verbraucht Akku nicht nur beim Senden von Anfragen. Sie verbraucht auch Akku, wenn etwas fehlschlägt, ein Retry gestartet wird, das Funkmodul wieder aufwacht und Arbeit wiederholt wird. Wenn eine API perfektes Wi‑Fi annimmt, zahlen reale Nutzer auf wackeligem 4G dafür.
Ermögliche es, weniger Daten anzufordern. Bevorzuge serverseitige Filter und Pagination statt „alles herunterladen und auf dem Telefon filtern“. Wenn ein Bildschirm die letzten 20 Events für einen Nutzer braucht, unterstütze genau diese Abfrage, damit die App nicht Hunderte von Zeilen holt und die meisten wieder verwirft.
Unterstütze Delta‑Sync, damit die App fragen kann "Was hat sich seit meinem letzten Check geändert?" Das kann so einfach sein wie ein Zeitstempel oder eine inkrementelle Versionsnummer, und der Client fordert nur Updates und Löschungen seit diesem Punkt an.
Retries sind unvermeidlich, also mache Updates idempotent. Ein Retry darf nicht doppelt belasten, doppelt einreichen oder Duplikate erzeugen. Idempotency‑Keys für Create‑Operationen und Update‑Semantiken, die Zustand setzen (statt „addiere eins“), helfen hier enorm.
Wenn Retries auftreten, vermeide Retry‑Stürme. Nutze exponentielles Backoff mit Jitter, damit tausende Geräte nicht gleichzeitig deine Server überfluten und damit das Telefon nicht jede Sekunde aufwacht.
Gib klare Fehlercodes zurück, die dem Client helfen, die richtige Entscheidung zu treffen. Ein 401 sollte Re‑Auth auslösen, ein 404 sollte normalerweise das Retry stoppen, ein 409 kann ein State‑Refresh nötig machen und 429 oder 503 sollten Backoff triggern.
Selbst mit gutem API‑Design kann der Client stillschweigend die Netzwerkarbeit vervielfachen. Auf Mobilgeräten kosten zusätzliche Weckungen und Funkzeiten oft mehr Akku als die Bytes selbst.
Cache Daten, die selten ändern. Profilfotos, Feature‑Flags und Referenzdaten (Länder, Status, Kategorien) sollten nicht bei jedem Bildschirmbesuch neu geladen werden. Gib ihnen sinnvolle Lifetimes, speichere sie auf Disk und aktualisiere nur bei Bedarf. Unterstützt die API Validierung (ETag oder Last-Modified), ist eine schnelle Prüfung oft deutlich günstiger als ein voller Download.
Ein weiterer häufiger Fehler sind doppelte gleichzeitige Requests. Zwei Teile der App fragen dieselbe Ressource gleichzeitig an (z. B. Header und Einstellungen fordern beide das Profil). Ohne Coalescing entstehen zwei Aufrufe, zwei Parsings und zwei State‑Updates. Behandle einen Netzwerkaufruf als single source of truth und lasse mehrere Verbraucher darauf warten.
Hintergrund‑Refresh sollte gezielt sein. Wenn es nicht bald zeigt, was der Nutzer sieht, oder keine Benachrichtigung auslöst, kann es meist warten. Vermeide Refresh‑Logik bei jedem App‑Resume. Füge eine kurze Cooldown‑Zeit hinzu und prüfe, wann die Daten zuletzt aktualisiert wurden.
Wenn du Backends mit AppMaster baust, ist es einfacher, diese Client‑Verhaltensweisen zu unterstützen, indem du Endpunkte um Bildschirme herum formst, Antwortschemata konsistent hältst und Caching‑Header kontrolliert setzt, damit Clients die meiste Zeit ruhig bleiben können.
Das Ziel sind weniger Funk‑Weckungen, weniger CPU‑Arbeit und weniger Retries. Einige Muster können die Einsparungen aufheben oder Bildschirme sogar langsamer machen.
Batching hilft, bis der Batch zu einem „gib mir alles“‑Aufruf wird. Wenn der Server viele Tabellen joinen muss, schwere Berechtigungsprüfungen ausführt und eine riesige Antwort baut, kann diese einzelne Anfrage länger dauern als mehrere kleinere. Auf Mobilgeräten hält eine langsame Anfrage die App auf, hält das Netzwerk aktiv und erhöht Timeout‑Risiken.
Ein gesünderer Batch ist bildschirmgeformt: nur das, was eine View braucht, mit klaren Grenzen. Wenn du die Antwort nicht in einem Satz beschreiben kannst, ist der Endpoint wahrscheinlich zu breit.
Caching ohne klare Invalidation erzeugt eine schlechte Schleife: Nutzer sehen alte Daten, ziehen zum Aktualisieren nach unten und die App macht unnötige Voll‑Reloads. Nutze Caching‑Header mit einem Plan, was die Daten aktualisiert (Create/Update‑Aktionen, Server‑Events oder kurze Frischefenster), damit der Client vertraut, gecachte Antworten zu verwenden.
Polling ist eine weitere Akku‑Falle. Ein enger 5‑Sekunden‑Timer hält das Gerät beschäftigt, selbst wenn sich nichts ändert. Bevorzuge servergetriebene Updates, wenn möglich, oder fahre aggressiv zurück (längere Intervalle nach leeren Polls, Pause im Hintergrund).
Übergroße Payloads sind ein stiller Kostenfaktor. Große verschachtelte Objekte „zur Bequemlichkeit“ bedeuten mehr Bytes, mehr JSON‑Parsing und mehr Speicher‑Churn. Sende nur, was der Bildschirm braucht, und lade Details bei Bedarf nach.
Und ignoriere niemals partielle Fehler in einem Batch. Wenn ein Sub‑Resultat fehlschlägt und du den ganzen Batch erneut anforderst, duplizierst du Traffic. Entwirf Antworten so, dass der Client nur die fehlgeschlagenen Teile erneut anfragen kann.
Eine kurze Checkliste: begrenze Batches, definiere Cache‑Frische im Voraus, vermeide enges Polling, kürze Payloads und unterstütze partielle Erfolge.
Mach vor dem Release einen Durchgang, der nur das Netzwerkverhalten betrachtet. Die meisten Akkugewinne kommen vom Entfernen von Überraschungen: weniger Weckungen, weniger Parsing und weniger Retries im Hintergrund.
Führe das auf deinen drei wichtigsten Bildschirmen durch:
ETag oder Last-Modified wo passend) und geben 304 Not Modified zurück, wenn sich nichts geändert hat.Ein einfacher Reality‑Check: Lade einen Bildschirm einmal, schalte dann den Flugmodus ein und öffne ihn erneut. Wenn er noch nützliche Inhalte zeigt (gecachte Inhalte, letzten bekannten Status, freundliche Platzhalter), hast du wahrscheinlich unnötige Aufrufe reduziert und die gefühlte Geschwindigkeit verbessert.
Ein Kunde öffnet eine Paketverfolgungs‑App im Mobilnetz mit 20 % Akku. Er will nur eines wissen: „Wo ist mein Paket gerade?“ Der Bildschirm wirkt einfach, aber der dahinterstehende API‑Traffic kann überraschend teuer sein.
Vorher lädt die App den Bildschirm mit einem Schub von Requests. Die UI wartet, während das Funkmodul immer wieder aufwacht, und ein paar Aufrufe laufen bei schwacher Verbindung in Timeouts.
Ein typisches "Vorher"‑Muster sieht so aus:
GET /orders/{id} für die BestellübersichtGET /orders/{id}/items für PositionenGET /orders/{id}/history für Status‑EventsGET /me für Profil und PräferenzenGET /settings für Darstellungsregeln (Währung, Datumsformat)Wende nun drei Änderungen an, die die UI nicht verändern.
Erstens: Füge einen einzelnen Bildschirm‑Endpoint hinzu, der nur das zurückgibt, was die View in einem Roundtrip braucht: Bestellübersicht, aktueller Status, jüngere Historie und Artikeltitel. Zweitens: Cache das Profil: GET /me liefert ein ETag und Cache-Control: private, max-age=86400, sodass die meisten Öffnungen zu einem schnellen 304 werden (oder gar keine Anfrage, wenn die gecachte Kopie noch frisch ist). Drittens: Schlanke Payloads: Die Artikelliste sendet nur id, name, qty und thumbnail_url, nicht vollständige Produktbeschreibungen oder ungenutzte Metadaten.
Das Ergebnis sind weniger Roundtrips, weniger Bytes und weniger Retries, wenn das Netz hakt. Das Funkmodul bleibt öfter im Schlaf, und genau dort liegen die Akku‑Einsparungen.
Für den Nutzer erscheint nichts „neu“. Der Bildschirm ist derselbe, lädt aber schneller, wirkt reaktiver und funktioniert besser bei flackernder Verbindung.
Wenn du schnelle Erfolge willst, fang klein an und belege den Effekt. Akkugewinne kommen meist von weniger Funk‑Weckungen und weniger Parsing‑Arbeit, nicht von einem großen Rewrite.
Drei Änderungen, die sicher, messbar und leicht rückgängig zu machen sind:
ETag‑Support für deine meistgenutzten GET‑Endpoints hinzu, damit Clients If-None-Match nutzen und 304 Not Modified erhalten könnenWähle ein Feature mit stabilem Traffic, wie eine Bestellliste oder Inbox. Schiebe hinter eine serverseitige Flag wenn möglich, vergleiche dann KPIs für alten vs. neuen Pfad über ein paar Tage. Suche nach weniger Requests pro Session, weniger Retries und weniger Bytes pro aktivem Nutzer.
Koordiniere API‑ und App‑Releases so, dass ältere Clients nicht brechen. Eine praktische Regel: neues Verhalten zuerst hinzufügen, Clients zweitens migrieren, altes Verhalten zuletzt entfernen. Wenn du Caching‑Verhalten änderst, sei vorsichtig mit personalisierten Daten und sorge dafür, dass Shared‑Caches keine Nutzer vermischen.
Wenn du Backend‑Änderungen schneller prototypen und ausliefern willst, kann AppMaster (appmaster.io) helfen: Daten visuell modellieren, Geschäftslogik per Drag‑and‑Drop bauen und produktionsreifen Source‑Code regenerieren, während sich Anforderungen ändern.
Teste zuerst einen gebündelten Endpoint plus ETag für einen hoch frequentierten Bildschirm. Verbessern sich die Zahlen, weißt du genau, wo sich weitere Investitionen lohnen.
How many API calls per screen is “too many” on mobile?Eine sinnvolle Vorgabe ist, ein Budget pro Bildschirm zu setzen und echte Sessions zu messen. Viele Teams starten mit etwa 4–8 Requests für einen kalten Bildschirm‑Ladevorgang über Mobilfunk und reduzieren dann die schlimmsten Verursacher. Die richtige Zahl ist diejenige, die zuverlässig dein Ziel für Time‑to‑Interactive erreicht, ohne viele Retries oder lange aktive Radio‑Zeiten auszulösen.
Is batching always better than multiple small endpoints?Batching hilft meistens, wenn mehrere Aufrufe immer zusammen passieren. Es kann jedoch nachteilig werden, wenn der Batch zu langsam oder zu groß wird. Halte Batch‑Antworten „bildschirmgerecht“ und begrenzt, damit eine Anfrage nicht zum Single Point of Failure wird. Wenn ein gebündelter Endpoint regelmäßig timeouts produziert oder viele ungenutzte Daten liefert, teile ihn lieber in ein paar fokussierte Aufrufe.
Which caching headers give the biggest battery savings?Beginne mit ETag plus bedingten Anfragen (If-None-Match), weil viele Refreshes so zu winzigen 304 Not Modified‑Antworten werden. Ergänze Cache-Control passend zur tatsächlichen Änderungsfrequenz der Daten, damit der Client unnötige Netzarbeit vermeidet. Wenn ETag schwer umzusetzen ist, ist Last-Modified mit If-Modified-Since ein robuster Fallback für "updated at"‑artige Ressourcen.
Should I use ETag or Last-Modified?Verwende ETag, wenn du eine verlässliche "Version" einer Ressource brauchst, vor allem wenn Änderungen nicht sauber zu einem Zeitstempel passen. Nutze Last-Modified, wenn der Server eine klare Änderungszeit hat und Zeitstempel‑Genauigkeit ausreicht. Wenn du nur eine Option implementieren kannst, ist ETag häufig genauer, um unnötige Downloads zu vermeiden.
What should I measure before I change my API?Instrumentiere nach Bildschirm und Session, nicht nur nach Endpoint. Logge Anzahl der Requests, Bytes (Header plus Body), Retries, Timeouts und Time‑to‑Interactive und trenne Vordergrund‑ und Hintergrundtraffic, damit du nicht die falschen Bereiche optimierst. Meistens erzeugen nur wenige Bildschirme oder Flows die meisten wiederholten Radio‑Weckungen.
How do I handle partial failures in a batched response?Gestalte die Batch‑Antwort so, dass jedes Unterergebnis unabhängig Erfolg oder Fehler melden kann, und liefere genug Fehlermeldungen, damit der Client nur die fehlgeschlagenen Teile erneut anfragen kann. Vermeide, dass der Client den ganzen Batch nochmals anfordert, weil ein Teil schiefgelaufen ist — das reduziert doppelten Traffic und zusätzliche Radio‑Weckungen bei instabiler Verbindung.
What’s the fastest way to reduce payload size without breaking the app?Streiche Felder, die der Bildschirm gerade nicht darstellt, und nutze Zusammenfassungs‑Formen für Listen. Lagere schwere oder selten benötigte Felder in einen Detail‑Endpoint aus, der nur beim Öffnen eines Elements geladen wird. So sinken Übertragungsvolumen und JSON‑Parsing‑Aufwand, was auf Geräten spürbare CPU‑ und Akku‑Einsparungen bringt.
How should retry logic be tuned to save battery?Nutze exponentielles Backoff mit Jitter und begrenze das gesamte Retry‑Fenster, damit das Gerät nicht alle paar Sekunden aufwacht. Mach Schreiboperationen idempotent, damit ein Retry keine Duplikate oder doppelte Aktionen erzeugt. Gib aussagekräftige Statuscodes zurück, damit der Client bei nicht‑behobenen Fehlern nicht sinnlos weiter versucht.
How do I avoid battery drain from polling for updates?Enge Polling‑Intervalle halten Radio und CPU beschäftigt, selbst wenn sich nichts ändert. Falls Polling nötig ist, erhöhe Intervalle, wenn Antworten unverändert bleiben, und pausiere Polling im Hintergrund. Noch besser: setze auf ereignisgesteuerte Updates, damit die App nur bei wirklich neuen Inhalten aufwacht.
How can AppMaster help me ship these API changes faster?In AppMaster (appmaster.io) kannst du bildschirmorientierte Endpunkte erstellen und Antwortschemata konsistent halten, was Batching und Payload‑Anpassung leichter macht. Du kannst zudem versionierende Logik und Header ergänzen, die bedingte Anfragen unterstützen, damit Clients schnelle "kein Wechsel"‑Antworten erhalten. Ein praktisches Vorgehen: beginne mit einem viel genutzten Bildschirm, implementiere einen gebündelten Endpoint und ETag für die wichtigsten GETs und messe dann den Rückgang bei Anfragen und Retries.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
