happy最紧要1. 主线程卡顿的根因：渲染流水线为什么要“排队”
先还原一个真实到不能再真实的场景：用户丢过来一句话，“你这 APP 一加载就卡成 PPT”。我拿到手机一看，好家伙，列表滚不动，转圈一直转。查了半天，不是网络慢，不是后端挂了，就是代码里一个批量数据处理的大循环，结结实实跑在了主线程上。
为什么主线程不能跑大循环？这不是什么“规范要求”，而是底层机制决定的。
1.1 主线程到底在忙什么
在鸿蒙应用里，UIAbility 所在的主线程几乎是“全栈”的。它要处理用户输入事件，要执行 ArkTS 的业务逻辑，要跑布局计算，要负责绘制渲染，还得每帧去响应 vsync 信号。一个典型的帧周期只有 16.6ms，60Hz 刷新率下留给应用的总预算就这么多。
你随便打开 DevEco Studio 里的 Profiler，录一段操作，就能看到主线程的时间片被分成一堆细碎的片段：输入事件、原生回调、ArkUI 渲染、布局、动画、任务调度。每一块都是“过来排队”的状态。主线程本质上是一个巨大的事件循环，所有任务共享同一条车道。
这时候一个大循环进来，比如“循环 2 万次，每次解析一条 JSON，再逐条建对象塞进数组”，它在主线程上是同步执行的。意味着什么？意味着这个循环不跑完，后面排队的所有任务——包括用户点击事件、列表滚动事件、动画帧回调——全部被挡住。用户手指已经滑了，但事件进不了处理队列，界面自然就僵住了。
1.2 掉帧是怎么“肉眼可见”的
常见的误区是：“我这个循环也就 100ms，不至于多卡吧。” 算一笔账：100ms 意味着在 60Hz 刷新率下，直接丢掉了大约 6 个帧周期。任何投入市场的机型，一旦主线程阻塞 50ms 以上，用户就能感受到反应迟钝；超过 100ms，基本就是“卡死”的体验。
而且 ArkUI 是声明式 UI，状态变量一变，框架要重新执行 diff 和渲染流程。如果你的大循环在循环体内还去改状态变量（比如往一个数组里 push 元素，这个数组被 @State 装饰），那问题更严重——你以为只是最后刷新一次，实际上每一帧都可能触发脏检查、依赖收集和部分重绘。循环体和渲染流程在互相抢时间，卡顿只会加倍。
我见过最典型的反例是：在主线程里循环生成大量图片缩略图，每生成一张就 onSet 一下状态，整个相册页加载的时候 CPU 直接跑满，帧率掉到个位数。这种代码“本地跑两次觉得还好”，一上真机就是灾难。
1.3 为什么很多开发者还是会这么写
老实说，这里面有“思维惯性”的成分。不少开发者是从传统脚本语言或者嵌入式裸机开发转过来的，潜意识里认为“代码就是这样一行一行顺序跑的”，多线程意味着麻烦、锁、不确定。还有一部分是业务进度压力——需求紧急，先把功能跑通，“线程后面再优化”。结果功能是跑通了，体验却没通。
更隐蔽的原因是：在华为 DevEco Studio 里新建工程，默认模板不会逼你去想并发问题。你写完一个同步函数，编译能过、能跑，就自然认为“没问题”。直到真机上一慢，才回头看架构。
所以下一章，我把鸿蒙并发模型的基本盘彻底摆开。它的设计目标，恰恰是帮你把“并发”这事从“会不会”变成“该怎么选”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 鸿蒙并发模型的基本盘：Actor 是根，Worker 和 TaskPool 各管一摊
鸿蒙的并发模型和传统线程模型有个根本差异：它是基于 Actor 模型构建的。
2.1 Actor 模型的核心理念
Actor 模型用一句话概括就是：并发实体之间不共享内存，只通过消息传递来通信。每个 Actor 有自己独立的状态，别人拿不到你内部的数据，你想要某个结果，就得发消息请求，等它回消息。
这个设计和传统“多线程 + 共享内存 + 锁”相比，最大的优势在于：从根上掐死了数据竞争。两个线程同时改一个全局变量的情况，在 Actor 体系里根本不会发生，因为你连对方的变量都摸不到。代价也很明显：消息传递有开销，所以“小而频繁”的数据交换不适合走 Actor，适合“大而独立”的任务切分。
鸿蒙的并发能力就是在这个思想上长出来的。它不是简单给你一个 Thread，而是给你几种不同粒度的并发执行器，让你根据任务特点去选。
2.2 Worker：有独立线程、有完整生命周期的“常驻搬运工”
Worker 是鸿蒙最接近“传统线程”的并发工具。它会真正创建一个独立的线程，并且这个线程可以长期存活。你用 new worker.Worker('workers/xxx.js') 创建一个实例，通过 postMessage 传参数，onmessage 接收结果，干完活儿可以手动 terminate()，也可以让它继续待命。
适合 Worker 的场景，通常是这几种：
- 持续在后台运行的任务，比如音视频转码、流式数据处理。
- 需要保活、需要维护状态的任务，比如维护一个计算引擎的上下文。
- 任务被多次调用，每次都重新创建线程不划算。
但 Worker 有个现实问题：你得自己管生命周期。你创建了线程，就得负责销毁；页面销毁了线程没关，就泄漏；并发实例开多了，CPU 和内存开销都不小。它能力完整，但对使用者的自觉性要求也高。
2.3 TaskPool：任务级调度，用完即走的“临时工”
TaskPool 是另一种思路。它不让你接触线程，而是让你提交任务。你只需要写一个普通的函数（加上 @Concurrent 装饰器），调用 taskpool.execute()，它就会自动把任务丢进一个调度池子