TaskPool和Worker的对比 (TaskPool和Worker)

TaskPool和Worker的作用是为应用程序提供一个多线程的运行环境，用于处理耗时的计算任务或其他密集型任务。可以避免任务阻塞宿主线程，从而提高系统性能和资源利用率。

本文将从实现特点和适用场景两个方面来进行TaskPool与Worker的比较。

实现特点对比

表1 TaskPool和Worker的实现特点对比

实现	TaskPool	Worker
内存模型	线程间隔离，内存不共享。	线程间隔离，内存不共享。
参数传递机制	采用标准的结构化克隆算法（Structured Clone）进行序列化、反序列化，完成参数传递。支持ArrayBuffer转移、SharedArrayBuffer共享和Sendable引用传递。	采用标准的结构化克隆算法（Structured Clone）进行序列化、反序列化，完成参数传递。支持ArrayBuffer转移、SharedArrayBuffer共享和Sendable引用传递。
参数传递	直接传递，无需封装。	消息对象唯一参数，需要自己封装。
方法调用	直接将@Concurrent修饰的方法传入并调用。	在Worker线程中解析消息并调用对应方法。
返回值	异步调用后默认返回。	主动发送消息，需在onmessage中解析并赋值。
生命周期	TaskPool自行管理生命周期，无需关心任务负载高低。	开发者自行管理Worker的数量及生命周期。
任务池个数上限	自动管理，无需配置。	同个进程下，最多支持同时开启64个Worker线程，实际数量由进程内存决定。
任务执行时长上限	3分钟（不包含Promise和async/await异步调用的耗时，例如网络下载、文件读写等I/O任务的耗时），长时任务无执行时长上限。	无限制。
设置任务的优先级	支持配置任务优先级。	从API version 18 开始，支持配置Worker线程的优先级。
执行任务的取消	支持取消已经发起的任务。	不支持。
线程复用	支持。	不支持。
任务延时执行	支持。	不支持。
设置任务依赖关系	支持。	不支持。
串行队列	支持。	不支持。
任务组	支持。	不支持。
周期任务	支持。	不支持。
异步队列	支持。	不支持。

适用场景对比

TaskPool和Worker均支持多线程并发能力。由于TaskPool的工作线程会绑定系统的调度优先级，并支持负载均衡（自动扩缩容），相比之下，Worker需要开发者自行创建，存在创建耗时。因此，性能方面TaskPool优于Worker，推荐在大多数场景中使用TaskPool。

TaskPool偏向独立任务维度，该任务在线程中执行，无需关注线程的生命周期，超长任务（大于3分钟且非长时任务）会被系统自动回收。而Worker偏向线程的维度，支持长时间占据线程执行，需要开发者主动管理线程生命周期。

常见开发场景及适用说明如下：

运行时间超过3分钟的任务（不包括Promise和async/await异步调用的耗时，如网络下载、文件读写等I/O任务的耗时）：例如后台进行1小时的预测算法训练等CPU密集型任务，需要使用Worker。场景示例可参考常驻任务开发指导。
有关联的一系列同步任务：例如在一些需要创建、使用句柄的场景中，句柄每次创建都是不同的，该句柄需永久保存，保证使用该句柄进行操作，需要使用Worker。场景示例可参考使用Worker处理关联的同步任务。
需要设置优先级的任务：在API version 18 之前，Worker不支持设置调度优先级，需要使用TaskPool。从API version 18 开始，Worker支持设置调度优先级，开发者可以根据使用场景和任务特性选择使用TaskPool或Worker。例如图库直方图绘制场景，后台计算的直方图数据会用于前台界面的显示，影响用户体验，需要高优先级处理，且任务相对独立，推荐使用TaskPool。
需要频繁取消的任务：例如图库大图浏览场景，为提升体验，会同时缓存当前图片左右侧各2张图片，往一侧滑动跳到下一张图片时，要取消另一侧的一个缓存任务，需要使用TaskPool。
大量或调度点分散的任务：例如大型应用的多个模块包含多个耗时任务，不方便使用Worker去做负载管理，推荐使用TaskPool。场景示例可参考批量数据写数据库场景。