Flutter三方库castscreen在OpenHarmony上的跨屏镜像适配实践

最近在一台 OpenHarmony 的开发板上折腾 Flutter 应用时，接了一个挺有意思的适配任务：把三方库 castscreen 在鸿蒙环境里跑起来，目标是实现跨屏镜像投影，让手机、平板、电视这些设备之间可以实时共享屏幕内容。castscreen 在 Android/iOS 上已经是很成熟的方案了，但到了 OpenHarmony 上，底层 API 对不上号、权限模型不一致、编码器接口不通用，各种问题接踵而至。我在这中间踩了不少坑，也把整个适配思路完整跑通了一遍，从默认的“能编译能运行”到真正的“无感多端协同”，中间的关键环节值得好好梳理一下，这篇文章就是完整记录。

如果你正准备做 Flutter 应用的鸿蒙化适配，或者在做投屏、屏幕共享、远程控制这类多端协同功能，这篇文章应该能帮你省下不少时间。我会从适配方案选型、工程配置、核心功能实现、性能调优到问题排查，把完整的实操链路讲清楚，既有思路层面的拆解，也有可以直接抄作业的配置和代码参考。

1. 适配前先搞清楚：为什么不能直接拿来用

1.1 跨屏镜像的本质是什么

跨屏镜像投影，说白了就是把一台设备的屏幕内容实时搬到另一台设备上展示，同时把触控、鼠标、键盘这些输入事件反向传回去，实现“用这个屏操作那台设备”的效果。常见场景有手机投电视、平板演示投会议屏、把开发板画面镜像到桌面端做调试，以及远程协助这种异地主控的场景。

这个链路本身不算神秘，核心就是四件事：画面采集、编码压缩、网络传输、解码渲染。但在不同操作系统上，这四件事的底层实现差异极大。castscreen 这类库之所以能跨平台，通常是对各平台的系统能力做了统一封装，比如在 Android 上用 MediaProjection 采集屏幕，在 iOS 上用 ReplayKit，在 Windows 上用 DXGI 抓帧，再把这些差异收敛到同一套 Flutter 插件接口背后。

1.2 OpenHarmony 上的真实差异点

等我把 castscreen 集成到 Flutter 的 OpenHarmony 工程里，首先崩溃的是平台通道。原来 castscreen 走的是 Android 的 PlatformView 和 MethodChannel，注册时会去找 Android 系统服务，而 OpenHarmony 的 Flutter 框架虽然保留了 MethodChannel 机制，但底层的媒体服务、权限系统、硬件编解码能力全部是另一套体系。

具体差异集中在三个地方：

第一，屏幕采集能力不通用。Android 的 MediaProjection 在 OpenHarmony 上没有任何对应实现，必须改用鸿蒙体系里的屏幕采集 API，而且这个 API 在不同版本上的行为还有细微差别，调用方式、回调时机、帧格式都不一样。

第二，硬编解码器的接口不通用。H.264 编码在 Android 上是 MediaCodec，在 OpenHarmony 上要走系统媒体框架的编解码器接口，参数配置方式不同，输出数据格式也有差异，尤其是关键帧间隔、码率控制模式、输入缓冲的填充方式，都得重新适配。

第三，权限模型不一致。OpenHarmony 的应用权限体系中，“屏幕采集”权限的申请时机、申请方式、用户授权弹窗的触发逻辑跟 Android 完全不同，如果用原来的逻辑去申请，要么静默失败，要么直接闪退。

所以所谓的“鸿蒙适配”，从来不是把源码复制过来改改包名就行，而是要基于鸿蒙的能力体系重新实现一遍插件的原生层。

1.3 适配的目标定义

动手之前，我把适配目标定义成三个层次：

第一层，功能可用。也就是手机端能采集屏幕，编码后发出去；接收端能解码并渲染出来，画面基本连贯。这一层解决“有没有”的问题。

第二层，体验可用。延迟控制在可感知的范围内，无线局域网环境下整体链路控制在 150 毫秒以内，声音同步误差不超过 50 毫秒，触控回传的响应不能有明显的滞涩感。这一层解决“好不好用”的问题。

