Mobile Game Battery Consumption Optimization
A game that drains the phone in an hour and a half gets one-star reviews — even if FPS is stable and there are no crashes. "Drains battery" reviews on App Store and Google Play directly impact install conversion. Meanwhile, energy consumption is a direct consequence of how efficiently computational resources are used.
Where Extra Consumption Comes From
Unlimited FPS. The most common mistake. Application.targetFrameRate = -1 (or no explicit setting) means Unity renders as fast as it can. On iPhone 15 Pro that's 120 FPS in a simple menu. Menu needs 30 FPS — the remaining 70% of CPU/GPU time is wasted and heats the device.
Particles and effects in the background. An animated menu background with 500 particles runs constantly, even when the user is looking at a push notification. No pause on lost focus — no savings.
GPS, accelerometer, other sensors. If the game requests Input.location or Input.gyro without necessity and the developer forgot to disable — sensors are polled constantly. On Android that's several mW extra.
Network requests without batching. Small HTTP requests every 5–10 seconds (analytics, heartbeat, synchronization) keep the radio module active. Radio is one of the most power-hungry components of the phone.
FPS Management by Context
The right strategy — different targets for different states:
// Gameplay: maximum quality
Application.targetFrameRate = 60;
// Menu, pauses, dialogs
Application.targetFrameRate = 30;
// Background computations (loading, saving)
Application.targetFrameRate = 15;
On iOS also account for ProMotion displays (120 Hz on iPhone 13 Pro+). By default Unity runs at 60 FPS even on 120 Hz screens, but explicitly setting CADisplayLink.preferredFrameRateRange through Native Plugin is worth it if finer control is needed.
OnApplicationPause(true) — reduce FPS to minimum or stop rendering completely here.
Shader Efficiency
On mobile GPU, computation precision matters. Using half instead of float in shaders on Adreno and Mali gives real energy savings, because ALU on these chips is optimized for half-precision. For most game effects (color, UV, lighting) half precision is enough.
Complex fragment shaders with many texture samples are particularly expensive. Each tex2D is a memory access with latency that can stall the pipeline. Baking lightmaps instead of dynamic lighting reduces fragment shader load.
Network Request Batching
Instead of sending game analytics events one by one — buffer and send in batches once per minute. Firebase Analytics does this automatically. If using custom analytics over HTTP — explicit RequestQueue with timer.
On Android WorkManager with setRequiresBatteryNotLow(true) allows deferring non-critical requests until the device is charging.
Verify Results
iOS: Xcode Energy Organizer + MetricKit. MXCPUMetric and MXGPUMetric in didReceive give real consumption data from user reports (aggregated, no PII).
Android: Android Vitals in Play Console → Battery → Excessive wakeups. If the app wakes the device more than 10 times per hour in background — it's a Google flag that affects search visibility.
For local testing — adb shell dumpsys batterystats --reset before test and adb shell dumpsys batterystats after. Shows detailed breakdown by component.
Optimization timeline: three to five business days, depends on number of problem areas and presence of native plugins.