Кордова: Сокеты, PushNotifications или многократный опрос сервера?
У меня есть приложение Cordova/PhoneGap.
Я хотел бы иметь некоторое подобие обновлений в реальном времени, когда приложение находится на переднем плане.
Какой наименее ресурсоемкий способ сделать это? Должен ли я использовать socket.io, плагины pushnotification или просто делать запрос API каждые несколько секунд? Какое наименьшее налогообложение как для устройства, так и для сервера?
2 ответа
Для мобильного устройства у вас есть классический компромисс между использованием батареи, использованием сети и своевременностью обновлений.
Служба push-уведомлений, встроенная в мобильную ОС, предназначена для того, чтобы попытаться дать вам лучшее из всех этих компромиссов, и работает в глобальном масштабе, а не для каждого приложения (что обычно более эффективно), хотя и дает вам несколько меньший контроль над деталями реализации.
При сравнении socket.io и опроса API-интерфейса socket.io (а точнее, webSockets) разрабатывался как более эффективный способ получения асинхронных уведомлений с сервера.
В socket.io вы создаете сокет-соединение с сервером. Это соединение остается открытым в течение всего времени работы вашего приложения (на переднем плане), и в любое время сервер может просто отправить вам данные, и вы получите их сразу после отправки. Поскольку соединения могут быть потеряны, и конечные точки не обязательно уведомляются об этом немедленно, socket.io использует небольшие тактовые пакеты, которые регулярно отправляются между клиентом и сервером. Если пакеты пульса перестают отвечать, то socket.io предполагает, что соединение прервано, и закроет исходный сокет и попытается создать новое соединение. Он делает все это прозрачно и автоматически для вас. Это сердцебиение, однако, имеет некоторые нежелательные последствия для мобильных устройств. Отправленные данные являются крошечными, поэтому на самом деле это не проблема использования полосы пропускания, но каждая передача с мобильного устройства использует батарею, и это может иметь значение, если оставить ее на длительное время. Интервал сердцебиения в socket.io настраивается. Его можно отключить (не рекомендуется) или установить более длительный интервал времени.
И push-сервис ОС, и socket.io очень эффективны с серверной стороны, поскольку сервер работает только тогда, когда есть что-то, что нужно отправить клиенту, и ему не нужно выставлять регулярные запросы там, где нечего делать.
Единственным возможным преимуществом опроса здесь было бы, если желаемый интервал обновления был длинным (например, один раз в час) или он обычно не включен и используется только изредка. Затем вы можете просто отправлять вызов Ajax каждый час или по требованию, и серверу не нужно будет ничего делать, кроме ответа на случайный вызов Ajax. Если желаемый интервал короче, то вы, вероятно, захотите использовать один из настоящих механизмов push (либо OS push, либо socket.io).
Используйте веб-сокеты.
Подход, основанный на опросах, предусматривает минимальные накладные расходы, связанные с необходимостью отправлять запрос каждые X секунд для проверки любых новых сообщений, что дает вам дурацкий компромисс: чем ниже частота запросов, тем менее отзывчивым ваше приложение. Длинный опрос xhr несколько снижает эту стоимость, оставляя http-запрос открытым в течение 30-60 секунд или около того, позволяя серверу отправлять ответ как можно скорее, но это все равно накладывает регулярный интервал запроса.
Веб-сокет - это постоянное соединение, то есть соединение остается открытым для каждого клиента. Это означает использование памяти, но я бы не стал сильно беспокоиться. Вы будете ограничены в фактическом трафике сообщений перед сохранением соединений
Это действительно хорошее прочтение, чтобы дать вам представление о том, какой масштаб возможен с помощью веб-сокетов на node.js: http://www.jayway.com/2015/04/13/600k-concurrent-websocket-connections-on-aws-using-node-js/ с помощью JS-/
Есть много вариантов, два, которые я бы порекомендовал, это socket.io и faye. Они оба очень легко встать и бежать. Оба также будут обрабатывать для вас такие вещи, как определение каналов сообщений, протоколы подключения / отключения, и у них есть дополнительное преимущество выбора правильного транспорта, который поддерживаются и клиентом, и сервером. Например, Socket.io 1.0+ (с использованием engine.io) начнется с длительного опроса и будет обновлен до веб-сокетов, если обе конечные точки его поддерживают, что может ускорить процесс. Faye - это простая и легкая система пабов / подсистем, тогда как socket.io - более сложное, основанное на сессиях предложение. Один или другой может быть хорошим выбором в зависимости от ваших потребностей.
Если минимизация нагрузки по вашему запросу является вашей первостепенной задачей, реализация веб-сокетов напрямую с помощью npm ws (это то, на что полагаются и socket.io, и faye), также вариант, но это, очевидно, более сложный.