第三层，无感协同。设备发现自动完成，不需要手动输入 IP，连接断线自动重连，分辨率码率能根据网络状况动态调整，用户不需要理解背后的技术细节，拿起来就用。这一层才是“无感多端协同”的完整定义。

我建议所有做适配的人先把这个目标写清楚，因为后面每一步方案选型和性能调优，都会回到这个目标上来判断取舍。

2. 适配方案选型：三条路怎么选

2.1 方案对比

面对“Flutter 三方库在 OpenHarmony 上适配”这个问题，通常有三条路可以走。

第一条路是平台通道桥接，也是最推荐的路线。Flutter 本身有标准化的插件机制，支持在原生层实现新平台的支持。castscreen 这种库内部已经做了 Flutter 层和原生层的隔离，外层 Dart 代码调用接口，内层通过 MethodChannel/EventChannel 跟原生通信。我们只需要在工程的 ohos 目录下新增一套鸿蒙原生实现，把原来 Android 原生层的能力替换成鸿蒙 API，Dart 层的调用逻辑基本不用动。

第二条路是纯 Dart 重写核心链路。把屏幕采集、编码、传输全部用 Dart 实现，好处是彻底绕开平台差异，但问题也很明显：Flutter 的 Dart 层拿不到系统级的屏幕采集能力，也没有访问硬编解码器的通道，纯算力编码 H.264 在移动设备上性能差得离谱，这条路在中低端设备上根本没有可用性。

第三条路是借助官方兼容层或迁移框架。一些跨端框架会提供 Android 兼容能力，理论上可以直接运行 APK 里的逻辑，简单粗暴，但性能损耗大，而且对需要高频访问系统能力的投屏类应用来说，额外引入一层转换带来的延迟不可接受。

我最终选了方案一：平台通道桥接，鸿蒙原生层按需重写。选它不是因为简单，而是因为这是唯一能满足“低延迟 + 硬件加速 + 长期可维护”这几个硬性要求的路线。Dart 层复用现有接口，原生层各平台自己适配，后续 castscreen 上游更新时，我们只需要合并 Dart 层的变更，鸿蒙原生层跟着补齐能力就行。

2.2 完整技术链路图景

整个跨屏镜像系统，从数据流上看是这样的：

发送端（被镜像设备）：屏幕内容通过鸿蒙屏幕采集能力逐帧获取，转成图像帧后送入 H.264 编码器，编码后的数据按自定义协议封装，通过局域网 TCP 连接发送到接收端。

接收端（展示设备）：收到数据包后按序重组，送进 H.264 解码器解出原始帧，再绑定到一个 Flutter Texture 上，最终渲染到页面的 Widget 里；同时接收端的输入事件通过反向通道传回发送端，模拟成鸿蒙的注入事件。

控制面：设备发现通过 mDNS 协议实现，两端在局域网内自动广播和发现服务；发现后建立控制连接，完成能力协商、鉴权、参数握手，然后再建立数据连接传输媒体流。

这套链路中，每一个环节都是可以独立替换的模块。适配工作的本质，就是把 Android 实现逐一替换成鸿蒙实现，同时保持接口契约不变。

2.3 为什么要定义自定义协议

我在传输层没有直接用现成的 RTSP/RTMP 协议，而是选择了一套轻量的自定义协议。原因有三：一是 RTSP 面向的是摄像机直播场景，控制流程偏重，握手交互多，对小尺寸移动端镜像场景来说太多冗余；二是我们还需要双向数据传输，不仅发屏幕流，还要回传输入事件，现成的流媒体协议大多不覆盖这一块；三是自定义协议可以把关键帧、重传策略、延迟控制完全握在自己手里，调优空间大。

自定义协议的代价就是需要自己处理分包、排序、丢包重传这些脏活。但做下来之后我认为这个代价是值得的，尤其是延迟和卡顿的优化空间，远大于通用协议能给到的上限。

3. 环境准备与工程配置

3.1 开发环境搭建

