Жизненный цикл работника службы расширения

Работники служб расширения реагируют как на стандартные события рабочих служб , так и на события в пространствах имён расширений. Они представлены вместе, поскольку часто один тип следует за другим при использовании расширения.

Установка

Установка происходит, когда пользователь устанавливает или обновляет Service Worker из Chrome Web Store или загружает или обновляет распакованное расширение со страницы chrome://extensions . Происходят три события в следующем порядке:

  1. install
  2. onInstall
  3. activate

ServiceWorkerRegistration.install

Первое событие, которое запускается во время установки, — это событие установки работника веб-службы.

chrome.runtime.onInstalled

Далее следует событие расширения onInstalled , которое срабатывает при первой установке расширения (не сервис-воркера), при обновлении расширения до новой версии и при обновлении Chrome до новой версии. Используйте это событие для установки состояния или для однократной инициализации, например, контекстного меню .

chrome.runtime.onInstalled.addListener((details) => {
  if(details.reason !== "install" && details.reason !== "update") return;
  chrome.contextMenus.create({
    "id": "sampleContextMenu",
    "title": "Sample Context Menu",
    "contexts": ["selection"]
  });
});

ServiceWorkerRegistration.active

Наконец, срабатывает событие активации сервис-воркера. Обратите внимание, что в отличие от веб-воркеров сервисов, это событие срабатывает сразу после установки расширения, поскольку в расширении нет ничего, что можно было бы сравнить с перезагрузкой страницы.

Запуск расширения

При запуске профиля пользователя срабатывает событие chrome.runtime.onStartup , но никакие события Service Worker не вызываются.

Простой и выключенный

Обычно Chrome завершает работу Service Worker при выполнении одного из следующих условий:

  • Через 30 секунд бездействия. Получение события или вызов API расширения сбрасывает этот таймер.
  • Когда обработка одного запроса, например события или вызова API, занимает более 5 минут.
  • Когда ответ fetch() приходит более чем через 30 секунд.

События и вызовы API расширений сбрасывают эти таймеры, и если сервис-воркер находится в состоянии покоя, входящее событие активирует их. Тем не менее, вам следует проектировать сервис-воркер таким образом, чтобы он был устойчив к неожиданному завершению работы.

Чтобы оптимизировать потребление ресурсов вашим расширением, по возможности не оставляйте Service Worker активным бесконечно. Протестируйте свои расширения, чтобы убедиться, что вы не делаете этого намеренно.

Сохраняйте данные вместо использования глобальных переменных

Все заданные вами глобальные переменные будут потеряны при завершении работы сервис-воркера. Вместо использования глобальных переменных сохраняйте значения в хранилище. Доступные варианты перечислены ниже.

API chrome.storage
API расширения, предлагающий различные типы хранения: локальное, сеансовое, управляемое (доменное) и синхронизированное. Этот API хранит JSON-объекты, идентифицированные и извлеченные с помощью ключей, определенных разработчиком. Этот тип хранилища не удаляется при очистке веб-кэша пользователем.
API IndexedDB
Низкоуровневый API для хранения структурированных данных на стороне клиента, включая файлы и BLOB-объекты. Этот API предоставляет примитивы для создания транзакционного хранилища и извлечения данных. Хотя этот API часто слишком сложен для некоторых сценариев использования, на его основе построен ряд сторонних решений для хранения данных.
API CacheStorage
Механизм постоянного хранения пар объектов «Запрос» и «Ответ». Этот API был разработан специально для рабочих веб-сервисов и используется для извлечения данных из конечной точки. Существует множество способов использования этого API в зависимости от того, насколько важно пользователям видеть актуальные данные. Подробнее см. в The Offline Cookbook . Если вы не проксируете сетевые запросы с помощью обработчика выборки, следует использовать chrome.storage .

Выберите минимальную версию Chrome

С момента выпуска Manifest V3 мы внесли несколько улучшений в сроки жизни сервис-воркеров. Это означает, что если ваше расширение Manifest V3 поддерживает более ранние версии Chrome, вам следует учитывать некоторые условия. Если эти условия не влияют на ваше расширение, вы можете продолжить этот раздел. Если влияют, рассмотрите возможность указания минимальной версии Chrome в манифесте.

Хром 120

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

Хром 118

Активные сеансы отладчика, созданные с помощью API chrome.debugger , теперь поддерживают работу сервис-воркера. Это предотвращает тайм-аут сервис-воркеров во время вызовов этого API.

Хром 116

В Chrome 116 реализованы следующие улучшения жизненного цикла Service Worker:

  • Активные соединения WebSocket теперь продлевают время жизни расширенного сервисного работника. Отправка или получение сообщений через WebSocket в расширенном сервисном работнике сбрасывает таймер простоя сервисного работника.

  • Дополнительные API расширений могут выходить за пятиминутный интервал ожидания для работников служб расширений. Эти API выводят запрос пользователю, поэтому их разрешение может занять более пяти минут. К ним относятся desktopCapture.chooseDesktopMedia() , identity.launchWebAuthFlow() , management.uninstall() и permissions.request() .

Хром 114

Отправка долгоживущего сообщения поддерживает работу сервисного работника. Открытие порта больше не сбрасывает таймеры.

Хром 110

Вызовы API расширения сбрасывают таймеры. До этого только запущенные обработчики событий поддерживали работоспособность сервис-воркера. Любые события, поставленные в очередь, но для которых обработчик не был вызван, не приводили к сбросу таймеров.

Хром 109

Сообщения, отправленные из документа, не отображаемого на экране, сбрасывают таймеры.

Хром 105

Подключение к нативному хосту обмена сообщениями с помощью chrome.runtime.connectNative() сохранит работоспособность сервис-воркера. В случае сбоя или завершения работы хост-процесса порт закрывается, и сервис-воркер завершает работу по истечении заданного времени. Для защиты от этого вызовите chrome.runtime.connectNative() в обработчике событий onDisconnect порта.