React Native BLE PLX 在 iOS 17+ 上的连接取消问题分析与解决方案

问题背景

在 React Native 应用开发中，使用 react-native-ble-plx 库进行蓝牙低功耗(BLE)设备连接时，部分开发者遇到了一个特定于 iOS 17 及以上版本的连接问题。当尝试连接 BLE 设备时，系统会抛出 [BleError: Operation was cancelled] 错误，导致连接中断。这个问题在 Android 设备上不会出现，且在某些 iOS 设备上表现为间歇性故障。

问题现象分析

根据开发者反馈，该问题具有以下特征：

1. 仅发生在 iOS 17 及以上版本系统
2. 错误信息为明确的 Operation was cancelled
3. 初始连接可能成功，但后续重试时失败
4. 通过日志分析发现，系统在连接过程中自动调用了 cancelPeripheralConnection

根本原因

经过社区讨论和技术分析，问题主要源于 iOS 系统对 BLE 扫描和连接机制的以下特性：

1. 重复设备扫描触发：iOS 的 BLE 扫描会非常快速地重复发现同一设备，导致多次连接尝试同时进行
2. 连接冲突处理：当检测到对同一设备的多个连接请求时，iOS 会自动取消之前的连接操作
3. 连接状态同步延迟：iOS 系统内部状态与实际连接状态可能存在短暂不一致

解决方案

方案一：禁用重复设备扫描

在 startDeviceScan 方法中明确设置 allowDuplicates: false，这是最直接的解决方案：

bleManager.startDeviceScan(
  [SERVICE_UUID_LIST],
  {
    allowDuplicates: false, // 关键设置
    callbackType: ScanCallbackType.AllMatches,
    scanMode: ScanMode.LowLatency
  },
  deviceFoundFunction
);

方案二：连接状态跟踪

在扫描回调函数中实现设备连接状态跟踪，防止对同一设备发起多次连接：

function startDeviceScanWrapper(deviceName) {
  let currentDeviceId = "";
  
  bleManager.startDeviceScan(
    [SERVICE_UUID_LIST],
    { allowDuplicates: false },
    async (error, device) => {
      if (error) return;
      
      if (device && device.isConnectable && 
          (device.name === deviceName || device.localName === deviceName)) {
        
        if (currentDeviceId === device.id) {
          return; // 已处理此设备，跳过
        }
        
        currentDeviceId = device.id;
        // 执行连接逻辑...
      }
    }
  );
}

方案三：管理器实例重建

对于顽固性案例，可以采用销毁并重建 BleManager 实例的方法：

if (error instanceof Error && error.message.includes('Operation was cancelled')) {
  await this.manager.destroy();
  this.manager = new BleManager();
  return this.connectToDevice(deviceId);
}

最佳实践建议

1. 统一管理 BleManager 实例：应用中使用单例模式管理 BleManager
2. 完善的错误处理：对所有 BLE 操作添加错误捕获和处理逻辑
3. 连接状态验证：在连接前验证设备是否已连接
4. 日志记录：实现详细的日志记录，便于问题排查
5. 用户反馈：在 UI 上提供清晰的连接状态反馈

兼容性考虑

这些解决方案已在以下环境中验证有效：

• iOS 17.5.1
• iOS 18.0.1
• react-native-ble-plx 3.2.1 及以上版本

结论

iOS 系统对 BLE 连接的特殊处理机制导致了 Operation was cancelled 错误的发生。通过控制设备扫描行为、管理连接状态或必要时重建管理器实例，开发者可以有效地解决这一问题。建议优先采用方案一和方案二的组合，它们提供了最优雅的解决方案，同时保持了代码的清晰性和可维护性。