别把耗时任务都丢进 async：HarmonyOS 里 TaskPool 和 Worker 的边界感

📌 一句话摘要

本文深入探讨了 HarmonyOS 中 TaskPool 和 Worker 的适用边界，通过实际案例和代码示例，指导开发者如何根据任务特性选择正确的并发方案，避免常见陷阱。

📝 详细摘要

文章以作者在 HarmonyOS 开发中遇到的实际性能问题为切入点，指出 async/await 并非多线程，CPU 密集型任务在主线程执行仍会导致 UI 卡顿。核心观点是：TaskPool 适合「短、散、可切分」的计算任务，如数据清洗、排序、分组；Worker 适合「长、独立、有自己状态」的后台任务，如持续 OCR、文件同步队列。文章通过一个本地数据整理页的完整示例，详细展示了如何将业务逻辑拆分为纯计算函数、封装服务类、处理页面生命周期和竞态条件。同时，文章还介绍了使用 TaskGroup 进行分块并行计算、Worker 的生命周期管理、常见坑位（如误用 async、忘记 terminate、任务切得太碎）以及性能优化建议（数据瘦身、分段回传、降级路径）。文章强调，并发方案的选择应以实际性能瓶颈为依据，避免过度设计。

💡 主要观点

- TaskPool 适合短、散、可切分的计算任务，Worker 适合长、独立、有自己状态的后台任务。 文章通过对比表格清晰界定了两者的适用场景：TaskPool 用于数据清洗、排序等输入输出清晰的任务；Worker 用于持续 OCR、文件同步等需要维护队列和状态的长任务。

后台任务应只做纯计算，不操作 UI，结果返回后由页面决定是否更新状态。 文章强调将业务逻辑拆分为纯函数，只传递纯数据对象，避免传递 UI 状态、Context 或组件实例，以保持边界清晰，减少脏状态。

处理页面生命周期和竞态条件是并发编程的关键，需使用 requestSeq 和 alive 标志。 文章通过代码示例展示了如何通过 requestSeq 防止旧任务结果覆盖新状态，以及通过 alive 标志避免页面销毁后更新 UI 导致的脏状态。

Worker 的生命周期管理至关重要，必须确保在任务完成、失败或页面销毁时释放资源。 文章指出 Worker 不是临时 Promise，需要手动 terminate()，否则会占用内存和线程资源，并提供了 cancel() 和 release() 的完整实现。

💬 文章金句

- async 不是多线程。这个坑，做前端或者移动端的人应该都踩过。它能把异步流程写得舒服一点，但 CPU 真在主线程上跑的时候，UI 该卡还是卡。

TaskPool 适合「短、散、可切分」的计算任务。Worker 适合「长、独立、有自己状态」的后台任务。
能传 number/string/boolean/普通数组/普通对象，就别传带行为的对象。能传 id，就别传整个业务实体。能传快照，就别传还会被 UI 修改的引用。
不卡的页面看起来没什么技术含量，真卡起来才知道前面省掉的边界，后面都要还。

📊 文章信息

AI 初评：88

来源：掘金本周最热

作者：李游Leo

分类：软件编程

语言：中文

阅读时间：21 分钟

字数：5191

标签： HarmonyOS, TaskPool, Worker, 并发编程, 性能优化

阅读完整文章

别把耗时任务都丢进 async：HarmonyOS 里 TaskPool 和 Worker 的边界感

🤖 問 AI