一、角色分析
文件傳輸流程中核心分為「發(fā)送端」和「接收端」，角色定義取決于數(shù)據(jù)流向，具體適配場景如下：
（一）角色定義
- 發(fā)送端：數(shù)據(jù)提供方（可是APP或設備端）；
- 接收端：數(shù)據(jù)接收方（可是APP或設備端）。
（二）API選擇建議
針對攝像頭類產(chǎn)品，需根據(jù)已集成的API框架選擇文件傳輸實現(xiàn)方式：
- 已集成 AVAPIs 或 RDTAPIs（模塊區(qū)別可參考：P2P SDK簡介）：直接基于對應AVAPIs或者RDTAPIs實現(xiàn)文件傳輸功能（本文檔重點講解）；
- 已集成 P2PTunnelAPIs：通過「P2PTunnelAPIs + HTTP/FTP」實現(xiàn)，詳細參考以下文檔：
二、基于AVAPIs的文件下載
基于AVAPIs的文件下載（點擊詳情）適用于已集成AVAPI框架的產(chǎn)品，對接復雜度中等，弱網(wǎng)環(huán)境下效能表現(xiàn)優(yōu)秀，是推薦的文件傳輸方案之一。
核心特性
- 設備端緩存區(qū)默認大?。好總€通道256KB（可調(diào)整，如有調(diào)整，需同時調(diào)增客戶端的buffer大小，建議客戶端buffer大小為設備端的4倍）；
- 每包數(shù)據(jù)大?。航ㄗh2~10KB（不超過緩存區(qū)大小即可，相關內(nèi)容：公版AV幀信息定義）；
- 可靠性：需檢查API返回值（如 avSendFrameData），返回 -20006 時需重新發(fā)送該數(shù)據(jù)包。
三、基于AVAPIs的文件上傳
當前公版文檔暫未提供基于AVAPIs的文件上傳詳細實現(xiàn)流程，如需開發(fā)可參考文件下載邏輯，核心需注意：
- 保持發(fā)送端/接收端角色反轉(zhuǎn)（APP作為發(fā)送端，設備作為接收端）；
- 嚴格遵循文件名格式規(guī)范（不帶路徑、包含正確擴展名）；
- 正確設置 endFlag（僅最后一個文件的最后一包設為1）。
說明：上傳功能需結合設備端接收邏輯自定義開發(fā)，確保文件數(shù)據(jù)完整性校驗和存儲適配。
四、基于RDTAPIs的文件下載
基于RDTAPIs的文件下載（點擊詳情）適用于對傳輸靈活性要求較高的場景，需自行處理數(shù)據(jù)打包、數(shù)據(jù)切包邏輯，對接復雜度高于AVAPIs。
核心特性
- 設備端緩存區(qū)大小：無限制（僅受設備RAM容量約束）；
- 幀結構定義：無限制（可根據(jù)實際場景自定義，相關內(nèi)容：公版RDT幀定義）；
- 關鍵要求：設備端需自行打包包頭和數(shù)據(jù)，APP端需對應實現(xiàn)切包和包頭解析邏輯。
五、基于RDTAPIs的文件上傳
當前公版文檔暫未提供基于RDTAPIs的文件上傳詳細實現(xiàn)流程，核心開發(fā)要點：
- 遵循RDT協(xié)議的包頭格式規(guī)范，自定義數(shù)據(jù)分片策略；
- 發(fā)送端需確保數(shù)據(jù)包順序一致性，接收端需處理亂序、丟包場景；
- 參考下載邏輯中的通道調(diào)度策略，保障上傳效率。
六、常見問題
1. 是否支持斷點續(xù)傳？
公版APP不支持斷點續(xù)傳功能，如需實現(xiàn)可自行開發(fā)：
- APP端維護下載表，記錄文件名、已下載位置、文件總大小等信息；
- 斷點續(xù)傳時，從已下載位置開始請求剩余數(shù)據(jù)，設備端對應返回分片數(shù)據(jù)。
2. 設備端的下載通道數(shù)及文件調(diào)度邏輯如何設計？
通道數(shù)和調(diào)度邏輯由設備端自定義設計，公版協(xié)議不做綁定限制，常見設計方案：
- 按文件類型分通道：視頻、圖像、聲音分別通過不同通道發(fā)送；
- 動態(tài)負載均衡：設備端可以根據(jù)傳輸文件數(shù)量，以及設備資源情況，自行定義開啟的通道數(shù)；
- 核心原則：確保文件信息和數(shù)據(jù)完整傳輸，無額外限制。
3. 目前支持哪些類型的文件？
公版協(xié)議不對文件類型做限制，理論上支持所有類型文件，需滿足以下條件：
- 設備端發(fā)送文件名時必須攜帶正確擴展名（如 .txt、.mp4、.jpg 等）；
- 手機系統(tǒng)需支持對應文件的解析（否則僅能保存文件，無法直接打開）。
4. 對接需要注意哪些問題？
- API返回值檢查：發(fā)送端需校驗 avSendFrameData 等API返回值，返回 -20006 時需重新發(fā)送該數(shù)據(jù)包；
- endFlag 設定：僅最后一個文件的最后一包數(shù)據(jù)的 endFlag 設為1，其余均為0；
- RDT協(xié)議特殊處理：設備端需自行打包包頭和數(shù)據(jù)，APP端需對應實現(xiàn)切包和包頭解析；
- 通道關閉時機：發(fā)送完最后一包數(shù)據(jù)后，需檢查發(fā)送緩存區(qū)是否有未發(fā)送完成的數(shù)據(jù)，確認無殘留后再關閉通道；
- 文件名規(guī)范：文件名不帶路徑，必須包含正確的擴展名。
七、AVAPIs和RDTAPIs文件傳輸對比
| 對比選項 | AVAPIs | RDTAPIs |
|---|---|---|
| 對接復雜度 | 一般（無需自定義打包/切包） | 較高（需自行實現(xiàn)包頭打包、數(shù)據(jù)切包） |
| 弱網(wǎng)效能 | 高（內(nèi)置優(yōu)化的重傳和抗丟包機制） | 較AVAPIs低（需自行處理弱網(wǎng)場景） |
| 設備端緩存區(qū)默認大小 | 每個通道256KB（可調(diào)整，建議≤1MB） | 不限制（僅受設備RAM容量約束） |
| 每包數(shù)據(jù)大小建議 | 2~10KB（不超過緩存區(qū)大?。?/td> | 不限制（可自定義） |
選擇建議：
- 優(yōu)先選擇 AVAPIs：弱網(wǎng)環(huán)境、對接效率要求高、無需復雜自定義場景；
- 選擇 RDTAPIs：需靈活調(diào)整傳輸策略、對數(shù)據(jù)包大小無限制、需自定義包頭解析場景。
