蓝牙音频与BLE同时使用时BLE数据包丢包的原因及调试方法

• 蓝牙射频资源调度优先级冲突：蓝牙耳机使用经典蓝牙（BR/EDR）的A2DP协议传输音频流，和BLE共享手机端的2.4G射频天线与硬件调度资源。手机系统蓝牙控制器默认会给实时性要求更高的音频流分配最高传输优先级，当两者同时工作时，BLE的连接事件会被主动抢占，导致BLE数据包无法按时发送、应答超时，最终被判定为丢包。有线耳机走的是独立音频通道，和蓝牙资源完全隔离，因此不会出现冲突。
• BLE连接参数适配不合理：如果当前使用的BLE连接间隔过小、从设备延迟（Slave Latency）为0、监控超时（Supervision Timeout）设置过短，一旦BLE传输被音频抢占2~3个连接周期，就会直接触发超时丢包。如果使用的是Write Without Response等无重传机制的传输模式，被抢占丢包后不会触发链路层重传，会直接拉高最终统计的丢包率。
• 同频段干扰放大冲突影响：如果测试环境存在大量2.4G WiFi、其他蓝牙设备等干扰源，会进一步降低两种蓝牙传输的信噪比，需要更多重传才能保证音频流正常，进一步挤压BLE的传输资源，放大丢包问题。

• 抓HCI日志确认根因：Android端开启开发者选项中的启用蓝牙HCI信息收集日志，iOS端使用PacketLogger工具抓取蓝牙底层日志，过滤你的BLE外设MAC地址，查看丢包类型：如果日志中存在大量BLE Connection Event Cancelled（连接事件被取消）、优先级调度标记显示A2DP优先级高于BLE，即可确认是资源调度冲突导致的丢包。
• 对比不同BLE参数下的丢包率：依次调整BLE连接参数，控制变量测试丢包率变化：可将连接间隔调整到12.5ms_{20ms区间，从设备延迟设置为2}3，监控超时调整到1000ms以上，对比参数调整前后的丢包率，如果丢包率明显下降，说明原参数适配不合理。
• 切换传输模式验证：将原有的无应答传输模式（如Write Without Response）切换为带链路层重传的Notify或Write With Response模式，若丢包率下降，说明原传输模式没有重传机制放大了丢包问题。
• 纯净环境交叉测试：关闭测试环境内所有2.4G WiFi、其他蓝牙设备，在无额外同频段干扰的场景下复测丢包率，如果丢包率明显降低，说明外部干扰也是问题诱因之一。

内容的提问来源于stack exchange，提问作者Android_dev