Сервисный работник против общего работника
В чем разница между обслуживающим работником и совместно используемым работником?
Когда мне следует использовать Service Worker вместо Shared Worker и наоборот?
4 ответа
У работника службы есть дополнительные функциональные возможности, помимо того, что доступно у совместно используемых работников, и после регистрации они сохраняются вне срока жизни данной веб-страницы.
Сервисные работники могут ответить на message события, как общие работники, но они также имеют доступ к дополнительным событиям. обращение fetch события позволяют работникам службы перехватывать любой сетевой трафик (исходящий от контролируемой страницы) и предпринимать конкретные действия, включая обслуживание ответов от Request/Response кэш. Есть также планы выставить push событие для сервисных работников, позволяющее веб-приложениям получать push-сообщения в "фоновом режиме".
Другое основное отличие связано с постоянством. Как только сервисный работник зарегистрирован для определенного источника и области, он остается зарегистрированным на неопределенный срок. (Работник сервиса будет автоматически обновляться, если базовый скрипт изменяется, и его можно удалить вручную или программно, но это исключение.) Поскольку работник сервиса постоянен и не зависит от страниц, активных в веб-браузере. это открывает двери для таких вещей, как их использование для питания вышеупомянутых push-сообщений - работника службы можно "разбудить" и обработать push событие, пока браузер работает, независимо от того, какие страницы активны. Будущие функции веб-платформы, вероятно, также воспользуются этим постоянством.
Есть и другие технические отличия, но с точки зрения более высокого уровня, это то, что выделяется.
Контекст SharedWorker представляет собой сеанс с состоянием и предназначен для объединения веб-страниц в одно приложение с помощью асинхронного обмена сообщениями (парадигма клиент / сервер). Его жизненный цикл основывается на домене, а не на одной странице, как DedicatedWorker (двухуровневая парадигма).
Контекст ServiceWorker разработан так, что он не имеет состояния. На самом деле это вообще не постоянный сеанс - это инверсия управления (IoC) или основанная на событиях парадигма персистентного обслуживания. Он обслуживает события, а не сессии.
Одна из целей состоит в том, чтобы обслуживать параллельные безопасные асинхронные события для долго выполняющихся запросов (LRQ) к базам данных и другим службам персистентности (например, к облакам). Именно то, что делает пул потоков на других языках.
Например, если ваше веб-приложение выполняет много параллельных безопасных LRQ для различных облачных сервисов, чтобы заполнить себя, ServiceWorkers - то, что вам нужно. Вы можете выполнить десятки безопасных LRQ мгновенно, не блокируя работу пользователя. SharedWorkers и DedicatedWorkers нелегко справиться со многими одновременными безопасными LRQ. Кроме того, некоторые браузеры не поддерживают SharedWorkers.
Возможно, вместо этого им следовало бы вызвать ServiceWorkers: CloudWorkers для ясности, но не все сервисы являются облаками.
Надеемся, что это объяснение должно привести вас к размышлению о том, как различные типы рабочих были разработаны для совместной работы. У каждого своя специализация, но общая цель - уменьшить задержку DOM и улучшить взаимодействие с пользователем в веб-приложениях.
Добавьте несколько WebSockets для push-уведомлений и WebGL для графики, и вы сможете создавать некоторые горячие горячие веб-приложения, которые работают как многопользовательские консольные игры.
2020 11 Обновление
Важная деталь для всех, кто интересуется этим обсуждением:
SharedWorkerэто НЕ поддерживается WebKit (намеренно удалены ~v6 или что - то).
Команда WebKit явно предлагает использовать
ServiceWorker где бы
SharedWorker может показаться актуальным.
Если сообщество желает вернуть эту функциональность в WebKit, см. Эту (нерешенную на данный момент) проблему.
Добавляем к предыдущим отличным ответам. Основное различие состоит в том, что ServiceWorker не имеет состояния (будет завершен, а затем запустится с чистой глобальной областью), а SharedWorker будет поддерживать состояние в течение всего сеанса.
Тем не менее, есть возможность запросить, чтобы ServiceWorker сохранял состояние на время обработки сообщения.
s.onmessage = e => e.waitUntil(async () => {
// do things here
// for example issue a fetch and store result in IndexedDb
// ServiceWorker will live till that promise resolves
})
Приведенный выше код требует, чтобы ServiceWorker не завершал работу до тех пор, пока не будет разрешено обещание, указанное в качестве параметра для waitUntil . Если таким образом одновременно обрабатывается много сообщений, ServiceWorker не завершит работу, пока не будут выполнены все обещания.
Возможно, это можно было бы использовать для продления жизни ServiceWorker на неопределенное время, сделав его фактически SharedWorker . Тем не менее, имейте в виду, что браузер может решить принудительно завершить работу, если ServiceWorker будет работать слишком долго.