Тестування потребування батареї мобільним додатком
Додаток, який розраджує телефон за полдня, отримує однозвіздкові відгуки та видаляється. iOS показує його у розділі «Висока енергоспоживання» у Налаштуваннях. Android з API 26+ перекладає його у Doze-режим та починає ограничувати фонові процеси. Проблема майже ніколи не в одній великій утечці — зазвичай це кілька дрібних: GPS не вимикається у фоні, WebSocket пінгує кожні 5 секунд, фоновий Worker спрацьовує занадто часто.
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 показує проблему, але не локалізує її до конкретного кода.
Мережеві операції та батарея
Кожний підйом радіо-модуля (WiFi або LTE) — пік спожиття. Радіо залишається активним 10–30 секунд після останнього запиту (tail energy). Замість 10 запитів по 1 об'єкту краще 1 запит на 10 об'єктів — один підйом замість десяти.
Для WebSocket: пінги кожні 5 секунд у фоні — це 12 підйомів радіо на хвилину. Розумний інтервал — 30–60 секунд, з урахуванням NAT-таймаутів.
Що включено
- Профілювання енергопотреблення на iOS (Instruments Energy Log, XCTMetric)
- Аналіз Battery Historian для Android (wakelocks, синхронізації, GPS)
- Перевірка фонових процесів: WorkManager, BGTaskScheduler, push-сесії
- Аналіз мережевих паттернів на надлишкові запити
- Звіт з конкретними находками та рекомендаціями по коду
Строки
2–3 дні — аналіз існуючого додатку, профілювання на реальних пристроях, звіт. Вартість розраховується індивідуально.