Battery optimization in mobile performance refers to two related things: the operating system mechanisms that restrict background activity to save energy, and the engineering practices developers use to make their apps consume less power. On Android the phrase also names a specific per-app setting that decides whether an app is subject to Doze and App Standby restrictions; on iOS the equivalent controls are background execution limits and Low Power Mode.
In the mobile domain, energy is a shared and scarce resource. A typical phone battery holds roughly 4,000 to 5,500 mAh, and every wake-up, radio transmission and screen frame draws from it. Battery optimization therefore balances user-visible responsiveness against power consumption, and apps that ignore it face throttling, warnings and uninstalls.
Where a mobile app spends energy
Energy use on a phone is dominated by a few components, and battery optimization starts with knowing which one an app keeps awake. The display and the cellular radio usually consume the most, while the CPU matters mainly when it is prevented from entering deep sleep by wake locks or frequent timers.
Radios behave in a particularly costly way. After transmitting even a small packet, a cellular modem stays in a high-power state for several seconds before dropping to idle, a period often called the radio tail. Many small, scattered requests therefore cost far more than the same data sent in one batch.
| Component | What keeps it busy | Optimization lever |
|---|---|---|
| Display | Brightness, refresh rate, bright content | Dark themes on OLED, adaptive refresh |
| Cellular radio | Frequent small requests, weak signal | Batch and defer network work |
| CPU | Wake locks, timers, heavy parsing | Let the device sleep, use efficient code |
| GPS | High-accuracy continuous location | Lower accuracy, geofences, batching |
| GPU | Animations, games, complex rendering | Cap frame rate, avoid needless redraws |
How operating systems enforce battery optimization
Both major mobile platforms actively limit background work rather than trusting apps. Android introduced Doze and App Standby to defer jobs, network access and alarms when the device is idle, and later added App Standby Buckets, which ration background work according to how recently and often the user opened an app.
| Mechanism | Platform | Effect on apps |
|---|---|---|
| Doze | Android | Defers jobs, alarms and network during idle periods |
| App Standby Buckets | Android | Limits jobs and alarms for rarely used apps |
| Background execution limits | Android | Restricts background services and broadcasts |
| Background App Refresh | iOS | System decides when apps fetch content |
| Low Power Mode | iOS and Android variants | Reduces background activity and performance |
On Android, users can mark an app as unrestricted in battery settings, exempting it from some limits. Apps may ask for this only in narrow cases such as alarm clocks or device companion apps, and store policy restricts such requests. Some manufacturers add their own aggressive task killers, which is a frequent cause of missed notifications on certain brands.
Engineering practices for energy-efficient apps
Effective battery optimization in app code follows one principle: do less work, less often, at better times. Work that is not urgent should wait until the device is charging or on Wi-Fi, and work that must happen should be grouped.
| Technique | When to apply it | Benefit |
|---|---|---|
| Scheduled background jobs | Sync, uploads, cleanup | System batches work with other apps |
| Push instead of polling | New messages or updates | No repeated radio wake-ups |
| Network request batching | Analytics, logs, prefetching | Fewer radio tail periods |
| Charging and Wi-Fi constraints | Large downloads, backups | Shifts cost to external power |
| Adaptive location accuracy | Tracking or local content | Avoids constant GPS use |
| Stopping work off-screen | Animations, sensors, video | No energy spent on invisible output |
Platform APIs implement most of these patterns: WorkManager on Android and BGTaskScheduler on iOS schedule deferrable work, and push services such as FCM and APNs replace polling. Using them lets the operating system align an app’s work with other apps, so the radio and CPU wake up once instead of many times.
Measuring battery impact
Battery optimization requires measurement, not intuition. A single misplaced wake lock can dominate energy use while the app looks idle, and it only shows up in traces.
- Android Studio Energy and Power Profilers show CPU, network and location activity over time.
- Perfetto and Battery Historian reveal wake locks, alarms and job execution in system traces.
- Xcode Energy Organizer and Instruments report energy impact and background activity on iOS.
- Android vitals flag excessive wake locks and wake-ups across the real user base.
- Long real-device tests of several hours expose drains that short sessions never reveal.
Comparing results against a baseline build is essential, because battery drain also varies with signal strength, temperature and battery age. Tests should keep these conditions as similar as possible.
Common mistakes in battery optimization
Battery problems usually come from background behavior the developer did not intend, and they often appear first as one-star reviews mentioning heat or drain.
| Symptom | Likely cause | Fix |
|---|---|---|
| Phone warm while idle | Held wake lock or busy loop | Release locks, use scheduled jobs |
| High mobile data in background | Polling or uncontrolled prefetch | Switch to push, add constraints |
| Constant location icon | Continuous high-accuracy GPS | Use geofences or lower accuracy |
| Drain during video calls | Unnecessary resolution or frame rate | Adapt quality to network and screen |
| Late notifications | Aggressive vendor restrictions | Use high-priority push correctly |
A further mistake is asking every user to disable battery optimization for the app. This shifts the cost to the user, may violate store policy and erodes trust; it should remain an exception for genuinely time-critical apps.
A non-technical view
Battery optimization is about making a phone’s battery last longer without making apps feel slow. The phone itself puts sleepy apps on a strict schedule, and good app makers write their apps to use as little power as possible.
Think of a household where everyone wants to run errands with the family car. Instead of driving out for every small item, it is far cheaper to collect the errands and do them in one trip. Phones and well-built apps do the same with their energy.
A concrete example
A fitness app receives many reviews complaining that phones lose a noticeable share of charge overnight. Traces from test devices show that the app polls its server every five minutes for challenge updates and keeps a partial wake lock after each sync because of a missing release call.
The team replaces polling with push messages, moves daily statistics uploads to a scheduled job that runs on Wi-Fi while charging, and fixes the wake lock leak. In the next release, Android vitals no longer flag excessive wake-ups, overnight drain attributed to the app becomes negligible in system battery settings, and complaints about battery in reviews largely disappear.