Аномальный разряд батареи — явный сигнал проблем в архитектуре
Пользователи замечают, что устройство нагревается и разряжается за полдня. Это приводит к негативным отзывам и падению 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 проектов по улучшению батареи и гарантируем результат. Закажите аудит вашего приложения — оценим текущее потребление и предложим план оптимизации. Получите консультацию, чтобы узнать, как снизить энергопотребление без потери функциональности.