TaskPool vs Worker一张表帮你选对并发方案写并发代码时最常被问的就是这个场景用 TaskPool 还是 Worker。两者都是基于 Actor 模型的多线程方案能力上有重叠定位上有差异。TaskPool 在 Worker 之上做了调度器和线程池的封装自动管生命周期Worker 给你一个独立 Runtime自由度高但要自己管。这篇把两者从实现特点、工作原理、适用场景、具体实践四个维度做一次完整对比最后给一个选型决策树。实现特点对比直接上表20 维度逐项对比维度TaskPoolWorker线程运行环境基于 Worker 线程池调度器统一管理每个 Worker 独立内存空间、EventLoop、CallStack内存模型线程间隔离内存不共享线程间隔离内存不共享通信方式调度器序列化分发任务Promise-Then 返回主子线程 Message 收发参数传递机制Structured Clone 序列化支持 ArrayBuffer 转移、SharedArrayBuffer 共享、Sendable 引用传递同 TaskPool参数传递直接传递无需封装消息对象为唯一参数需自己封装方法调用直接传Concurrent修饰的方法在 Worker 线程里解析消息调用对应方法返回值异步调用后默认返回主动 postMessage需在 onmessage 里解析调度机制内置调度器优先级 防饥饿算法无调度器开发者自行管理线程池管理自动扩缩容不支持自行创建销毁生命周期自动管理手动管理个数上限自动管理无需配置同进程最多 64 个实际由内存决定执行时长上限3 分钟不含异步 I/O 等待LongTask 无限制无限制任务优先级支持API 18 起支持任务取消支持不支持线程复用支持不支持任务延时执行支持不支持任务依赖关系支持不支持串行队列支持不支持任务组支持不支持周期任务支持不支持异步队列支持不支持TaskPool 支持的能力比 Worker 多很多这些都是调度器封装带来的。Worker 没有调度器所以优先级、取消、任务组、延时、依赖这些都没法做。工作原理对比两者都基于 Actor 并发模型但架构层次不同。Worker 工作原理每个 Worker 线程和主线程一样有完整的 Runtime内存空间、MessageQueue、EventLoop、CallStack。线程之间通过 Message 交互。Worker线程2Worker线程1主线程postMessagepostMessagepostMessagepostMessageCallStackEventLoopMemoryCallStackEventLoopMemoryCallStackEventLoopMemory多核 CPU 上多个 Worker 线程可以真正并行。但 Worker 之间不能直接通信必须通过主线程中转。TaskPool 工作原理TaskPool 在 Worker 之上加了调度器和线程池。主线程调execute()把任务按优先级放进 TaskQueue调度器按优先级 防饥饿算法取任务序列化后丢给 Worker 线程池工作线程执行后反序列化结果以 Promise-Then 返回主线程。线程池根据任务数量和执行时间自动扩缩容。主线程 executeTaskQueue按优先级排队调度器优先级 防饥饿序列化Worker 线程池自动扩缩容工作线程执行反序列化Promise-Then 返回主线程关键差异TaskPool 多了调度器和线程池两层所以它支持优先级、取消、任务组这些能力但也因此多了一些内存开销。适用场景对比TaskPool 工作线程绑定系统调度优先级支持负载均衡。Worker 要自己创建销毁有创建和管理成本。大多数场景优先 TaskPool。适合 Worker 的场景运行时间超过 3 分钟的任务。这里的 3 分钟指同步执行时长不含 Promise/async-await 异步 I/O 等待。比如后台跑 1 小时的预测算法训练CPU 密集型必须用 Worker。有强关联的一系列同步任务。比如要创建并使用句柄的场景每次创建的句柄都不同且必须持续保存该句柄确保后续操作正确执行。这种依赖线程上下文的场景Worker 的独立 Runtime 正好合适。对运行时内存占用敏感的场景。TaskPool 多了调度器和线程池任务多时多占一些内存。设备内存受限或任务量大时Worker 内存占用更低。适合 TaskPool 的场景需要设置任务优先级的任务。API 18 之前 Worker 不支持调度优先级。比如图像直方图绘制后台计算的直方图数据要给前台显示影响用户体验任务相对独立用 TaskPool 配 HIGH 优先级。需要频繁取消的任务。比如大图浏览场景缓存当前图片左右各两张。滑到下一张时要取消另一侧的缓存任务TaskPool 支持取消Worker 不支持。大量或调度点分散的任务。大型应用多个模块都有耗时任务用 Worker 难以做负载管理TaskPool 自动调度更合适。具体实践对比图片编辑场景以 ArkTS 图片编辑场景为例从编码效率、线程创建耗时、数据传输、任务执行耗时、内存占用五个维度对比。实验环境8 核手机中载CPU 占用 50%~60%和重载CPU 占用 90%两种。编码效率Worker 方案要开发者自己控制 Worker 实例数量最多 64 个复用线程及时销毁。基本流程// 1. 根据任务数创建 Worker最多 64 个consttaskNum14;constcurTaskNumtaskNum64?taskNum:64;constworkers:worker.ThreadWorker[][];for(leti0;icurTaskNum;i){workers.push(newworker.ThreadWorker(WorkerName));}// 2. 拆分图片像素数据分配给 WorkerconstbufferssplitArrayBuffer(bufferArray,taskNum);for(leti0;itaskNum;i){workers[i].postMessage(newMessageItem(buffers[i],sliderValue,value));}// 3. 接收结果复用 Worker 处理剩余任务全部完成后销毁workers[index].onmessage(e:ESObject){newBuffers[e.data.index]e.data.buffer;if(allocation!0){workers[index].postMessage(messages[n]);// 复用allocation--;}elseif(numtaskNum){for(leti0;icurTaskNum;i){workers[i].terminate();// 销毁}updatePixelMap(mergeArrayBuffers(newBuffers));}};TaskPool 方案用 TaskGroup 把大任务拆成小任务丢进任务组privateasyncexecImageProcessing(buffer:ArrayBuffer,type:AdjustId,value:number):PromiseArrayBuffer{constbufferssplitArrayBuffer(buffer,240);constgroupnewtaskpool.TaskGroup();for(constbufofbuffers){group.addTask(imageProcessing,{value,buffer:buf,type});}// 任务组 HIGH 优先级系统自动调度returnmergeArrayBuffers(awaittaskpool.execute(group,taskpool.Priority.HIGH)asArrayBuffer[]);}对比下来Worker 代码量明显多要管线程数量上限、复用、销毁。TaskPool 几行就完事TaskGroup 优先级自动调度。线程创建耗时Worker 要自己管线程数量、复用、生命周期避免大量系统资源消耗。TaskPool 系统统一管理动态调度 负载均衡。结论创建线程耗时 Worker TaskPool。应用首帧要快速响应的场景用 TaskPool。数据传输方式两者都支持两种传递方式转移控制权transfer 列表中的 ArrayBuffer 转移到工作线程不复制。传输后宿主线程里这个 ArrayBuffer 失效。深拷贝复制一份数据传过去执行线程修改不影响宿主线程原数据。底层用同一套序列化/反序列化机制。差异在于 TaskPool 支持任务方法传递Worker 的任务方法必须写在 Worker.ets 文件里。所以 TaskPool 比 Worker 多了任务方法的序列化/反序列化步骤。一个任务时 TaskPool 序列化数据参考内容序列化数据量bytes序列化时间μs反序列化时间μs方法589.54943.749参数21736.111115.294结果4716.66785.243如果用转移控制权序列化数据量小很多效率高。深拷贝会增加开销。宿主线程传完数据后不需要紧接着访问的场景推荐转移控制权。任务执行耗时中载和重载环境下随任务数增多耗时变化重载环境任务数 1 时TaskPool 和 Worker 总耗时相近任务数 4 时Worker 效率最高比单任务减少约 57%TaskPool 在并发数 8 后优于 Worker 并趋于稳定比单任务减少约 50%中载环境任务数 1 时两者用时相近任务数 4 时Worker 略优于 TaskPool任务数 4 时Worker 稳定在 3.3s 左右TaskPool 在任务数 8 时耗时较多8 核手机最多 7 个工作线程第 8 个任务串行任务数 8 时 TaskPool 稳定在 2.95s 左右任务数 50 时两者差异不大并发能带来 50%~65% 收益但不是任务越多越好。重载下 TaskPool 的高优先级任务更容易抢到系统资源所以 TaskPool 稍快中载下系统资源充足高优先级效果不明显两者差不多。运行时内存占用任务数少时两者差别不大。任务数多时 TaskPool 内存比 Worker 大因为 TaskPool 多了调度器和线程池的封装开销。任务执行完后都会回收释放。选型决策树是否是否是否是否是否新任务同步执行 3 分钟?用 Worker需要保存线程上下文如句柄状态?需要频繁取消任务?用 TaskPool需要优先级 / 任务组 / 延时?任务量大且内存敏感?文字版决策路径同步执行超过 3 分钟→ Worker需要保存线程上下文句柄、长期状态→ Worker需要频繁取消任务→ TaskPool需要优先级 / 任务组 / 延时 / 周期任务→ TaskPool任务量大且内存敏感→ Worker其他场景→ TaskPool总结一下下哦别教条。决策树是参考不是教条。有些场景两者都能用选你写得快、维护成本低的。一个 2 分钟的独立计算任务用 TaskPool 写 5 行代码搞定没必要为了理论最优硬上 Worker 写 50 行。TaskPool 的 3 分钟限制只算同步执行。异步 I/O 等待不计入。数据库异步插入、网络请求的等待时间都不算只算 CPU 实际处理时间。别看到 3 分钟就慌先看任务是同步还是异步。Worker 复用是关键。频繁创建销毁 Worker 开销大。如果用 Worker做好复用池一个 Worker 跑完任务别立刻销毁看还有没有后续任务。重载下 TaskPool 优先级才有优势。中载下系统资源充足TaskPool 的高优先级效果不明显和 Worker 差不多。重载下高优先级任务更容易抢资源TaskPool 才快。任务数不是越多越好。8 核手机 TaskPool 最多 7 个工作线程任务数超过 7 后会有任务串行。根据任务计算量和 CPU 核数调任务数一般 4~8 个并发收益就到顶了。数据传输用转移控制权。大 ArrayBuffer 传输宿主线程传完不再访问的场景用setTransferList()转移所有权比深拷贝快很多。内存占用监控。TaskPool 任务多时内存占用比 Worker 高但任务完会回收。如果应用整体内存紧张且任务量大考虑 Worker。否则 TaskPool 的便利性更值得。