Тестирование потребления батареи мобильным приложением

Тестирование потребления батареи мобильным приложением

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