北京
几个月前，我在开发一款名为Fastary的Chrome截图扩展时，撞上了一堵反直觉的性能墙。按照所有现代Web开发指南的教导，我把画布操作（canvas operations）一股脑交给了Offscreen Document——Chrome扩展里的后台进程，也就是大家常说的“不阻塞主线程”的标准做法。可无论怎么调，每次截图操作都会多出2到3秒的延迟，截图这种动作本应该毫无卡顿地瞬间完成。那一刻我忽然意识到：我们拼命往Worker里扔任务，可能有一部分时间根本不是花在计算上，而是花在了搬数据本身上。
这听起来很刺耳，因为“永不阻塞主线程”已经是刻进Web开发者骨子里的铁律。几乎所有性能指南都会告诉你：浏览器的主线程是单线程，它不仅要跑你的JavaScript逻辑，还要伺候渲染引擎、输入事件处理和其他关键任务，你占用的时间越少，应用就越跟手。于是我们养成了条件反射——凡是数据处理、重计算，统统移交给Web Worker或者后台脚本。这条规训如此普遍，以至于有人画出了“推荐架构”：UI和计算之间必须有一条不可逾越的硬边界，井水不犯河水。
但很少有人会反过来追问：把数据搬到Worker这件事本身，会不会也在阻塞UI？要知道，浏览器里的各种执行环境是彼此隔离的，主线程、Web Worker、Service Worker、Chrome扩展的背景脚本和Offscreen Document，每个都住在自己的内存空间里，遵守“共享无”（shared-nothing）架构。它们不能直接伸手去读对方的变量，所有的通信都必须靠一条狭窄的信道——结构化克隆（structured cloning）。传递数据的过程就是把对象递归地序列化、复制一遍，再在另一端反序列化，对于大体积的图像数据而言，这套操作本身就能吃掉主线程的几百毫秒，甚至让渲染掉帧。
这就形成了一个荒诞的困境：我们用反射动作把任务送出主线程以避免UI冻结，结果用来“搬运”数据的串行开销却亲手冻结了UI；而那个被寄予厚望的后台通道，最终跑完全程的时间可能比老老实实在主线程上做完全部工作还要长。我在Fastary里的遭遇就是活生生的例子——并非说Web Worker不好，而是当数据的拷贝成本超越了计算本身的收益时，“不阻塞”就变成了一种自我欺骗的性能倒挂。
更值得兴奋的是，一旦看清这层真相，很多优化决策就不再是死板的教条。比如当你在主线程处理一个耗时20毫秒的即时任务，而把数据序列化并发送到Worker却需要30毫秒，那么“阻塞”主线程反而才是界面更快更灵敏的选择。我们长久以来把主线程和Worker当成非黑即白的对立面，但真实世界里，只有算一笔“数据搬运 vs. 直接执行”的账，才能决定哪一边更值得“牺牲”。这将引导出一批新的实践模式：对小规模高频率的操作保持原地执行；对真正需要长时间CPU密集计算的大块头才出动Worker；甚至在局部场景下，用原生的可转移对象（transferables）来规避拷贝，前提是你知道自己正在把数据的所有权真正交出去。
“永远不要阻塞主线程”作为一种经验法则无可厚非，但它不该成为技术选型里唯一的声音。我在Fastary上看到的2到3秒延迟，教会了我一件事：没有哪一种架构糖衣能掩盖数据传输的代价，当你开始把性能优化当成一种可测量的权衡而非道德戒律时，很多本可更快的体验才会真正被解放出来。这才是让前端性能工作变得性感的部分。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
