网站建设 金手指 排名22,一个网站2级域名多,搭建wordpress写不进去,网站开发能不能用win7系统目录
前言
引入 Web Worker
Worker 实践
Worker 到底有多难用
类库调研
有类库加持的 worker 现状
向着舒适无感的 worker 编写前进
1. 抽取依赖#xff0c;管理编译和更新#xff1a;
2. 定义公共调用函数#xff0c;引入所打包的依赖并串联流程#xff1a;
3. …目录
前言
引入 Web Worker
Worker 实践
Worker 到底有多难用
类库调研
有类库加持的 worker 现状
向着舒适无感的 worker 编写前进
1. 抽取依赖管理编译和更新
2. 定义公共调用函数引入所打包的依赖并串联流程
3. 优化语法支持
4. 其他问题
总结
参考资料 前言 Web Workers 是 2009 年就已经提案的老技术但是在很多项目中的应用相对较少常见一些文章讨论如何写 demo 但很少有工程化和项目级别的实践本文会结合 Web Workers 在京东羚珑的程序化设计项目中的实践分享一下在当下的 2023 年关于 worker 融入项目的一些思考和具体的实现方式涉及到的 demo 已经放在 github 上附在文末可供参考。 先简单介绍下 Web Workers它是一种可以运行在 Web 应用程序后台线程独立于主线程之外的技术。众所周知JavaScript 语言是单线程模型的而通过使用 Web Workers我们可以创造多线程环境从而可以发挥现代计算机的多核 CPU 能力在应对规模越来越大的 Web 程序时也有较多收益。 Web Workers 宏观语义上包含了三种不同的 WorkerDedicatedWorker(专有worker)、 SharedWorker(共享Worker)、 ServiceWorker本文讨论的是第一种其他两种大家可以自行研究一下。
引入 Web Worker
当引入新技术时通常我们会考虑的问题有 1、兼容性如何 2、使用场景在哪
问题 1Web Workers 是 2009 年的提案2012 年各大浏览器已经基本支持11 年过去了现在使用已经完全没有问题啦 问题 2主要考虑了以下 3 点 ·Worker API 的局限性同源限制、无 DOM 对象、异步通信因此适合不涉及 DOM 操作的任务 ·Worker 的使用成本创建时间 数据传输时间考虑到可以预创建可以忽略创建时间只考虑数据传输成本这里可参考 19 年的一个测试 Is postMessage slow[1] 简要结论是比较乐观的大部分设备和数据情况下速度不是瓶颈 ·任务特点需要是可并行的多任务为了充分利用多核能力可并行的任务数越接近 CPU 数量收益会越高。多线程场景的收益计算可以参考 Amdahl 公式其中 F 是初始化所需比例N 是可并行数
综上结论是可并行的计算密集型任务适合用 Worker 来做。
不过 github 上我搜罗了一圈也发现有一些不局限于此颇有创意的项目供大家打开思路 ·redux 挪到了 worker 内[2] ·dom 挪到了 worker 内[3] ·可使用多核能力的框架[4]
Worker 实践 介绍完 worker 一个问题出现了为什么一个兼容性良好能够发挥并发能力的技术听起来很有诱惑力到现在还没有大规模使用呢 我理解有 2 个原因一是暂无匹配度完美的使用场景因此引入被搁置了二是 worker api 设计得太难用参考很多 demo 看限制多配置还麻烦让人望而却步。本文会主要着力于第二点希望给大家的 worker 实践提供一些成熟的工程化思路。 至于第一点理由在如此卷的前端领域当你手中已经有了一把好用的锤子还找不到那颗需要砸的钉子吗
Worker 到底有多难用
下面是一个原始 worker 的调用示例上面是主线程文件下面是 worker 文件
// index.js
const worker new Worker(./worker.js)
worker.onmessage function (messageEvent) {console.log(messageEvent)
}// worker.js
importScripts(constant.js)
function a() {console.log(test)
}其中问题有 ·postMessage 传递消息的方式不适合现代编程模式当出现多个事件时就涉及分拆解析和解决耦合问题因此需要改造 ·新建 worker 需要单独文件因此项目内需要处理打包拆分逻辑独立出 worker 文件 ·worker 内可支持定义函数可通过importScript 方式引入依赖文件但是都独立于主线程文件依赖和函数的复用都需要改造 ·多线程环境必然涉及同步运行多个 worker多 worker 的启动、复用和管理都需要自行处理
看完这么多问题有没有感觉头很大一个设计这样原始的 api如何舒服的使用呢
类库调研 首先可以想到的就是借助成熟类库的力量下面表格是较为常见的几款 worker 类库其中我们可能会关注的关键能力有 ·通信是否有包装成更好用的方式比如 promise 化或者 rpc 化 ·是否可以动态创建函数——可以增加 worker 灵活性 ·是否包含多 worker 的管理能力也就是线程池 ·考虑 node 的使用场景是否可以跨端运行 比较之下workerpool[5] 胜出它也是个年纪很大的库了最早的代码提交在 6 年前不过实践下来没有大问题下文都会在使用它的基础上继续讨论。
有类库加持的 worker 现状 通过使用 workerpool我们可以在主线程文件内新建 worker它自动处理多 worker 的管理可以执行 worker 内定义好的函数 a可以动态创建一个函数并传入参数让 worker 来执行。
// index.js
import workerpool from workerpool
const pool workerpool.pool(./worker.js)
// 执行一个 worker 内定义好的函数
pool.exec(a, [1, 2]).then((res) {console.log(res)
})
// 执行一个自定义函数
pool.exec((x, y) {return x y}, // 自定义函数体[1, 2], // 自定义函数参数).then((res) {console.log(res)})// worker.js
importScripts(constant.js)
function a() {console.log(test)
}但是这样还不够为了可以舒适的写代码我们需要进一步改造。
向着舒适无感的 worker 编写前进
我们期望的目标是 ·足够灵活可以随意编写函数今天我想计算11明天我想计算12这些都可以动态编写最好它可以直接写在主线程我自己的文件里不需要我跑到 worker 文件里去改写 ·足够强大我可以使用公共依赖比如 lodash 或者是项目里已经定义好的某些公共函数。 考虑到 workerpool 具备了动态创建函数的能力第一点已经可以实现而第二点关于依赖的管理则需要自行搭建接下来介绍搭建步骤。
1. 抽取依赖管理编译和更新 新增一个依赖管理文件worker-depts.js可按照路径作为 key 名构建一个聚合依赖对象然后在 worker 文件内引入这份依赖
// worker-depts.js
import * as _ from lodash-es
import * as math from ../mathconst workerDepts {_,util/math: math,
}export default workerDepts// worker.js
import workerDepts from ../util/worker/worker-depts2. 定义公共调用函数引入所打包的依赖并串联流程 worker 内定义一个公共调用函数注入 worker-depts 依赖并注册在 workerpool 的方法内
// worker.js
import workerDepts from ../util/worker/worker-deptsfunction runWithDepts(fn: any, ...args: any) {var f new Function(return ( fn ).apply(null, arguments);)return f.apply(f, [workerDepts].concat(args))
}workerpool.worker({runWithDepts,
})主线程文件内定义相应的调用方法入参是自定义函数体和该函数的参数列表
// index.js
import workerpool from workerpool
export async function workerDraw(fn, ...args) {const pool workerpool.pool(./worker.js)return pool.exec(runWithDepts, [String(fn)].concat(args))
}完成以上步骤就可以在项目任意需要调用 worker 的位置像下面这样。自定义函数内容引用所需依赖已注入在函数第一个参数进行使用了。 这里我们引用了一个项目内的公共函数 fibonacci也引用了一个 lodash 的 map 方法都可以在depts 对象上取到
// 项目内需使用worker时
const res await workerDraw((depts, m, n) {const { map } depts[_]const { fibonacci } depts[util/math]return map([m, n], (num) fibonacci(num))},input1,input2,
)3. 优化语法支持 没有语法支持的依赖管理是很难用的通过对 workerDraw 进行 ts 语法包装可以实现在使用时的依赖提示
import workerpool from workerpool
import type TDepts from ./worker-deptsexport async function workerDrawT extends any[], R(fn: (depts: typeof TDepts, ...args: T) PromiseR | R, ...args: T) {const pool workerpool.pool(./worker.js)return pool.exec(runWithDepts, [String(fn)].concat(args))
}然后就可以在使用时获取依赖提示 4. 其他问题 新增了 worker 以后出现了 window和 worker 两种运行环境如果你恰好和我一样需要兼容 node 端运行那么运行环境就是三种原本我们通常判断 window 环境使用的也许是 typeof window object这样现在不够用了这里可以改为 globalThis 对象它是三套环境内都存在的一个对象通过判断globalThis.constructor.name的值值分别是Window / DedicatedWorker/ Object从而实现环境的区分
总结 通过使用 workerpool添加依赖管理和构建公共 worker 调用函数我们实现了一套按需调用灵活强大的 worker 使用方式。 在京东羚珑的程序化设计项目中通过把 skia 图形绘制部分逐步改造为 worker内调用我们实现了整体服务耗时降低 75% 的效果收益还是非常不错的。 文中涉及的代码示例都已放在 github[6] 上内有 vite 和 webpack 两个完整实现版本感兴趣的小伙伴可以 clone 下来参照着看~
参考资料 [1] Is postMessage slow: https://dassur.ma/things/is-postmessage-slow/
[2] redux 挪到了 worker 内: https://blog.axlight.com/posts/off-main-thread-react-redux-with-performance
[3] dom 挪到了 worker 内: https://github.com/ampproject/worker-dom
[4] 可使用多核能力的框架: https://github.com/neomjs/neo
[5] workerpool: https://github.com/josdejong/workerpool
[6] github: https://github.com/Silencesnow/worker-demo-2022
[7] MDN Web Workers API: https://developer.mozilla.org/zh-CN/docs/Web/API/Web_Workers_API
[8] workerpool: https://github.com/josdejong/workerpool
[9] 前端项目上 Web Worker 实践: https://www.youtube.com/watch?vAEpG-3XXrjk
[10] Web Worker 文献综述: https://juejin.cn/post/6854573213297410062