适配工作开始前，先把环境理清楚。开发机上需要安装 DevEco Studio 用于 OpenHarmony 应用的编译调试，同时安装 Flutter SDK 以及对应的 OpenHarmony 平台支持包。版本匹配是第一步坑：Flutter SDK 和鸿蒙 SDK 的版本耦合很紧，低版本 Flutter 可能不支持鸿蒙的某些新 API，高版本 Flutter 又可能引入了跟 OpenHarmony 平台通道机制不兼容的改动。建议直接用当前稳定版本搭配匹配的 DevEco Studio 版本，尽量避免两个都选最新这种激进做法。

3.2 Flutter 工程的鸿蒙化配置

在已有的 Flutter 工程里集成鸿蒙支持，主要做三件事。

第一，在项目根目录的 pubspec.yaml 中确认 castscreen 依赖版本，并确保工程具备 ohos 平台的插件注册逻辑。Flutter 的鸿蒙插件机制需要插件工程里存在 ohos 目录，包含 ets 原生代码和插件注册类，这样 Dart 层调用 MethodChannel 时，鸿蒙端才能正确接收并分发。

第二，在 ohos 工程的模块配置文件中声明硬件能力和权限。屏幕采集、网络通信、系统事件注入这些都需要对应的权限声明。需要注意，OpenHarmony 的权限分为系统级和用户级，屏幕采集这类涉及隐私的权限，声明后还需要在代码里动态申请，不能只写进配置文件。

第三，配置签名与调试设备。开发板或真机的开发者模式、调试证书都要提前搞定，否则安装应用时会被拦截，这个卡住非常影响效率。

3.3 权限申请的实现要点

权限这块我单独拿出来说，因为在 OpenHarmony 上权限问题比 Android 更容易踩坑。

屏幕采集的权限申请，需要在页面生命周期里主动调用授权接口，用户同意后才能调起采集能力。我第一次适配时直接把 Android 里的做法搬过来，在插件初始化时申请权限，结果在鸿蒙上完全没有弹窗，调试了半天才发现鸿蒙要求权限申请必须绑定到具体的 UIAbility 上下文，而且申请时机必须在页面已经可见之后。

另外一个容易忽略的点是网络访问权限。局域网通信在 Android 上可能默认放行，但在鸿蒙的严格模式下，网络权限如果不声明，连接会直接被拒。而且鸿蒙对网络权限的管理分得更细，监听端口和主动连接是不同场景，最好都显式声明。

实操中我的建议是：把权限申请逻辑放在应用入口页面的 onPageShow 回调里，不要放在插件内部，这样用户感知最明确，系统也不会拦截弹窗。

4. 核心功能实现：设备发现与连接建立

4.1 mDNS 设备发现：局域网内的自动握手

无感协同的起点是设备发现。如果每次都要手动输入接收端设备的 IP 地址，那就谈不上“无感”了。我的方案是走 mDNS 协议，也就是局域网内的零配置服务发现。

mDNS 的原理可以这样理解：每台设备加入局域网后，都会通过组播地址向网段内广播自己的服务信息，比如“我是一个投屏接收端，我叫 living-room-tv”；同时在监听这个组播地址，等待其他设备的服务声明。当发送端看到目标类型的服务后，就直接拿到对方的 IP 和端口，发起连接。整个过程不需要中央服务器，也不需要手动配置。

在鸿蒙端实现 mDNS 服务订阅，走的是网络服务发现相关能力，注册服务类型、监听服务上线和下线事件、解析服务信息。这套流程代码量不大，但有一个关键细节：服务上线事件是异步分批返回的，有时候同一台设备会多次出现在结果列表里，需要用设备唯一标识做去重。否则界面上会出现重名设备，用户根本分不清该投哪个。

4.2 连接建立与能力协商

设备发现之后，紧接着是建立控制连接。我在发送端和接收端之间建立了两条 TCP 连接：一条控制通道，用来传输握手、心跳、能力协商这类低频指令；一条数据通道，专门传音视频流。分开的原因很实际：如果混用一条连接，视频帧的突发流量会把控制指令堵在队列里，导致画面都停止更新了，用户按下的断开指令还迟迟没执行。

