蓝牙应用的阻塞式/同步操作

更新日期: 2022-06-18 阅读次数: 130 字数: 419 分类: 微信小程序

最近写了一个蓝牙微信小程序的 bug,修复的过程中,我反思了一下蓝牙通信合理的交互模式。

原实现逻辑

在点击模式选择(即开始)/ 暂停 / 继续 / 停止,这几步操作时:

点击后,先向硬件发送蓝牙指令,然后立即更新本地状态,更新 UI 界面。

在通信正常,没有干扰,没有数据丢失的情况下,确实没有问题。

异常情况

然而在硬件放到控制柜之后,整体装机之后,诡异的现象就出现了。

20% 的概率出现界面卡住, 或者状态不同步。

根本原因在于概率性通信指令丢失。

新的交互逻辑

  • 点击后,弹出 loading 状态框,禁止其他操作。提示,通信中...
  • 收到状态变化的蓝牙回复,再允许操作,并去掉 loading 状态框
  • 如果蓝牙板子一直没有响应,最多等 10 秒。自动取消 loading 状态框。也方便用户重试。

这种就类似于 tcp / http 式的同步操作,等待有返回才允许进行后续操作。否则就得同时维护一个本地状态,还要兼顾同步硬件的状态。

带来的问题

  • 如果设备一直没有响应,怎么办?概率很小
  • 如果正好赶上之前,每十秒一次的定时查询。把状态覆盖了怎么办?这个担心多余,因为覆盖也是之前的状态,不影响新的状态。

tags: 小程序蓝牙

爱评论不评论