uni-app怎么解决蓝牙传输数据丢失的问题-uni-app-PHP中文网

必须串行写入并加延迟，android需300ms以上延时防丢包；写入前需探测设备活跃性；避免重复注册notify监听；跨平台须按实际mtu分片传输。

uni-app怎么解决蓝牙传输数据丢失的问题

uni.writeBLECharacteristicValue 写入太快导致丢数据

Android 设备上最常见的情况是：调用 uni.writeBLECharacteristicValue 连续写入多段数据，但设备只收到前几条，后面全丢了。这不是 API 报错，而是底层蓝牙协议栈缓冲区溢出或设备固件来不及处理——尤其在连接打印机、传感器批量上报等场景下高频复现。

根本原因在于，该 API 是异步非阻塞的，调用后立即返回“成功”，但实际蓝牙链路并未完成发送。如果紧接着发下一条，旧数据可能被丢弃或覆盖。

必须在每次写入后加延迟，且延迟要包裹在 uni.writeBLECharacteristicValue 外层（不是 inside 回调里）
推荐起始延迟设为 300ms，视设备响应时间调整；实测部分 BLE 打印机需 500ms 以上
不要用 for 循环直接连发，改用队列 + 串行执行：上一条 success 回调触发下一条写入
iOS 一般不需此处理，但若遇到丢包，也建议统一加 100ms 基础延迟作兼容

// 正确示例：串行写入队列
const writeQueue = ['data1', 'data2', 'data3']
function sendNext() {
  if (writeQueue.length === 0) return
  const data = writeQueue.shift()
  uni.writeBLECharacteristicValue({
    deviceId,
    serviceId,
    characteristicId,
    value: hexToArrayBuffer(data),
    success: () => setTimeout(sendNext, 300), // 下一条等 300ms 后发
    fail: (err) => console.error('写入失败', err)
  })
}
sendNext()

设备进入休眠或服务特性被禁用

连接成功后隔几分钟再发指令，出现“写入成功但无返回”，大概率不是丢数据，而是设备已断连或服务不可用。BLE 设备为省电常在空闲几十秒后自动关闭 notify 或 suspend 特征值，此时写入虽成功（链路未断），但设备根本不处理。

典型表现是：uni.writeBLECharacteristicValue 返回 success，但 onBLECharacteristicValueChange 完全不触发，且后续读特征值也返回 null。

uni-app

uni-app 是基于 Vue 的跨端开发框架，适合开发 H5、App、小程序、鸿蒙和多端业务应用。

下载

不能只依赖连接状态判断是否可用，必须在写入前主动探测：调用 uni.readBLECharacteristicValue 读一个已知可读的特征值，成功即说明服务活跃
更稳妥的做法是维持心跳：每 45~55 秒 发一次轻量指令（如读电池电量），避免设备休眠
若心跳失败，立即走重连流程，而不是继续写入
某些设备要求启用 notify 后才能接收写入，务必确认 uni.notifyBLECharacteristicValueChange 已成功调用并返回 success

重复注册 onBLECharacteristicValueChange 导致“假丢包”

用户断连重连后，点击一次控制按钮，设备却执行了两次动作——日志里 onBLECharacteristicValueChange 被触发两次。这容易被误判为“数据重复发送”，实则是回调被注册了多次，造成业务逻辑重复执行，看起来像“一条指令被当两条处理”。

每次调用 uni.notifyBLECharacteristicValueChange 前，必须先用 uni.offBLECharacteristicValueChange 清除旧监听
监听函数应定义为组件级变量（如 this.handleNotify），而非匿名函数，否则无法正确移除
重连时若跳过 off 直接 notify，iOS 和 Android 都会累积监听器，且无报错提示
可在页面 onUnload 或断连时统一调用 uni.offBLECharacteristicValueChange 做兜底

MTU 值不匹配引发分包异常

当传输单次数据超过默认 MTU（通常是 23 字节），系统会自动分包。但 Android 和 iOS 对 MTU 协商的支持差异大：Android 支持 uni.setBLEMTU 主动协商更大值（如 512），而 iOS 通常固定为 23，且不支持运行时修改。若你按大 MTU 拆包发送，在 iOS 上就会因单包超限被静默截断，表现为“部分数据丢失”。