Соединительные разъемы и опрос. Что является лучшим решением с точки зрения срока службы батареи?

Итак... Я делаю приложение для Android. Приложение должно отправлять и получать данные чата реального времени (должен быть сокетом), но ему также необходимо отправлять команды (которые не так, как клиент знает, когда он что-то посылает).

Мне нужно знать, что является лучшим решением с точки зрения экономии батареи пользователя.

a) Открытие и закрытие соединения при каждой отправке команды, если вкладка чата открыта, а затем поддерживать постоянную связь.

b) Постоянно поддерживайте связь.

Я просмотрел интернет, но получил смешанные ответы, некоторые говорят, что поддерживать постоянное соединение плохо для батареи, а другие говорят, что это не так. (Пример: "Вы спрашиваете, открыта ли соединение TCP? будет ли батарея разряжена? Может быть, я ПУТЬ здесь, но, поддерживая соединение, не следует тратить время на отработку батареи... Если вы думаете, что мне будет интересно узнать, где вы получили эту информацию, это звучит так странно для меня." )

Или, если будет другое решение, которое было бы лучше. Я не думаю, что Google C2DM был бы очень полезен и в этой ситуации.

В принципе, что больше разряжает батарею: имеет постоянное соединение или открывает и закрывает соединение, если не открыта вкладка чата?

Спасибо!

Ответ 1

Сохранение незанятого соединения сокетов TCP (без отправки или получения данных) не будет (или, по крайней мере, не должно) потреблять больше батареи, чем закрывать ее. Это связано с тем, что простоя TCP-соединения не использует полосы пропускания или циклы CPU (*).

Тем не менее, сохранение TCP-соединения в течение продолжительного периода времени может быть хорошим вариантом для мобильного устройства, поскольку TCP-соединения плохо взаимодействуют с компьютерами, которые переходят в спящий режим. Сценарий проблемы будет следующим: ваш пользователь Android помещает свое устройство Android в режим сна во время работы вашего приложения, а затем удаленная пользовательская программа (или что-то другое на TCP-соединении) отправляет некоторые данные по потоку TCP. Удаленная пользовательская программа никогда не получает ACK обратно с устройства Android, потому что, конечно, устройство Android спит, поэтому TCP-стек удаленного устройства предполагает, что пакеты TCP-пакетов, которые он отправил, должны быть потеряны, и он реагирует, увеличивая период ожидания, уменьшая размер его TCP-окна (например, количество TCP-пакетов, разрешенных в полете в один момент) и повторно отправляя пакеты TCP. Но устройство Android все еще спит, и, таким образом, одно и то же происходит снова. Результат заключается в том, что через несколько минут удаленный конец TCP-соединения замедлился до такой степени, что даже если Android-устройство должно было проснуться, TCP-соединение, вероятно, будет слишком медленным, чтобы его можно было использовать, - в этот момент ваш программа должна будет закрыть подключенное TCP-соединение и запустить новую в любом случае, поэтому зачем пытаться ее открыть?

Таким образом, моя рекомендация состояла бы в том, чтобы пойти с опцией (а), с условием, что вы закрываете TCP-соединение как часть вашей процедуры "устройство-это-к-к-спать-сейчас".

Одно из возможных предостережений было бы в том случае, если у Android будет функция, в которой сохранение открытого TCP-соединения приведет к тому, что оборудование WiFi или сотовой сети останется включенным в ситуации, когда в противном случае его можно было бы спать - если это так, то Android-устройство будет платить за батарею за питание антенны, что в противном случае ей не пришлось бы платить. Я не знаю ни одной такой логики Android, но я немного использовал Android, так что это может быть просто невежество с моей стороны. Возможно, стоит проверить, по крайней мере.

(*) Ну, технически TCP действительно отправляет пакет "keepalive" так часто, пока TCP-соединение открыто, и оно использует некоторые циклы процессора и мощность антенны... но интервал по умолчанию для отправки пакетов keepalive на Android два часа, поэтому я сомневаюсь, что сила, используемая для этого, будет заметна.

Ответ 2

Чтобы действительно открыть соединение, вам, вероятно, придется посылать сигналы пульса туда и обратно, так как любые маршрутизаторы с поддержкой состояния между устройством Android и серверами будут забывать о соединении после относительно короткого времени.

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

Ответ 3

Батарея очень сильно связана с переходом состояния радиосвязи в 3G с DCH/FACH/IDLE. Если вы хотите, чтобы приложение было энергоэффективным, вы должны отправить как можно больше данных на ограниченный промежуток времени, не имеющий отношения к постоянному соединению, или нет...