鸿蒙原生APP性能优化之TaskPool和Worker的对比实践

往期推文全新看点

• 鸿蒙（HarmonyOS）北向开发知识点记录~
• 鸿蒙（OpenHarmony）南向开发保姆级知识点汇总~
• 鸿蒙应用开发与鸿蒙系统开发哪个更有前景？
• 嵌入式开发适不适合做鸿蒙南向开发？看完这篇你就了解了~
• 对于大前端开发来说，转鸿蒙开发究竟是福还是祸？
• 鸿蒙岗位需求突增！移动端、PC端、IoT到底该怎么选？
• 记录一场鸿蒙开发岗位面试经历~
• 持续更新中……

概述

ArkTS提供了TaskPool与Worker两种多线程并发方案，下面我们将从其工作原理、使用效果对比两种方案的差异，进而选择适用于ArkTS图片编辑场景的并发方案。

工作原理

TaskPool与Worker两种多线程并发能力均是基于 Actor并发模型实现的。Worker主、子线程通过收发消息进行通信；TaskPool基于Worker做了更多场景化的功能封装，例如支持任务组TaskGroup、任务优先级设置、取消任务等功能，且可以根据任务数量进行自动的扩容与缩容，还可以根据任务优先级进行任务调度。

Worker工作原理

Worker拥有独立的运行环境，每个Worker线程和主线程一样拥有自己的内存空间、消息队列（MessageQueue）、事件轮询机制（EventLoop）、调用栈（CallStack）等。线程之间通过Message进行交互，如下图所示：

图1Worker工作原理

在多核的情况下（下图中的CPU 1和CPU 2同时工作），多个Worker线程（下图中的Worker thread1和Worker thread2）可以同时执行，因此Worker线程做到了真正的并发，如下图所示：

图2多核CPU下Worker并发原理图

TaskPool工作原理

TaskPool在Worker之上实现了调度器和Worker线程池。在主线程（ArkTS Main Thread）中调用execute接口会将待执行的任务方法及参数信息，根据设置的任务优先级放入任务队列（TaskQueue）中等待调度执行。调度器会依据调度算法（优先级，防饥饿），从优先级队列中取出任务进行序列化，放入TaskPool中的Worker线程池，工作线程（ArkTS Worker Thread）根据调度器的安排执行任务方法，并将任务处理结果进行反序列化，最终以Promise-Then的方式返回给主线程。TaskPool的工作线程池会根据待执行的任务数量，任务的执行时间进行相应的扩容与缩容。原理图如下所示：

图3 TaskPool工作原理图

TaskPool与Worker并发方案对比

使用场景

本章节主要介绍Worker与TaskPool并发方案在ArkTS图片编辑场景下的使用及性能差异。分别从编码效率、线程创建耗时、数据传输、任务执行耗时、应用运行内存占用几个维度进行分析，对比不同方案各自的优缺点，以供开发者在遇到不同场景时参考。

图4 ArkTS图片编辑效果