如何去優(yōu)化一個大的音頻數(shù)據(jù)通過藍牙設(shè)備傳輸?shù)絚端，保證數(shù)據(jù)包的完整汇歹，合理的延遲性黔龟。
我的思路主要是從下面幾個地方開始開展：
現(xiàn)在藍牙的開發(fā)都是ble4.0協(xié)議進行開展了序宦，那我們現(xiàn)在面臨哪些核心的挑戰(zhàn)呢：
1. 核心挑戰(zhàn)
? ? 1.? BLE 帶寬限制：
? ? ?? 藍牙 4.0 的典型傳輸速率為 1 Mbps，但實際應(yīng)用中可用帶寬約 260 Kbps为狸。
? ? ?? 單次數(shù)據(jù)傳輸大小受 MTU 限制（默認 23 字節(jié)歼郭，數(shù)據(jù)部分 20 字節(jié)）。
? ? 2.? 數(shù)據(jù)分片和丟包：
? ? ?? 音頻數(shù)據(jù)較大辐棒，需要分片傳輸病曾。
? ? ?? 可能因干擾、帶寬不足導(dǎo)致丟包漾根。
? ? 3.? 實時性：
? ? ?? 需要小延遲傳輸音頻泰涂，避免累積數(shù)據(jù)包。
? ? 4.? 數(shù)據(jù)完整性：
? ? ?? 需要檢測并恢復(fù)丟失的分片數(shù)據(jù)辐怕。
針對這些問題逼蒙，我們就要開始想出一些對應(yīng)的優(yōu)化方案：
1. BLE 數(shù)據(jù)傳輸優(yōu)化
(1) 增加 MTU
協(xié)商更大的 MTU，減少分片次數(shù)寄疏，提高傳輸效率是牢。
[peripheral requestMtu:185]; // 適用于 Android，
iOS 會自動協(xié)商最大 MTU陕截。
(2) 減少連接間隔
設(shè)置連接間隔到較小值（7.5ms 至 15ms）（建議值）驳棱，提高數(shù)據(jù)傳輸頻率。
NSDictionary *options = @{
? ? CBConnectPeripheralOptionMinimumConnectionIntervalKey: @(0.0075), // 7.5ms
? ? CBConnectPeripheralOptionMaximumConnectionIntervalKey: @(0.015)? // 15ms
};
2. 數(shù)據(jù)分片和重組
(1) 數(shù)據(jù)包格式
(2) 分片發(fā)送
將音頻數(shù)據(jù)分片成小包（不超過 MTU - 1 字節(jié)）农曲，逐包發(fā)送社搅。
3. 確保數(shù)據(jù)完整性
(1) 序號管理
? ? ?? 發(fā)送端：每個數(shù)據(jù)包附加序號，按序發(fā)送。
? ? ?? 接收端：
? ? ?? 檢測序號是否連續(xù)形葬。
? ? ?? 序號不連續(xù)時却汉，標記丟失并請求重傳。
(2) ACK 重傳機制
? ? ?? 發(fā)送端等待接收端返回 ACK荷并，未收到則重傳合砂。
4. 提高實時性
(1) 音頻編碼
? ? ?? 使用高效音頻編碼減少數(shù)據(jù)量，提高實時性源织。
? ? ?? 推薦使用 ADPCM 或 Opus翩伪。
? ? ?? ADPCM：輕量級、適合 BLE谈息。
? ? ?? Opus：高壓縮比缘屹、適合高質(zhì)量音頻。
? ? ?? 示例：
? ? ?? 原始 PCM 音頻為 16KHz侠仇，16 位單聲道轻姿，數(shù)據(jù)量約為 256 KB/s。
? ? ?? 使用 Opus 編碼后逻炊，數(shù)據(jù)量減少到 8-64 KB/s互亮。
(2) 數(shù)據(jù)緩沖
? ? ?? 在接收端使用環(huán)形緩沖區(qū)存儲接收到的音頻數(shù)據(jù)，按時間順序播放余素，避免延遲豹休。
? ? (2) 數(shù)據(jù)緩沖
? ? ?? 在接收端使用環(huán)形緩沖區(qū)存儲接收到的音頻數(shù)據(jù)，按時間順序播放桨吊，避免延遲威根。
5. 重傳機制
? ? 1.? 接收端：
? ? ?? 記錄丟失的數(shù)據(jù)包序號。
? ? ?? 發(fā)送重傳請求到發(fā)送端视乐。
? ? 2.? 發(fā)送端：
? ? ?? 在接收到重傳請求時洛搀，重新發(fā)送丟失的數(shù)據(jù)包。
