同一张图片测试两次，均匀2250ms
mask尺寸超大的状况，wasm机能是worker的6倍
初步论断
转换机能：mask的机能在各种场景下都优于worker，机能最少晋升4倍以上，当mask很小时，机能是worker的30倍。
内存占用：内存占用不太好测试，用阅读器的Performance简略测试了一下，wasm的内存占用也比worker的小。
技术调研Worker 计划
将一个mask绘制到界面次要有两个步骤，这两个步骤都对比耗时，第一步是转换，将mask转成imageData，这一步是纯计算的，会放在worker外面，第二步是绘制，下列只关注转换这一步，第二步暂不关注（虽然它也很慢，还存在可优化的空间）。
因为worker是异步的，转化分为三个小步骤：
postMessage to worker ，这一步将需求转换的mask传给workerGenerate ImageData，这一步将mask转成ImageData，像素点操作，机能问题次要泛起在这一步骤postMessage to brower，这一步将转换好的ImageData传回给阅读器，而后就能绘制啦！
与worker交互，数据需求序列化、反序列化，当对象很大时，是很耗机能的，如下的例子就能充沛阐明，不论mask多大，postMessage to worker这一步会花不少时间，实际上mask转行是很快（1毫秒摆布），但往返的传输就很慢了
Webassembly 摹拟worker计划
重构为Wasm的初版版本，我选择跟worker相似的计划，只是用rust完成罢了，也是分三个小步骤：
mask_data to JsValue，与wasm交互，动静一样需求序列化Generate ImageData，mask转换，跟worker逻辑同样image_data to JsValue，将image_data序列化后给到阅读器
论断：实际测试上去，最初一步将image_data序列化很耗时，整体时间乃至比worker的还慢，所以此计划废弃了。
Webassembly 同享内存计划
数据序列化和反序列化通常很耗时，那有无计划绕过它？谜底就是同享内存，这也是wasm保举的做法之一，与wasm交互时，数据只要一份且存在wasm的memory对象中，阅读器间接读取wasm中内存数据并渲染，无需额定空间，三个小步骤
Write mask to share memory，将需求转换的数据写入wasm内存，再也不经过序列化传给wasm了Generate ImageData，从内存读取mask数据并转成ImageData，并将ImageData写入share memory，再也不经过序列化传给阅读器Read ImageData from share memory，阅读器间接读取wasm内存，并绘制，无需再结构对象
注册会员