TaskPool+主线程降级：鸿蒙拼豆图案导出管线优化

鸿蒙专家

在HarmonyOS应用中，导出高分辨率PNG图像时，如果将所有像素填充计算放在主线程，很容易导致UI卡顿。例如，一个128×128格子的拼豆图案，每格填充32×32像素，总像素数超过1600万，主线程执行约需800ms，期间界面会完全冻结。本文分享一条基于TaskPool并行填充缓冲区、主线程降级兜底、并修复RGBA→BGRA通道色偏问题的导出管线，适用于拼豆图案、像素画、十字绣等大尺寸图像导出场景。

一、导出管线整体架构

管线分为四个阶段：
1. 计算每格像素大小（cellPx），根据格子数量确定最终图像尺寸，确保不超过4096×4096的安全上限；
2. 填充RGBA缓冲区——这是耗时最长的阶段（占总耗时70%~85%），优先使用TaskPool在Worker线程并行执行，失败时回退到主线程分块渲染；
3. 将RGBA缓冲区交换为BGRA格式，以匹配HarmonyOS的PixelMap内部编码；
4. 创建PixelMap、编码PNG并写入文件。

二、TaskPool并行填充的要点

TaskPool是HarmonyOS提供的线程池API，适合分发CPU密集型任务。使用时有几个关键约束：
- 被@Concurrent修饰的函数，参数必须是可序列化的原始类型或ArrayBuffer，不能传入ArkUI的@State对象、PixelMap等。
- 不支持boolean类型参数，需用number代替（0/1）。

因此，需要将ArkUI数据“翻译”为普通数组。例如，将调色板对象数组（AoS）转换为结构数组（SoA）格式：将每个颜色的R、G、B分别存入三个平铺数组，这样在热循环中每次访问只需一次数组索引，省去了对象属性和方法查找。在JS引擎中，这种SoA优化可带来15%~25%的性能提升，尤其在调色板颜色较多时效果更明显。

另外，@State修饰的数组可能被Proxy包裹，直接传给TaskPool会导致DataCloneError。解决办法是在调用前用Array.from()克隆一份普通数组。

三、主线程降级路径

TaskPool并非在所有设备上都能稳定运行，某些版本存在bug或限制。为此准备了降级方案：在主线程分块填充缓冲区。

将图像高度分成12块（经验值，太少每块耗时过长，太多上下文切换开销大），依次填充每一块，并在每块填充完成后调用yieldToMain()（即setTimeout(0)返回的Promise）让出事件循环，使UI能够更新进度条并响应用户操作。

四、RGBA→BGRA通道交换

HarmonyOS的PixelMap在编码PNG时内部使用BGRA格式，而逻辑缓冲区是RGBA。直接创建PixelMap会导致红蓝通道互换，导出的图片偏蓝。修复方法很简单：在编码前遍历缓冲区，交换每像素的R和B字节，G和A保持不变。这个操作对4096×4096图像大约耗时30ms，可在TaskPool中或主线程直接完成。

五、自适应进度条

为提供流畅的用户体验，采用四档自适应假进度与真实进度取最大值的策略：
- 进度0~70%时，每240ms增加1%；
- 70%~80%时，每520ms增加1%；
- 80%~90%时，每720ms增加1%；
- 90%~99%时，每1000ms增加1%。

真实进度来自管线各阶段的完成标记。两者取Math.max保证进度条永不回退，且最终稳定跳至100%。同时设置5秒超时保护，避免假进度无限循环。

六、踩坑记录

1. TaskPool参数序列化：不能传入@State Proxy、布尔值、PixelMap等，务必在调用前转为纯数据。
2. ArrayBuffer的复制问题：TaskPool默认复制ArrayBuffer而非转移，导致内存峰值翻倍（64MB缓冲区变成128MB）。解决方案是使用较小的中间缓冲区，分块处理后合并。
3. 色彩偏差：RGBA与BGRA顺序不同导致偏蓝，需在编码前做通道交换。
4. 编号模式的字体渲染：无像素级文字API，采用预制5×7点阵位图，每个数字占用35字节（共73个数字约2.5KB），渲染时逐像素绘制。
5. 真假进度冲突：单独使用假进度会导致跳变，单独使用真进度因TaskPool无内部回调而无法更新。两者取最大值解决了平滑度与准确性矛盾。

七、性能数据

TaskPool并行填充相比主线程，真实计算时间差异不大，但UI响应完全不受影响（进度条动画正常、按钮可点击）。在128×128格子、每格32×32像素的场景下，TaskPool方案使得导出过程用户感知流畅，无卡顿感。

这套管线的设计思路可推广至任何需要将结构化数据转换为大尺寸图像的场景：如十字绣导出、像素画导出、地图瓦片生成、热力图渲染等。核心模式固定为“计算缓冲区大小→并行填充→通道转换→编码”，仅填充逻辑需按业务定制。

热心网友6

感谢分享！这套导出管线的设计非常实用，特别是TaskPool并行填充与主线程降级兜底的组合策略，兼顾了高性能和稳定性。对S oA数据格式优化、RGBA→BGRA通道交换以及自适应进度条的处理也很细致，尤其是踩坑记录中关于ArrayBuffer复制导致内存翻倍的解决方案，很有参考价值。期待后续能分享更多关于HarmonyOS性能优化的实践。

热心网友6

感谢楼主分享这么详细的优化方案！把TaskPool并行填充和主线程降级结合起来，既保证了UI流畅，又考虑了兼容性，确实很实用。特别是SoA数组转换和假进度与真实进度取最大值的思路，很有启发。 想请教一下，在实际分块填充时，如果格子数量很大（比如超过256×256），TaskPool的任务粒度如何设置比较合适？是按格子分还是按像素块分？另外，通道交换在C++层面做会不会更快一些？希望楼主能再补充些细节。

热心网友6

这个思路非常实用，尤其是TaskPool失败时主线程分块渲染加yieldToMain()的降级设计，既保证了性能又兼顾了UI流畅。之前我试过直接在主线程跑导出，确实卡到怀疑人生。想请教一下，你们在实际设备上遇到TaskPool无法创建或执行失败的具体场景多吗？另外，分块渲染的12块这个经验值在不同分辨率的设备上是否需要调整？谢谢分享。