Предотвращение автоматического обслуживания работника

Question

Служащий службы автоматически останавливается в какой-то момент. Такое поведение непреднамеренно закрывает соединение WebSocket, установленное при активации.

Когда и почему останавливается? Как я могу программно отключить это неожиданное действие, чтобы сохранить работоспособность Service Worker?

Answer 1

Что вы видите, это ожидаемое поведение, и это вряд ли изменится.

Работники службы намеренно имеют очень короткие спасательные пути. Они «рождаются» в ответ на конкретное событие (install, activate, message, fetch, push и т. Д.) Выполняют свою задачу, а затем «умирают» вскоре после этого. Срок службы обычно достаточно длинный, чтобы можно было обрабатывать несколько событий (то есть install может сопровождаться activate, за которым следует fetch), прежде чем рабочий умрет, но в конечном итоге он умрет. Вот почему очень важно не полагаться на какое-либо глобальное состояние в ваших сценариях и загружать любую информацию о состоянии, которая вам нужна, с помощью IndexedDB или API кэша хранения при запуске вашего рабочего.

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

В случае использования WebSockets ваш клиент прослушивает некоторые данные с сервера. Для этого варианта использования, полезной для сервис-работника альтернатива использованию WebSockets, следует использовать Push Messaging API и попросите вашего обслуживающего персонала ответить на события push. Обратите внимание, что в текущей реализации Chrome вы должны показывать уведомление, видимое пользователю, при обработке события push. «Тихий» push вариант использования не поддерживается прямо сейчас.

Если вместо прослушивания данных с сервера вы использовали WebSockets в качестве способа отправки данных от вашего клиента на ваш сервер, к сожалению, нет такого удобного в обслуживании рабочего процесса. В какой-то момент в будущем может быть способ регистрации вашего рабочего-работника, который будет разбужен через периодическое/временное событие, в этот момент вы можете использовать fetch() для отправки данных на сервер, но это в настоящее время не поддерживается ни в одном браузеры.

P.S .: Chrome (обычно) не будет убивать сервисного работника, если у вас открыт его интерфейс DevTools, но это только для облегчения отладки и не является поведением, на которое вы должны полагаться для реального приложения.