JS `BroadcastChannel` 结合 `Web Locks API` 实现跨标签页的精确状态同步

各位观众，早上好！欢迎来到今天的“跨标签页状态同步，精确到像素”研讨会。今天咱们不聊虚的，直接上硬菜，看看如何用 BroadcastChannel 和 Web Locks API 这两个小家伙，把各个标签页的状态同步玩出新花样。

一、为什么我们需要跨标签页状态同步？

想象一下：你在一个标签页里编辑文档，啪啪啪敲了一堆字，结果手贱关掉了。然后你又在另一个标签页打开同一个文档，发现刚刚敲的字全没了！是不是想砸电脑？这就是跨标签页状态同步没做好的后果。

更实际的例子：

• 多人协作: 多个标签页同时编辑同一份文档，需要实时同步每个人的修改。
• 单点登录: 用户在一个标签页登录后，其他标签页自动登录。
• 任务调度: 一个标签页负责执行任务，完成后通知其他标签页。
• 防止重复操作: 例如，防止用户在多个标签页重复提交订单。

总之，跨标签页状态同步的需求无处不在，尤其是在现代 Web 应用中。

二、BroadcastChannel: 广播员，但有点“聋”

BroadcastChannel 就像一个广播电台，一个标签页发送消息，所有监听同一个频道的标签页都能收到。听起来很美好，但它有两个问题：

• 消息丢失: BroadcastChannel 不保证消息一定送达。如果标签页正在忙于其他事情，或者网络不稳定，消息可能会丢失。
• 无序: 消息的发送顺序和接收顺序可能不一致。

所以，BroadcastChannel 适合发送一些不那么重要，丢失了也无所谓的消息，比如： “用户头像已更新，刷新一下看看？”

代码示例：BroadcastChannel 初体验

// 发送消息的标签页
const channel = new BroadcastChannel('my-channel');
channel.postMessage({ type: 'user-avatar-updated', userId: 123 });

// 接收消息的标签页
const channel = new BroadcastChannel('my-channel');
channel.onmessage = (event) => {
  const data = event.data;
  if (data.type === 'user-avatar-updated') {
    console.log('用户头像已更新，用户ID:', data.userId);
    // 刷新头像
  }
};

// 别忘了关闭 channel ，释放资源
window.addEventListener('beforeunload', () => {
    channel.close();
});

这段代码演示了如何使用 BroadcastChannel 发送和接收消息。是不是很简单？但是，正如我前面说的，它并不靠谱。

三、Web Locks API: 锁住资源，保证独占

Web Locks API 就像一把锁，可以锁定一个资源，保证同一时刻只有一个标签页可以访问它。这玩意儿听起来就比 BroadcastChannel 靠谱多了。

Web Locks API 的主要作用是解决并发问题，防止多个标签页同时修改同一份数据，导致数据冲突。

代码示例：Web Locks API 小试牛刀

navigator.locks.request('my-resource', { mode: 'exclusive' }, async (lock) => {
  if (lock) {
    console.log('成功获取锁！');
    // 在这里安全地访问和修改资源
    try {
      // 模拟耗时操作
      await new Promise(resolve => setTimeout(resolve, 3000));
      console.log('资源访问完成！');
    } finally {
      lock.release(); // 释放锁
      console.log('锁已释放！');
    }
  } else {
    console.log('获取锁失败！');
  }
});

这段代码演示了如何使用 Web Locks API 获取锁，访问资源，然后释放锁。注意 mode: 'exclusive' 表示独占锁，同一时刻只能有一个标签页拥有锁。

四、BroadcastChannel + Web Locks API: 黄金搭档，天下无敌？

单独使用 BroadcastChannel 或 Web Locks API 都有局限性。但是，如果把它们结合起来，就能发挥出强大的威力。

我们的思路是：

1. 使用 Web Locks API 锁定需要同步的状态。
2. 修改状态后，使用 BroadcastChannel 通知其他标签页。
3. 其他标签页收到通知后，再次使用 Web Locks API 锁定状态，更新自己的状态。

这样，既能保证状态的同步，又能避免数据冲突。

代码示例：跨标签页状态同步的完整实现

const channel = new BroadcastChannel('my-state-channel');
const stateKey = 'my-shared-state';

// 获取状态
async function getState() {
  return JSON.parse(localStorage.getItem(stateKey) || '{}');
}

// 设置状态
async function setState(newState) {
  localStorage.setItem(stateKey, JSON.stringify(newState));
}

// 同步状态
async function syncState(newState) {
  return new Promise((resolve, reject) => {
    navigator.locks.request(stateKey, async (lock) => {
      if (lock) {
        try {
          await setState(newState); // 更新本地存储
          channel.postMessage({ type: 'state-updated', state: newState }); // 广播更新
          resolve();
        } finally {
          lock.release(); // 释放锁
        }
      } else {
        reject('获取锁失败');
      }
    });
  });
}

// 监听状态更新
channel.onmessage = async (event) => {
  const data = event.data;
  if (data.type === 'state-updated') {
    // 尝试获取锁并更新状态
    navigator.locks.request(stateKey, async (lock) => {
      if (lock) {
        try {
          await setState(data.state); // 更新本地存储
          console.log('状态已同步:', data.state);
          // 在这里更新 UI 或执行其他操作
        } finally {
          lock.release(); // 释放锁
        }
      } else {
        console.warn('无法获取锁，状态同步失败');
      }
    });
  }
};

