Аномальний розряд батареї — явний сигнал проблем в архітектурі
Користувачі помічають, що пристрій нагрівається і розряджається за півдня. Це призводить до негативних відгуків і падіння retention. iOS та Android оснащені вбудованими моніторами енергоспоживання — приховати проблему неможливо. Ми проводимо аудит і усуваємо причини: некеровані wakelock-и, надлишковий GPS, часті мережеві запити, неправильні фонові задачі. У 90% випадків достатньо скоригувати 2–3 елементи архітектури, щоб знизити енергоспоживання в 3–5 разів без втрати функціональності. Гарантуємо прозорий звіт із вимірами до та після. Зниження енергоспоживання прямо скорочує витрати на серверні ресурси та підвищує лояльність користувачів — економія бюджету до 50% на рік.
Чому додаток швидко розряджає батарею?
PowerManager.WakeLock.acquire() без таймауту або без гарантованого release() — пристрій не переходить у deep sleep. Один незакритий PARTIAL_WAKE_LOCK тримає процесор активним всю ніч. Ми використовуємо WakefulBroadcastReceiver або WorkManager, які керують wakelock автоматично. Періодична задача з інтервалом 15 хвилин (мінімально допустимий) із мережевими запитами, записом у БД та GPS — надто часта. JobScheduler batching дозволяє групувати задачі та використовувати setRequiredNetworkType(NetworkType.CONNECTED), щоб не будити радіо без мережі.
Як провести аудит батареї? Інструменти та методика
Для діагностики використовуємо Battery Historian — відкритий інструмент Google для аналізу bugreport з Android. Він будує часову шкалу: wakelock-и, network activity, GPS-фікси, CPU wakeup. Типова картина проблемного додатку: wakelock кожні 15 хвилин на 2–3 секунди, періодичні мережеві запити, GPS у фоні з високою точністю.
- Збір даних — зніміть bugreport на Android (команда нижче) або Energy Log на iOS через Xcode Instruments.
- Аналіз — знайдіть аномальні піки активності та тривалі пробудження.
- Ідентифікація — визначте, який компонент (wakelock, GPS, мережа) дає основний внесок.
- Оптимізація — реалізуйте виправлення за списком.
- Повторний вимір — переконайтеся, що споживання знизилося.
adb bugreport bugreport.zip # Потім завантажити в Battery Historian Як оптимізувати використання GPS?
LocationManager з PRIORITY_HIGH_ACCURACY вмикає GPS-приймач і тримає його активним. Реальні цифри: 1–2% батареї на годину при безперервному GPS. Правильна стратегія:
| Тип додатку | Рекомендована точність | Споживання |
|---|---|---|
| Навігація (активна) | PRIORITY_HIGH_ACCURACY |
1–2% на годину |
| Навігація (фон) | PRIORITY_BALANCED_POWER_ACCURACY |
0.3–0.5% на годину |
| Геофенсинг | GeofencingClient |
Мінімальне |
| Пошук поруч | разовий getCurrentLocation() |
Одиничний запит |
На iOS: CLLocationManager з desiredAccuracy = kCLLocationAccuracyBest у фоні — серйозна проблема. significantLocationChangeMonitoring споживає на порядок менше і достатній для більшості сценаріїв. allowsBackgroundLocationUpdates = true потребує явного обґрунтування — без нього iOS агресивно обмежує оновлення.
Як скоротити споживання мережі?
Радіомодуль при активації витрачає енергію на підйом з'єднання навіть при передачі одного байта. Краще один великий запит раз на 5 хвилин, ніж 20 маленьких кожні 15 секунд. HTTP Keep-Alive та HTTP/2 multiplexing скорочують кількість TCP handshake, що економить батарею. Push-повідомлення через FCM/APNs — правильний спосіб сигналізувати про нові дані замість long polling. Server-Sent Events та WebSocket прийнятні для реального часу, але їх потрібно закривати при переході у фон.
iOS: які обмеження на фонову роботу?
BGAppRefreshTask та BGProcessingTask — сучасний API для фонових задач. Система сама вирішує, коли їх запустити, спираючись на патерни використання пристрою. Спроби обійти це через background audio або VoIP push — порушення App Store Guidelines. URLSession.shared.configuration.waitsForConnectivity = true дозволяє не піднімати радіо одразу.
Практичний кейс: оптимізація фітнес-трекера
Наш клієнт — додаток для трекінгу фітнес-активностей. Користувачі скаржилися на 8–10% батареї на годину у фоні. Battery Historian показав: CoreLocationManager з PRIORITY_HIGH_ACCURACY працював безперервно, плюс PeriodicWorkRequest кожні 15 хвилин робив чотири мережевих запити. Перемикання на PRIORITY_BALANCED_POWER_ACCURACY для фонового трекінгу + злиття мережевих запитів в один + збільшення інтервалу до 30 хвилин дало 1.5–2% на годину — у 4–5 разів менше при збереженні функціональності.
Результати оптимізації:
| Параметр | До | Після |
|---|---|---|
| Споживання на годину | 8–10% | 1.5–2% |
| Інтервал запитів | 15 хвилин | 30 хвилин |
| Точність GPS | HIGH_ACCURACY | BALANCED_POWER |
Що входить в роботу
- Діагностика поточного споживання за допомогою Battery Historian (Android) та Xcode Energy Log (iOS)
- Звіт із виявленими проблемами та пріоритетами
- Реалізація оптимізацій: виправлення wakelock-ів, налаштування GPS, групування мережевих запитів, перегляд фонових задач
- Тестування на реальних пристроях з виміром споживання
- Документація за виконаними змінами
Наші спеціалісти мають понад 5 років досвіду в оптимізації мобільних додатків, ми реалізували більше 30 проектів із покращення батареї та гарантуємо результат. Замовте аудит вашого додатку — оцінимо поточне споживання та запропонуємо план оптимізації. Отримайте консультацію, щоб дізнатися, як знизити енергоспоживання без втрати функціональності.