Xamarin Forms：触发阻塞式显式GC导致无法连接BLE设备

我目前在使用ble.net这个NuGet包连接BLE设备，最近遇到了一个棘手的问题：不管是调试还是发布模式下，当扫描发现大量设备后，输出窗口会出现如下GC日志：

05-21 13:14:29.862 I/art (22207): Starting a blocking GC Explicit
05-21 13:14:29.897 I/art (22207): Explicit concurrent mark sweep GC freed 5355(414KB) AllocSpace objects, 2(40KB) LOS objects, 48% free, 8MB/16MB, paused 357us total 35.054ms

之后就完全无法连接任何BLE设备了，恳请大家帮忙分析解决。

问题分析 #

这些日志显示系统正在执行显式阻塞式垃圾回收，回收后内存仍占用了8MB（总可用16MB）。这种情况通常是BLE扫描过程中内存管理不当导致的：大量临时设备对象、未释放的回调引用或资源泄漏，会让GC频繁触发，甚至干扰BLE模块的正常工作流程，最终导致连接失败。

具体解决方案 #

• 优化扫描生命周期与资源持有

  • 扫描到目标设备或扫描超时后，立即调用ble.net的停止扫描API，避免持续生成新的设备对象。
  • 不要全局存储所有扫描到的设备，只保留需要连接的设备的核心信息（如设备ID、名称），其余对象及时解除引用，让GC可以回收。

• 消除内存泄漏隐患

  • 检查BLE相关的回调（扫描回调、连接状态回调）是否使用了匿名委托，或者未在合适时机解绑事件处理器。这些强引用会导致对象无法被回收，务必在不再需要时手动解绑。
  • 对于非必需的设备对象，使用WeakReference来持有，降低内存占用压力。

• 针对性调整Android平台GC行为

  • 在扫描结束、尝试连接前，可以手动调用一次GC.Collect()帮助回收闲置内存，但不要频繁调用以免影响性能。
  • 避免在扫描回调中创建大量临时对象（如字符串、自定义数据类），尽量复用已有对象减少内存分配。

• 规范ble.net包的使用

  • 确保所有BluetoothLEDevice实例在使用完成后调用Dispose()方法释放资源。
  • 检查ble.net的官方文档或社区讨论，确认是否存在已知的内存泄漏问题，是否有版本更新可以修复。

内容的提问来源于stack exchange，提问作者Tamás Deák