web workers 在移动端未必省电，其功耗取决于任务类型与调度；仅当有效卸载高负载计算（如图像处理、加密解密）时才可能降低净功耗，否则空闲worker反增8%–12%电量消耗。

Web Workers 在移动端确实能提升 JavaScript 执行的并发性，但其电量与性能表现并非总是正向收益——关键取决于任务类型、调度方式和设备能力。

Worker 线程本身不省电，反而可能增加功耗

创建 Worker 会启动独立的 JS 执行上下文，占用额外内存与 CPU 调度资源。在中低端 Android 设备上，即使 Worker 处于空闲状态（如仅监听 postMessage），系统仍需维持其线程调度和内存驻留，导致待机功耗小幅上升。实测显示：持续运行一个空循环 Worker（setInterval(() => {}, 100)）比主线程挂起时多消耗约 8%–12% 的单位时间电量（基于 Pixel 4a 和 Redmi Note 9 测量）。

真正节电的前提是“有效卸载高负载计算”

只有当 Worker 承担了原本会阻塞主线程、触发频繁重排重绘或长期占用 CPU 的任务时，才可能带来净功耗下降。典型适用场景包括：

• 图像处理（Canvas 像素级运算、滤镜应用）
• 加密解密（JWT 解析、AES 加解密）
• 离线数据预处理（大型 JSON 解析、本地搜索索引构建）
• WebAssembly 模块调用（如 WASM 版音视频编解码）

注意：若任务本身耗时低于 5ms，或频繁跨线程通信（postMessage + onmessage 往返），通信开销可能抵消计算收益，甚至因序列化/反序列化加重 CPU 负担。

移动端需特别关注生命周期与资源回收

Android WebView 和 iOS WKWebView 对 Worker 的资源管理策略不同。未显式调用 worker.terminate() 的 Worker 可能在页面隐藏后继续存活，尤其在 PWA 或单页应用中易被忽略。建议：

• 在页面 visibilitychange 为 hidden 时终止非持久型 Worker
• 对长时任务采用分片（chunking）+ setTimeout 退让，避免单次执行超 16ms 引发帧丢弃
• 优先使用 SharedWorker 协调多个标签页间任务，减少重复实例（但注意其兼容性限制）

性能提升≠体验提升，需结合渲染管线评估

Worker 解放主线程后，若后续 UI 更新仍依赖大量 DOM 操作或 Layout Thrashing，滚动卡顿、输入延迟等感知性能问题不会自动消失。应配合：

• 使用 requestIdleCallback 或 IntersectionObserver 控制 Worker 结果的消费节奏
• 将 Worker 输出转为 DocumentFragment 或 CSS 自定义属性，减少强制同步布局
• 在低端设备上降级：通过 navigator.hardwareConcurrency 判断核心数，≤2 时直接在主线程执行轻量任务

不复杂但容易忽略：电量与性能不是单一维度的取舍，而是任务粒度、通信成本、设备能力和用户感知共同作用的结果。合理用好 Worker，本质是让 CPU 在“该用力时用力，该休息时彻底休息”。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！