握手阶段做的事，一是校验两端协议版本是否匹配，二是交换能力集，比如发送端支持的编码格式、接收端支持的最大分辨率、两端共同支持的帧率范围。能力协商的核心是取交集，比如发送端支持 1080P 和 720P，接收端只支持最高 720P，那双方自动对齐到 720P，避免接收端收到解不动的数据流导致花屏或卡死。

握手完成后，接收端返回一个会话 ID，后续所有数据包都携带这个 ID 做标识，防止连接错乱。再配合心跳机制，默认每隔 3 秒发送一次心跳包，超过 10 秒没收到回应就判定连接断开，自动触发重连流程。

4.3 为什么用 TCP 而不是 UDP

直播行业普遍用 UDP 来传视频，因为 UDP 延迟低、丢包不重传，对于音视频这种可以容忍少量丢失但必须实时到达的数据很友好。但我的镜像场景选择了 TCP，原因是交互式控制对可靠性的要求远高于直播。

试想一下，接收端用户的每一次触控点击、每一次键盘输入，都需要可靠地到达发送端。如果走 UDP，少量关键输入事件丢失，用户会感觉鼠标偶尔“跳一下”、点击偶尔没反应，这种体验非常糟糕。TCP 的自动重传机制天然解决了这个问题。视频帧偶尔卡一下可以接受，但输入事件丢了是即时感知的。

当然 TCP 也有它的毛病，尤其是队头阻塞问题——前面一个包没到，后面的包就算已经到了也得等。这个问题我在视频传输上做了缓解：每个视频包都有一个发送序号和有效时间戳，接收端发现某个帧已经超过预期的解码时间还没到齐，就直接丢弃这一帧，继续等下一帧的起始包，避免一个坏帧拖死整条链路。

5. 屏幕采集、编码与传输：最核心的链路

5.1 屏幕采集：从系统拿帧

屏幕采集是整个系统里第一个性能瓶颈。在鸿蒙上，我需要通过系统媒体采集能力注册一个虚拟屏幕，然后持续回调当前屏幕的图像数据。这里有一个关键设置：屏幕采集的帧率不要盲目拉满。

很多人一开始就把采集帧率调到 60fps，觉得这样画面才流畅。但采集、编码、传输、解码、渲染是一条流水线，任何一个环节跟不上，帧率再高也没用。实测下来，普通办公场景 30fps 已经足够顺滑，30fps 相比 60fps 能显著降低编码负载和功耗，而且画面体验差距在非高速运动场景下基本不可感知。我的做法是把采集帧率做成动态可调的，默认 30fps，遇到文档滚动、视频播放这类高频变化场景再临时上调。

屏幕采集还有一个细节：镜像场景中采集到的帧默认包含系统状态栏、悬浮按钮这些 UI 元素。如果做的是“应用镜像”而不是“整机镜像”，最好在应用层过滤掉这些区域，既能减少数据量，也能保护用户隐私，避免不小心把通知消息也投到接收端屏幕上。

5.2 编码器选型与参数配置

采集到原始帧后，下一步是编码压缩。我选的是 H.264 硬件编码，而不是软件编码，原因很直接：硬件编解码器在移动系统上功耗低、延迟低，而且覆盖率广，几乎所有鸿蒙设备都支持 H.264 硬解。

编码器的参数配置是整个适配中最敏感的部分，我建议重点关注以下四个参数。

第一个是码率。分辨率越高，码率需求越大。我的经验值参考如下：

码率设低了，画面会出现块状模糊，尤其是文字较多的界面；码率设高了，传输压力大，弱网环境下反而卡顿。建议设置一个自适应码率机制：根据最近一段时间的网络质量，周期性地在区间内调整码率，而不是写死一个值。

第二个是帧率，前面提到了默认 30fps。第三个是关键帧间隔，也就是 I 帧的间隔。I 帧是解码的“基准帧”，接收端只有收到 I 帧才能开始解码，如果 I 帧间隔太长，新加入的连接会等很久才能出画面。我一般把 I 帧间隔设为 1 秒，也就是说每秒钟至少一个 I 帧，兼顾画质和连接响应速度。

