文件传输流程中核心分为「发送端」和「接收端」，角色定义取决于数据流向，具体适配场景如下：

• 发送端：提供文件数据的一方（可是应用程序或设备）；

• 接收端：接收并保存文件数据的一方（可是应用程序或设备）。

针对摄像头类产品，需根据已集成的API框架选择文件传输实现方式：

1. 已集成 AVAPIs 或 RDTAPIs：直接基于对应API实现文件传输功能（本文档重点讲解）；

2. 已集成 P2PTunnelAPIs：通过「P2PTunnelAPIs + HTTP/FTP」实现，详细参考以下文档：

- 基于P2PTunnelAPIs和TCPIP协议开发NAS（或者摄像头）-APP端

- 基于P2PTunnelAPIs和TCPIP协议开发NAS（或者摄像头）-设备端

基于AVAPIs的文件下载适用于已集成AVAPI框架的产品，对接复杂度中等，弱网环境下效能表现优秀，是推荐的文件传输方案之一。

• 设备端缓存区默认大小：每个通道256KB（可调整，建议不超过1MB）；

• 每包数据大小：建议2~10KB（不超过缓存区大小即可）；

• 可靠性：需检查API返回值（如 avSendFrameData），返回 -20006 时需重新发送该数据包。

当前公版文档暂未提供基于AVAPIs的文件上传详细实现流程，如需开发可参考文件下载逻辑，核心需注意：

1. 保持发送端/接收端角色反转（APP作为发送端，设备作为接收端）；

2. 严格遵循文件名格式规范（不带路径、包含正确扩展名）；

3. 正确设置 endFlag（仅最后一个文件的最后一包设为1）。

上传功能需结合设备端接收逻辑自定义开发，确保文件数据完整性校验和存储适配。

基于RDTAPIs的文件下载适用于对传输灵活性要求较高的场景，需自行处理包头打包、数据切包逻辑，对接复杂度高于AVAPIs。

• 设备端缓存区大小：无限制（仅受设备RAM容量约束）；

• 每包数据大小：无限制（可根据实际场景自定义）；

• 关键要求：设备端需自行打包包头和数据，APP端需对应实现切包和包头解析逻辑。

当前公版文档暂未提供基于RDTAPIs的文件上传详细实现流程，核心开发要点：

1. 遵循RDT协议的包头格式规范，自定义数据分片策略；

2. 发送端需确保数据包顺序一致性，接收端需处理乱序、丢包场景；

3. 参考下载逻辑中的通道调度策略，保障上传效率。

RDTAPIs无内置的数据包校验机制，需自行实现完整性校验（如CRC校验）和重传逻辑。

公版APP不支持断点续传功能，如需实现可自行开发：

• APP端维护下载表，记录文件名、已下载位置、文件总大小等信息；

• 断点续传时，从已下载位置开始请求剩余数据，设备端对应返回分片数据。

通道数和调度逻辑由设备端自定义设计，公版协议不做绑定限制，常见设计方案：

• 按文件类型分通道：视频、图像、声音分别通过不同通道发送；

• 动态负载均衡：将慢通道的文件调度至快通道，提升整体传输效率；

• 故障转移：通道异常时，将该通道文件调度至其他正常通道，保障传输连续性。

核心原则：确保文件信息和数据完整传输，无额外限制。

公版协议不对文件类型做限制，理论上支持所有类型文件，需满足以下条件：

• 设备端发送文件名时必须携带正确扩展名（如 .txt、.mp4、.jpg 等）；

• 手机系统需支持对应文件的解析（否则仅能保存文件，无法直接打开）。

（1）API返回值检查：发送端需校验 avSendFrameData 等API返回值，返回 -20006 时需重新发送该数据包；

（2）endFlag 设定：仅最后一个文件的最后一包数据的 endFlag 设为1，其余均为0；

（3）RDT协议特殊处理：设备端需自行打包包头和数据，APP端需对应实现切包和包头解析；

（4）通道关闭时机：发送完最后一包数据后，需检查发送缓存区是否有未发送完成的数据，确认无残留后再关闭通道；

（5）文件名规范：文件名不带路径，必须包含正确的扩展名。

• 优先选择 AVAPIs：弱网环境、对接效率要求高、无需复杂自定义场景；

• 选择 RDTAPIs：需灵活调整传输策略、对数据包大小无限制、需自定义包头解析场景。