.NET MAUI Mac端BLE下载速度中途骤降问题排查求助

问题背景 #

用.NET MAUI开发Mac桌面应用，通过CoreBluetooth下载BLE传感器记录：前1200条仅需20秒（约3600条/分钟），之后速度骤降到500条/分钟；但其他平台工具能稳定维持5000条/分钟。已排除应用层逻辑问题（仅读取丢弃数据），MTU设置正常且启用了无响应写入。

可能原因及排查方案 #

• CoreBluetooth内部事件积压/节流
  Mac上的CoreBluetooth对连续的特征值更新回调可能存在内部缓冲区限制，初始快速是因为缓冲区有空闲空间，填满后触发节流机制。可以尝试：

  • 确保CBCentralManager使用的是串行调度队列，且队列没有被其他任务阻塞；
  • 在UpdatedCharacteristicValue回调处理完成后，主动触发下一次数据请求（如果是主动读取模式），避免被动等待设备推送；
  • 检查设备端的通知推送策略，是否在批量推送后调整了间隔，可尝试让设备维持固定的推送频率。

• 系统BLE缓存/连接上下文残留
  Mac的CoreBluetooth会缓存BLE设备的连接历史、特征值数据，残留的缓存可能影响后续传输效率。可以：

  • 断开连接时调用CancelPeripheralConnection，并彻底释放CBPeripheral实例，避免复用旧的连接上下文；
  • 关闭Mac蓝牙再重新打开，清除底层缓存；
  • 备份后删除~/Library/Preferences/com.apple.Bluetooth.plist文件，重启Mac后测试。

• .NET MAUI绑定层的性能开销
  .NET MAUI对CoreBluetooth的跨层绑定可能在高频回调场景下产生额外开销，甚至出现对象未及时回收的情况。可以：

  • 用原生Swift/Obj-C写一个最小测试案例，对比.NET MAUI版本的性能，确认是否是绑定层导致的差异；
  • 在回调中使用弱引用处理CBPeripheral或特征对象，避免不必要的内存占用；
  • 监控应用的内存占用，看速度下降时是否有内存持续攀升的情况。

• Mac系统/硬件的隐性限制
  部分Mac的BLE硬件模块或系统设置可能限制了吞吐量：

  • 关闭Mac的「低功耗模式」，避免系统为节能限制蓝牙性能；
  • 在活动监视器中查看blued进程的CPU、内存占用，若速度下降时该进程资源飙升，说明系统层面的蓝牙处理出现瓶颈；
  • 对比不同Mac设备的测试结果，确认是否是特定硬件的限制。

额外建议 #

优先测试原生CoreBluetooth实现的性能，快速定位是.NET MAUI绑定的问题，还是Mac系统/CoreBluetooth本身的限制。如果原生实现也有同样问题，那大概率是Mac端的系统或硬件限制；如果原生正常，再针对.NET MAUI的绑定层做优化。

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