Android 遥控系统并不是普通的视频播放器，而是一个完整的：
实时图传 + 数传 + 云台控制 + Android遥控终端系统。
其本质接近数字图传遥控器，而不是普通 Android APP。
本文将从 Android 技术角度，深入分析：
-
图传（视频传输）如何实现
-
数传（控制链路）如何实现
-
Android 如何解码视频
-
如何渲染到 SurfaceView
-
Flutter 与 Native 如何协同
-
Binder 与 JNI 如何参与
-
整个系统的线程与数据流架构
1 、整体系统架构****
从反编译结构可以推断，整个系统采用：
Flutter + Native + 图传SDK + 实时通信
混合架构。
完整数据流如下：
机器人摄像头
↓
H264编码
↓
无线图传链路
↓
Android Native SDK
↓
JNI/C++
↓
视频解码器
↓
SurfaceView
↓
Flutter界面
而控制链路则为：
Android摇杆
↓
控制协议
↓
无线数传链路
↓
机器人控制器
2 、图传系统的真正本质
很多开发者误以为：
RTSP = 图传
实际上并不是。
真正的图传系统包括：
因此：播放器只是最后一步，真正复杂的是无线实时链路。
3 、视频采集与编码
机器人端摄像头通常不会直接输出：Bitmap，而是：YUV420视频帧。随后通过硬件编码器进行 H264/H265 压缩。
典型流程：
Camera Sensor
↓
ISP处理
↓
YUV Frame
↓
MediaCodec Encoder
↓
H264 NALU
编码后：
每一帧会变成：
NAL Unit
例如：
SPS
PPS
IDR
P Frame
这些数据随后进入无线链路。
4 、无线图传链路原理
代码中存在：
D2D
Pair
Master
Slave
RSRP
说明其底层并不是普通 WiFi。
而是：
点对点数字链路
其原理更接近：
数字图传系统
而非：
Socket通信
5 、图传中的 RTP/UDP
图传系统通常不会使用 TCP。因为：TCP 会导致：
- 重传
- 阻塞
- 延迟增加
因此实时系统更常用RTP over UDP架构：
H264 Frame
↓
RTP Packet
↓
UDP
这样可以保证：低延迟，即使丢包也继续播放。
6 、 FEC 前向纠错机制
无线环境下：视频包会丢失。为了避免：卡顿系统通常会加入：FEC，即Forward Error Correction
原理：发送端会额外发送，冗余数据包，即使部分丢包，接收端仍能恢复原视频帧。这也是低延迟图传区别于普通 RTSP 的关键。
7 、 Android 端的视频接收
Android 遥控器端收到 UDP 数据后：通常不会直接交给 Java。而是：Native层，原因： Java 层：
- GC 不可控
- 内存复制多
- 实时性差
因此：实时图传一般采用：JNI + C++架构。 8 、 JNI 在图传中的作用
代码存在大量：.so动态库。说明：真正核心逻辑位于：Native层，典型结构：
Java API
↓
JNI
↓
Native Decoder
↓
OpenGL/MediaCodec
JNI 主要负责：
9 、 Android 视频解码原理
系统通常不会使用软件解码。因为：1080P/60FPS，CPU 很难实时处理。因此采用：MediaCodec 硬解码。
流程：
H264 NALU
↓
MediaCodec
↓
GPU
↓
Surface
这样，视频解码完全由硬件完成。CPU 负担极低。
10 、为什么必须使用 SurfaceView ？
代码中存在：PlatformView，SurfaceView
说明：视频并不是 Flutter 绘制。
原因：
Flutter 不适合：
- 高频视频
- OpenGL
- YUV渲染
因此，系统采用：Native SurfaceView架构。
11 、视频如何渲染到 Android 界面
完整流程：
UDP视频流
↓
Native RTP解析
↓
MediaCodec 解码
↓
Surface
↓
SurfaceView
↓
Flutter嵌入其中Surface是GPU共享缓冲区。
MediaCodec 解码完成后直接将图像输出到：Surface
避免：CPU拷贝，因此延迟极低。
12 、 Flutter 如何嵌入 Native 视频
系统中出现：registerViewFactory()，说明：使用了：PlatformView技术。
架构：
Flutter Widget
↓
AndroidView
↓
SurfaceView
Flutter：
只负责：
- UI
- 摇杆
- 状态显示
真正视频：
由 Native 渲染。
13 、数传系统实现原理
数传并不是视频。而是：控制指令链路
例如：
14 、数传协议实现
数传一般采用：UART，MAVLink，SBUS等协议。
控制流程：
Android UI
↓
RCSDK
↓
串口协议
↓
无线链路
↓
飞控
其中：MAVLink非常常见。因为：其支持：
-
遥测
-
GPS
-
姿态
-
Waypoint
15 、为什么数传与图传必须分离
视频：强调带宽，而控制：强调实时性
因此：系统通常：不同优先级队列
避免：视频占满带宽导致失控。
16 、 Binder IPC 的作用
代码存在：
IAirControlService
ID2DService
说明：采用：Android Binder IPC架构。
原因：图传服务需要：
- 长时间后台运行
- 独立进程
- 高稳定性
17 、线程模型分析
图传系统通常包含：
这也是为什么普通 Android App 很难实现低延迟图传。
18 、低延迟的关键优化
真正决定体验的：不是播放器。而是：延迟控制
核心优化：
1. UDP 替代 TCP
减少阻塞。
2. 小缓存队列****
例如：100ms buffer，而不是2秒缓存
3. MediaCodec 硬解****
减少 CPU 压力。
4. Surface 直出****
避免 Bitmap 拷贝。
5. Native RTP**解析******
减少 Java GC。
19 、为什么不用 WebRTC ？****
很多开发者会想到：
WebRTC，但机器人系统通常不用。
原因：
| WebRTC**问题****** | 说明**** |
| 延迟更高 | Buffer较大 |
| 音视频同步 | 无意义 |
| STUN/TURN | 不需要 |
| 浏览器兼容 | 不需要 |
因此，机器人系统更偏向：RTP/UDP + Native
20 、最终系统架构总结****
整个 Android 图传遥控系统：
本质架构：
Flutter UI
↓
PlatformView
↓
Native SDK
↓
JNI/C++
↓
MediaCodec
↓
SurfaceView
而底层无线链路：
则是：数字图传 + 数传一体系统，真正核心：并不是 Android 页面。而是：低延迟实时通信，这类系统已经属于：Android + 音视频 + 嵌入式 + 实时通信综合工程领域。
