WebWork浅谈
- 前言:
- 都知道JS是单线程语言,最让人头疼的莫过于在网络正常的情况下经常出现页面的假死,
- 以及在进行大量的for循环计算时会导致线程阻塞,由于要进行大量的计算JS后面的运行会被阻隔在此处,使得性能较差,代码维护性差等一系列的问题发生。
- 本人也看了很多关于webwork的demo和官方的讲解,都说是官方很多都不是很容易读懂,在最近几天的学习过程我也针对这个做了些功课发现了webwork的作用非同一般!
- 先上代码:
let worker = new Worker("work.js")//此处写待处理的地址
let data = [1, 2, 3, 4, 5, 6, 7]
worker.postMessage(data);
worker.onmessage = function(event) {
console.log(event.data)
document.querySelector("ul").innerHTML = event.data
}
//此部分是work.js中
this.addEventListener("message", (data) => {
let str = render(data.data)
this.postMessage(str)
})
function render(data) {
let str = ''
data.forEach(i => {
str += `<li>${i}</li>`
});
return str
}
- 正如您所看到的,这就是一个简单的Demo:
- 但是你在之后再补一句简单的console.log(1)就能够看出结果了,
- 打开F12(传说中的开发者模式)你会惊奇的发现单线程语言居然先输出了1然后在UL中添加了节点,
- 思考?
- 照以前的写法我们肯定会这样做:
let str = "";
data.forEach(i => {
str += `<li>${i}</li>`
});
document.querySelector("ul").innerHTML = str;
- 是不是发现了其中的好处?
- 简单来说我们把一套本该同步的代码该成了异步,也就是在主线程中开辟了一条子线程,这样的好处就是不会影响主线程,线程任务的执行,具体步骤在子线程中进行,最后返回结果给主线程中,很巧妙的解决了之前上文提到的,假如在主线程中我有个任务循环了10000次(当然是开玩笑!)这时webwork是不是很巧妙的处理了这个问题呢?
结尾:
- 为什么要这么做?
随着web的发展,时代越来越讲究优化二字,能够用更加优雅的代码,更加简洁的代码去完成任务是至关重要的。
- 用户需求一直是我们开发者比较密切关心的问题,试想一下如果在某一天有个用户访问了你的网站由于你代码的到至了页面的假死的现象的发生那是一件多么可怕的事情,在深层次的探究中,每一个优秀的前端工作者都应该去努力解决这些问题。
作者寄语:刘某人,写文章不多,不喜勿喷,只是发表个人见解,如果有更好的建议希望可以互相帮助,相互学习