// 初始化状态
async function initializeState() {
  const initialState = { count: 0 };
  await syncState(initialState);
}

// 增加计数器
async function incrementCounter() {
  const currentState = await getState();
  const newState = { ...currentState, count: currentState.count + 1 };
  await syncState(newState);
}

// 初始化
initializeState();

// 测试代码：每隔一段时间增加计数器
setInterval(incrementCounter, 5000);

// 关闭 channel
window.addEventListener('beforeunload', () => {
    channel.close();
});

这段代码实现了一个简单的计数器，可以在多个标签页之间同步计数器的值。 你可以打开多个标签页运行这段代码，观察计数器的变化。

代码解释:

• getState() 和 setState() 函数用于从 localStorage 中读取和设置状态。 localStorage 是一个简单的键值对存储，可以跨会话存储数据。
• syncState() 函数是核心函数，它使用 Web Locks API 锁定状态，更新本地存储，然后使用 BroadcastChannel 通知其他标签页。
• channel.onmessage 监听状态更新消息，收到消息后，尝试获取锁，更新本地存储，然后更新 UI。
• initializeState() 函数用于初始化状态。
• incrementCounter() 函数用于增加计数器的值。
• setInterval() 函数每隔 5 秒增加计数器的值。

五、优化和注意事项

• 状态序列化: BroadcastChannel 只能传递字符串，所以需要将状态序列化成字符串。 JSON.stringify() 和 JSON.parse() 是常用的序列化和反序列化方法。
• 错误处理: Web Locks API 可能会失败，例如，如果锁已经被其他标签页占用。 需要添加错误处理机制，例如，重试获取锁。
• 锁的超时: 可以设置锁的超时时间，防止锁被永久占用。
• 状态压缩: 如果状态比较大，可以考虑使用压缩算法，减少消息的大小。
• 节流和防抖: 如果状态更新频繁，可以考虑使用节流和防抖技术，减少消息的发送频率。
• 浏览器兼容性: BroadcastChannel 和 Web Locks API 的浏览器兼容性良好，但是仍然需要进行测试，确保在目标浏览器上正常工作。
• localStorage 的限制: localStorage 的容量有限，不适合存储大量数据。 如果需要存储大量数据，可以考虑使用 IndexedDB 或其他存储方案。
• 锁的粒度: 锁的粒度越小，并发性能越高，但是实现难度也越大。 需要根据实际情况选择合适的锁粒度。
• 死锁: 在使用多个锁时，需要注意避免死锁。 死锁是指多个标签页互相等待对方释放锁，导致所有标签页都无法继续执行。

六、更高级的用法：消息队列

为了进一步提高可靠性，我们可以引入消息队列的概念。 每个标签页维护一个消息队列，将需要同步的状态变更添加到队列中。 然后，定期从队列中取出消息，使用 Web Locks API 锁定状态，更新本地存储，然后使用 BroadcastChannel 通知其他标签页。

这种方法可以有效地解决消息丢失和无序的问题。 即使某个标签页暂时无法接收消息，消息也会保存在队列中，稍后重新发送。

七、总结

BroadcastChannel 和 Web Locks API 是两个强大的工具，可以用于实现跨标签页的状态同步。 它们各有优缺点，需要根据实际情况选择合适的组合方式。 通过合理的架构设计和优化，我们可以构建出可靠、高效的跨标签页状态同步方案。

希望今天的讲座能对你有所帮助。 谢谢大家！

附：常见问题解答

问题	回答
BroadcastChannel 和 WebSockets 的区别？	BroadcastChannel 用于同一浏览器的不同标签页之间的通信，而 WebSockets 用于浏览器和服务器之间的双向通信。 BroadcastChannel 不需要服务器，更轻量级，但是可靠性较低。 WebSockets 需要服务器，更可靠，但是实现更复杂。
如何处理 Web Locks API 的锁竞争？	可以使用重试机制，例如，在获取锁失败后，等待一段时间，然后再次尝试获取锁。 还可以使用指数退避算法，逐渐增加等待时间。 还可以使用优先级队列，根据优先级决定哪个标签页可以优先获取锁。
如何避免 localStorage 的数据冲突？	使用 Web Locks API 可以避免 localStorage 的数据冲突。 在修改 localStorage 之前，先获取锁，修改完成后，释放锁。 这样可以保证同一时刻只有一个标签页可以修改 localStorage。
如何测试跨标签页状态同步？	可以使用浏览器的开发者工具，打开多个标签页，分别运行代码，观察状态的变化。 还可以使用自动化测试工具，模拟多个标签页的操作，验证状态同步的正确性。
SharedWorker 能否替代以上方案？	SharedWorker 可以在多个标签页之间共享，也可以用于实现状态同步。 但是，SharedWorker 的生命周期更长，管理更复杂。 而且，SharedWorker 的调试也比较困难。 BroadcastChannel 和 Web Locks API 更加轻量级，更易于使用。