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

контекст

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

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

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

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

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

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

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

Ищу ответы

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

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

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

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

• Safari прерывает соединение через веб-сокет из-за неактивности, когда страница не в фокусе

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

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

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

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

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

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

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

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

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