Что вызывает сброс глобального контекста сервисного работника?

У меня есть (в идеале) безопасный объект входа в систему, который я хотел бы сохранить в контексте работника службы, но ServiceWorkerGlobalScope, похоже, сбрасывается случайным образом (Chrome 47 Ubuntu).

Для проверки в сервис-воркер вставил:

var iid = setInterval(function () {
  var now = performance.now();
  return self.clients.matchAll().then(function(clients) {
    return Promise.all(clients.map(function(client) {
      return client.postMessage({messageType: "canary", value: now})
    }))
  })
}, 1000);

И в клиенте:

navigator.serviceWorker.addEventListener("message", function(event) {
  if (event.data.messageType = "canary") console.log(event.data.value)
});

В результате на клиентской консоли появилось:

⋮
147200.06500000003
148200.08000000002
149200.09000000003
1212.9800000000002
2212.5350000000003
3212.4700000000003
⋮

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

Насколько мне известно, сервис-воркер должен быть удален из памяти в какой-то момент после того, как его объект clients больше не возвращает никаких Client. Однако вышеописанное происходит как минимум за десять секунд до любого события отмены регистрации, о котором я могу догадаться.

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


javascript service-worker
person den-chan    schedule 13.01.2016    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Из спецификации:

Время жизни сервисного работника привязано к времени жизни выполнения событий, а не к ссылкам, хранящимся у клиентов сервисного работника на объект ServiceWorker. Пользовательский агент может завершить работу сервис-воркеров в любое время, когда у него нет события для обработки, или он обнаруживает ненормальную работу, такую ​​как бесконечные циклы и задачи, превышающие установленные ограничения по времени, если таковые имеются, при обработке событий.

Таким образом, можно полагаться только на то, что сервис-воркеры сохранят свое состояние достаточно долго, чтобы обработать событие. Они определенно не живут, пока они зарегистрированы у клиентов.

каковы наилучшие методы сохранения объекта как связанного со сценарием работника службы без сериализации и, желательно, без отправки в контекст клиента?

Существует Cache API.

person Robert K. Bell    schedule 14.01.2016
comment
И IndexedDB также можно использовать, чтобы не полагаться на Cache API для сохранения пар без запроса/ответа. - person Salva; 14.01.2016
comment
Я понял, что пытался использовать состояние для чего-то, что я должен был хранить в памяти, другими словами, это был мой плохой выбор дизайна, который вызвал этот вопрос. Теперь вместо этого используйте indexedDB. - person den-chan; 21.01.2016