Як працюють сервісні воркери розширень Chrome

Коротка відповідь

Сервісний воркер Manifest V3 — обробник подій, який Chrome запускає за потреби й може завершити під час простою. Він не має DOM сторінки, а глобальні змінні зникають із завершенням процесу. Реєструйте слухачі синхронно під час обчислення модуля, завантажуйте збережені дані всередині обробників і робіть операції безпечними для повторення.

Воркер корисний для подій встановлення, команд, будильників і координації поза відкритим вікном. Це не постійний сервер UI-стану. Вікно може звертатися до сховища напряму, а контентний скрипт має володіти взаємодією з конкретним документом. Перенесення всіх операцій у воркер додає повідомлення, але не робить стан документа збереженим.

Практичні кроки реалізації

Реєструйте до асинхронної ініціалізації

Якщо реєстрація слухача відбувається після очікування параметрів, подія пробудження може прийти раніше за появу обробника. Спочатку зареєструйте його. Потім нехай кожен обробник очікує проміс ініціалізації або читає потрібні дані. Модульний воркер підтримує статичні імпорти; динамічний import() у ньому не підтримується.

Відокремте кеш від джерела істини

Кеш модуля може зменшувати повторні читання протягом життя воркера, але правильність має зберігатися з порожнім кешем. Використовуйте storage.local для сталих записів або storage.session для придатних даних сеансу браузера. Не покладайтеся на localStorage: воркер не має цього API вікна.

Передбачайте переривання

Документація Chrome описує обмеження простою й довгих завдань, які змінювалися між версіями. Вони пояснюють потребу в коротких обробниках і збереженні прогресу, але не є точним розкладом для побудови процесу. Запит мережі може відмовити, а браузер — закритися до завершення. Збережіть ідентифікатор очікуваної операції перед важливим зовнішнім ефектом та узгодьте її після відновлення воркера.

Перевірте холодний запуск

Закрийте DevTools воркера перед оцінкою простою, бо налагодження змінює його тривалість життя. Викличте функцію після бездіяльності чи перезапуску браузера та перевірте відновлення стану. Успіх теплого воркера не доводить стійкості до перезапуску. Збережені звіти LocaleStress ілюструють записи, які мають бути доступними незалежно від фонового процесу; це продуктова потреба, а не твердження про реалізацію.

Приклад реалізації

За наявності дозволу storage й оголошеної кнопки цей воркер визначає бейдж зі збережених даних при їхній зміні та запуску воркера. Лічильник не існує лише в пам’яті.

async function refreshBadge() {
  const { savedCount = 0 } = await chrome.storage.local.get("savedCount");
  const count = Number.isInteger(savedCount) && savedCount >= 0 ? savedCount : 0;
  await chrome.action.setBadgeText({ text: count ? String(count) : "" });
}

chrome.storage.onChanged.addListener((changes, area) => {
  if (area === "local" && "savedCount" in changes) {
    void refreshBadge().catch(console.error);
  }
});

chrome.runtime.onInstalled.addListener(() => {
  void refreshBadge().catch(console.error);
});

void refreshBadge().catch(console.error);

Це приклад похідного відображення, а не транзакційного лічильника. Якщо кілька викликів змінюють savedCount, послідовність читання й збільшення може втратити оновлення. Призначте одного власника записів або зберігайте окремо ідентифіковані записи й обчислюйте кількість. Повторні записи бейджа безпечні, тому відновлення простіше за збереження ще одного стану бейджа.

Компроміси та альтернативи

Для роботи, до якої потрібно повернутися пізніше, використовуйте будильники й допускайте затримку. Для видимого користувачеві завдання з DOM використовуйте сторінку розширення. Позaекранний документ — спеціальна можливість із власними причинами й обмеженнями, а не універсальна заміна старої постійної фонової сторінки.

Порт підтримує повторні повідомлення, але його відкриття не є універсальним способом утримувати воркер активним. Життєвий цикл залежить від версії; вибирайте документовану мінімальну версію, якщо покладаєтеся на конкретну зміну. Віддавайте перевагу коротким відновлюваним операціям замість штучної періодичної активності.

Поширені помилки

• Реєструвати слухачі лише після завершення промісу мережі чи сховища.
• Вважати глобальні змінні або setInterval збереженим станом чи надійним планувальником.
• Читати DOM API через імпорти воркера.
• Перевіряти простій із відкритими DevTools воркера.
• Перезаписувати вподобання при кожному оновленні замість міграції відсутніх полів.

Контрольний список випуску

• ☐ Слухачі реєструються під час обчислення модуля.
• ☐ Кожна важлива операція працює з порожніми глобальними змінними.
• ☐ Помилки сховища й відхилені проміси обробляються.
• ☐ Зовнішні ефекти мають правила переривання та повторення.
• ☐ Холодний запуск перевіряється без відкритого налагодження воркера.
• ☐ Припущення про версії API записані поруч із мінімальною версією браузера.

Поширені запитання

Чи живе воркер після закриття вікна?

Воркер має окремий життєвий цикл, але це не гарантує завершення довільної роботи. Зберігайте важливий прогрес і надайте спосіб відновлення.

Чи всі виклики сховища мають іти через воркер?

Лише якщо цього потребують централізований дозвіл або відповідальність за записи. Сторінки розширення можуть використовувати сховище напряму.

Що спершу змінювати в ненадійному воркері?

Перенесіть слухачі на верхній рівень, приберіть залежність правильності від глобальних змінних і відтворіть операцію з холодного запуску. Це виправляє життєвий цикл до додавання нової бібліотеки керування станом.

Первинні джерела

• Основи сервісного воркера
• Життєвий цикл воркера
• Події воркера
• API сховища

Пов’язані посібники та приклади

• Тематичний розділ
• Як створити розширення Chrome з Manifest V3
• Структура проєкту розширення Chrome, що масштабується
• Як написати файл manifest.json для Manifest V3
• Необов’язкова локальна історія звітів LocaleStress