Web Worker 在移动设备上不天然省电，空闲或轻量任务反而增加功耗；仅当有效卸载CPU密集型任务（如图像处理、加密解密）时才可能降低整体电量消耗。

Web Worker 在移动设备上不是天然省电的方案，它是否降低电量消耗，完全取决于你用它干什么、怎么用、以及设备本身的性能水平。

空闲 Worker 反而更耗电

创建一个 Worker 就意味着启动一个独立 JS 执行环境，哪怕它什么也不做，只是监听 postMessage，系统仍需维持其线程调度和内存驻留。实测显示，在 Pixel 4a 和 Redmi Note 9 这类中低端 Android 设备上，一个空循环 Worker（比如 setInterval(() => {}, 100)）比主线程挂起时多消耗约 8%–12% 的单位时间电量。

• Worker 线程本身不省电，它增加的是额外开销
• 低端设备对线程调度更敏感，空闲 Worker 的待机功耗更明显
• 频繁创建/销毁 Worker 比长期持有更耗资源，尤其在内存紧张时

真正节电只发生在“有效卸载”时

只有当 Worker 承担了原本会严重拖慢主线程、触发大量重排重绘或长时间独占 CPU 的任务，才可能带来净功耗下降——因为此时主线程得以释放，UI 渲染更高效，整体系统调度更平稳。

• 图像处理：Canvas 像素级运算、实时滤镜应用
• 加密解密：JWT 解析、AES 加解密等 CPU 密集型操作
• 离线预处理：大型 JSON 解析、本地搜索索引构建
• WebAssembly 调用：WASM 版音视频编解码、科学计算

通信开销可能抵消收益

Worker 和主线程之间靠 postMessage 通信，每次传递数据都要序列化/反序列化。如果任务本身很轻（比如单次计算耗时低于 5ms），或者通信过于频繁，这部分开销反而会让 CPU 更忙，功耗不降反升。

• 避免高频小数据通信，尽量合并批量任务再发送
• 大数组、TypedArray 等可使用 Transferable Objects 避免拷贝
• 不要为简单逻辑（如格式化字符串、基础数学运算）引入 Worker

鸿蒙与 ArkTS 的 Worker 实践参考

HarmonyOS 的 ArkTS Worker 线程机制设计更贴近系统层，支持类型安全、优雅终止和按需调度。但同样遵循“任务粒度要合理”的原则：拆得太碎（如每千条数据启一个 Worker）易触发线程创建失败或调度瓶颈；拆得太粗又无法发挥并行优势。实测中，将百万级数据分块（如每块 1 万～5 万）交由并行 Worker 处理，配合 AtomicLong 合并结果，是兼顾性能与功耗的常见做法。

• 优先选用 TaskDispatcherType.PARALLEL 而非手动 new Thread
• 任务完成后主动调用 terminate() 释放资源
• 避免在 Worker 中执行 DOM 操作或发起网络请求（需主线程代理）