Electron应用如何通过蓝牙与移动端App通信实现数据上传

一、前期技术栈选型 #

• 移动端优先选React Native，不推荐Ionic。React Native的蓝牙原生模块封装成熟度更高，双端权限、连接稳定性表现都更好；Ionic基于webview封装的蓝牙接口在iOS后台权限、BLE长连接场景下坑点极多，调试成本很高。
• 蓝牙协议统一选BLE（低功耗蓝牙），不要用经典蓝牙。经典蓝牙在iOS端有严格的MFi认证要求，非认证硬件设备无法建立连接，BLE是双端系统都开放的通用协议，不需要额外资质。
• Electron端不要使用内置的Web Bluetooth实验特性，该特性仅支持作为中心设备扫描其他蓝牙设备，不支持作为外设被手机扫描连接，且默认处于禁用状态，兼容性极差。

二、分端实现步骤 #

1. Electron端实现 #

• 依赖选择：使用社区持续维护的BLE外设库@abandonware/bleno，原生bleno库已经停止维护多年，不兼容新版Electron和新系统。安装依赖后需要针对当前使用的Electron版本重新编译原生模块，否则会运行报错。
• 核心逻辑：
  • 初始化蓝牙模块后，注册自定义GATT服务，自行生成128位唯一UUID作为服务标识，避免和其他设备的蓝牙服务冲突。
  • 在服务下定义两个特征值：一个为可写特征，用于接收移动端传回的服务器响应、控制指令；一个为通知特征，用于主动向移动端推送需要上传到服务器的本地数据。
  • 启动蓝牙广播，广播包中携带自定义服务UUID，方便移动端快速识别过滤设备。
• 权限配置：Windows端需要在系统设置中给应用开放蓝牙权限；macOS端需要在打包配置的Info.plist中添加蓝牙外设使用说明，否则应用无法启动蓝牙广播。

2. React Native移动端实现 #

• 依赖选择：使用react-native-ble-plx库，该库维护周期长，双端BLE逻辑封装统一，是目前React Native生态下蓝牙开发的首选。
• 核心逻辑：
  • 提前配置双端权限：Android端根据系统版本声明蓝牙扫描、连接权限，安卓11及以下版本还需要声明粗略定位权限才能正常扫描蓝牙设备；iOS端在Info.plist中添加蓝牙始终使用说明，若需要后台保持连接，还要在能力配置中开启蓝牙后台模式。
  • App启动后开启BLE扫描，通过之前定义的自定义服务UUID过滤目标设备，扫描到Electron端设备后自动发起连接。
  • 连接成功后发现对应服务与特征值，订阅通知特征的消息回调，收到Electron端发来的数据后，直接通过蜂窝网络将数据转发到自有服务器；拿到服务器响应结果后，通过可写特征将结果回传给Electron端。

3. 传输规则约定 #

• BLE默认单包最大传输载荷仅20字节，协商MTU后一般单包最大也不超过512字节，传输大于单包上限的数据时需要自行实现分包逻辑：可以在每帧数据头部加固定长度的标记位，记录当前帧序号、总帧数量、数据校验值，接收端按序号拼接完整数据包，校验不通过时触发对应帧重传。
• 实现简单的心跳机制：每隔2秒左右双端互发1字节的心跳包，实时检测连接状态，断连后自动触发重连，避免连接异常中断后无法自动恢复。

三、常见避坑点 #

• iOS端对BLE外设的广播包长度有限制，不要在广播包里塞自定义业务数据，所有业务数据都要等连接建立后通过特征值传输。
• Electron端打包时要把蓝牙原生模块正确打包进安装包，否则用户安装后会出现找不到模块的报错。
• 初期实现不用追求传输速度，先跑通小数据量的传输链路，后续如果有大数据传输需求，可以在BLE握手建立信任后，尝试通过Bluetooth PAN建立TCP通道提升传输速率，不过该方案配置复杂度较高，适合后期迭代再做。

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