鸿蒙开发中的并发与多线程

---

---

前言

并发是指在同一时间内，存在多个任务同时执行的情况。对于多核设备，这些任务可能同时在不同CPU上并行执行。对于单核设备，多个并发任务不会在同一时刻并行执行，但是CPU会在某个任务休眠或进行I/O操作等状态下切换任务，调度执行其他任务，提升CPU的资源利用率。

---

异步并发 (Promise和async/await)

• Promise 的特点与用法：Promise 用于处理异步操作，有 pending、fulfilled、rejected 三种状态，通过构造函数传入 executor 函数创建 Promise 对象，executor 函数接收 resolve 和 reject 回调函数。可使用 then 和 catch 方法指定不同状态的回调函数。
• async/await 的优势：async/await 是 Promise 的语法糖，使异步代码更易读，async 函数返回 Promise 对象，内部可用 await 等待 Promise 解析，将异步操作以同步方式编写，还可结合 try/catch 捕获异常。

多线程并发

• ArkTS并发模型：ArkTS采用内存隔离的线程模型，不同线程之间通过消息通信，线程内无锁化运行。与传统共享内存并发模型相比，异步I/O不阻塞ArkTS线程，TaskPool及I/O线程池由系统管理，提升能效。

• 
  不支持在多线程中使用AppStorage。

• TaskPool的使用：TaskPool可执行耗时任务，提供任务分发入口，支持将任务分发到不同优先级队列，自动管理工作线程并根据任务数量扩缩容。适用于相对独立的耗时任务、长时任务，但任务执行中有通信开销、不能阻塞过长、不能有上下文依赖等限制。

• Worker的使用：Worker可执行常驻任务，需开发者主动创建或关闭并维护其生命周期，同时运行的Worker子线程数量有限。适用于长耗时且并发量不大的常驻任务场景。

• 实现特点对比：

  • 内存模型与参数传递机制：TaskPool 和 Worker 都采用线程间隔离、内存不共享的方式，且参数传递都采用结构化克隆算法，支持 ArrayBuffer 转移和 SharedArrayBuffer 共享。，开发者自行管理数量及生命周期，不支持上述 TaskPool 的其他特性。

• 适用场景对比：

  • TaskPool 适用场景：大多数场景推荐使用，性能优于 Worker，适用于需要设置优先级、频繁取消任务、大量或调度点较分散任务等。
  • Worker 适用场景：适用于运行时间超过 3 分钟的任务、有关联的一系列同步任务等特定场景。

场景编号	场景分类	场景名称	简述
1	并发能力选择	耗时任务并发执行	相对独立的耗时任务需要放到单独的子线程中执行，推荐TaskPool
2		常驻任务并发执行	常驻的耗时任务需要放到单独的子线程中执行，推荐Worker
3		共享内存并发业务	开发常见的共享内存并发业务，推荐使用TaskPool和Worker的API进行开发
4		长时任务并发执行	长时间运行的任务，不独占线程执行，推荐TaskPool长时任务
5	并发任务管理	多任务关联执行（串行顺序依赖）	有严格执行顺序的任务，不希望并发执行
6		多任务关联执行（树状依赖）	待执行的任务存在依赖关系，等待被依赖执行完再调度
7		多任务同步等待结果（任务组）	多个关联的任务需要等待全部结果返回后再进行后续操作
8		多任务优先级调度	不同任务设置不同的优先级
9		任务延时调度	任务不希望立即执行，希望延时一定时间后调度
10	线程间通信	同语言线程间通信（ArkTS内）	介绍ArkTS线程间的通信机制
11		跨语言多线程通信（C++与ArkTS）	介绍C++与ArkTS线程间的通信机制
12		线程间模块共享（单例模式）	介绍进程内单例场景的实现方式
13		线程间不可变数据共享	介绍不可变数据共享场景的实现方式
14		生产者与消费者模式	介绍生产者与消费者模式场景的实现方式

并发能力选择

耗时任务并发执行场景

典型的耗时任务有CPU密集型任务、I/O密集型任务以及同步任务。=>任务池（TaskPool）
对于独立的耗时任务，不建议采用Worker来实现。

import { taskpool } from '@kit.ArkTS';

@Concurrent
async function foo(a: number, b: number) {
  return a + b;
}

