Service workers essentially act as proxy servers that sit between web applications, the browser, and the network (when available). They are intended, among other things, to enable the creation of effective offline experiences, intercept network requests and take appropriate action based on whether the network is available, and update assets residing on the server. They will also allow access to push notifications and background sync APIs.
A service worker is an event-driven worker registered against an origin and a path. It takes the form of a JavaScript file that can control the web-page/site that it is associated with, intercepting and modifying navigation and resource requests, and caching resources in a very granular fashion to give you complete control over how your app behaves in certain situations (the most obvious one being when the network is not available).
A service worker is run in a worker context: it therefore has no DOM access, and runs on a different thread to the main JavaScript that powers your app, so it is non-blocking. It is designed to be fully async; as a consequence, APIs such as synchronous XHR and Web 存储 can't be used inside a service worker.
Service workers only run over HTTPS, for security reasons. Having modified network requests, wide open to man in the middle attacks would be really bad. In Firefox, Service Worker APIs are also hidden and cannot be used when the user is in private browsing mode .
注意 : Service workers win over previous attempts in this area such as; AppCache because they don't make assumptions about what you are trying to do, and then break when those assumptions are not exactly right; you have granular control over everything.
注意 : Service workers make heavy use of promises , as generally they will wait for responses to come through, after which they will respond with a success or failure action. The promises architecture is ideal for this.
A service worker is first registered using the
ServiceWorkerContainer.register()
method. If successful, your service worker will be downloaded to the client and attempt installation/activation (see below) for URLs accessed by the user inside the whole origin, or inside a subset specified by you.
At this point, your service worker will observe the following lifecycle:
The service worker is immediately downloaded when a user first accesses a service worker–controlled site/page.
After that, it is updated when:
Installation is attempted when the downloaded file is found to be new — either different to an existing service worker (byte-wise compared), or the first service worker encountered for this page/site.
If this is the first time a service worker has been made available, installation is attempted, then after a successful installation, it is activated.
If there is an existing service worker available, the new version is installed in the background, but not yet activated — at this point it is called the
worker in waiting
. It is only activated when there are no longer any pages loaded that are still using the old service worker. As soon as there are no more pages to be loaded, the new service worker activates (becoming the
active worker
). Activation can happen sooner using
ServiceWorkerGlobalScope.skipWaiting()
and existing pages can be claimed by the active worker using
Clients.claim()
.
You can listen for the
安装
event; a standard action is to prepare your service worker for usage when this fires, for example by creating a cache using the built in storage API, and placing assets inside it that you'll want for running your app offline.
There is also an
activate
event. The point where this event fires is generally a good time to clean up old caches and other things associated with the previous version of your service worker.
Your service worker can respond to requests using the
FetchEvent
event. You can modify the response to these requests in any way you want, using the
FetchEvent.respondWith()
方法。
注意
: Because
安装
/
activate
events could take a while to complete, the service worker spec provides a
waitUntil()
method. Once it is called on
安装
or
activate
events with a promise, functional events such as
fetch
and
push
will wait until the promise is successfully resolved.
For a complete tutorial to show how to build up your first basic example, read 使用服务工作者 .
Service workers are also intended to be used for such things as:
In the future, service workers will be able to do a number of other useful things for the web platform that will bring it closer towards native app viability. Interestingly, other specifications can and will start to make use of the service worker context, for example:
缓存
Request
/
响应
object pairs that are cached as part of the
ServiceWorker
life cycle.
CacheStorage
缓存
objects. It provides a master directory of all the named caches that a
ServiceWorker
can access, and maintains a mapping of string names to corresponding
缓存
对象。
Client
SharedWorker
, which is controlled by an active worker.
Clients
Client
objects; the main way to access the active service worker clients at the current origin.
ExtendableEvent
安装
and
activate
events dispatched on the
ServiceWorkerGlobalScope
, as part of the service worker lifecycle. This ensures that any functional events (like
FetchEvent
) are not dispatched to the
ServiceWorker
, until it upgrades database schemas, and deletes outdated cache entries, etc.
ExtendableMessageEvent
message
event fired on a service worker (when a channel message is received on the
ServiceWorkerGlobalScope
from another context) — extends the lifetime of such events.
FetchEvent
ServiceWorkerGlobalScope.onfetch
handler,
FetchEvent
represents a fetch action that is dispatched on the
ServiceWorkerGlobalScope
的
ServiceWorker
. It contains information about the request and resulting response, and provides the
FetchEvent.respondWith()
method, which allows us to provide an arbitrary response back to the controlled page.
InstallEvent
oninstall
handler, the
InstallEvent
interface represents an install action that is dispatched on the
ServiceWorkerGlobalScope
的
ServiceWorker
. As a child of
ExtendableEvent
, it ensures that functional events such as
FetchEvent
are not dispatched during installation.
NavigationPreloadManager
Provides methods for managing the preloading of resources with a service worker.
Navigator.serviceWorker
ServiceWorkerContainer
object, which provides access to registration, removal, upgrade, and communication with the
ServiceWorker
objects for the
associated document
.
NotificationEvent
onnotificationclick
handler, the
NotificationEvent
interface represents a notification click event that is dispatched on the
ServiceWorkerGlobalScope
的
ServiceWorker
.
ServiceWorker
ServiceWorker
对象。
ServiceWorkerContainer
Provides an object representing the service worker as an overall unit in the network ecosystem, including facilities to register, unregister, and update service workers, and access the state of service workers and their registrations.
ServiceWorkerGlobalScope
Represents the global execution context of a service worker.
ServiceWorkerMessageEvent
ServiceWorkerGlobalScope
.
Note that this interface is deprecated in modern browsers. Service worker messages will now use the
MessageEvent
interface, for consistency with other web messaging features.
ServiceWorkerRegistration
Represents a service worker registration.
ServiceWorkerState
ServiceWorker
的状态。
SyncEvent
The SyncEvent interface represents a sync action that is dispatched on the
ServiceWorkerGlobalScope
of a ServiceWorker.
SyncManager
Provides an interface for registering and listing sync registrations.
WindowClient
Client
object, with some additional methods and properties available.
| 规范 | 状态 | 注释 |
|---|---|---|
| 服务工作者 | 工作草案 | 初始定义。 |
缓存
CacheStorage
Client
Clients
ExtendableEvent
FetchEvent
InstallEvent
Navigator.serviceWorker
NotificationEvent
PeriodicSyncEvent
PeriodicSyncManager
PeriodicSyncRegistration
ServiceWorker
ServiceWorkerContainer
ServiceWorkerGlobalScope
ServiceWorkerRegistration
SyncEvent
SyncManager
SyncRegistration
WindowClient