在当今快速发展的数字时代,用户对网页性能的期待已经达到了前所未有的高度,想象一下,当你打开一个网站,瞬间加载、流畅操作,没有任何卡顿和延迟,这种体验无疑会让你倍感惊喜。然而在前端开发中,如何实现这样的流畅体验却是一个巨大的挑战。这时,Web Worker 作为一项强大的技术,悄然崭露头角。
目录
🧐初识webworker
🤓webworker使用
😎webworker案例
🧐初识webworker
单线程和多线程概念:
1)定义:
单线程是指在一个进程中只有一个执行线程。这个线程负责处理所有的任务和操作,包括用户输入、界面更新和数据处理。
多线程是指在一个进程中可以同时存在多个执行线程。这些线程可以并行处理多个任务,提高程序的效率和响应能力。
2)应用场景:
单线程适合简单、快速开发的应用,但在处理复杂或耗时任务时可能导致性能瓶颈。
多线程则在性能和响应性方面具有优势,但同时也带来了更高的开发复杂度和潜在的安全问题。
我们知道JavaScript是单线程语言,也就是说所有任务只能在一个线程上完成,一次只能做一件事情,然而webworker的出现就是为JS创造多线程环境,允许主线程创建worker线程,将一些任务分配给后者运行,在主线程运行的同时worker线程在后台运行,两者互不干扰,如下图所示:
使用webworker可以单独的开启一个线程,线程直接通过message消息进行通信,webworker中的代码不会影响ui的响应,案例代码如下所示:
// 主线程
var worker = new Worker('work.js')
worker.onmessage = e => {console.log(e.data)
}// worker线程
// 做一些耗时的操作
self.postMessage('worker:' + result)
多线程和异步操作有什么关系:
多线程是同时运行多个线程以并行处理任务,创建独立的线程来执行js代码,可以进行计算密集型任务,而不会阻塞主线程。
异步操作是在不阻塞主线程的情况下执行某些任务,常见的异步操作包括网络请求、定时器等。
异步操作:众所周知,js一直被说不擅长计算确实,计算是同步的,大规模的计算会让js主线程阻塞,主线程阻塞的结果就是界面完全卡死一样,所以异步只是把任务发布出去等着,后面还是会拉到主线程执行的,异步不可能在异步队列自己执行,所以一个耗时很高的操作,无论你做不做异步,他始终会卡死你的页面,如下所示:
从上图我们可以看出来,假设这个耗时任务必须消耗2秒去计算,我们主线程永远不可能躲开这两秒的计算时间,只能同过切片等操作,把这两秒切分成好几个几十毫秒,一点点计算来解决卡顿的问题
线程操作:webworker是真正的多线程,开一条支线,让他计算然后把结果返回,当计算完成把结果发给主线程,如下图所示:
兼容性问题:我们可以从 caniuse网站:地址 可以看到webworker的兼容性还是不错的,现代浏览器基本上都已经支持了,除了低版本的安卓等其他老式低版本浏览器:
当然具体的webworker使用也可以参考mdn文档:地址 里面也是非常详细的介绍了其使用:
worker注意点(局限性):
1)无法访问 DOM:Web Worker 运行在独立的线程中,因此它们无法直接访问 DOM,所有与用户界面相关的操作必须在主线程中进行。
2)消息传递机制:Worker 之间以及 Worker 与主线程之间的通信是通过消息传递进行的。这意味着数据需要被序列化(例如使用 postMessage),而某些复杂对象(如函数和 DOM 元素)无法直接传递。
3)资源限制:Workers 在浏览器中有一些资源限制,比如内存使用和最大线程数。在资源紧张的情况下,浏览器可能会限制 Worker 的创建或运行。
4)调试困难:在开发过程中,调试 Web Worker 可能比较复杂,因为它们的执行环境与主线程不同,错误和日志信息可能不容易追踪。
5)没有全局作用域:Web Worker 没有全局作用域,它们只能访问 Web Workers API 和一些基本的 JavaScript 功能。这限制了可以使用的库和框架。
6)启动时间:创建 Worker 有一定的启动时间,尤其是在需要频繁创建和销毁 Worker 的场景下,这可能导致性能下降。
7)浏览器支持:尽管大多数现代浏览器都支持 Web Worker,但在某些老旧的浏览器或特定的环境中(如某些版本的移动浏览器),可能不完全支持。
虽然 Web Worker 提供了一种有效的方法来处理并行计算和长时间运行的任务,但开发者需要了解这些局限性,以便在设计应用时做出合理的权衡和选择。
🤓webworker使用
消息发送:要定义webworker可以直接新建一个普通的js文件,在其中监听onmessage事件,通过事件参数的data属性访问传递进来的消息,然后使用postMessage回传消息给主线程,注意:worker里面有一个全部变量self,类似浏览器当中的window全局变量对象,类似node当中的global局变量对象一样的作用,示例如下:
控制台打印的结果如下所示,我们可以通过e.data来获取到我们传递到主进程的数据:
通过上面代码我们完全看不出使用worker线程有什么优势,别着急,接下来我们可以看看如果想在项目中实现一段斐波那契数列,需要耗费多少时间,代码如下:
<script>var worker1 = new Worker("worker1.js");worker1.onmessage = e => {console.log(e);}function fb(n) {if (n == 1 || n == 2) {return 1;}return fb(n - 1) + fb(n - 2);}console.time('fb执行时间');var result = fb(43);console.timeEnd('fb执行时间');
</script>
从控制台可以看出,我们斐波那契数列最终的执行结果需要耗费近四千毫秒左右,而js项目由于是单线程内容,必须得等到我们斐波那契数列执行完毕才会渲染页面,也就是说我们足足等了四秒钟页面才会被加载出来:
如果有一个需求,让你在同一个组件当中执行类似上面非常耗时的斐波那契四遍,你会怎么做?不了解多线程的可能就会在同一个组件执行呗,无非多花一点时间,这里就导致了执行四遍斐波那契函数的时间出现了累加,整个页面需要足足等待4*4=16秒,这不是我们想要看到的结果,所以这里我们将耗时的代码(斐波那契递归代码)放置在worker线程当中,看看有没有什么出奇的效果,代码如下:
如下代码我们可以看到,多个斐波那契数列被同时执行了,这也就意味着一个12秒的活,我分派给三个人去做,最终所花费的时间仅仅是四秒钟而已,公司招聘多名员工进行协作开发项目也是同一个道理。
文件引入:在使用框架进行开发项目中,worker构造函数创建的webworker实例传递的url路径必须是同源的,之后才能保持返回的实例,也就是说后期我们项目如果想上线的话,我们设置的worker文件就不能是本地文件,必须将其放置在线上地址也就是我们的public文件夹下,其他文件夹都只算是本地文件,如果真正发布到服务器上去了,就可以让后端人员把我们的worker文件丢到某个静态资源下就好了,如下所示:
模块引入:Worker函数有第二个配置项的函数,其对应的可以控制模块引入的模式,如下:
🥳SharedWorker使用
SharedWorker接口代表一种特定类型的worker,可以从几个浏览上下文中访问,例如几个窗口、iframe或其他worker,它们实现一个不同于普通worker的接口,具有不同的全局作用域。
区别:SharedWorker与worker的区别在于在调用的使用SharedWorker会使用一个连字符port,用于表示在当前这个上下文中的这个worker。
因为SharedWorker会根据传递的文件路径作为唯一性判定,像下面代码我创建了十次SharedWorker,但是他们都是指向同一个文件,所以他们都会复用用一个SharedWorker,所以下面代码虽然循环了十次但是他们使用的worker是同一个的,代码如下所示:
// 主进程
<script>console.time("test")let count = 0for (var i = 0; i < 10; i++) {let worker = new SharedWorker("./share.js")worker.port.postMessage(40)worker.port.onmessage = function (e) {console.log(e.data)count++if (count === 10) console.timeEnd("test")}}
</script>// sharedworker进程
function fib(n) {return n < 2 ? 1 : fib(n - 1) + fib(n - 2);
}self.onconnect = function(e) {var port = e.ports[0];port.onmessage = function(e) {let num = e.data;let res = fib(num)port.postMessage(res);};
};
从日志当中我们可以看到其打印了10次,结果是15秒左右,这个和直接把斐波那契函数全部写在一起串行调用效果是一样的,这是因为所有的任务都是一个shareWorder来运行的:
sharedworder作用: 在不同的页面之间,只有url相同,只有挂载一个sharedworker,这个会被所有页面所共享,这个是和worder所不同的地方!
😎webworker案例
图片像素操作:在处理图片像素点的时候,如下代码所示,可能由于计算量过于庞大导致页面出现卡死的状态,用户由于一段程序的导致页面的卡死而不能操作其他页面了,如下代码就是这样的效果:
<template><input type="text"><button @click="imgHandler">过滤</button><canvas id="imgCanvas" width="1200" height="600"></canvas>
</template><script setup lang="ts">
import image from "./assets/1.jpeg"let canvas: any
let ctx: any
// 将图片画在画布上
let img = new Image()
img.src = image
img.onload = function () {canvas = document.getElementById("imgCanvas") as HTMLCanvasElementctx = canvas.getContext("2d") as CanvasRenderingContext2Dctx.drawImage(img, 0, 0, 1200, 600)
}
const imgHandler = () => {// 读取所有像素点const imageData = ctx.getImageData(0, 0, 1200, 600)const data = imageData.data// 循环每一个像素点,依次给其做计算,如果一张图有50万像素点的话,每个像素点rgba值为4个,也就是data有200多万像素点// 循环200万次for (let i = 0; i < data.length; i += 4) {// 每次循环内部在循环100次,合集20亿次for (let j = 0; j < 255; i++) {if (imageData.data[i] !== 255) {imageData.data[i] = Math.min(data[i] + j, 0)}}}// 每个像素点添加滤镜ctx.putImageData(imageData, 0, 0);
}
</script>
接下来我们把计算量庞大的代码进行抽离出去放置到worker线程当中,从而不影响主进程的使用,所以即使某段代码的耗时过大也不会影响到其他页面的使用,如下所示:
<template><input type="text"><button @click="imgHandler">过滤</button><canvas id="imgCanvas" width="1200" height="600"></canvas>
</template><script setup lang="ts">
import image from './assets/1.jpeg'let canvas: HTMLCanvasElement
let ctx: CanvasRenderingContext2D// 将图片画在画布上
let img = new Image();
img.src = image;
img.onload = function () {canvas = document.getElementById("imgCanvas") as HTMLCanvasElement;ctx = canvas.getContext("2d", { willReadFrequently: true }) as CanvasRenderingContext2D; // 设置 willReadFrequentlyctx.drawImage(img, 0, 0, 1200, 600);
}let worker = new Worker("http://127.0.0.1:5173/picwork.ts");
worker.addEventListener("message", (e: MessageEvent) => {const imageData = e.data;// 每个像素点添加滤镜ctx.putImageData(imageData, 0, 0);
});const imgHandler = () => {// 读取所有像素点const imageData = ctx.getImageData(0, 0, 1200, 600);worker.postMessage(imageData);
}
</script>
在worder线程当中我们把需要大量计算的代码放置在里面:
self.addEventListener("message", (e) => {if (e.data.data.length) {let imageData = e.datafor (let i = 0; i < imageData.data.length; i += 4) {for (let j = 0; j < 255; j++) {if (imageData.data[i] !== 255) {imageData.data[i] = Math.min(imageData[i] + j, 0)}}}self.postMessage(imageData);}
});
最终呈现的效果如下所示,可以看到图片像素的改变并没有阻塞我们主进程页面的使用:
excel表格操作:如下代码我们使用xlsx第三方库去生成一个excel表格,并往表格中添加十万条数据,这个数据量是非常庞大的,当我们点击导出的时候,可以会导致页面卡死而无法在输入框当中进行操作,代码如下所示:
<template><input type="text"><button @click="exportExcel">导出</button>
</template><script setup lang="ts">
import { writeFile, utils } from 'xlsx';
let arr = []
for (let i = 0; i < 100000; i++) {arr.push({id: i,name: '测试' + i,age: i,location: 'xx大道' + i + '号',a: i + 2,b: i + 3,c: i + 4,})
}
const exportExcel = () => {const sheet = utils.json_to_sheet(arr) // 转换为sheetconst workbook = utils.book_new() // 创建工作簿utils.book_append_sheet(workbook, sheet, 'Sheet1') // 添加到工作簿console.log(workbook)writeFile(workbook, '测试导出' + new Date().getTime() + '.xlsx') // 写入文件
}
</script>
这个时候我们就需要使用worker去把大量的写入数据放置在线程里面,在导出函数中会在按钮点击时被调用,它向 Worker 发送一个空消息,指示 Worker 开始执行生成 Excel 文件的任务:
<template><input type="text"><button @click="exportExcel">导出</button>
</template><script setup lang="ts">
import { writeFile } from 'xlsx';let worker = new Worker("http://127.0.0.1:5173/excelwork.js")
worker.onmessage = (e) => {let workbook = e.datawriteFile(workbook, 'test.xlsx')
}const exportExcel = () => {worker.postMessage('')
}
</script>
线程当中使用 self.postMessage(workbook) 将生成的工作簿发送回主线程,供主线程进一步处理如保存为文件,代码如下所示:
importScripts('./xlsx.js')
let arr = []
for (let i = 0; i < 100000; i++) {arr.push({id: i,name: '测试' + i,age: i,location: 'xx大道' + i + '号',a: i + 2,b: i + 3,c: i + 4,})
}
self.onmessage = function (e) {const sheet = XLSX.utils.json_to_sheet(arr) // 转换为sheetconst workbook = XLSX.utils.book_new() // 创建工作簿XLSX.utils.book_append_sheet(workbook, sheet, 'Sheet1') // 添加到工作簿self.postMessage(workbook)
}
主进程负责用户界面交互和文件保存,Worker 线程负责大量数据的处理和 Excel 文件的生成,使用 Web Worker 有效避免了 UI 阻塞,提高了用户体验。
还有一位博主分享了一篇关于webworker应用于three.js方向的,这个也是不错的方法:地址
总结:大部分情况下前端是用不上webworker的,但是如果你确实项目里面涉及到了非常大的计算,这就相当于前端的一个性能瓶颈了,这个时候使用webworker可能是一个不错的选择!