Как определить, когда браузер регулирует отключение таймеров и веб-сокетов после того, как пользователь покидает вкладку или выключает экран? (javascript) - PullRequest
Новая
       11

Как определить, когда браузер регулирует отключение таймеров и веб-сокетов после того, как пользователь покидает вкладку или выключает экран? (javascript)

12 голосов
/ 19 марта 2020

Контекст

Игра поставляется в виде прогрессивного веб-приложения с таймерами (setTimeout, setInterval) и подключениями через веб-сокет для связи в реальном времени.

Что происходит

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

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

Такое поведение зависит от браузеров и платформы и, может быть, даже зависит от конкретного поведения пользователя. Я предполагаю, что браузеры и ОС имеют свой собственный жизненный цикл / механизмы для экономии заряда батареи и / или вычислений.

Когда пользователь возвращается, приложение находится в неизвестном состоянии, и я изо всех сил пытаюсь восстановить его правильно.

Относительно веб-сокетов У меня есть автоматическое переподключение с socket.io и Повторное подключение-веб-сокет , но этого недостаточно, чтобы решить все.

Ищем ответы

  • Каковы "жизненные циклы" различных браузеров относительно них? Это задокументировано? Когда они решают выключить и включить газ?
  • Что они делают именно с веб-розетками? Браузеры просто отключают их?
  • Что они делают именно с таймерами? Они душат их или отрицают или что-то еще?
  • Что происходит с javascript казнью вообще? Приостановлено / уничтожено / задушено?
  • Есть ли способ подключиться к какому-либо событию жизненного цикла браузера, когда оно собирается выключить? Единственное, что я могу найти, это API видимости

  • Есть ли способ искусственно воспроизвести это поведение, чтобы иметь возможность тестировать решения? Это особенно сложно на рабочем столе. Невозможно отключить веб-сокеты, и разработчики Chrome не спешат помочь проблеме 2014 года (!): Веб-сокеты не включены при использовании регулирования соединения

  • Независимо от вышесказанного, существует ли прагматическое c кросс-браузерное решение для обнаружения / решения этой проблемы? (например, из опыта, Firefox на рабочем столе, кажется, ведет себя совершенно иначе по сравнению с Chrome, и iPhone будет отключаться гораздо чаще, чем Android)

Ссылки по теме

Ответы [ 2 ]

7 голосов
/ 28 марта 2020

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

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

Вот документы из Chrome.

Я вспомнил, что Есть некоторые события, такие как onload, которые сообщают вам, покинул ли пользователь или снова открыл вкладку. Вы можете использовать это событие для переподключения et c ..

0 голосов
/ 07 апреля 2020

Я бы дал другой совет относительно того, как разработать ваше приложение. Из того, что я понимаю, ваше намерение состоит в том, чтобы добавить больше logi c, чтобы понять, не активен ли пользователь в браузере. Это влечет за собой другую проблему: специфика браузера для реализации этого логика c. Имея это в виду, я бы вместо этого инвестировал в лучшую обработку ошибок , как на сервере, так и на клиенте.

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

Это идея, которую вы можете найти в архитектуре сервисов, но тот же шаблон применим к любому веб-приложению. Возможно, вы захотите поискать Design-for-Fail концепций:

Сложность делает невозможным предполагать надежность со стороны систем, на которые опирается. Вместо этого необходимо спроектировать системы и приложения на любом данном уровне в ИТ-стеке, чтобы предположить возможность отказа на более низких уровнях. Дизайн для отказа требует думать о отказоустойчивости на всех уровнях. Разработчики приложений больше не могут ограничиваться размышлениями о функциональности.

https://www.oreilly.com/library/view/designing-delivery/9781491903742/ch04.html

...