浏览器扩展后台脚本：迎接 JavaScript Service Worker 迁移

浏览器扩展开发的格局在不断演变。最近最重要的变化之一是从传统的持久性后台页面转向使用 JavaScript Service Worker 作为后台脚本。这一迁移主要由基于 Chromium 的浏览器中的 Manifest V3 (MV3) 驱动，带来了诸多好处，但也给开发者带来了独特的挑战。本综合指南将深入探讨这一变化背后的原因、优缺点以及迁移过程的详细步骤，确保您的扩展能够顺利过渡。

为什么要迁移到 Service Worker？

这一转变的主要动机是提高浏览器的性能和安全性。在 Manifest V2 (MV2) 中常见的持久性后台页面，即使在空闲时也会消耗大量资源，影响电池寿命和浏览器的整体响应速度。而 Service Worker 则是事件驱动的，只在需要时才会被激活。

Service Worker 的优点：

• 提升性能： Service Worker 仅在事件触发时（例如 API 调用或来自扩展其他部分的消息）才会被激活。这种“事件驱动”的特性减少了资源消耗，提高了浏览器性能。
• 增强安全性： Service Worker 在一个更受限制的环境中运行，减少了攻击面，提高了扩展的整体安全性。
• 面向未来： 大多数主流浏览器都正在转向使用 Service Worker 作为扩展中后台处理的标准。立即迁移可确保您的扩展保持兼容，并避免未来的弃用问题。
• 非阻塞操作： Service Worker 被设计用于在后台执行任务而不会阻塞主线程，从而确保更流畅的用户体验。

缺点与挑战：

• 学习曲线： Service Worker 引入了一种新的编程模型，对于习惯了持久性后台页面的开发者来说可能具有挑战性。其事件驱动的特性需要一种不同的方法来管理状态和通信。
• 持久状态管理： 在 Service Worker 的多次激活之间维护持久状态需要仔细考虑。像 Storage API 或 IndexedDB 这样的技术变得至关重要。
• 调试复杂性： 由于其间歇性的特性，调试 Service Worker 可能比调试传统的后台页面更复杂。
• 对 DOM 的访问受限： Service Worker 无法直接访问 DOM。它们必须与内容脚本通信才能与网页交互。

理解核心概念

在深入了解迁移过程之前，掌握 Service Worker 背后的基本概念至关重要：

生命周期管理

Service Worker 有一个独特的生命周期，包括以下几个阶段：

• 安装 (Installation)： 当扩展首次加载或更新时，Service Worker 会被安装。这是缓存静态资源和执行初始设置任务的理想时机。
• 激活 (Activation)： 安装后，Service Worker 被激活。此时它可以开始处理事件。
• 空闲 (Idle)： Service Worker 保持空闲状态，等待事件来触发它。
• 终止 (Termination)： 当不再需要 Service Worker 时，它将被终止。

事件驱动架构

Service Worker 是事件驱动的，这意味着它们只在响应特定事件时执行代码。常见的事件包括：

• install: 当 Service Worker 安装时触发。
• activate: 当 Service Worker 激活时触发。
• fetch: 当浏览器发出网络请求时触发。
• message: 当 Service Worker 从扩展的其他部分接收到消息时触发。

进程间通信

Service Worker 需要一种与扩展的其他部分（如内容脚本和弹出脚本）进行通信的方式。这通常通过使用 chrome.runtime.sendMessage 和 chrome.runtime.onMessage API 来实现。

分步迁移指南

让我们逐步完成将一个典型的浏览器扩展从持久性后台页面迁移到 Service Worker 的过程。

步骤 1：更新您的清单文件 (manifest.json)

第一步是更新您的 manifest.json 文件，以反映向 Service Worker 的转变。删除 "background" 字段，并用包含 "service_worker" 属性的 "background" 字段替换它。

示例 Manifest V2 (持久性后台页面)：

{
  "manifest_version": 2,
  "name": "My Extension",
  "version": "1.0",
  "background": {
    "scripts": ["background.js"],
    "persistent": true
  },
  "permissions": [
    "storage",
    "activeTab"
  ]
}

示例 Manifest V3 (Service Worker)：

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0",
  "background": {
    "service_worker": "background.js"
  },
  "permissions": [
    "storage",
    "activeTab"
  ]
}

重要注意事项：

• 确保您的 manifest_version 设置为 3。
• "service_worker" 属性指定了您的 Service Worker 脚本的路径。

步骤 2：重构您的后台脚本 (background.js)

这是迁移过程中最关键的一步。您需要重构您的后台脚本，以适应 Service Worker 的事件驱动特性。

1. 移除持久性状态变量

