Оптимізація потребування батареї мобільною програмою
«Ваша програма сажає батарею» — один з найбільш болісних відзивів у сторі. iOS з iOS 16 показує користувачам рейтинг потребування батареї за програмами. Android з версії 12 активно сигналізує про фонові процеси через Battery Usage alerts. Програма може працювати коректно технічно, але при цьому бути в списку «прожорливих» — і користувачі її видалять.
Головні споживачі: що показує Battery Historian
Battery Historian — інструмент Google для аналізу bugreport з Android-пристрою. Показує часову шкалу: wakelock-и, network activity, GPS фіксації, CPU wakeup. Типова картина програми з проблемним потреблям: wakelock кожні 15 хвилин на 2-3 секунди, періодичні network запити, GPS у фоні з високою точністю.
Wakelock-и. PowerManager.WakeLock.acquire() без таймауту або без гарантованого release() — пристрій не уходит у deep sleep. Один незакритий PARTIAL_WAKE_LOCK тримає процесор активним всю ніч. Використовуємо WakefulBroadcastReceiver або WorkManager, які керують wakelock автоматично.
WorkManager та невірні інтервали. Періодична задача з інтервалом 15 хвилин (мінімально допустимий) на пристрої з агресивною Battery Optimization може працювати рідше. Але якщо в задачі є мережевий запит + запис у базу + GPS — 15 хвилин занадто часто. JobScheduler batching: групуємо задачі, використовуємо setRequiredNetworkType(NetworkType.CONNECTED) щоб не будити радіо без сети.
GPS: головний убивця батареї
LocationManager з LocationRequest.PRIORITY_HIGH_ACCURACY (Fused Location Provider) включає GPS-приймач та тримає його активним. 1-2% батареї на годину при безперервному GPS — це реальні цифри на сучасних пристроях.
Правильна стратегія за типами програм:
- Навігація у фоні:
PRIORITY_HIGH_ACCURACYлише при активній навігації, переключення наPRIORITY_BALANCED_POWER_ACCURACYпри фоновому трекінгу маршруту - Геофенсинг:
GeofencingClientзамість постійного GPS — спрацьовує лише при вході/виході з зони, потребування мінімальне - «Знайти рядом»: розовий
getCurrentLocation()замість постійних оновлень
На iOS: CLLocationManager з desiredAccuracy = kCLLocationAccuracyBest у фоні — серйозна проблема. significantLocationChangeMonitoring потребує на порядок менше та достатня для більшості сценаріїв фонової геолокації. allowsBackgroundLocationUpdates = true вимагає явного обґрунтування — без нього iOS агресивно ограничує оновлення.
Мережеві запити та радіо
Радіомодуль (Wi-Fi, LTE) при активації тратить додаткову енергію на підйом з'єднання, навіть якщо передається 1 байт. Закономірність: краще один крупний запит раз у 5 хвилин, ніж 20 маленьких запитів кожні 15 секунд. Batching запитів через WorkManager з setRequiredNetworkType гарантує, що запити не розбудять радіо без сети.
HTTP Keep-Alive та HTTP/2 multiplexing скорочують кількість TCP handshake — це не тільки латентність, але й батарея.
Push-уведомлення через FCM/APNs — правильний спосіб сигналізувати про нові дані замість long polling або short polling. Server-Sent Events та WebSocket прийнятні коли потрібна реалтайм-комунікація, але їх потрібно закривати при уходе у фон.
iOS: Background App Refresh та BGTaskScheduler
BGAppRefreshTask та BGProcessingTask — сучасний API для фонових задач на iOS. Система сама вирішує, коли їх запустити, спираючись на паттерни використання пристрою (ночі, на зарядці). Спроби обійти це через background audio trick або VoIP push для не-VoIP програм — порушення App Store Guidelines.
URLSession.shared.configuration.waitsForConnectivity = true — мережеві запити не піднімають радіо одразу, чекають готового з'єднання.
Практичний кейс
Програма для трекінгу фітнес-активностей. Користувачі скаржилися на 8-10% батареї на годину у фоні. Battery Historian показав: CoreLocationManager з PRIORITY_HIGH_ACCURACY працював безперервно, плюс PeriodicWorkRequest кожні 15 хвилин робив 4 мережеві запити. Переключення на PRIORITY_BALANCED_POWER_ACCURACY для фонового трекінгу + об'єднання мережевих запитів в один + збільшення інтервалу до 30 хвилин дало 1.5-2% на годину — в 4-5 разів менше, при збереженні функціональності.
Інструменти діагностики
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 не трекає батарею, але трекає кількість мережевих запитів та їхній розмір — непрямий індикатор
Термін оптимізації: одна-два тижні: діагностика, пріоритизація, виправлення.