这阵子在折腾 Flutter 往鸿蒙上迁移手头恰好有个需求要做远程桌面让手机能够实时看电脑画面、顺带能点两下鼠标。翻了一圈方案最后选了 dart_rfb 这个 VNC 客户端库。之所以选它一是纯 Dart 实现理论上可以不写原生代码二是它对 RFB 协议的核心流程封装得比较完整握手机制、编码协商、帧更新回调都有不像自己撸协议那样要从字节流开始造轮子。结果实际开工之后才发现理想很丰满编译没问题一跑起来各种 MissingPluginException、渲染黑屏、握手失败的问题轮着来。这篇文章就把我这次把 dart_rfb 搬到鸿蒙 Flutter 工程里的完整过程记录下来包括协议层面的关键逻辑、真正需要改的代码位置、低延迟优化手段以及那些不踩一遍根本不会知道的坑。1. 为什么要在鸿蒙上折腾 dart_rfb背景与选型1.1 VNC 到底在解决什么问题VNC 远程桌面的底层是 RFBRemote Frame Buffer协议通俗点讲它做的事情就是服务端把屏幕当成一块巨大画布客户端请求某一区域的像素数据服务端把“画布上的变化”发给客户端客户端负责把像素画出来同时把键盘鼠标事件回传给服务端。它的核心优势在于协议本身极其简单没有复杂的媒体编码没有流状态机一条 TCP 连接承载所有消息帧更新可以按需拉取。所以很多跨设备的屏幕监控、远程协助、无人值守系统都喜欢基于 VNC 来做。相比直接用 RTSP 推流或者自己采集视频流走 WebRTCVNC 方案的优点是门槛低、兼容老设备、数据量可控。如果你只是要“低延迟”地看清界面、偶尔操作一下VNC 这套广播式的像素更新已经够用。1.2 为什么选择 dart_rfb 而不是自己实现 RFB我一开始也想过直接照 RFB 协议文档写一个纯 Dart 客户端但深入了解后放弃了。RFB 虽说不复杂可是细节多到烦人协议版本协商有 3.3、3.7、3.8 三个常见版本认证又要处理 None、VNC Authentication、RA2、RA2ne、Tight 等多种安全类型进入初始化阶段后还要解析服务端的像素格式、名称和尺寸之后每次画面前都要协商编码至少把 Raw、CopyRect、Hextile、Zlib、ZRLE 这几种常见编码的 decode 写完再加上光标、桌面尺寸变更这种伪编码说实话半个月不一定能稳定跑通。dart_rfb 把这些都做成了一套相对完整的状态机你只需要提供一个 socket、实现回调、请求更新。它内部已经处理了从 ProtocolVersion 开始的字节解析也支持了常用编码。要不是它有这个底子在我不会轻易选这条路。1.3 鸿蒙化意味着什么这里说的“鸿蒙”我踩的是 HarmonyOS NEXT 以及对应的 OpenHarmony SDK 下通过 Flutter 引擎跑 Dart 代码的这条技术路线。它与 Android 最大的区别在于不兼容 APK不暴露 Java 层所有能力都走 ArkTS / Native 的接口。Flutter 上大部分插件默认只实现了 Android 和 iOS 的平台通道鸿蒙上并不会自动变成可用状态。所以“鸿蒙化适配”实际上分为两层第一层是让 dart_rfb 这种纯 Dart 包能编进鸿蒙 Flutter 工程第二层是让 Flutter 引擎在鸿蒙设备上能正常使用网络、纹理渲染、输入事件这些底层能力。渲染编解码是全 Dart 的部分一般问题不大真正的雷区通常在系统能力差异上后面会一个个讲。2. dart_rfb 的协议核心逻辑拆解2.1 一次 VNC 连接的完整生命周期把 dart_rfb 的源码翻开后会发现它的核心逻辑其实可以类比成一个状态机客户端先连上 TCP发送 ProtocolVersion比如 “RFB 003.008”同时读对端的版本号取版本交集。随后进入 SecurityType 消息服务端列出支持的安全类型客户端选择一种。最常见的是 None 和 VNC Authentication。VNC Authentication 的套路是服务端发 16 字节 challenge客户端用密码做 DES 加密后返回且密钥的每一位反转后才能用。认证完成后是 SecurityResult继续走 ServerInit服务端把屏幕宽高、像素格式、桌面名一次性发过来。之后客户端可以发 SetPixelFormat、SetEncodings、FramebufferUpdateRequest每发一次请求服务端回复一个 FramebufferUpdate里面包含一个或多个矩形区域。我在鸿蒙上遇到的一个典型坑就在 ProtocolVersion 这里。有些老旧的 VNC 服务端还停留在 3.7 甚至 3.3而 dart_rfb 为了保持整洁可能会直接按 3.8 走。如果你连的是一台十年前的内网工控机大概率会在握手阶段卡死。解决办法不能指望库自动降级得在连接前加一个探测逻辑先用 Socket 连接上但初始化协议版本号时容忍对端更低的版本把 dIY 客户端版本回退到二者兼容的数值。2.2 编码格式与帧更新低延迟的命门VNC 的低延迟体验很大一部分取决于编码协商。Raw 编码就是直接甩原始像素数据量巨大适合初次全屏CopyRect 编码会告诉客户端“把屏幕某个矩形区域从另一个偏移位置拷贝过来”在窗口拖动时非常省钱Hextile 是 16x16 瓷砖拼图会根据 tile 内容做颜色继承Zlib 和 ZRLE 则在此基础上加了压缩。dart_rfb 默认会注册若干可用的编码解码器但它不会替你选择最优组合。如果你直接全屏不断请求 Raw在 1080p 分辨率下带宽需求能跑到几百 Mbps鸿蒙手机哪怕 Wi-Fi 再好也扛不住。所以我的建议是连接建立后不要用默认的编码列表要按照服务端能力动态协商await client.setEncodings([ Encoding.copyRect, Encoding.hextile, Encoding.zlib, Encoding.raw, // 最后兜底 ]);这里 setEncodings 的具体接口名在不同版本里有差异你看完源码里的注释就能对上。重点是编码列表的顺序越靠前表示越优先。把 CopyRect 放在最前面是因为远程桌面大多数时候都是大面积静态区域偶尔窗口移动一下CopyRect 能大幅减少流量。2.3 dart_rfb 里容易栽跟头的抽象边界dart_rfb 在实现上把自己定位成“VNC 客户端协议库”它提供像素字节流和区域位置但不负责到底怎么画到屏幕。这样设计的好处是灵活你可以把帧数据传到底层纹理、PlatformView、甚至转成图片发出去坏处是鸿蒙适配时“渲染”这最后一公里得自己写。我当时读它的 Frame 回调从里面拿到的是一连串 Rectangle 对象或者 Uint8List 像素数据。如果你直接把这个字节数组丢给 RawImageFlutter 会先把它当成一个 MemoryImage 去解码而 VNC 帧通常是裸 RGBA 数据没有 PNG 头MemoryImage 根本认不了。所以必须把回调里的像素转换为ui.Image再用 RawImage 或 Texture 来渲染。3. 鸿蒙 Flutter 工程里的适配实操记录3.1 工程准备与依赖改造先说结论dart_rfb 不需要改一大片原生代码大部分工作是在 Dart 侧收尾。我用的鸿蒙 Flutter 工程是 DevEco Studio 里基于 hvigor 构建的pubspec.yaml 引入依赖的方式和普通 Flutter 工程几乎一样。但有一个问题pub.dev 上的 dart_rfb 老版本可能依赖了一些在鸿蒙上不被支持的传递依赖或者使用了dart:ffi之外的实验特性。稳妥一点的做法是不要去直接依赖远端包而是把 dart_rfb 源码 clone 下来扔进项目里以 path dependency 的方式引入。这样改起来方便也方便断点调试。dependencies: flutter: sdk: flutter dart_rfb: path: ./third_party/dart_rfb然后要处理鸿蒙的网络权限。HarmonyOS 应用默认不申请网络权限所以必须打开模块的entry/src/main/module.json5在requestPermissions里加上 INTERNET{ name: ohos.permission.INTERNET }这一步漏了的话现象非常诡异Socket 连接不报错也不会超时但就是迟迟收不到服务端的数据因为请求在系统网络层就被静默拦掉了。这个坑我排查了整整一个晚上。3.2 真正需要动代码的地方把包放进来之后第一件要确认的是它有没有依赖dart:io独有的能力。dart_rfb 用dart:io的Socket做连接鸿蒙 Flutter 引擎同样实现了dart:io所以这块天然兼容。真正需要动的地方集中在三块第一块Socket 连接方式。鸿蒙系统对应用在后台联网有限制且多网卡路径选择策略和 Android 不太一样。连接前建议用Socket.connect直接指定地址和端口不要依赖未指定的默认路由。第二块数据读取与背压。dart_rfb 基于Stream读取 socket 数据鸿蒙上如果 UI 线程的解码速度跟不上网络速度你会看到一个现象画面越来越卡内存持续上涨。这个问题本质是解码速度没有跟上生产者后文会详细说解法。第三块定时器。协议里的某些伪编码或者状态机里的超时判断依赖Timer鸿蒙 Flutter 引擎的标准Timer实现没问题但如果你用了dart:io的Socket.timeout方法注意它的单位是毫秒而非秒虽然这是 Dart 的标准但跨端移植时很容易惯性写错。3.3 像素格式转换与渲染上屏VNC 服务端在 ServerInit 阶段会告诉我们它的 pixel format一般有三种情况32 位真彩色RGBA 或 BGRA、16 位高彩色、8 位索引色。dart_rfb 内部虽然做了像素格式到标准 RGBA 的转换但在鸿蒙 Flutter 上渲染时还得考虑字节顺序。我的做法是写一个统一的VncView组件专门负责把ui.Image渲染出来void _onFrame(Rectangle rect, Uint8List rgbaBytes) { ui.decodeImageFromPixels( rgbaBytes, rect.width, rect.height, ui.PixelFormat.rgba8888, (ui.Image image) { setState(() { _latestImage image; _repaintRect rect; }); }, ); }这个写法看起来简单但如果每次回调都创建ui.Image很快会触发大量的 Image 对象回收对 GC 造成压力。更稳的方案是常驻一个ui.Image每次只更新像素区域但 Flutter 的 immutable image 模型导致局部更新非常困难所以我最后选了“双缓冲”方案两个ui.Image轮流用解码线程往一块空闲缓冲写数据UI 线程读上一块已经写好的缓冲上屏。这样既不会频繁创建图片也减少了 UI 线程的等待。3.4 输入事件和控制通道远程桌面的另一半是键盘鼠标回传。dart_rfb 提供了发送鼠标事件和按键事件的方法比如pointerEvent、keyEvent。鸿蒙 Flutter 里监听手势和按键相对容易但要注意坐标换算客户端窗口大小和设备物理分辨率不一致时需要按比例换算成 VNC 服务端屏幕坐标。比如监听鼠标移动GestureDetector( onPanUpdate: (details) { final localPos details.localPosition; final vncX (localPos.dx / _viewWidth * _serverWidth).round(); final vncY (localPos.dy / _viewHeight * _serverHeight).round(); client.sendPointerEvent(vncX, vncY, buttonMask: 1); }, )这里很容易踩的坑是VNC 的鼠标按键 mask 不是 Flutter 的按钮枚举而是 BIT 位标记。左键通常是 1中键是 4右键是 2滚动事件则有专门的编码类型。如果直接把 Flutter 里的1当成左键发过去右键和中键会被算错。键盘方面鸿蒙的 Focus 系统默认不把键码暴露给 Flutter widget需要先在FocusScope里监听 KeyEvent再把 keyCode 映射为 VNC 的 X11 keysym。注意 translate 的键位名在鸿蒙和标准 Linux 桌面上不一致最好维护一张映射表而不是直接用系统键位值。4. 低延迟的优化实践4.1 先分清瓶颈是网络、解码还是渲染远程桌面卡顿有几种完全不同的表现画面一卡一卡但 CPU 占用不高是网络问题CPU 跑满且内存抖动是解码问题界面刷新像幻灯片但其他操作正常是渲染或图片对象创建问题。我建议在调优之前先分层打时间戳别凭感觉优化。给网络读取和解码之间插入一个计时点给解码完成和 setState 之间再插一个计时点。实测下来我第一次全屏请求在鸿蒙上光解码就花了 60ms后来发现问题出在服务端默认编码是 Zlib而 dart_rfb 的 Zlib 解码器在启用了gzdecode后效率较低换成 Hextile 后降到了 18ms。4.2 增量更新与编码协商远程桌面通讯最忌讳全屏请求。我在开发时把“屏幕变化检测”做在了客户端侧默认请求一个小矩形区域只有当用户第一次连接、窗口 resize 或服务端主动推送 DesktopSize 变更时才请求全屏。其余时间让服务端只推送脏矩形。dart_rfb 里 requestUpdate 方法可以传多个矩形参数。如果你的需求是持续监控某个软件窗口可以先做一次全屏 FrameBufferUpdateRequest然后按固定间隔请求屏幕总区域里的一小块比如 100ms 间隔请求 256x256 的区域轮转扫描。这样比全屏 60fps 的流量低一个数量级但要注意轮转区域之间可能会漏掉变化需要允许每 N 次请求里包含一次全量 Raw 帧做校准。对于编码协商我建议把 CopyRect 和 Hextile 放在最前面。CopyRect 本身不是压缩而是“移动区域”指令对桌面环境下窗口移动特别友好。Hextile 在远程 SSH 终端、代码编辑等场景下刷字符效率高。另外如果 dart_rfb 支持 ZRLE 的话在弱网下可以把它提升到首位它的压缩比比 Zlib 更高。4.3 并发解码与隔离Flutter 的单线程隔离模型在这里是个痛点。网络数据在 Dart isolate 主线程收到后如果直接在同一个 isolate 里面解码会阻塞 UI 渲染。理想方案是拆成两个代码块一个 isolate 负责读 socket、解析协议另一个 isolate 负责解码像素定期把ui.Image传回主 isolate。不过 dart:ui 的图片对象不能跨 isolate 直接传递只能在解码后的 isolate 把它传给主 isolate 之前转换成 TransferableImage。实际上鸿蒙 Flutter 引擎对ui.decodeImageFromPixels的支持和 Android 不完全一致我后来换了一种做法解码 isolate 只做字节拷贝和格式转换把处理完的标准 RGBA 缓冲通过SendPort发送回主 isolate由主 isolate 再生成ui.Image。Isolate.spawn(_decodeLoop, receivePort.sendPort); ReceivePort receivePort ReceivePort(); void _decodeLoop(SendPort sendPort) { receivePort.listen((RfbFrameData data) { // 在这里只做像素格式转换、区域裁剪 sendPort.send(ConvertedFrameData(...)); }); }这个方案的好处是解码耗时完全不占 UI 线程坏处是跨 isolate 传递的字节数据会多一次拷贝。经过权衡收益大于损耗而且配合双缓冲渲染整体刷新率稳定在多出来了 10 到 15 帧每秒。4.4 渲染层优化低延迟的最后一段是渲染。Flutter 的RawImage接受ui.Image对象每次 setState 都会触发 widget rebuild如果一秒钟要刷新 30 次widget 重建的开销会很可观。建议把参考图像放到一个独立的 widget 里用RepaintBoundary隔离刷新区域避免整个页面的 widget 树都跟着 rebuild。另外鸿蒙 Flutter 引擎如果启用了 Impeller 后端纹理上传和 GPU 光栅化会更快。你可以在 flutter 控制台看到 backend 类型若引擎版本支持的话用--enable-impeller开启。实测下来同样一张 1080p 的 RGBA 画面从字节流到上屏的耗时能低 20% 左右尤其是窗口缩放、平台视图叠加这类场景效果更明显。这里要提醒一句不要迷信 Impeller如果连接的是低配设备或者嵌入在 x86 模拟器里Impeller 的初始化反而可能失败。稳定的做法是做成可开关默认关闭或按机型判断。5. 常见问题排查与避坑速查5.1 握手失败类问题最常见的是 “ProtocolVersion mismatch” 或者直接没响应。遇到这类问题先抓包鸿蒙侧可以用系统抓包工具也可以直接在 dart_rfb 连接前打印收到的前 12 字节。正常情况应该看到 “RFB 003.00x” 字符串后跟 LF。如果前 12 字节都不对说明服务端不是标准 VNC或者是反向连接协议需要换思路。认证失败的问题也常遇到。VNC Authentication 的 DES 加密有个非常经典的坑key 的每一字节的二进制位都要反转后再作为 DES 密钥。网上很多实现直接拿密码 ASCII 做 key解密失败后客户端毫无提示就是卡在认证环节。dart_rfb 内部有处理但如果你在鸿蒙上从别的系统翻译过来的代码替换过很容易改出这个错。另外有些 VNC 服务端根本不开启标准 5900 端口而是走 5901、5902 这种 display 端口连接时端口号可能是 5900 display。建议把端口设计成可配置项并且初始值使用 5900不能用固定常量。5.2 黑屏、花屏与内存暴涨黑屏的原因多半是编码协商出了问题服务端默认发了不支持的编码dart_rfb 没有注册对应 decoder。比如服务端上来就发 Tight 编码而你只在 setEncodings 里写了 Hextile服务端通常会忽略你的偏好继续用自己默认的 Tight于是黑屏。解决办法有两个方向一是在 setEncodings 里把 Raw 放到最后兜底几乎任意服务端都支持二是在 onFrame 回调里检查 rect.encodingType如果遇到未识别的编码立即断开重连并用更保守的编码列表协商。内存暴涨在鸿蒙上特别容易出现。一个原因是ui.Image没释放每次 setState 前没有把上旧的 Image 调用dispose。另一个原因是Socket的缓存没有背压网络快速写入解码跟不上socket 缓冲区增长。遇到内存膨胀时优先看这两块。5.3 MissingPluginException 与鸿蒙插件兼容我的工程里不止有 dart_rfb还有 shared_preferences、path_provider 这类常见 Flutter 插件。在鸿蒙 Flutter 上这些插件如果没做鸿蒙实现运行时会出现E/flutter: MissingPluginException(No implementation found for method getAll on channel plats.flutter.io/shared_preferences)这个现象和 dart_rfb 本身无关但会严重干扰调试。建议先把项目依赖收敛到最小集再一个个加。像 shared_preferences鸿蒙社区已经有人做了 fork 版pubspec 里替换成本地路径即可。dart_rfb 是纯 Dart 包不依赖这些插件但你的 UI 层如果因为 shared_preferences 崩掉还是会让人觉得是 VNC 适配没成功。这里提醒一下鸿蒙工程里的 Flutter 插件需要对应平台的pubspec.yaml增加harmony标志并实现FlutterPlugin的鸿蒙版本接口。如果没有不要硬跑可以先改成内存存储避免插件。5.4 问题速查表现象大概率原因处理方式连接后无响应缺少 INTERNET 权限module.json5 添加权限握手阶段卡死服务端版本低于 3.8降级协议版本或手动协商认证失败DES 密钥位反问题检查密钥反转逻辑黑屏服务端使用未注册编码编码列表加 Raw 兜底并重连花屏像素格式字节序不对检查 big-endian / true color 解析内存持续增长ui.Image 未释放及时 dispose 旧图UI 卡顿解码阻塞主线程拆 isolate / 双缓冲桌面画面更新慢全屏 Raw 开销大使用 CopyRect/Hextile鼠标位置错位未做分辨率换算按远端桌面尺寸比例变换键盘输入无效keycode 映射缺失维护完整 keysym 映射表后台断连鸿蒙系统限制使用前台服务或保持活跃连接5.5 一条龙排查路径如果以上问题还是没解决我一般会重新理一遍连接流程。从 dart_rfb 的 connect 开始每收到一条完整消息就把状态打点输出连接成功是否触发是否收到 ProtocolVersion是否收到 SecurityType是否进入 ServerInit是否收到第一个 FramebufferUpdate不要嫌日志啰嗦。VNC 调试最大的误区是直接看画面画面不出来时根本不知道死在哪一步。把状态机日志打出来任何一个 “未进入下一状态” 的卡点基本都能对应到上表的某个原因。最后聊点实在的心得。dart_rfb 的鸿蒙化适配技术难度不算高但需要足够的耐心去读协议细节和源码。起初我以为会大量改到底层网络甚至 C 代码实际做下来百分之八十的工作都在 Flutter 层真正的地基是理解 RFB 状态机和像素数据流。像 CopyRect、Hextile 这些编码的取舍、脏矩形怎么请求、解码和渲染如何分离性能优化到最后拼的都是这些基础点。如果你的需求和我类似想给鸿蒙应用加一块跨设备屏幕监控建议不要只看框架好不好用先把服务端的支持能力和字节流调性摸清楚适配过程会顺很多。也强烈推荐把 dart_rfb 的源码从头到尾读一遍哪怕它只是一百来 kb 的代码里面协议状态机的组织方式看完之后你会对整个 VNC 体系有更清晰的认识。