在 MV2 的后台页面中，您可以依赖全局变量来维持不同事件之间的状态。然而，Service Worker 在空闲时会被终止，因此全局变量对于持久性状态是不可靠的。

示例 (MV2)：

var counter = 0;

chrome.browserAction.onClicked.addListener(function(tab) {
  counter++;
  console.log("Counter: " + counter);
});

解决方案：使用 Storage API 或 IndexedDB

Storage API (chrome.storage.local 或 chrome.storage.sync) 允许您持久地存储和检索数据。对于更复杂的数据结构，IndexedDB 是另一个选择。

示例 (MV3 与 Storage API)：

chrome.browserAction.onClicked.addListener(function(tab) {
  chrome.storage.local.get(['counter'], function(result) {
    var counter = result.counter || 0;
    counter++;
    chrome.storage.local.set({counter: counter}, function() {
      console.log("Counter: " + counter);
    });
  });
});

示例 (MV3 与 IndexedDB)：

// Function to open the IndexedDB database
function openDatabase() {
  return new Promise((resolve, reject) => {
    const request = indexedDB.open('myDatabase', 1);

    request.onerror = (event) => {
      reject('Error opening database');
    };

    request.onsuccess = (event) => {
      resolve(event.target.result);
    };

    request.onupgradeneeded = (event) => {
      const db = event.target.result;
      db.createObjectStore('myObjectStore', { keyPath: 'id' });
    };
  });
}

// Function to get data from IndexedDB
function getData(db, id) {
  return new Promise((resolve, reject) => {
    const transaction = db.transaction(['myObjectStore'], 'readonly');
    const objectStore = transaction.objectStore('myObjectStore');
    const request = objectStore.get(id);

    request.onerror = (event) => {
      reject('Error getting data');
    };

    request.onsuccess = (event) => {
      resolve(request.result);
    };
  });
}

// Function to put data into IndexedDB
function putData(db, data) {
  return new Promise((resolve, reject) => {
    const transaction = db.transaction(['myObjectStore'], 'readwrite');
    const objectStore = transaction.objectStore('myObjectStore');
    const request = objectStore.put(data);

    request.onerror = (event) => {
      reject('Error putting data');
    };

    request.onsuccess = (event) => {
      resolve();
    };
  });
}

chrome.browserAction.onClicked.addListener(async (tab) => {
  try {
    const db = await openDatabase();
    let counterData = await getData(db, 'counter');
    let counter = counterData ? counterData.value : 0;

    counter++;

    await putData(db, { id: 'counter', value: counter });
    db.close();
    console.log("Counter: " + counter);

  } catch (error) {
    console.error("IndexedDB Error: ", error);
  }
});

2. 用消息传递取代事件监听器

如果您的后台脚本与内容脚本或扩展的其他部分进行通信，您将需要使用消息传递。

示例 (从后台脚本向内容脚本发送消息)：

chrome.runtime.onMessage.addListener(
  function(request, sender, sendResponse) {
    if (request.message === "get_data") {
      // Do something to retrieve data
      let data = "Example Data";
      sendResponse({data: data});
    }
  }
);

示例 (从内容脚本向后台脚本发送消息)：

chrome.runtime.sendMessage({message: "get_data"}, function(response) {
  console.log("Received data: " + response.data);
});

3. 在 `install` 事件中处理初始化任务

install 事件在 Service Worker 首次安装或更新时触发。这是执行初始化任务（如创建数据库或缓存静态资源）的绝佳位置。

示例：

chrome.runtime.onInstalled.addListener(function() {
  console.log("Service Worker installed.");
  // Perform initialization tasks here
  chrome.storage.local.set({initialized: true});
});

4. 考虑 Offscreen Documents (离屏文档)

Manifest V3 引入了离屏文档来处理以前在后台页面中需要 DOM 访问的任务，例如音频播放或剪贴板交互。这些文档在独立的上下文中运行，但可以代表 Service Worker 与 DOM 交互。

如果您的扩展需要大量操作 DOM 或执行使用消息传递和内容脚本不易实现的任务，离屏文档可能是正确的解决方案。

示例 (创建离屏文档)：

// In your background script:
async function createOffscreen() {
  if (await chrome.offscreen.hasDocument({
    reasons: [chrome.offscreen.Reason.WORKER],
    justification: 'reason for needing the document'
  })) {
    return;
  }
  await chrome.offscreen.createDocument({
    url: 'offscreen.html',
    reasons: [chrome.offscreen.Reason.WORKER],
    justification: 'reason for needing the document'
  });
}

chrome.runtime.onStartup.addListener(createOffscreen);
chrome.runtime.onInstalled.addListener(createOffscreen);

