没什么问题,符合我们的期望值

页面失活时

接下来我们,切换到其他浏览器标签,保持几分钟,几分钟后我们看下打印数据

明显发现有些数据不符合我们的期望值

甚至有些夸张到长达 41003ms,将近 40 倍,不靠谱!

寻找方案用 setTimeout 模拟 setInterval

其实网上最多的方案就是说用 setTimeout 模拟 setInterval

但是很可惜,笔者亲自模拟下来,也是同样的结果,我们看截图

而且发现更加不靠谱了...错误的概率明显更高了...

其实可想而知,setInterval 和 setTimeout 在事件循环中都属于 Task

事件循环的优先级是一样的,同样都属于主线程任务(标记起来,后面考重点)

Web Worker

其实网上还有类似于 requestAnimationFrame 的方案

但是测试下来更离谱,就不浪费彦祖们的时间了

进入正题吧

其实上文说了,主线程任务的优先级会被降低,那么我们思考一下子线程任务呢?

子线程任务在前端领域,我们不就能想到 Web Worker 吗?

当然除了 Web Worker,还有 SharedWorker Service Worker

非本文重点,不做赘述

什么是 Web Worker

首先我们来认识下什么是 Web Worker

Web Worker 是一种运行在浏览器后台的独立 JavaScript 线程，允许我们在不阻塞主线程（即不影响页面 UI 和用户交互的情况下）执行一些耗时的任务，比如数据处理、文件操作、复杂计算等。

不阻塞主线程这恰恰是我们的所需要的!

使用 Web Worker

其实 Web Worker 在常规使用和 vue 中还是有一定的区别的

常规使用

常规使用其实非常简单,我们还是以上文中的 demo 为例

改造一下

const worker = new Worker('./worker.js');

我们还需要一个 worker.js文件

let prev = performance.now()
setInterval(() => {
  const offset = performance.now() - prev
  prev = performance.now()
  console.log('__SY__ ~ setInterval ~ offset:', offset)
}, 1000)

切换 tab 几分钟后让我们来看看打印结果

非常完美,几乎都保持在 1000ms 左右

在 vue 中使用 Web Worker

在 vue 中使用就和常规使用有所不同了

这也是笔者今天踩坑比较多的地方

网上很多文中配置了 webpack 的 worker-loader,然后改造 vue.config.js

但是笔者多次尝试,还是各种报错(如果有大佬踩过坑,请在评论区留言)

最后笔者翻到了之前的笔记,其实早在多年之前就记录了在 vue 中使用 Web Worker 的文章

使用方式非常简单

我们只需要把 worker.js 放置于 public 目录即可!

看下我们此时的代码

// 此处注意要访问 根路径 /
const myWorker = new Worker('/worker.js')

let prev = performance.now()
setInterval(() => {
  const offset = performance.now() - prev
  prev = performance.now()
  console.log('__SY__ ~ setInterval ~ offset:', offset)
}, 1000)

测试一下

非常完美!

解决业务问题

彦祖们此时可能要问道,你只是证明了 Web Worker 不会阻塞主进程

和你的业务有什么关系吗?

其实这还得依赖于Web Worker的通信机制

我们继续改造

const myWorker = new Worker('/worker.js')
myWorker.postMessage('createPingInterval') //向 worker 发送开启定时器的指令
// 接收 Web Worker 的执行指令,执行对应业务
myWorker.onmessage = function (event) {
  console.log('__SY__ ~ event:', event)
}

// 接收到主进程 `开启定时器的指令` 处理定时器逻辑
self.onmessage = function(event) {
  const interval = setInterval(() => {
    self.postMessage('executor') // 定时向主进程发送定时器执行指令
  }, 1000)
}

封装一个 setWorkerInterval

其实有了以上的代码模型,我们就能封装一个不受主进程阻塞的定时器了

我们暂且命名它为 setWorkerInterval

函数设计

首先设计一下我们的函数

为了减少开发者心智负担

我们需要把函数设计成和 setInterval 一样的用法

我们在使用 setInterval 的时候,日常最常用的参数就是 callback 和 delay

它的返回值是一个 intervalID

由此可见我们的函数签名如下

function setWorkerInterval(callback,delay){
    const intervalID = xxx(callback,delay) // 定时执行
    return intervalID
}

动手实现

有了上面的函数设计,我们就开始来实现

目前我们遇到一个问题,那就是上文中的 xxx 具体是个啥?

这其实就是 Web Worker 中的 setInterval

我们只需要把 Web Worker 中的 setInterval的功能暴露给主线程不就完事了吗?

来看 代码

