Android BLE多设备连接时GATT回调并发上报数据丢包问题咨询

问题1：多BLE设备并发上报notification的可行性 #

Android原生BLE协议栈原生支持多设备并发上报notification，不需要强制串行处理多设备请求。
需要注意的是Android系统对BLE同时连接数有硬上限，原生AOSP的默认上限是7台，部分厂商定制ROM可能会调整到4-10台不等，超过上限后底层会主动断开优先级较低的连接，也会表现为丢包或连接中断。
你当前遇到的多设备上报仅第一台正常的问题，不属于需求不可实现，而是实现逻辑存在优化空间。

问题2：连续notification是否会阻塞后续GATT操作 #

会。Android BLE的所有GATT操作（包括notification回调、特征值读写、连接参数更新、MTU协商）均共享同一个底层Binder线程队列，notification属于底层主动上报事件，优先级高于主动发起的GATT请求。
多台设备同时以毫秒级间隔上报notification时，队列会被快速占满，后续上报的notification会直接被底层缓冲区丢弃，其他GATT操作也会因为队列阻塞出现超时或执行失败。

问题3：GATT回调逻辑的影响及队列方案的可行性 #

大概率和你的GATT回调处理逻辑有关。绝大多数BLE丢包问题都源于开发者在BluetoothGattCallback#onCharacteristicChanged回调中执行了耗时操作（比如数据解析、磁盘IO、UI更新、冗余日志打印），该回调运行在BLE专属Binder线程上，只要单次回调处理耗时超过单包上报间隔，底层的ATT层缓冲区就会溢出，直接丢弃后续上报的数据包。
关于队列处理方案的顾虑是多余的，只要你做两层队列隔离，完全不会出现队列上限问题：

• 第一层：回调层仅做数据入队操作，不执行任何其他逻辑，单次入队耗时在微秒级，完全不会阻塞Binder线程
• 第二层：单独启动一个高优先级工作线程，异步消费队列中的数据，执行拼接、解析、存储等操作
  队列容量可以按照「最大并发设备数 * 单设备单次最大上报包数 * 2」的规则配置，比如你同时连接5台设备，单设备单次上报200包，设置2048大小的环形队列即可完全满足需求，不会出现队列溢出。

可落地的优化建议 #

• 连接设备后第一时间协商MTU到512，单包有效载荷可以从默认20字节提升到509字节，几KB的数据只需要十几包就能传完，大幅降低队列压力，可以解决90%的并发丢包问题
• 禁止在onCharacteristicChanged回调中执行任何耗时操作，生产环境关闭BLE相关的debug日志，磁盘IO、UI更新等操作全部抛到工作线程/主线程执行
• 不同设备的BluetoothGatt实例、数据缓存区完全隔离，避免多线程并发写全局变量导致的数据覆盖（很多时候你以为的丢包其实是不同设备的数据被互相覆盖了）
• 条件允许的话可以在BLE通信协议中增加简单的流控机制：主机每收到10-20包数据后给从设备回一个确认帧，从设备收到确认后再发下一批，从根源避免上报速度超过主机处理速度

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