示例 (offscreen.html)：

<!DOCTYPE html>
<html>
<head>
  <title>Offscreen Document</title>
</head>
<body>
  <script src="offscreen.js"></script>
</body>
</html>

示例 (offscreen.js，在离屏文档中运行)：

// Listen for messages from the service worker
chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
  if (request.action === 'doSomething') {
    // Do something with the DOM here
    document.body.textContent = 'Action performed!';
    sendResponse({ result: 'success' });
  }
});

步骤 3：彻底测试您的扩展

在重构您的后台脚本之后，彻底测试您的扩展以确保它在新的 Service Worker 环境中正常运行是至关重要的。请密切关注以下领域：

• 状态管理： 验证您的持久性状态是否使用 Storage API 或 IndexedDB 正确存储和检索。
• 消息传递： 确保消息在后台脚本、内容脚本和弹出脚本之间正确发送和接收。
• 事件处理： 测试所有事件监听器，确保它们按预期触发。
• 性能： 监控您的扩展的性能，确保它没有消耗过多资源。

步骤 4：调试 Service Worker

由于其间歇性的特性，调试 Service Worker 可能具有挑战性。以下是一些帮助您调试 Service Worker 的技巧：

• Chrome DevTools： 使用 Chrome DevTools 检查 Service Worker、查看控制台日志和设置断点。您可以在“Application”选项卡下找到 Service Worker。
• 持久化控制台日志： 自由使用 console.log 语句来跟踪您的 Service Worker 的执行流程。
• 断点： 在您的 Service Worker 代码中设置断点以暂停执行并检查变量。
• Service Worker 检查器： 使用 Chrome DevTools 中的 Service Worker 检查器来查看 Service Worker 的状态、事件和网络请求。

Service Worker 迁移的最佳实践

以下是迁移您的浏览器扩展到 Service Worker 时应遵循的一些最佳实践：

• 尽早开始： 不要等到最后一刻才迁移到 Service Worker。尽快开始迁移过程，给自己充足的时间来重构代码和测试扩展。
• 分解任务： 将迁移过程分解为更小、更易于管理的任务。这将使过程不那么令人生畏，也更容易跟踪。
• 频繁测试： 在整个迁移过程中频繁测试您的扩展，以便及早发现错误。
• 使用 Storage API 或 IndexedDB 进行持久状态管理： 不要依赖全局变量来存储持久状态。应使用 Storage API 或 IndexedDB。
• 使用消息传递进行通信： 使用消息传递在后台脚本、内容脚本和弹出脚本之间进行通信。
• 优化您的代码： 优化您的代码以提高性能，最大限度地减少资源消耗。
• 考虑使用离屏文档： 如果您需要大量操作 DOM，请考虑使用离屏文档。

国际化注意事项

为全球用户开发浏览器扩展时，考虑国际化 (i18n) 和本地化 (l10n) 至关重要。以下是一些确保您的扩展能够被全球用户访问的技巧：

• 使用 _locales 文件夹： 将您的扩展的翻译字符串存储在 _locales 文件夹中。该文件夹包含每个支持语言的子文件夹，其中有一个包含翻译的 messages.json 文件。
• 使用 __MSG_messageName__ 语法： 在您的代码和清单文件中使用 __MSG_messageName__ 语法来引用您的翻译字符串。
• 支持从右到左 (RTL) 的语言： 确保您的扩展的布局和样式能够正确适应像阿拉伯语和希伯来语这样的 RTL 语言。
• 考虑日期和时间格式： 为每个地区使用适当的日期和时间格式。
• 提供文化相关的内容： 调整您的扩展内容，使其与不同地区的文化相关。

示例 (_locales/en/messages.json)：

{
  "extensionName": {
    "message": "My Extension",
    "description": "The name of the extension"
  },
  "buttonText": {
    "message": "Click Me",
    "description": "The text for the button"
  }
}

示例 (在代码中引用翻译字符串)：

document.getElementById('myButton').textContent = chrome.i18n.getMessage("buttonText");

结论

将您的浏览器扩展的后台脚本迁移到 JavaScript Service Worker 是朝着提高性能、安全性和未来保障迈出的重要一步。虽然这一转变可能会带来一些挑战，但其好处是值得的。通过遵循本指南中概述的步骤并采纳最佳实践，您可以确保迁移过程顺利成功，为全球用户提供更好的体验。请记住要进行彻底测试，并适应新的事件驱动架构，以充分利用 Service Worker 的强大功能。

更多资源

• Chrome 扩展 Manifest V3 文档
• Mozilla Service Worker API 文档
• Service Worker 基础知识