TaskPool和Worker的对比分析 - KaihongOS技术社区 - 电子技术论坛 - 广受欢迎的专业电子论坛
分享 收藏 返回
新疆切糕 关注 私信
[文章]

TaskPool和Worker的对比分析


  • askPool（任务池）和Worker的作用是为应用程序提供一个多线程的运行环境，用于处理耗时的计算任务或其他密集型任务。可以有效地避免这些任务阻塞主线程，从而最大化系统的利用率，降低整体资源消耗，并提高系统的整体性能。
    本文将从实现特点和适用场景两个方面来进行TaskPool与Worker的比较。
    实现特点对比

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

    TaskPool和Worker均支持多线程并发能力。由于TaskPool的工作线程会绑定系统的调度优先级，并且支持负载均衡（自动扩缩容），而Worker需要开发者自行创建，存在创建耗时以及不支持设置调度优先级，故在性能方面使用TaskPool会优于Worker，因此大多数场景推荐使用TaskPool。
    TaskPool偏向独立任务维度，该任务在线程中执行，无需关注线程的生命周期，超长任务（大于3分钟）会被系统自动回收；而Worker偏向线程的维度，支持长时间占据线程执行，需要主动管理线程生命周期。
    常见的一些开发场景及适用具体说明如下：

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

更多回帖

我也要说两句 回帖

相关经验

×
发帖