第四个是编码延迟模式。部分鸿蒙设备支持低延迟编码选项，开启后编码器会减少内部帧缓冲数量，延迟能降低 20 到 40 毫秒。这个必须实测设备的支持情况，有些设备开了低延迟模式后画质下降明显，需要权衡。

5.3 传输协议设计：数据包封装与组包

传输层我用的是自定义数据包结构。每个数据包包含固定的头部信息：帧序号、分片序号、分片总数、时间戳、数据格式标记。一帧画面经过编码后，如果超过网络包大小上限（一般按 1200 字节计算），就拆分成多个分片分别发送。

接收端的组包逻辑是：先根据帧序号把分片按序缓存，凑齐一个完整帧后送解码器。这里要注意，视频帧的解码是有依赖关系的，P 帧依赖前面的帧，B 帧依赖前后帧。我在编码器配置里直接把 B 帧关闭了，只保留 I 帧和 P 帧，这样虽然码率略有提升，但解码复杂度大幅降低，而且丢帧后的恢复速度更快。

还有一个容易被忽略的点：TCP 是流式协议，没有天然的“包边界”。发送端一次 send 调用传出的数据，在接收端可能分多次收到，也可能多个包粘在一起到达。因此接收端必须自己维护一个缓冲区，按头部里的包长度字段切分数据，不能假设每次 recv 到的就是完整的一包。这个“粘包拆包”问题对刚上手的人特别容易踩坑，调试的时候画面花屏或解析错误，十有八九是这里出了问题。

6. 解码渲染与交互回传

6.1 接收端的解码接入

接收端收到完整帧后，需要送入 H.264 硬件解码器解码成原始图像。鸿蒙的解码器接口跟 Flutter 原生层对接时，有一个典型的用法：解码输出可以直接绑定到一个 Surface 上，然后把 Surface 的纹理句柄传给 Flutter 侧生成 Texture，最后由 Flutter 的 Texture widget 渲染出来。

这个绑定关系需要在初始化时提前建立好，不能在解码中途动态切换，否则会丢失纹理导致黑屏。顺序是：先创建解码器，再获取输出 Surface，再把 Surface 交给 Flutter 纹理注册器，拿到 text ID，最后在页面上用 Texture(textureId: id) 展示。

6.2 音画同步与时间戳对齐

纯屏幕镜像模式下，音频部分可按需选配。如果只做画面镜像，那就不存在音画同步问题；但如果要把设备的声音也投到接收端，音画同步就变成必修课。

我的实现思路是：发送端在每一帧编码前打上基于同一时钟源的采集时间戳，音频包同样携带这个时间戳；接收端解码后，将视频帧和音频帧分别放入各自的缓冲队列，然后根据时间戳对齐播放。视频不能追得太紧，音频也不宜抢跑，常用的策略是以音频时钟为主时钟，当视频落后太多时丢帧追赶，视频领先太多时则延迟显示。

实际测试时，我用了一个直白的验证方法：在发送端屏幕上播放一个在线秒表，让接收端画面里的秒表数字跟发送端本机肉眼比，差距在 0.2 秒以内就算达标。这个方法很土，但直观有效，比盯着专业仪器更有说服力。

6.3 触控回传与事件注入

无感协同里，用户最常做的操作是在接收端屏幕上滑动、点击、输入文字，这些操作需要反向转发回发送端。接收端捕获的触控坐标是相对于自己屏幕的，必须先做坐标变换，把接收端的坐标映射回发送端的实际分辨率，再通过控制通道传给发送端，由发送端注入对应的输入事件。

坐标变换看起来是简单的比例缩放，但因为两端的屏幕宽高比可能不一致，如果用简单的除法缩放，会出现“点不准”的问题。我的做法是：优先保持发送端的原始宽高比，接收端把多出来的黑边区域当作无效区，坐标变换时先判断触摸点是否落在有效区内，落在有效区才做映射。这样虽然牺牲了接收端屏幕的部分区域，但保证了操作精准度。

7. 难点攻坚与性能调优

