Flutter 与原生交互的最后一层：RTC 视频帧怎么走

做一个 Flutter 视频通话页，点击"切摄像头"很快，画面却偶尔掉帧；把 RTC 回调里的每帧图像发给 Dart 后，卡顿更明显。于是很容易得出一个结论："Flutter 和原生之间的桥太慢。"这个判断只说对了一半。要先看清楚，到底是什么东西在过桥。

一句话结论：通话命令和状态可以经过 Flutter 的消息通道，持续产生的视频帧应尽量留在原生 RTC 与图形渲染链路；调优的重点是减少逐帧搬运、控制缓冲与生命周期，而不是把所有 Channel 换成 FFI。

本文以 Flutter 3.47 文档和 2026 年 10 月可查的 Android、环信、声网资料为边界。图和接口分工是教学模型，实际采集、渲染 API 要以所用 RTC SDK 版本为准。重点讨论移动端视频通话的 Flutter／原生边界，不展开 RTC 编码器和网络拥塞算法。

1. 先把"桥接"拆成两条线

一通电话至少有两条速度完全不同的链路：

text 复制代码

控制线：Flutter 按钮 → MethodChannel / Pigeon → Android/iOS RTC SDK
         原生回调 → 事件通道 → Flutter 通话状态

媒体线：摄像头/麦克风 → 原生 RTC 引擎 → 编码、传输
         远端数据 → 原生 RTC 引擎解码 → 原生 Surface / 纹理 → Flutter 页面合成

控制线传的是"加入频道""静音""挂断"以及成员变化、网络质量等事件，通常每秒只有少数几次。Flutter 官方把 Platform Channel 定义为 Dart 与宿主平台之间的异步消息机制；Pigeon 可以生成类型安全的接口，减少字符串和手写数据结构带来的错误。Flutter Platform Channels 文档

媒体线面对的是连续帧。假设预览为 1280×720、30 fps、RGBA 每像素 4 字节 ，一次完整拷贝就是 1280 × 720 × 4 × 30 = 110,592,000 B/s，约 111 MB/s 。这是估算一次内存搬运的量级，不是某款 SDK 的实测带宽或最终 GPU 开销 。如果每帧还要转换格式、序列化、回传 Dart、再上传纹理，成本会继续叠加。声网 Flutter SDK 的说明也明确指出，音视频原始数据的高级处理受性能约束，建议通过原生 SDK 能力完成。声网 Agora Flutter SDK

所以，"有没有比 Channel 更快的桥"不是首要问题。先确认视频帧是否真的被送进了 Channel：成熟 RTC 插件通常会让 Dart 负责控制，媒体处理留在原生侧，但具体插件的渲染实现必须看版本和源码。

2. 一帧本地预览到底怎么来？

Android 的 Camera2 模型里，CameraDevice 可以向一个或多个输出目标送流；预览和录像可以是不同的流水线，CameraCaptureSession 管理请求。实际接入第三方 RTC 时，通常由 SDK 自己打开摄像头、完成采集、前处理和编码，应用通过 SDK 的接口配置分辨率、帧率和本地预览目标。Android Camera2 文档

text 复制代码

摄像头 → RTC SDK 采集/前处理 ─┬→ 本地预览的 Surface 或纹理
                              └→ 编码器 → 网络发送
网络接收 → 解码器 → 远端画面的 Surface 或纹理

本地预览只是采集流的显示分支，把预览画面放进 Flutter 并不代表采集流也必须经过 Dart。想加美颜、背景替换或 AI 处理时，先找 RTC SDK 的原生视频处理回调或自定义视频源接口，再判断处理应放在 GPU、C/C++ 还是平台层。只有 SDK 明确允许外部采集、且原有采集能被正确关闭时，才自己接管摄像头；否则容易出现双重占用摄像头、帧时间戳不一致和前后台恢复失败。

3. 画面进入 Flutter，有哪些真正可选的路径？

路径	适合的输入	主要取舍
`MethodChannel`／`EventChannel`	呼叫命令、状态、低频统计	接入简单；每帧消息会增加编解码与线程调度成本
Flutter `Texture`	SDK 能向插件可管理的纹理或 `Surface` 输出画面	后端纹理可随视频帧自主重绘，通常无需每帧执行 Dart；还要处理纹理和 `Surface` 生命周期
`PlatformView`	SDK 只提供原生 `View`，尤其依赖 `SurfaceView` 行为	保留原生控件能力；不同合成模式在滚动、裁剪、无障碍、Flutter 帧率上有不同代价
`dart:ffi`	SDK 暴露稳定的 C ABI，且确实需要 Dart 调用原生计算	可减少某些调用的消息序列化；不会自动解决画面显示、Java/Kotlin SDK 调用或内存所有权

Flutter 的 Texture 用纹理 ID 引用插件管理的后端纹理，后端新帧到来时可自行触发重绘，通常不需要 Dart 为每帧 setState()。Flutter Texture API 对 Android 新插件，如果 SDK 接受外部 Surface ，可以评估 TextureRegistry.SurfaceProducer；Flutter 官方建议用它让引擎管理底层实现，并要求处理 onSurfaceAvailable 与 onSurfaceCleanup。不能因为拿到了一个 Surface，就假设 RTC SDK 一定支持把解码画面直接输出给它。Flutter SurfaceProducer 迁移说明

