im пытается с месяца сделать правильный «push» без использования внешних библиотек или gcm.Android Long Polling TCP Connection
Сначала я попробовал xmpp с asmack, затем mosquitto с клиентом paho или ibm mqtt и http с alarmtimer.
В конце концов, я закончил с диаконом и метеоритом, но так как это не очень хорошо (на стороне сервера - высокая скорость процессора и память), я пытаюсь сделать длинное соединение.
Я знаю, что для этого требуется сердцебиение, и, наконец, я думал о задержке (300 секунд сердцебиение должно быть достаточно?) И надлежащим образом.
Лучше (использование батареи и т. Д.) Отправлять Heartbeat (с 1 байт или что-то еще) с сервера на клиент (например, задержка 300 секунд) и установить тайм-аут сокета на стороне клиента 300 или это лучше сделать отправку с клиента на сервер?
В настоящее время им пользуется Служба, которая регистрирует наблюдателя в onCreate и unregister в onDestroy.
Наблюдатель наблюдает за объектом, который устанавливает соединение со штепсельной вилкой tcp в потоке и повторяет его onec, а это отключает (тайм-аут гнезда).
Я также проверяю с помощью трансляции, если сетевое подключение изменилось и при необходимости снова подключится.
Что произойдет, когда устройство перейдет в режим ожидания? Мне действительно нужен будильник или timertask, чтобы получить ИЛИ отправить пакет?
Удаляет ли устройство соединение onec, оно переходит в режим ожидания?
В настоящее время я попытался отправить с сервера клиенту с задержкой в 120 секунд, и даже когда дисплей устройств повернулся, он все еще может послать пульс.
Но, по крайней мере, похоже, что утечка батареи не является «приемлемой».
Итак .. Каков наилучший способ сделать это?
Благодарим вас.
Благодарим вас за это, но кажется, что его все еще связано, так как дьякон делает «почти» то же самое, и он работает. https://github.com/davidrea/Deacon/blob/develop/src/org/deacon/MeteorPushReceiver.java Ну, я не мог распознать какие-либо разъединения в Wifi с Standby, но я предполагаю, что это может произойти через некоторое время (вероятно, если GC захочет это). Но по этой причине есть служба с return_sticky. В диаконе нет проблем с батареями (например). Теперь, когда ping от сервера к клиенту с задержкой в 2 секунды, я не смог распознать батареи. Ну, соединение должно быть ПОСТОЯННО живым. –
2 секунды, может быть, немного быстро. В расширенной настройке Wi-Fi есть системная настройка, чтобы предотвратить отключение устройства в режиме ожидания. – MobileSam
Спасибо за этот намек. Не знал этого. Ну, на галактике s3 он успешно работал на Wi-Fi даже в режиме ожидания. GC уничтожил службу, но поток все еще работал. Когда поток убит (но он занимает не так много памяти, поэтому обычно gc не будет его убивать), он вернется. «2 секунды» предназначались только для тестирования дренажа батареек. Я думаю, 300 - это «хороший» интервал. Но это все еще не лучшее решение. Итак, какие-то улучшения? –