7.1 延迟优化：从端到端口径拆解

端到端延迟 = 采集帧间隔 + 编码输入队列排队 + 编码耗时 + 网络传输耗时 + 接收端缓冲 + 解码耗时 + 渲染排队。

我在优化时把这条链路拆开逐项打点。实测一次局域网环境下，采集约 8ms，编码约 10ms，网络传输约 5ms，接收端解码约 8ms，渲染约 5ms，中间各环节排队累计约 30ms，整体加起来 70~80ms 是常态。如果不做末端缓冲调节，用户感知的延迟会更明显。

优化重点是砍掉不必要的排队。编码输入队列如果积压超过 3 帧，说明编码速度跟不上采集速度，此时与其继续排队导致延迟越来越大，不如主动丢帧。我设了一个规则：编码队列深度超过 2 帧时，新进队列的帧直接标记跳过，不送编码器。画面偶尔丢一帧人眼几乎察觉不到，但延迟是持续累积的，前者可接受，后者不可接受。

接收端同理，解码输出缓冲控制在 2 帧以内，超过就丢旧帧。延迟控制的核心哲学是“宁可丢，不能拖”。

7.2 画质与流畅度的平衡

画质和流畅度在很多场景是矛盾的，尤其是弱网环境。码率调高画质变好，但带宽不足导致卡顿；码率调低流畅，但画面模糊。

我最终实现了一个带宽感知机制：优先保证流畅度，在流畅的前提下尽量提升画质。数据通道上每秒钟统计一次实际吞吐量，当吞吐量逼近码率上限时，主动下调目标码率到区间的 70%，同时通知发送端降低编码复杂度。当吞吐量低于目标码率一半时，直接降一档分辨率，从 1080P 降到 720P。这个机制的跳变要平滑，用渐变而不是台阶式突变，否则用户能看到频繁的画面清晰度切换，非常影响观感。

7.3 内存与功耗控制

投屏功能很耗电，这是天然属性，因为屏幕本身常亮，编码器持续工作，网络持续发送数据。但我发现有三个因素是可控的。

第一是空闲检测。如果连续一段时间没有用户操作，且屏幕内容变化很小，可以自动把采集帧率降到 10fps，甚至暂停采集。很多办公场景中用户只是看着屏幕不动，此时还在满帧率采集纯属浪费。

第二是动态分辨率。编码 1080P 60 帧的功耗大约是编码 720P 30 帧的两到三倍。如果接收端只能显示小窗口，发送端完全可以降到 720P 编码，画质感知差异不大，但功耗差距非常明显。

第三是定时清理缓存。TCP 接收缓冲区、解码缓冲、纹理缓存，时间久了都会膨胀。我每次会话结束时强制清空全部缓冲，并回收纹理资源，防止多次开会话后内存持续爬升。这个问题我自己就遇到过：连续投屏三小时后，内存从 180MB 涨到 420MB，用户操作开始卡顿，重启应用才恢复正常，定位原因是解码器内部缓冲没有完全释放。

8. 常见问题与排查实录

8.1 问题速查表

8.2 三个比较隐蔽的坑

第一个坑是权限弹窗的时机。有一次在真机上测试，应用怎么都调不起屏幕采集，控制台也没有明显报错，折腾了很久才发现是权限申请被系统拦了，原因是上一轮授权被用户拒绝后，系统进入了“短时间内不再弹窗”的状态，必须到系统设置里手动开启权限才能恢复。所以权限被拒以后一定要有引导用户去设置页开启的流程，不能只弹一次就算了。

第二个坑是 Flutter 侧纹理 ID 泄漏。接收端的 Texture 在 Widget 销毁时需要显式调纹理回收接口。我漏掉这一步之后，连续切换投屏接收页面若干次，渲染资源逐渐耗尽，最终整个应用直接黑屏。排查时通过系统监控工具看到 GPU 内存持续上涨，基本就能锁定是纹理没有释放。

