Энергоэффективная периодическая отправка данных

У меня есть веб-приложение для запуска на мобильных телефонах, которое при открытии непрерывно генерирует данные (несколько килобайт каждые несколько секунд или каждые несколько минут в зависимости от настроек) и должно передавать их на сервер в режиме реального времени. Никакие данные никогда не отправляются с сервера в браузер.

Моя главная задача — сделать эту отправку эффективной, задержка в несколько секунд вполне допустима.

Я предусмотрел два решения:

  1. Периодически выполняйте POST на сервер с данными (чтобы не поддерживать постоянное соединение).
  2. Иметь открытый websocket и периодически отправлять сообщения (чтобы избежать веса HTTP-запроса).

Какой из них наиболее эффективен для батареи? Есть ли другие стратегии, которые мне не хватает?

На самом деле мое приложение будет размещено на героку, что делает пока не поддерживает веб-сокеты, что приводит к длительному опросу, поэтому на данный момент я предполагаю, что лучше выполнять POST по запросу, но мне интересно, может ли это быть вариантом в будущем (или, может быть, это предположение неверно ).


http javascript websocket battery
person Mathieu    schedule 31.10.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Андроид

На устройствах Android существует три разных состояния сетевого радио, как указано в документации. говорит:

Конечный автомат типичной сетевой радиостанции 3G состоит из трех энергетических состояний:

  1. Полная мощность: используется при активном соединении, что позволяет устройству передавать данные с максимально возможной скоростью.

  2. Низкое энергопотребление: промежуточное состояние, при котором используется около 50 % заряда батареи при полном заряде.

  3. Ожидание: состояние минимального энергопотребления, в течение которого сетевое подключение не активно или не требуется.

В то время как состояния низкого уровня и простоя расходуют значительно меньше заряда батареи, они также приводят к значительной задержке сетевых запросов. Возврат к полной мощности из низкого состояния занимает около 1,5 секунд, а переход от холостого хода к полному может занять более 2 секунд.

Устройство переключается с полного на низкий через 5 секунд бездействия, а затем с низкого на ждущий еще через 12 секунд.

Вышеупомянутая ссылка также охватывает некоторые передовые методы для безопасных для батареи подключений, хотя ничего конкретного о веб-сокетах не говорится.

iOS

Я не смог найти такую ​​конкретную документацию по устройствам iOS, но модель применяется аналогичным образом:

Сотовые и Wi-Fi-радио предназначены для отключения питания, когда нет активности. Однако в зависимости от радио это может занять несколько секунд. Если ваше приложение передает небольшие пакеты данных каждые несколько секунд, радиостанции могут оставаться включенными и продолжать потреблять энергию, даже если они фактически ничего не делают. Вместо более частой передачи небольших объемов данных лучше передавать больший объем данных один раз или с относительно большими интервалами.

Ну и что?

В общем, вам, вероятно, следует использовать короткие POST-запросы и отправлять данные как можно реже, чтобы радиостанция могла отключаться в промежутках между ними.

person pixelistik    schedule 31.10.2012
comment
Выполнение периодических запросов POST звучит более логично, и я также добавлю параметр буферизации для ограничения частоты. Что касается Android, мне неясно, будет ли активный веб-сокет предотвращать переход в режим низкого энергопотребления / ожидания, потому что он говорит, что радио не работает в течение XX секунд, но неиспользуемый сокет фактически не будет отправлять пакеты. Я должен попробовать с DDMS. - person Mathieu; 01.11.2012
comment
Из моего опыта работы с веб-сокетами служба REST (POST, GET,...) ЯВЛЯЕТСЯ сокетом. Согласно документации, устройства Android обрабатывают и помечают соединения, чтобы поддерживать их активность, даже если радиостанция простаивает (GCM реализован с использованием постоянного соединения TCP/IP). - person Goufalite; 27.05.2016