如果 SDK 的渲染入口只接受 View，先使用 PlatformView 做最小集成，再在目标机型测试合成模式。Flutter 官方文档指出，Android Platform View 的纹理层、混合合成各有性能和功能取舍；较新的 HCPP 仍是有设备与版本要求的实验选项。Flutter Android Platform Views 文档 Texture 和 PlatformView 也都不等于"端到端零拷贝"：相机、SDK、解码器、图形缓冲和屏幕合成之间仍可能发生格式转换或内存复制。

我会优先用第三方 SDK 官方 Flutter 插件已经提供的画面组件。只有它暴露不了必需的渲染入口、且测试确实定位到插件边界时，才自建纹理插件。自建插件意味着后续每次升级 Flutter、Android 图形后端和 RTC SDK，都要重新验证画面与生命周期。

4. 以环信为例：IM、RTC 和 Flutter 各管哪段？

环信官方 Android CallKit 文档写得很直白：SignalingManager 处理邀请、接听、拒绝、取消等信令，RtcManager 管理声网 RTC 的入会、摄像头和麦克风等能力，通话界面由原生 Activity 承载。环信 Android CallKit 架构这是一种"IM 管呼叫关系，RTC 管实时媒体，原生 UI 承载通话页"的实现，不能据此推断环信 Flutter SDK 的每个内部细节都相同。

环信有官方 Flutter IM SDK 接入文档，其 Flutter Demo 也包含实时音视频通话示例；但官方平台支持表将 Flutter CallKit 标为不支持。接项目时要分别核对"IM SDK 能用""Demo 展示了通话"和"有受支持的 Flutter CallKit 产品"这三件事，别把 Demo 或第三方封装当作同一份产品承诺。

如果要在 Flutter 项目里接这类能力，我会先画出责任线：

text 复制代码

Flutter 页面：按钮、参与者列表、通话状态
环信 IM：邀请、接听、拒绝、超时、离线通知等信令
声网 RTC：采集、编码、网络传输、解码、音频路由
显示层：优先官方 Flutter RTC 组件；不满足需求再评估 PlatformView 或 Texture

通话状态应有一个明确的原生／业务所有者，Flutter 只是订阅可展示的状态。不要让 Flutter 和原生各自维护一份"是否已接听"并互相覆盖。尤其在推送唤起、锁屏来电、进程恢复时，先恢复真实会话状态，再重建页面；"页面还在"并不等于 RTC 连接还在。

5. 真要调优，从哪里量起？

先用 profile 模式 复现，记录设备、系统版本、Flutter/插件/RTC SDK 版本、通话人数、分辨率、帧率和网络条件。Flutter DevTools 的 Performance 视图能看 Flutter UI 与 Raster 帧耗时，但摄像头到远端屏幕的延迟还要结合 RTC SDK 统计、Android System Trace/Perfetto 和应用自己的时间戳。Flutter DevTools Performance

我会按这条顺序排：

采集端：看 SDK 实际输出的采集帧率、前处理耗时、设备温度与降频。预览掉帧时，先确认编码发送是否也掉帧。
桥接端 ：统计 Channel 每秒消息数、每条字节数及主线程耗时。把网络质量、音量波动等高频状态合并或按 UI 需要采样；通话关键事件仍应可靠送达。Flutter 文档要求平台侧向 Dart 发送 Channel 消息时遵守平台主线程规则，耗时工作应从消息处理器移走。Flutter Channel 线程说明
显示端 ：区分"采集/解码慢"和"合成慢"。固定视频源做 A/B：只显示视频、再叠加 Flutter 控件；分别观察 UI、Raster、GPU 与掉帧。若 SDK 只给原生 View，比较目标设备上的 Platform View 模式，而不是凭通用跑分下结论。
端到端：用可识别的画面时间戳，测"拍到 → 编码发送 → 远端解码 → 屏幕显示"。只看 Flutter fps，无法解释网络抖动和解码积压。

几个常见坑也能从这条链看出来：把 YUV 转 RGBA 再经 Dart 传一圈，缓冲队列越积越长导致"帧率没降，延迟却升"；重复创建纹理却没有释放，返回通话页后黑屏或内存上涨；Surface 在后台被销毁，前台回来仍向旧对象输出；主线程执行 SDK 初始化、权限处理或大对象转换，按钮和动画一起卡。对实时通话，队列满时通常应按 SDK 策略丢弃过期视频帧，优先显示新帧，不能无限排队。

最后记住一个选型顺序：先用 SDK 官方 Flutter 接口；帧留在原生媒体链；命令和状态走类型明确的桥；只有测出瓶颈并确认 SDK 提供对应输出能力，才改显示路径或引入 FFI。 FFI 适合 C/C++ 接口，Pigeon 适合把消息协议做牢靠，它们各自解决不同问题。Flutter FFI 与插件文档