Optimizing Mobile App Battery Usage
"Your app drains battery" — one of the most painful review comments. iOS since 16 shows users battery consumption rating by apps. Android since 12 actively signals about background processes through Battery Usage alerts. App may work correctly technically but still be on the "battery hog" list — and users delete it.
Main Consumers: What Battery Historian Shows
Battery Historian — Google tool for analyzing bugreport from Android device. Shows timeline: wakelocks, network activity, GPS fixes, CPU wakeup. Typical picture of problematic consumption app: wakelock every 15 minutes for 2-3 seconds, periodic network requests, GPS in background with high accuracy.
Wakelocks. PowerManager.WakeLock.acquire() without timeout or without guaranteed release() — device can't enter deep sleep. One unclosed PARTIAL_WAKE_LOCK keeps processor active all night. Use WakefulBroadcastReceiver or WorkManager which manage wakelock automatically.
WorkManager and incorrect intervals. Periodic task with 15-minute interval (minimum allowed) on device with aggressive Battery Optimization may run less often. But if task has network request + database write + GPS — 15 minutes is too frequent. JobScheduler batching: group tasks, use setRequiredNetworkType(NetworkType.CONNECTED) to avoid waking radio without net.
GPS: Main Battery Killer
LocationManager with LocationRequest.PRIORITY_HIGH_ACCURACY (Fused Location Provider) enables GPS receiver and keeps it active. 1-2% battery per hour with continuous GPS — real numbers on modern devices.
Proper strategy by app type:
- Navigation in background:
PRIORITY_HIGH_ACCURACYonly during active navigation, switch toPRIORITY_BALANCED_POWER_ACCURACYfor background route tracking - Geofencing:
GeofencingClientinstead of continuous GPS — triggers only on zone entry/exit, minimal consumption - "Find nearby": single
getCurrentLocation()instead of continuous updates
On iOS: CLLocationManager with desiredAccuracy = kCLLocationAccuracyBest in background — serious problem. significantLocationChangeMonitoring consumes an order of magnitude less and sufficient for most background geolocation scenarios. allowsBackgroundLocationUpdates = true requires explicit justification — without it iOS aggressively limits updates.
Network Requests and Radio
Radio module (Wi-Fi, LTE) at activation consumes extra energy on bringing up connection, even if transmitting 1 byte. Pattern: one large request every 5 minutes better than 20 small requests every 15 seconds. Batching requests via WorkManager with setRequiredNetworkType ensures requests don't wake radio without net.
HTTP Keep-Alive and HTTP/2 multiplexing reduce TCP handshakes — not just latency but battery.
Push notifications via FCM/APNs — right way to signal new data instead of long polling or short polling. Server-Sent Events and WebSocket acceptable when real-time communication needed, but must close when going background.
iOS: Background App Refresh and BGTaskScheduler
BGAppRefreshTask and BGProcessingTask — modern API for background tasks on iOS. System itself decides when to run them, relying on device usage patterns (nights, charging). Attempts to bypass via background audio trick or VoIP push for non-VoIP apps — App Store Guidelines violation.
URLSession.shared.configuration.waitsForConnectivity = true — network requests don't bring radio up immediately, wait for ready connection.
Practical Case
Fitness tracking app. Users complained about 8-10% battery per hour in background. Battery Historian showed: CoreLocationManager with PRIORITY_HIGH_ACCURACY running continuously, plus PeriodicWorkRequest every 15 minutes making 4 network requests. Switching to PRIORITY_BALANCED_POWER_ACCURACY for background tracking + merging network requests into one + increasing interval to 30 minutes gave 1.5-2% per hour — 4-5x less while preserving functionality.
Diagnostic Tools
Android: Battery Historian, Android Studio Energy Profiler, adb shell dumpsys batterystats
iOS: Xcode Instruments → Energy Log, MetricKit MXCPUMetric, Xcode Organizer → Battery Usage
Cross-platform: Firebase Performance Monitoring doesn't track battery but tracks network request count and size — indirect indicator
Optimization timeline: one to two weeks — diagnosis, prioritization, fixes.