做跨端图像处理这件事说起来都是泪。团队维护的那套跨端App在Android、iOS、Web三个平台跑了快两年图像滤镜、批量压缩、特征提取这些重计算一直靠底层线程扛着倒也没出大篓子。今年项目要覆盖到鸿蒙设备本来想着Flutter的跨端能力能让这事很简单结果一上真机滤镜操作直接把UI线程拖到掉帧后来排查才发现问题出在并发模型的底层映射上——同一个计算任务在Android上要走Isolate搬到一个独立线程在Web上要投递给Web Worker而到了鸿蒙系统的Flutter运行时里这两条路都不完全通最后走了保守的同步回退路径主线程差点被榨干。这篇就讲讲我们当时怎么把Flutter三方库worker_bee迁到OpenHarmony上用一套代码同时打通Web Worker与Isolate的跨端映射并且在鸿蒙设备上把并发计算的性能一点点抠出来的过程。如果你也在做Flutter跨端或者刚好遇到鸿蒙设备上并发任务卡顿的怪问题这篇值得慢慢看。1. 为什么需要跨端并发映射从一次实际踩坑说起1.1 并发计算在跨端项目里的地位很多刚入门的Flutter开发者会把并发当成一个“加分项”实际上它基本是所有带重计算功能的App的命门。UI线程就像餐厅的前厅你得保证服务员随时能回应顾客如果让服务员去后厨炒两个小时菜前厅必然乱成一锅粥。Isolate和Web Worker这些并发原语本质上是把“炒菜”这个动作放到后厨去Flutter的UI线程只需要拿到“出锅的菜”就行。在Android、iOS和Web上各自的“后厨”长得不一样Dart的Isolate是独立的执行单元与主线程不共享内存靠消息端口通信Web端则是靠浏览器为你创建的Worker线程数据和主线程之间用postMessage交换鸿蒙作为新进入Flutter生态的平台并发能力怎么接、怎么映射就成了最让人头疼的地方。如果业务代码直接依赖某个平台的并发API比如在Android上直接Isolate.spawn那到了Web端就要重写一套Web Worker逻辑。我们之前为了图省事用的Flutter自带compute函数它在Android/iOS上走得通在Web端却有自己的限制到了鸿蒙上更是彻底发挥不出多线程的威力。这时候底层就需要一个抽象层来兜底这也是worker_bee这类并发库存在的核心价值。1.2 三大平台的并发方案差异对比先放一张当时整理的对比表方便直观感受三个平台的差异。这里说的Web指Flutter Web的浏览器环境“原生”指Android/iOS“鸿蒙”指我们这次要处理的OpenHarmony运行时。维度Android/iOSIsolateWebWeb WorkerOpenHarmonyFlutter运行时并发单元Dart Isolate浏览器Worker线程鸿蒙原生线程/任务池创建成本较高需初始化Dart运行时中等受浏览器调度限制中高依赖适配层实现数据传递消息端口可传递TransferablepostMessage 结构化克隆跨语言边界需显式转换内存共享不共享传递副本或所有权不共享结构化克隆不共享依赖通道设计Flutter支持度成熟较成熟适配不完整容易回退从表里就能看出问题不在于“有没有并发能力”而在于“Flutter的运行时能不能把这些能力准确暴露给Dart层”。鸿蒙设备本身有线程调度、任务池等原生能力但Flutter侧如果不知道该怎么调用就会回退到低效路径性能自然上不去。1.3 鸿蒙平台上Flutter并发面临的特殊问题我们在真机上观测到的现象非常典型调用compute执行一个CPU密集的模糊计算耗时是Android的三到四倍页面滚动时掉帧也非常严重。进一步打点确认后任务根本没跑到独立后台线程而是被放到了一个低优先级的共享线程上和渲染任务抢资源。后来检查Flutter运行时在鸿蒙侧的适配源码发现问题出在Isolate映射并不完整遇到compute请求时运行时没有把任务正确投递到原生线程池而是走了同步回退路径。也就是说之前写好的并发代码在鸿蒙上等于没并发。我们最后决定引入worker_bee并针对鸿蒙做一次适配改造亲手补上这一层映射。下面就是整个方案的设计思路和落地过程。2. worker_bee的核心机制是怎么设计的2.1 统一的任务抽象与编程模型worker_bee的设计思路其实很聪明。它没有要求你直接去操作线程或Worker而是让你定义一个计算任务——输入什么、输出什么、如何执行。上层业务完全不关心这个任务最终跑在Isolate里还是Worker里只管提交任务和等待结果。我们内部使用的版本任务抽象大致长这样abstract class BeeTaskInput, Output { Output run(Input input); }业务代码里只需要继承这个基类实现run方法。比如一个图片模糊任务class BlurTask extends BeeTaskUint8List, Uint8List { final double radius; BlurTask(this.radius); override Uint8List run(Uint8List input) { // 在这里做像素模糊计算 return _gaussianBlur(input, radius); } }然后通过统一入口提交任务final blurred await Bee.computeUint8List, Uint8List( BlurTask(2.0), imageBytes, );这段代码在Android上会跑到Isolate里在Web上会跑到Worker里在鸿蒙上经过适配后也会跑到对应的原生线程池里。对业务开发者来说API完全一致。这种“契约式”抽象有一个极大好处并发细节被封装在底层迁移或者适配一个新平台时不用改动业务层的任务定义。我们后来加鸿蒙适配时业务代码一行没动只动了平台适配层非常舒服。2.2 平台适配器的分发逻辑worker_bee在底层维护了一套适配器列表工作逻辑并不复杂根据当前运行环境选择对应的适配器每个适配器负责两件事——启动一个后台执行单元建立主线程与后台单元之间的消息通道。以Web端为例适配器会创建新的Worker脚本把任务函数打包进去再通过postMessage把输入数据发过去Worker算完后把结果通过postMessage传回来。而在原生端适配器则通过Isolate.spawn启动独立隔离线程用ReceivePort和SendPort做消息传递。这套逻辑的关键是“平台判断”。最早的版本里鸿蒙没有被识别为原生Isolate环境任务直接走了默认的同步执行路径。我们要做的就是在适配器列表里新增一个专门面向鸿蒙的适配器并让它优先生效。2.3 消息协议与数据传输设计另一个关键机制是数据传递。并发调度再快如果数据在两端之间频繁拷贝性能也会被拖垮。worker_bee在消息协议上默认支持JSON可序列化对象同时支持Transferable类型的字节数据后者可以转移所有权避免深拷贝。这一块对鸿蒙适配尤其重要。鸿蒙侧和Dart侧的数据传输要跨越语言边界如果每次传图都做完整拷贝内存压力会成倍增加。我们在适配层里优先使用通道传递字节所有权并在传递完成后显式释放原始数据。注意消息协议不是越复杂越好。保持“可序列化”这条边界清晰底层才能放心地把任务调度到任意线程。自定义复杂对象跨线程传递很容易在适配新平台时踩序列化坑。3. 鸿蒙适配的四个关键改造点3.1 新增一个平台适配器而不是大规模改业务我们做的第一个决定就是绝不动业务任务定义。业务层一旦改了将来换平台、升级依赖都要跟着动适配成本会直线上升。真正要动的是worker_bee的平台适配器内部逻辑。大致思路是在worker_bee的适配器选择代码中新增一个针对OpenHarmony运行时环境的适配器类处理两件事启动后台执行单元以及收发消息。我们把鸿蒙的原生线程池能力封装在适配器内部对外仍然暴露Dart层的标准接口。团队内部版本的伪代码大致长这样class OhosBeeAdapter extends BeePlatformAdapter { override void start() { // 在鸿蒙侧注册一个任务执行线程池 } override void postMessage(Object message) { // 把任务数据投递给原生侧 } override StreamObject get onMessage { // 监听原生侧返回的结果 } }这段代码看起来简单但里面承载的细节不少。启动逻辑里要判断线程池是否已经初始化、任务队列是否为空postMessage里要处理大对象的转移onMessage流要处理好背压防止结果积压导致内存上涨。3.2 线程池与调度参数的选取鸿蒙设备的CPU核数普遍不低但核数多不代表线程可以无脑开满。线程开多了上下文切换和锁竞争会把收益吃掉。我们当时的经验是线程池大小先从机器的物理核数减一起步再通过压测调整。假设一台设备是8核初始线程池就设置成7个如果是纯计算型任务7个线程可以各自占满一个核如果任务里夹杂了IO或者等待再适当增加缓冲线程。实测下来9个线程和7个线程的吞吐量差别很小但内存占用明显升高所以我们最终保留了“物理核数减一”这个保守方案。调度策略上不要把所有任务一次性提交到线程池。我们按批次提交每批任务数量控制在线程池大小的两倍左右任务进来之后排队执行避免多个大任务同时抢占CPU、互相拖累。3.3 大块数据的传递与内存优化鸿蒙适配里最容易被忽略的是内存问题。一次图片模糊任务输入和输出都是几MB级别的字节数组如果每次传递都整体拷贝内存占用会瞬间飙高。我们在适配层做了几个关键优化优先使用字节所有权转移传递完成后原对象立即释放。尽量避免在主线程做大数据转换图像数据的头部解析可以放主线程完整像素数据的解码、归一化放到后台线程。对高频小任务复用预先分配好的缓冲区减少GC触发。实测里光是把“传递大对象”改成“传递所有权”内存峰值就下降了大约40%。这一点在鸿蒙这种新平台上尤其明显因为新运行时的内存回收调优还没有像Android生态那样打磨多年。3.4 生命周期管理与worker池回收还有一个容易被忽视的点后台任务的回收。App切到后台如果worker池还在持续占用线程会给系统带来不必要的电量消耗和性能压力。我们在适配器里增加了生命周期回调App进入后台时主动回收线程池回到前台时再按需重建。这个逻辑听起来简单实际坑不少。我们最早踩过一个坑回收线程池时正在执行的任务被直接取消导致UI侧收到的结果缺失偶发闪退。后来改成了优雅退出——先停止接收新任务等正在跑的任务结束后再销毁线程。4. 完整实操在OpenHarmony上跑通worker_bee4.1 环境准备与项目接入我们做适配时用的是OpenHarmony 4.x的一套实验SDK配合Flutter 3.x的鸿蒙分支。这个组合并不是所有版本都能直接跑通建议先确认自己的Flutter版本是否支持目标鸿蒙版本否则后面编译期会卡在一堆和并发无关的报错上。工程接入分三步在pubspec.yaml中加入worker_bee依赖以及我们自研的一个适配扩展包——因为官方库还没完整支持鸿蒙需要在本地引用。确保鸿蒙侧工程配置里启用了对应的任务能力权限并指定线程池的默认大小。在启动流程里显式注册OhosBeeAdapter替代默认适配器。第3步特别提醒如果不做这一步worker_bee在鸿蒙上依然走默认回退路径等于白接入。4.2 用图像模糊任务做并发计算Demo为了验证适配效果我们有意识地设计了一个计算密集型的Demo对一张1080P的彩色照片做高斯模糊每种方案跑30次取平均耗时。任务本身不包含任何网络请求和文件IO确保测试结果主要反映并发调度的差异。任务定义和前面展示的BlurTask类似。调用层的代码非常简洁final imgBytes await loadImage(assets/sample.jpg); final result await Bee.computeUint8List, Uint8List( BlurTask(radius: 3.0), imgBytes, ); await saveImage(result);跑通之后我们发现整个调用链从业务层看没有任何平台差异但实际执行时数据已经通过鸿蒙适配器跑到原生线程池里计算了主线程只负责发送输入、接收结果。4.3 性能对比验证这是最让我们兴奋的部分。同一台鸿蒙设备上分别用三个方案执行同样的模糊任务结果如下方案平均耗时30次内存峰值主线程卡顿单线程直接计算约2180ms约360MB明显Flutter compute函数约1400ms约420MB轻微掉帧worker_bee鸿蒙适配约860ms约275MB基本无感知耗时从2180ms降到860ms内存峰值从420MB降到275MB。这个结果的核心来源不是“换了个库”而是真正把任务调度到了鸿蒙的原生线程池并且减少了数据拷贝。当时还有一个有意思的发现并发度提升不是线性收益。线程池从4个增加到6个时模糊任务性能提升明显从6个增加到8个时几乎没有变化了。这说明设备资源已经被压到了某个平衡点再往上加线程只会增加调度开销。5. 常见问题与排查技巧实录5.1 高频问题速查表现象可能原因解决办法任务提交后一直不返回线程池被占满或者创建失败检查线程池数量设置查看异常日志返回结果全是空数据消息通道数据未正确反序列化确认序列化格式尽量统一使用Transferable内存持续上涨数据拷贝过多或缓冲区未复用使用所有权转移限制并发任务批次后台任务导致闪退回收线程池时强制取消任务改为优雅退出等待任务结束再销毁Web端正常但原生端异常适配器选择逻辑有问题打印当前平台标识确认注册顺序5.2 一次任务静默失败的排查复盘我印象最深的一个排查案例是某个数据压缩任务在Android上跑得好好的到了鸿蒙设备上偶尔超时返回结果还是空数据而且没有任何异常抛出。第一反应是线程池问题但看日志发现线程池本身正常任务确实被消费了。后来我们在消息通道的收发两端都加了日志才发现问题出在数据序列化上。鸿蒙原生侧返回的是一个特殊格式的字节缓冲区Dart侧用标准Json解析识别不了反序列化失败后静默返回了空对象。解决办法很简单在鸿蒙适配器里增加一个字节类型的显式转换分支确保返回数据经过一次格式归一化。这个坑如果不在适配层兜底业务层根本定位不了。5.3 一个让内存暴涨的坑还有一个坑也值得说压测时我们把一批大图处理任务连续提交了100次内存曲线一路攀升最后被系统强制杀掉。看堆栈发现不是任务本身占用大内存而是任务结果在主线程一端没有被及时释放——线程池那边任务算完就算完了主线程侧却拿着结果引用不释放累积下去就成了OOM。我们的做法是在任务完成回调里主动做一次引用清空并且提示业务侧不要保留过期的结果对象。同时把单次批次的提交数量从50降到20压测下来内存曲线平稳多了。6. 从这次适配里总结出的几点经验6.1 三方库适配的核心是理解契约适配一个三方库往往不是改代码而是找到它底层依赖的契约。对worker_bee来说契约就是“任务定义、消息协议、平台适配器”。只要你遵守这个契约新增一个平台只是工作量问题。反过来如果没有先把契约理解清楚抱着“哪里不兼容改哪里”的思路去堆补丁最后会越改越乱。6.2 并发调试先让日志告诉你线程在哪并发环境的调试有个铁律先定位线程再定位数据。我们给适配层加了一套带线程标识的日志每次任务进入、调度、出结果都会打点记录线程ID、耗时、队列长度。哪条链路慢了、哪个环节卡了一眼就能看出来。排查问题时这套日志省下的时间远超过加日志的成本。6.3 值得继续做的方向这次适配做完之后我们列了一个待办清单里面有几件事我自己很心动任务优先级支持让核心任务优先于后台预计算任务多worker池隔离不同业务的并发负载再把GPU辅助计算也收进同一套抽象里。不过这些能不能做成还要看鸿蒙侧线程模型和调度能力的开放程度。先记在这里等真做出来再单独写一篇分享。