相关文件参考：
一、角色分析：
文件下载主要分为发送端和接收端。
发送端和接收端一般对应着应用程序和设备，主要取决于数据的流向。
目前对于摄像头类的产品：
- 如果已经集成了AVAPIs或者RDTAPIs开发产品，则可以继续使用AVAPI或者RDTAPI来实现文件传输功能。
- 如果是已经使用了P2PTunnelAPIs开发产品，则可以继续使用P2PTunnelAPIs+HTTP/FTP等方式实现文件传输。
*本文档仅讲解公版基于AVAPIs和RDTAPIs的文件下载流程，如想了解基于P2PTunnelAPIs实现文件传输，可以参考：
基于P2PTunnelAPIs和TCPIP协议开发NAS（或者摄像头）-APP端
基于P2PTunnelAPIs和TCPIP协议开发NAS（或者摄像头）-设备端
二、章节
- 基于AVAPIs的文件下载：基于AVAPIs的文件下载
- 基于AVAPIs的文件上传：
- 基于RDTAPIs的文件下载：基于RDTAPIs的文件下载
- 基于RDTAPIs的文件上传：
FAQ
- 是否支持断点续传？
目前公版APP不支持这个功能。如果自行开发，可以实现断点续传。APP端可以维护一个下载表，记录文件名、已下载位置等信息。下次进行断点续传时，可以从对应位置继续下载。
- 设备端的下载通道数以及文件调度的逻辑该怎样设计？
目前公版的定义由设备端决定要开启多少个通道以及每个通道要传输什么样的文件。设备端可以自行决定发送逻辑和调度的设计，因此具有足够的灵活性和自由度。设备端常见的一些逻辑设计包括：
- 视频和图像、声音分别通过不同通道发送；
- 如果某个通道发送比较慢（比如某个通道有一个超大文件），可以把这个通道的文件动态调度到发送比较快的通道；
- 如果某个通道异常，可以把此通道的文件动态调度到其他正常的通道。
目前公版的协议并不对通道和文件进行绑定，因此设备端可以自行设计各种各样的逻辑，只要保证文件信息和数据完整传输即可。
- 目前支持哪些类型的文件？
公版协议的设计目前并未对文件类型做出限制。APP只是将收到的二进制数据以设备传过来的文件名进行保存。因此，理论上可以支持任何类型的文件，前提是手机的系统要支持对应文件的解析。这种做法非常灵活。但也正因为如此，要求设备端在传送文件名时必须带上正确的扩展名，例如*.txt、*.mp4、*.mp3、*.jpg等。
- 对接需要注意哪些问题？
（1）发送端在发送时务必注意对相关的API返回值进行检查，例如avSendFrameData。如果返回值为-20006，则需要重新发送该数据包。
（2）发送端的endFlag务必要判断准确，只有最后一个文件的最后一包的endFlag才能设定为1。
（3）如果使用RDT进行发送的时候，设备端需要自行打包包头和数据，APP端需要进行切包和对包头进行解析。
（4）发送完最后一包数据后，不能立刻关闭通道，需要检查发送缓存区是否还有数据未送完。
（5）文件名不要带路径，需要带上拓展名。
- AVAPIs和RDTAPIs做文件传输的对比
