★ FEATURED ARTICLE 做鸿蒙应用开发的人迟早会遇到同一个问题明明把耗时逻辑放进了Promise里界面为什么还是会卡这背后的原因不复杂——异步不等于多线程Promise只是把任务塞进事件队列真正的CPU密集型计算依然占着主线程不放。HarmonyOS 6把多线程并发能力进一步收敛到两个入口TaskPool线程池和Worker线程一个负责把任务丢给系统调度一个负责在独立线程上常驻通信。这篇是系统能力系列的第7篇我结合自己实际项目里踩过的坑把这两套机制的通信链路、数据传递方式和选型边界一次讲透。适合刚接触鸿蒙并发开发的初学者也适合已经用过TaskPool和Worker但没搞懂底层逻辑的人。1. 单线程模型跑不满CPU多线程需求从哪来1.1 ArkTS的异步不是并行ArkTS的运行时模型和JavaScript类似主线程只有一个事件循环。你在代码里写的setTimeout、Promise回调、异步接口回调本质都是往事件队列里排队事件循环空闲时再逐个执行。这意味着两件事第一主线程同一时刻只能做一件事第二所谓异步只解决等待I/O时不阻塞并不能解决计算本身太重的问题。我见过不少刚上手的人写这样的代码function heavyTask(): number { let sum 0; for (let i 0; i 100000000; i) { sum Math.sqrt(i); } return sum; } Promise.resolve().then(() { heavyTask(); // 主线程依旧被长任务卡死 });这段代码里heavyTask虽然在Promise回调里执行但它仍然跑在主线程上。只要它不结束用户滑动列表、点击按钮、页面转场全都得等它。异步IO可以交给系统去等但纯计算必须开新线程才能真正并行。1.2 什么时候真正需要多线程不是所有耗时操作都需要多线程。我先列几个判断标准操作是否超过100毫秒、是否持续消耗CPU、是否在用户交互的关键路径上。网络请求本身不需要开线程因为底层IO是异步的但拿到响应后做JSON解析、图片压缩、加密解密、复杂计算这些是典型的CPU密集段。我在项目里遇到的三类典型场景基本覆盖了大部分并发需求列表快速滑动时对网络图片做缩略图裁剪和滤镜处理处理速度必须跟得上滑动帧率。后台批量同步本地数据需要对几千条记录做格式转换、去重、排序整个过程不能影响用户操作页面。长连接场景里收包后要做协议拆包、校验和业务解析且解析频率很高需要一条常驻线程持续处理。第一类适合用TaskPool任务短、数量多、来一个处理一个第二类也适合TaskPool通过任务组批量调度第三类就必须考虑Worker了因为连接和解析是长生命周期的状态化工作不能每次新建线程再从零初始化。2. TaskPool把任务交给系统调度而不是自己开线程2.1 从创建Task到拿结果TaskPool的核心思路很直接你定义一个可以被并发执行的函数把它包装成taskpool.Task然后交给taskpool.execute执行。真正跑在哪个线程、线程池里有多少线程、什么时候调度都由系统决定开发者不需要也最好不要手动干预。一个最小可用的TaskPool例子是这样的import { taskpool } from kit.ArkTS; Concurrent function calculatePrimes(limit: number): number[] { const primes: number[] []; for (let n 2; n limit; n) { let isPrime true; for (let i 2; i * i n; i) { if (n % i 0) { isPrime false; break; } } if (isPrime) { primes.push(n); } } return primes; } const task new taskpool.Task(calculatePrimes, 50000); taskpool.execute(task).then((result) { console.info(prime count ${(result as number[]).length}); });这里有个关键点是Concurrent装饰器。它告诉系统这个函数可以被调度到独立工作线程执行。Task构造函数的第二个参数开始是传给这个函数的实参参数必须是可序列化的普通对象不允许传递函数、也不允许引用函数外部的状态。2.2 任务组、优先级和取消TaskPool不是只能一个一个执行任务。当你有一批相互独立的计算任务时可以用TaskGroup把它们打包一次提交等全部完成后统一拿到结果数组const group new taskpool.TaskGroup(); group.addTask(new taskpool.Task(calculatePrimes, 10000)); group.addTask(new taskpool.Task(calculatePrimes, 20000)); group.addTask(new taskpool.Task(calculatePrimes, 30000)); taskpool.execute(group).then((results: object[]) { // results[0] 对应第一个任务的结果顺序和添加顺序一致 });这种方式比逐个execute的好处在于系统可以对整组任务做统一的调度和资源管理减少反复提交的开销。优先级也很有用。比如用户正在快速滑动列表图片处理任务的优先级可以适当降低让滚动事件和渲染任务占用主线程资源用户点击立即生成报表时对应任务可以给HIGH优先级taskpool.execute(task, taskpool.Priority.HIGH);取消功能要留意一个边界taskpool.cancel(task)只能取消还在排队中、尚未开始执行的任务。如果任务已经跑在工作线程里取消指令到达时线程并不能真正做到掐断正在运行的代码只能等它执行完。所以不要在任务函数里写无限循环否则取消也救不了你。2.3 任务函数和数据传递的硬性约束TaskPool的任务函数有几个约束违反任何一个都可能运行时报错。我吃过的亏是任务函数引用了同文件里的工具函数或全局变量。// 这段代码大概率执行失败 let baseConfig { retryCount: 3 }; Concurrent function badTask() { return baseConfig.retryCount; // 非法引用了函数外部对象 }原因在于任务函数和调用它的宿主跑在不同线程、不同模块上下文里。系统需要把函数本身和参数序列化后投递到工作线程外部变量不会跟着一起穿越过去。正确做法是把一切依赖都作为参数显式传入Concurrent function goodTask(config: { retryCount: number }): number { return config.retryCount; } taskpool.execute(new taskpool.Task(goodTask, { retryCount: 3 }));数据传递同理。参数和返回值都涉及跨线程传输系统会做序列化/反序列化。普通对象、数组、字符串、数字、布尔值都没问题Date、Map、Set这类对象在部分版本里也做了支持但不要依赖自定义类的实例。遇到复杂对象最稳妥的做法是拆成纯数据对象或者用JSON字符串中转。3. Worker一条独立线程上的常驻通信链路3.1 创建Worker和它的生命周期Worker和TaskPool最大的区别是Worker是一条属于你的、独立命名的线程从创建到销毁都由你管理。它适合那些需要长期存在、内部有状态、且要持续和主线程双向通信的任务。创建Worker的代码很简单import { worker } from kit.ArkTS; const wk new worker.Worker(entry/ets/workers/CalcWorker.ts, { name: CalcWorker });第二个参数里的name是给这个Worker起的名字不是必须的但多Worker场景下非常有用。脚本路径要写对IDE工程模板里一般会生成src/main/ets/workers目录把Worker脚本放在这个目录下路径按模块名写。Worker线程内部的代码框架是这样的import { worker } from kit.ArkTS; const parentPort worker.parentPort; parentPort.onmessage (event: worker.MessageEvent) { const data event.data as { seq: number; payload: string }; // 在这里做耗时处理 parentPort.postMessage({ seq: data.seq, echoed: data.payload }); };parentPort就是Worker线程和主线程之间的门。主线程通过wk.postMessage发消息Worker通过parentPort.onmessage接收Worker回复时通过parentPort.postMessage发出去主线程通过wk.onmessage接收。这是一条全双工消息通道两边都能主动发起通信。生命周期管理是Worker最容易被忽视的部分。主线程销毁Worker用wk.terminate()Worker内部也可以自己调用parentPort.close()退出。页面退出之前不终止Worker线程就会继续活着这里面藏着内存泄漏风险。我第5章会专门展开。3.2 postMessage背后发生了什么Worker通信的默认机制是数据结构化克隆。你可以把postMessage想象成主线程把消息内容完整复制一份塞进Worker线程的入站队列Worker线程的事件循环再把这份副本取出来用。整个过程对开发者是透明的但代价是复制耗时。如果消息数据只有几十字节这个代价可以忽略但如果是一张图片的base64字符串或者一个几十MB的JSON主线程在调用postMessage的那一刻会发生明显的卡顿因为结构化克隆是在调用线程里同步完成的。遇到大块二进制数据比如图片、音频、文件切片最有效的优化是用ArrayBuffer转移所有权const buffer new ArrayBuffer(1024 * 1024); // 第二个参数是transfer列表buffer的所有权会被转移到Worker线程 wk.postMessage(buffer, [buffer]); // 到这里主线程侧的原buffer已经不可用了转移所有权和克隆的区别在于克隆是我留一份再给你一份转移是这份东西彻底给你我这边不再持有。这避免了复制开销但语义约束很强转移之后主线程如果还去读这个buffer会得到不可预期结果。3.3 多Worker场景下的消息怎么路由一个应用里可以创建多个Worker每个Worker都是独立线程、独立消息队列。但它们之间没法直接互发消息所有通信都要经过主线程中转。这就有点像几个外包团队互相不能直接对接所有信息都通过项目经理转发。多Worker时主线程收到消息后需要知道判断这条消息是哪个Worker发来的。最直接的做法是在Worker实例自己的onmessage回调里处理因为每个实例的回调是独立的const wkA new worker.Worker(entry/ets/workers/WorkerA.ts); const wkB new worker.Worker(entry/ets/workers/WorkerB.ts); wkA.onmessage (event) { console.info(A says: ${JSON.stringify(event.data)}); }; wkB.onmessage (event) { console.info(B says: ${JSON.stringify(event.data)}); };如果主线程要给指定Worker发消息直接调用对应实例的postMessage即可。消息本身也可以带from、to之类的字段做统一的订阅分发。我的经验是多Worker通信越简单越好不要让两个Worker之间做复杂的消息依赖一旦消息乱序或丢失排查成本极高。4. 通信机制对比TaskPool和Worker谁是更优解4.1 线程模型上的根本差异表面上TaskPool和Worker都能执行耗时任务但它们的设计出发点完全不同。TaskPool是一组共享的、由系统调度的工作线程。你提交一个任务系统从池子里挑一个空闲线程来跑跑完再回收。开发者完全不知道也不关心任务落在哪个线程上。好处是系统能做全局调度避免开发者手动创建过多线程代价是任务的执行环境和上下文是短暂、无状态的每次任务提交都要做一次函数和参数的投递。Worker是一条开发者完全拥有的独立线程。创建之后这个线程会一直存在内部变量、缓存、连接状态都保留着直到你显式销毁它。它的消息通道是长连接式的可以随时双向通信但线程资源由你负责管理管理不当就会泄漏或过度占用。4.2 一张表直接对照对比维度TaskPoolWorker线程归属系统统一管理的线程池开发者独立创建和持有生命周期跟随任务执行完即回收跟随Worker实例直到terminate/close任务形态无状态函数适合短任务有状态常驻逻辑适合长任务通信方式提交参数、返回结果双向消息通道任意时刻可互相发消息数据传递序列化拷贝结构化克隆 ArrayBuffer转移并发调度系统决定线程数和调度策略开发者自己决定创建几个Worker典型场景图片处理、批量计算、临时任务长连接、状态机、持续采集、复杂业务驻留使用门槛低不用管生命周期中高需要处理创建、销毁、错误恢复这张表是我在做选型时反复对照的清单。项目里不是必须二选一两类机制完全可以共存大量短计算任务交给TaskPool常驻的服务型任务交给Worker。4.3 我的选型顺序我给团队的约定很简单按这个顺序判断如果任务是来了就做、做完就走默认用TaskPool。不要自己开线程不要让任务的清理逻辑散落在业务代码里。如果任务需要初始化一次资源之后反复使用这些资源处理不同输入比如一个对象检测模型、一个缓存连接池那就用Worker。把初始化放到Worker内部消息里只传输入和结果。如果业务是持续性的双向交互比如WebSocket协议层、音视频流处理直接上Worker。TaskPool不适合维护这种长连接状态。如果既要做大量计算又需要实时进度回调优先考虑TaskPool加主线程接收结果的方案只有当TaskPool的无状态约束实在满足不了时才用Worker自己维护回调。这套顺序帮我在项目里少踩了很多坑。最怕的不是选错而是反复横跳今天用Worker写了个一次性任务明天嫌生命周期麻烦又改TaskPool最后两边都不熟。5. 排错现场通信机制里最容易踩的坑5.1 大对象在postMessage里的同步拷贝卡顿我有一次处理一个实时图像预览功能主线程把每一帧的原始数据通过Worker去做算法处理结果界面掉帧非常明显。一开始以为是算法慢后来打了点才发现卡顿发生在主线程调用postMessage那一下——几MB的帧数据被结构化克隆时同步执行主线程在那几十毫秒里什么都做不了。后来改成ArrayBuffer所有权转移主线程发消息的开销直接降到接近零掉帧问题立刻缓解。这里有个经验凡是大于几百KB的二进制数据优先考虑转移而不是克隆。虽然转移后主线程失去这块buffer的所有权但你可以提前准备一个buffer池用完再由Worker把内存归还或重新分配。5.2 TaskPool任务函数引用外部变量直接失败第一次用TaskPool时我写了个任务函数内部调用了一个模块级工具函数结果运行时提示任务执行失败日志指向函数不可序列化之类的问题。排查了很久才发现任务函数的依赖链上不能有任何外部引用所有工具函数要么写成内部嵌套要么作为参数传入要么干脆把逻辑全放在Concurrent函数体里。这确实是TaskPool的上手门槛。我的建议是凡是给TaskPool用的函数当成一个独立小程序来写打印日志、错误处理、工具函数都尽量收敛到函数内部。刚开始会有点不习惯但熟悉后反而会觉得清爽因为任务函数的逻辑更纯粹了。5.3 Worker没有terminate导致的内存泄漏页面A创建了一个Worker页面销毁时没有调用wk.terminate()Worker线程带着它内部的所有对象继续驻留。反复进出页面几次内存持续上涨最终被系统回收掉的是整个进程。这种问题在真机上比模拟器更容易暴露因为真机内存竞争更激烈。我的做法是在页面的aboutToDisappear生命周期里统一销毁所有WorkeraboutToDisappear() { if (this.calcWorker) { this.calcWorker.terminate(); this.calcWorker null; } }同时给Worker内部也加一个自杀通道主线程发来shutdown指令时Worker完成手头收尾工作后调用parentPort.close()。双保险比单靠主线程强制销毁更稳。5.4 子线程不能直接碰UI结果回传也要走宿主线程有些新手在Worker里拿到数据后试图直接更新组件状态这是行不通的。Worker线程里没有UI上下文强制操作要么报错要么什么都不发生。正确路径是Worker把结果postMessage回主线程主线程的回调在UI宿主线程中执行再通过组件状态或全局状态管理去刷新界面。TaskPool的结果也类似execute().then()里的回调最终会切回宿主线程执行所以你可以放心在里面更新UI。这是TaskPool比Worker更顺手的一个点它帮你处理了线程切换的时机。6. 数据量大时怎么办共享内存和缓冲池思路6.1 ArrayBuffer所有权转移的正确姿势先看一个标准用法主线程准备一块buffer把它转移给WorkerWorker处理后把结果buffer再转移回来。// 主线程 const sendBuffer new ArrayBuffer(4 * 1024 * 1024); wk.postMessage({ type: process, buffer: sendBuffer }, [sendBuffer]); // Worker内 parentPort.onmessage (event) { const data event.data; // 处理 data.buffer const resultBuffer new ArrayBuffer(2 * 1024 * 1024); parentPort.postMessage({ type: result, buffer: resultBuffer }, [resultBuffer]); };注意postMessage的第二个参数是transfer数组里面放的是要转移所有权的ArrayBuffer。这样做之后发送方原来的buffer长度会变为0再次写入会抛错。很多人的第一反应是那我还要继续用原buffer怎么办解决办法是提前分配两块或多块buffer交替使用或者等Worker把结果回传时把用完的buffer再转移回来实现循环复用。6.2 做一个简单的工作线程缓冲池当Worker长期处理视频帧这类高频数据时每次都new一个ArrayBuffer再销毁GC压力会非常大。更稳的做法是维护一个空闲buffer列表主线程从池里取空闲buffer填充数据后转移给WorkerWorker处理完把用完的buffer再转移回主线程插入空闲池。这种缓冲池代码不复杂核心就是两边各维护一个数组靠transfer语义避免复制class BufferPool { private idle: ArrayBuffer[] []; acquire(size: number): ArrayBuffer { let buffer this.idle.pop(); if (!buffer || buffer.byteLength size) { buffer new ArrayBuffer(size); } return buffer; } release(buffer: ArrayBuffer) { if (buffer.byteLength 0) { this.idle.push(buffer); } } }这只是最基础的思路生产环境还要考虑buffer回收、线程安全的入队出队、池上限等。但核心价值已经体现出来了跨线程通信不一定每次都要产生一颗新对象炸弹复用可以让长期高频任务的内存曲线稳定得多。我在实际项目里把这块优化做完之后持续几小时的视频流处理任务内存占用从持续爬升变成了平稳波动。对追求极致性能的场景来说通信机制只是入门数据在跨线程之间的搬运方式才是真正的决战场。多线程并发这部分我的体会是TaskPool和Worker都不是银弹但它们把鸿蒙应用开发者从手动管理线程的泥潭里拉了出来。了解每一条通信路径上发生了什么你才能在性能优化这件事上做出对的选择。希望在HarmonyOS 6上做并发开发遇到瓶颈的读者看到这里能少走一些弯路。
阅读完成 · 觉得有帮助？
