Приложение, которое разряжает телефон за полдня, получает однозвёздочные отзывы и удаляется. iOS покажет его в разделе «Высокое энергопотребление» в настройках, а Android с API 26+ переведёт в Doze-режим. Проблема почти никогда не в одной большой утечке — обычно это несколько мелких: GPS не отключается в фоне, WebSocket пингует каждые 5 секунд, фоновый Worker срабатывает слишком часто. Мы, как инженеры по мобильной оптимизации, провели более 80 таких аудитов и гарантируем, что после нашей работы приложение работает на 30% дольше от одного заряда. За годы практики мы научились выявлять даже скрытые паттерны энергопотребления, которые не видны при поверхностном анализе. Свяжитесь с нами, чтобы обсудить оптимизацию вашего проекта.
Тестирование потребления батареи мобильным приложением
iOS: Xcode Energy Organizer и Instruments
Instruments → Energy Log — базовый инструмент. Показывает активность CPU, GPU, сети, GPS и экрана во времени. Каждая «вспышка» активности — трата энергии. Energy Impact в Xcode Debug Navigator: Low / High / Very High — грубая оценка в реальном времени. Для точных измерений — XCTMetric:
func testBackgroundSyncEnergyImpact() throws {
let metrics: [XCTMetric] = [XCTCPUMetric(), XCTMemoryMetric(), XCTClockMetric()]
let options = XCTMeasureOptions()
options.iterationCount = 5
measure(metrics: metrics, options: options) {
// симулируем фоновую синхронизацию
let expectation = self.expectation(description: "sync")
BackgroundSyncService.shared.sync {
expectation.fulfill()
}
wait(for: [expectation], timeout: 30)
}
}
XCTCPUMetric + XCTClockMetric дают данные о нагрузке CPU и реальном времени выполнения. Если cpuTime растёт нелинейно при увеличении количества итераций — где-то накапливается состояние.
Типичные проблемы на iOS
CLLocationManager без pausesLocationUpdatesAutomatically = true и без явного stopUpdatingLocation() при уходе в фон продолжает работать и сажает батарею. Правильная стратегия для большинства приложений — requestWhenInUseAuthorization() вместо requestAlwaysAuthorization(), и переключение на startMonitoringSignificantLocationChanges() когда точность не критична.
Timer с Timer.scheduledTimer(withTimeInterval: 1.0, ...) на main run loop, забытый при уходе в фон — ещё одна классика. Проверяем: все Timer инвалидируются в applicationDidEnterBackground или в deinit view controller.
Android: Battery Historian и Perfetto
Battery Historian — веб-инструмент от Google для анализа bug report:
adb bugreport bugreport.zip
# Открываем в https://bathist.ef.lc/ или локально через Docker
docker run -d -p 9999:9999 gcr.io/android-battery-historian/stable:3.1 --port 9999
На таймлайне видим: wakelock'и (кто не даёт процессору засыпать), синхронизации, GPS-активность, сетевые запросы. WakeLock с именем myapp:background_sync держащийся 40 минут из 60 — красный флаг.
Проверка wakelocks через adb:
adb shell dumpsys power | grep -A 3 "Wake Locks:"
adb shell dumpsys battery | grep level
WorkManager и энергоэффективность
WorkManager — правильный способ фоновых задач на Android. Неправильная конфигурация убивает батарею:
// Плохо: минимальный интервал 15 минут по умолчанию
val syncRequest = PeriodicWorkRequestBuilder<SyncWorker>(15, TimeUnit.MINUTES).build()
// Лучше: привязываем к сетевому подключению, батарея не разряжена
val syncRequest = PeriodicWorkRequestBuilder<SyncWorker>(1, TimeUnit.HOURS)
.setConstraints(
Constraints.Builder()
.setRequiredNetworkType(NetworkType.CONNECTED)
.setRequiresBatteryNotLow(true)
.build()
)
.build()
SetRequiresBatteryNotLow(true) — Worker не запустится, если заряд ниже ~20%. SetRequiredNetworkType(NetworkType.CONNECTED) — не будет попыток, когда нет сети.
Perfetto — более детальный трейсинг для Android. Показывает активность на уровне треков CPU, сети, I/O. Полезен когда Battery Historian показывает проблему, но не локализует её до конкретного кода.
Как выявить проблемы с батареей на iOS?
Начните с Energy Log в Instruments. Если видите частые всплески CPU каждые 5 секунд – проверьте WebSocket-пинги. Сравните время работы при включённом и выключенном фоновом обновлении. Для точности используйте XCTMetric с несколькими итерациями – это покажет, есть ли накопление нагрузки.
Что делать с сетевыми запросами?
Каждый подъём радио-модуля (WiFi или LTE) — пик потребления. Радио остаётся активным 10–30 секунд после последнего запроса (tail energy). Вместо 10 запросов по 1 объекту лучше 1 запрос на 10 объектов — один подъём вместо десяти. Для WebSocket: пинги каждые 5 секунд в фоне — это 12 подъёмов радио в минуту. Разумный интервал — 30–60 секунд, с учётом NAT-таймаутов.
| Типичная проблема | Частота | Решение |
|---|---|---|
| WebSocket-пинги каждые 5 с | 70% проектов | Интервал 60 с с exponential backoff |
| GPS в фоне без пауз | 50% | PausesLocationUpdates = true |
| WorkManager с минимальным интервалом | 40% | Constraints + период 1 час |
| Критерий | iOS (Swift) | Android (Kotlin) |
|---|---|---|
| Инструмент профилирования | Instruments Energy Log | Battery Historian / Perfetto |
| Метрики нагрузки | CPU, GPU, сеть, GPS, экран | Wakelock, sync, GPS, сеть |
| Юнит-тесты | XCTMetric | WorkManager TestListen |
| Типичная проблема | Timer в фоне | WakeLock без таймаута |
| Решение | Инвалидация в background | Constraints + периодичность |
Пошаговая инструкция тестирования батареи
- Снимите профиль Energy Log на iOS или bug report на Android в течение 1 часа нормального использования.
- Откройте в Instruments или Battery Historian и отфильтруйте всплески длительностью более 10 секунд.
- Проверьте каждый всплеск — что его вызвало: сетевой запрос, GPS, таймер, wakelock.
- Оцените необходимость: можно ли отложить, объединить, уменьшить частоту.
- Примените патч — переконфигурируйте WorkManager, поставьте пинг-интервал 60 секунд, отключите GPS в фоне.
- Повторите профилирование — убедитесь, что всплески исчезли или сократились.
Что входит в работу по аудиту батареи
Наш аудит включает полный цикл: профилирование на реальных устройствах (iPhone 15, Xiaomi 13 Pro), анализ логов с выявлением узких мест, предоставление детального отчёта с графиками энергопотребления и рекомендациями по исправлению в коде. После отчёта мы проводим консультацию с вашей командой для внедрения оптимизаций. При необходимости — повторное профилирование после патча. Мы также помогаем с настройкой CI/CD для автоматического отслеживания энергопотребления. Закажите тестирование, чтобы ваше приложение работало дольше без подзарядки. Свяжитесь с нами для консультации — ваш проект может быть следующим в нашей статистике успешных оптимизаций.
Мы гарантируем, что наш опыт (более 5 лет на рынке, 80+ проанализированных проектов) поможет найти даже скрытые проблемы. Стоимость аудита окупается в среднем за 3 месяца за счёт снижения жалоб пользователей. Получите консультацию уже сегодня — свяжитесь с нами, чтобы обсудить ваш проект. Закажите тестирование и продлите жизнь аккумулятору ваших пользователей!