taskpool.execute(foo, 1, 2).then((ret: Object) => { // 结果处理
  console.log('Return:' + ret);
})

常见业务场景

常见业务场景	具体业务描述
图片/视频编解码	将图片或视频进行编解码再展示
压缩/解压缩	对本地压缩包进行解压操作，或者本地文件的压缩操作
JSON解析	对JSON字符串的序列化和反序列化操作
模型运算	对数据进行模型运算分析等
网络下载	密集网络请求下载资源、图片、文件等
数据库操作	将聊天记录、页面布局信息、音乐列表信息等保存到数据库，或者应用二次启动时，读取数据库展示相关信息

常驻任务并发执行场景

常驻不是指可以在后台保活运行的任务，而是相比于短时任务，时间更长的任务，可能与主线程生命周期一致。
对于一些长耗时（大于3min）且并发量不大的常驻任务场景，使用Worker在后台线程中运行这些耗时逻辑，避免阻塞主线程而导致出现丢帧卡顿等影响用户体验性的问题 。
常驻任务不推荐作为任务分发给TaskPool。

常见业务场景

常见业务场景	具体业务描述
游戏中台场景	启动子线程作为游戏业务的主逻辑线程，UI线程只负责渲染
产线硬件压测	需要阻塞调用硬件能力，做老化测试，阻塞式

传统共享内存并发业务

如果需要使用内存共享，当前可以通过Node-API到C++层进行共享，或者定义Sendable对象进行线程间数据共享。

长时任务并发执行场景

长时任务不同于阻塞任务，长周期运行，但是每次执行不会阻塞线程很久。因此不推荐将需要独占线程的任务封装成长时任务。任务池（TaskPool）

对于非常驻的长时任务，不建议采用Worker来实现。

长时任务指的是长时间不间断运行的独立任务，例如监听某个事件，发起执行后不会再接收发起方的输入，虽然也可以使用worker（推荐常驻后台任务才使用worker），但是更推荐使用TaskPool，TaskPool更方便，资源消耗更低。

常见业务场景

常见业务场景	具体业务描述
定期传感器数据采集	周期性采集一些传感器信息（例如位置信息、速度传感器等），应用运行阶段常驻运行。
Socket端口信息监听	长时间监听Socket数据，不定时需要响应处理。

import { taskpool } from '@kit.ArkTS';

@Concurrent
async function foo() {
  // 长监听等任务
  taskpool.Task.sendData();
}

function executeTaskPool() {
  let longTask: taskpool.LongTask = new taskpool.LongTask(foo);
  longTask.onReceiveData((msg: Object) => {
    // 监听回调
    console.info(`onReceiveData, ${JSON.stringify(msg)}`);
  });

  taskpool.execute(longTask).then(() => {
    console.info('execute');
  });
}

executeTaskPool();

并发任务管理

多任务关联执行(串行顺序依赖)

多任务关联执行(树状依赖)

多任务同步等待结果(任务组)

多任务优先级调度

任务延时调度

线程间通信

同语言线程间通信（ArkTS内）

跨线程交互场景	通信方式	通信优先级
宿主JS线程->TaskPool线程	参数传递后分发任务；过程中不支持正向通信	支持
TaskPool线程->宿主JS线程	结果返回；sendData触发宿主线程异步回调，底层为uv_async_send实现	不支持
宿主JS线程->Worker线程	采用postMessage&onmessage异步通信	不支持
Worker线程->宿主JS线程	异步方式：采用postMessage & onmessage异步通信 同步方式：支持Worker线程同步调用宿主线程注册的方法，并返回结果	不支持
任意JS线程<->任意JS线程	使用ohos.emitter实现双向异步通信	支持

线程间模块共享（单例模式）

实现方案介绍（方案二）

步骤一：采用ArkTS对象，定义Sendable类的单例，封装成共享模块（进程内共享），子线程进行初始化；

步骤二：初始化完成通知主线程，主线程导入使用该单例对象。

线程间不可变数据共享

实现方案介绍

通过冻结API，使共享对象变成只读对象。实现方案介绍：

步骤一：业务逻辑定义、生成需要的Sendable对象；

步骤二：发送到其他ArkTS线程前通过Object.Freeze API冻结该对象；

步骤三：通过taskpool或worker的消息通信机制将该对象共享到其他ArkTS线程。

生产者与消费者模式