第三个坑是编码器偶发异常导致的黑帧。某些设备的硬编解码器在长时间运行时，偶尔会输出畸形帧，解码后画面变成全黑的。这个问题如果靠重传一直解决不了，就要在发送端周期性重置信令编码器，强制重新编码一个 I 帧。虽然会带来一次轻微的画面跳动，但远比持续黑屏好得多。

8.3 调试工具与手段

针对投屏类应用的调试，我用下来最有效的三件套是：系统日志抓取、网络抓包、帧率监控。这三个工具能覆盖九成以上的问题定位需求。

系统日志用来定位权限、服务、编解码器的报错，排查时我会把过滤关键字设为“屏幕采集”“解码”“会话”等。网络抓包用来确认数据包交互是否正常，重点看 TCP 握手是否成功、数据帧是否在持续流动。帧率监控可以在页面左上角悬浮显示当前采集帧率和渲染帧率，实测时我能直观看到链路是顺畅还是积压。

这三件套里最难的是网络抓包，因为数据包结构是自己定义的，一般抓包工具默认不识别。我的做法是在开发调试阶段，在数据包头里额外追加一个 4 字节的魔数标记，方便过滤；正式版本再把这个标记删掉，不影响协议本身。

9. 实战心得与横向扩展

9.1 适配工作本身的一些建议

把这套流程走下来，我的一个强烈体会是：三方的 Flutter 库在鸿蒙上的适配工作，本质上不是“改代码”，而是“重写原生层”。Dart 层的接口设计和调用逻辑大概率不用动，真正的工程量都在原生实现里。所以动手之前一定要先梳理清楚原来 Android 实现里，哪些能力在鸿蒙上有对应物、哪些没有、哪些是鸿蒙独有的可以做得更好。

没有对应物的能力最容易拖延进度。比如 Android 的 MediaProjection 在鸿蒙上虽然能找到替代方案，但回调时机和帧格式都有差异，此时不要试图做一个完美的抽象层掩盖差异，直接适配具体平台的特性就好，否则反而会引入不必要的复杂度。

另外，适配过程中请一定保留小步验证的习惯。先跑通采集，再跑通编码，再跑通传输，每一步都验证无误后再进行下一步。我见过有人一口气写完整个链路才开始调试，结果黑屏了根本不知道问题在哪一环，排查成本比多花几天验证高得多。

9.2 从镜像投屏到更广泛的多端协同

castscreen 的适配只是第一步，这套链路跑通后，可以做很多横向扩展。

一个是多设备群组协同。当前实现是一对一镜像，改动伸到多接收端就是做分发。发送端采集一帧后通过组播或多路转发同时送给多个接收端，就能实现“一屏分发到多端”，这个东西用在会议、教学场景很有价值。

另一个是反向远控增强。当前已经实现了触控回传，继续加键盘映射、剪贴板同步、文件拖拽，就能成为一个轻量级的远程桌面方案。这些能力很多技术栈都能做，但在鸿蒙的 Flutter 生态里，有一个跑通的完整参考很重要，能省下大量的踩坑时间。

还有一块是文档标注与协同批注。接收端画笔画出的标记可以通过控制通道回传到发送端，叠加到屏幕上，这就是一个简单的无线投屏批注系统，用到在线教研、远程会诊、协同评审场景都挺合适。

9.3 最后再分享一个真实体会

在我做完整套适配后，最大的收获不是代码本身，而是逐渐形成了“以链路视角看问题”的习惯。摄像头采集也好、屏幕镜像也好，本质都是数据流水线。排查问题时，与其盯着某一个环节反复改参数，不如先把整条链路上每一环的数据量、耗时、丢帧率都打点量化，问题自然就浮出水面了。

比如你发现画面卡顿，不要先去调码率，先回答几个问题：是采集端掉帧，还是编码端积压，还是网络上丢包，还是解码端来不及？把这些问题都量化出来，答案往往比拍脑袋清晰得多。这个方法论不只适用于投屏，几乎所有的实时音视频项目都是同一个思路。

希望这篇适配记录能给你提供一条相对完整的参考路径。如果你也在做类似的鸿蒙适配，欢迎把你自己踩到的坑和解决方案分享交流，大家一起把这条路踩得更平。