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 操作或发起网络请求（需主线程代理）