export default function(callback, delay) {
  //创建一个 worker
  const worker = new Worker('/worker.js')
  worker.postMessage('') // 开启定时器
  // 接收 Web Worker 的消息
  worker.onmessage = function(event) {
    // 收到 worker 的 setInterval 触发,触发对应业务逻辑
  }
}

// 处理定时器逻辑
self.onmessage = function(event) {
  const interval = setInterval(() => {
    self.postMessage({}) // 定时通知主线程,即上文中的 xxx
  }, 1000)
}

这样我们就初步完成了以上 xxx 的逻辑

但随之而来又有两个问题

1.如何触发对应业务逻辑?

2.如何清除定时器?

触发对应业务逻辑

其实第一个问题非常容易解决,我们不是传递了一个 callback 吗?

这不就是我们的业务逻辑吗

改造一下

export default function(callback, delay) {
  const worker = new Worker('/worker.js')
  worker.postMessage('') // 开启定时器
  // 接收 Web Worker 的消息
  worker.onmessage = function(event) {
    callback() // 定时执行业务 callback
  }
}

清除定时器

这个问题还是踩了坑的,刚开始以为 intervalID 的来源不就在 worker.js吗?

那我们只需要把它通知给主线程即可,后来发现不可行,主线程的 clearInteravl 对于 worker 的 intervalID 并不生效...

那我们换个思路,在主线程发送一个 clear 指令不就行了吗? 说干就干,思路有了,直接看代码

// 处理定时器逻辑
self.onmessage = function(event) {
  const intervalID = setInterval(() => {
    self.postMessage({}) // 定时通知主线程,即上文中的 xxx
  }, 1000)
  /// 收到clear消息后, 清除定时器
  if (event.data === 'clear') {
    clearInterval(intervalID)
  }
}

export default function(callback, delay) {
  const worker = new Worker('/worker.js');
  // 因为 onmessage 是异步的, 所以我们要抛出一个 promise
  return new Promise((resolve) => {
    worker.postMessage('') // 开启定时器
    // 接收 Web Worker 的消息
    worker.onmessage = function(event) {
      callback() // 执行业务逻辑
    }
  })
  const clear = () => {worker.postMessage('clear')}
  return clear // 返回一个函数, 用于关闭定时器
}

让我们看下使用方式

let prev = performance.now()
const clear = setWorkerInteraval(function(){
  const offset = performance.now() - prev
  console.log('__SY__ ~ setWorkerInteraval ~ offset:', offset)
  prev = performance.now()
},1000)
setTimeout(clear,5000) // 5000ms 后清除

以上代码看似没问题,但是使用下来并不生效,也就是定时器并未被清除

问题出在哪里呢?

其实我们在发送 clear 指令的时候,也会进入 self.onmessage 函数

那么此时又会新建一个 interval,而我们清空的只是当前 interval 而已

那么我们必须想个方法,使得 interval 在当前实例是唯一的

其实非常简单,借助于 JS 万物皆对象 的思想,我们的 self 不也是一个对象吗?

那我们在它上面挂载一个 interval 有何不可呢?说干就干

// 处理定时器逻辑
self.onmessage = function (event) {
  // 返回一个非零值 所以我们可以大胆使用 ||=
  self.intervalID ||= setInterval(() => {
    self.postMessage({}) // 定时通知主线程,即上文中的 xxx
  }, 1000)
  /// 收到clear消息后, 清除定时器
  if (event.data === 'clear') {
    clearInterval(self.intervalID)
  }
}

测试后,非常完美,至此,一个靠谱的定时器我们就完成了!

当然我们还可以把上文中的 1000ms 改成 delay 传参,直接看完成代码吧

完整代码

// 处理定时器逻辑
self.onmessage = function (event) {
  /// 收到clear消息后, 清除定时器
  if (event.data === 'clear') {
    clearInterval(self.intervalID)
  } else {
    const delay = event.data
    self.intervalID ||= setInterval(() => {
      self.postMessage({}) // 定时通知主线程,即上文中的 xxx
    }, delay)
  }
}

export default function(callback, delay) {
  const worker = new Worker('/worker.js');
    worker.postMessage(delay) // 传递 delay 延时参数
    // 接收 Web Worker 的消息
    worker.onmessage = function(event) {
      callback() // 执行业务逻辑
    }
  const clear = () => {worker.postMessage('clear')}
  return clear
}

写在最后

技术服务于业务,但最怕局限于业务

希望彦祖们在开发业务中,能获取更多更深层次的思考和能力!共勉✨

感谢彦祖们的阅读

个人能力有限

如有不对，欢迎指正如有帮助，建议小心心大拇指三连

彩蛋

宁波团队还有一个资深前端hc， 带你实现海鲜自由。 欢迎彦祖们私信