Service Worker vs. Shared Worker

Was ist der Unterschied zwischen Service Worker und Shared Worker?

Wann sollte ich Service Worker anstelle von Shared Worker verwenden und umgekehrt?

Ein Service Worker verfügt über zusätzliche Funktionen, die über das hinausgehen, was in gemeinsam genutzten Workern verfügbar ist, und sobald er registriert ist, bleiben sie über die Lebensdauer einer bestimmten Webseite hinaus bestehen.

Servicemitarbeiter können darauf reagieren message Events, wie Shared Worker, aber sie haben auch Zugriff auf zusätzliche Events. Handhabung fetch events ermöglicht es Servicemitarbeitern, jeglichen Netzwerkverkehr (der von einer kontrollierten Seite stammt) abzufangen und bestimmte Maßnahmen zu ergreifen, einschließlich der Bereitstellung von Antworten von a Request/Response Zwischenspeicher. Es gibt auch Pläne aussetzen push Ereignis an Servicemitarbeiter, sodass Web-Apps Push-Nachrichten im “Hintergrund” empfangen können.

Der andere große Unterschied betrifft die Persistenz. Sobald ein Servicemitarbeiter für einen bestimmten Ursprung und Bereich registriert ist, bleibt er auf unbestimmte Zeit registriert. (Ein Service-Worker wird automatisch aktualisiert, wenn sich das zugrunde liegende Skript ändert, und er kann entweder manuell oder programmgesteuert entfernt werden, aber das ist die Ausnahme.) Weil ein Service-Worker dauerhaft ist und unabhängig von den in einem Webbrowser aktiven Seiten lebt , öffnet es die Tür für Dinge wie deren Verwendung, um das oben erwähnte Push-Messaging zu betreiben – ein Servicemitarbeiter kann „aufgeweckt“ werden und a push Ereignis, solange der Browser läuft, unabhängig davon, welche Seiten aktiv sind. Zukünftige Funktionen von Webplattformen werden wahrscheinlich ebenfalls von dieser Persistenz profitieren.

Es gibt noch weitere, technische Unterschiede, aber aus übergeordneter Sicht fallen diese auf.

EIN SharedWorker Kontext ist ein Zustandsbehaftete Sitzung und wurde entwickelt, um Webseiten über asynchrones Messaging (Client/Server-Paradigma) in eine einzige App zu bündeln. Sein Lebenszyklus ist domänenbasiertstatt Einzelseite basiert wie Engagierter Arbeiter (zweistufiges Paradigma).

EIN Servicemitarbeiter Kontext soll sein staatenlos. Es ist eigentlich überhaupt keine dauerhafte Sitzung – es ist die Umkehrung der Kontrolle (IoC) oder ereignisbasiert Persistenzdienst Paradigma. Es dient Ereignissen, nicht Sitzungen.

Ein Zweck besteht darin, gleichzeitige sichere asynchrone Ereignisse zu bedienen lang andauernde Abfragen (LRQs) zu Datenbanken und anderen Persistenzdienste (dh Wolken). Genau das, was ein Thread-Pool in anderen Sprachen tut.

Wenn Ihre Web-App beispielsweise viele gleichzeitige sichere LRQs an verschiedene Cloud-Dienste ausführt, um sich selbst zu füllen, ServiceWorker sind was du willst. Sie können Dutzende von sicheren LRQs sofort ausführen, ohne die Benutzererfahrung zu blockieren. SharedWorkers und Engagierte Mitarbeiter nicht ohne weiteres in der Lage sind, viele gleichzeitige sichere LRQs zu handhaben. Außerdem werden einige Browser nicht unterstützt SharedWorkers.

Vielleicht hätten sie anrufen sollen ServiceWorker stattdessen: CloudWorker zur Verdeutlichung, aber nicht alle Dienste sind Clouds.

Hoffentlich sollte diese Erklärung Sie dazu bringen, darüber nachzudenken, wie die verschiedenen Worker-Typen entworfen wurden, um zusammenzuarbeiten. Jeder hat seine eigene Spezialisierung, aber das gemeinsame Ziel ist es, die DOM-Latenz zu reduzieren und die Benutzererfahrung in webbasierten Anwendungen zu verbessern.

Werfen Sie etwas hinein WebSockets zum Streamen u WebGL für Grafiken und Sie können einige brandheiße Web-Apps erstellen, die eine ähnliche Leistung erbringen Multiplayer-Konsolenspiele.

2022 06 Aktualisierung

WebKit hat Unterstützung für die SharedWorker Kürzlich finden Sie die Details der Lösung im unten genannten Problemlink.

2020 11 Aktualisierung

Wichtiges Detail für alle, die an dieser Diskussion interessiert sind: SharedWorker ist NICHT unterstützt von WebKit (wurde absichtlich entfernt ~v6 oder so).

Das WebKit-Team empfiehlt ausdrücklich die Verwendung ServiceWorker wo auch immer SharedWorker könnte relevant erscheinen.

Für eine Community, die diese Funktionalität zurück zu WebKit bringen möchte, siehe Dies (bis jetzt ungelöstes) Problem.

Hinzufügen zu den vorherigen großartigen Antworten. Denn der Hauptunterschied ist das Servicemitarbeiter ist zustandslos (wird heruntergefahren und dann mit klarem globalen Bereich gestartet) und SharedWorker behält den Zustand für die Dauer der Sitzung bei.

Es besteht jedoch die Möglichkeit, dies zu beantragen Servicemitarbeiter behält den Zustand für die Dauer eines Nachrichtenhandlers bei.

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
})())

Der obige Code erfordert, dass die Servicemitarbeiter wird nicht heruntergefahren, bis das Versprechen als Parameter an gegeben wurde warte bis beschließt. Wenn viele Nachrichten gleichzeitig auf diese Weise behandelt werden Servicemitarbeiter wird nicht heruntergefahren, bis alle Versprechungen gelöst sind.

Dies könnte möglicherweise zur Verlängerung genutzt werden Servicemitarbeiter Leben auf unbestimmte Zeit effektiv machen a SharedWorker. Denken Sie jedoch daran, dass der Browser möglicherweise beschließt, ein Herunterfahren zu erzwingen, wenn Servicemitarbeiter geht zu lange.