无人机图传SDK项目总结（APP）

无人机很火，无论是国外国内，以后就不知道了，说到这个无人机玩具（跟大疆没的比），让我想起了小时候遥控赛车，刚刚出来时候也是非常火，俺一直以来都是穷B所以都是跑再别人的背后看人家玩，即使是很想拥（题外话）。
说说我主要负责的任务，就是封装好android 端app，以sdk的方式提供给客户二次开发。简单点就是直播

整个app是以mpv+EventBus框架进行开发,这里主要是说native层
native层主要由三个板块组成
1. 飞控指令模块
2.设备命令交互模块
3. 图传模块

1>.飞控指令模块走的是私有协议，所谓的私有协议是指，指令传输过程中，指令的校验方式，传输的位数都是由自己定义，这个是要跟设备【图传板子】端一起配合起来的用的，飞控指令主要是控制飞机的基本命令，比如控制前后左右，上下飞行，翻转等等，简单来说就是将市场上看到的遥控手柄上面的功能搬迁到app端，说到这个，我先普及一下无人机硬件的基本组成部分，市场上的无人机主要分为两种，一种是不带图传的，最主要的硬件组成就是飞控板，飞控板类似于电脑的cpu,接受各种指令，保存飞控平衡等等，马达啥的，就不说了，一种是带图传的，最主要的硬件组成是飞控板，跟图传板，他们之间是通过串口进行传输，不带图传的就是仅仅通过手柄遥控飞控，带图传的就是通过手柄遥控飞机的过程，可以通过手机连接飞机的wifi即图传板，看飞机上面拍摄到的图像，我负责的app端的命令交互就是跟图传板进行交互。

2>.设备命令交互模块,是指app端向图传板发送一些规定好的指令，让设备端去执行指定的任务，比如录像，拍照等….，交互方式主要有两种，一种是cgi格式，一种是json格式，其中都是通过使用socket来发送，一个是udp，一个是tcp,这个主要是由飞控板上面的程序决定的，app端只需要发送即可

3>图传模块，是最难，问题最多的模块，也是最重要的模块，图传走的是rtsp标准协议，传输过程是h264数据流，实时播放过程，最难解决的问题是图像卡顿，图像花瓶问题，图像在各个手机表现不一样，在性能好的手机上面，会出现图像抖动厉害的情况等等。

要解决图像卡顿的问题，先要知道卡顿的原因：
1.由数据在传输过程中丢失，没有数据，造成的卡顿
2.app端接收不及时，造成数据丢失而引起的卡顿
3.为了减少花屏，而造成的卡顿，比如说刚好丢失了i帧，为了后面显示不花屏，会对后面的p帧进行抛掉，直到下一个i帧才开始显示

我们都知道花屏的原因是因为丢帧造成的，比如说丢失了 i帧，关键帧，后面的p帧送去给ffmpeg解码得到的图像是花屏，或者马赛克等等（也有一种是大p,小p的说法，这里就不详细说了），【注意，这个传输过程没有用到b帧，整个传输过程只有两种帧 i帧，个p帧】,多一点花屏，可以减少卡顿，客户更能接受的是卡顿，而不是花屏。

解决方案：
第一个问题：由数据在传输过程中丢失，没有数据，造成的卡顿，有外部环境的影响，也有图传板信号的稳定性影响等等，app端没有很好的解决方法，无非就两个选择，一个是tcp传输，一个是udp传输。根据实测，tcp效果更好一点。
tcp ：数据传输过程，能保正数据的完整，所以花屏少点，距离相对upd会近一点，
udp：传输过程不保证数据的完整性，容易花屏，距离比较远

第二个问题：app端接收不及时，造成数据丢失而引起的卡顿，我这里遇到的情况是这样的，之前的接收数据跟解码同一个线程，显示另外一个线程，这样就有一种情况就是解码不及时，会造成接收线程阻塞，从而影响了数据的接收（udp）,解决方案是接收数据自己一个线程，解码跟显示一个线程，中间通过缓存队列来进行数据的共享，即增加缓存，基本所有的在线播放都是用这个方式。

第三个问题：就客户需求而定，我这里为了不花屏，会直接丢掉

项目使用mpv+EventBus的方式非常灵活，模块的替换，复用，重写都很灵活，而且java层没有特殊必要，一般都不会动，优化各个方面都是在jni层，也主要是图传的优化，这样也方便版本的迭代，要不客户版本升级要多痛苦。

上面的几个问题，说起来解决方法简单，真正做起来非常不容易，很多坑，要做到方便ios移植,稳定性好，兼容性强（再手机牌子众多的中国，深有体会），非常不容易，其中的苦于乐也只有自己知道（现在想想也不是很难啦，很多事过了，想想也就那么一回事），下面附上底源码结构图，源码就不共享了。总的来说学到了很多东西。