最近写了一个蓝牙微信小程序的 bug，修复的过程中，我反思了一下蓝牙通信合理的交互模式。
原实现逻辑
在点击模式选择（即开始）/ 暂停 / 继续 / 停止，这几步操作时：
点击后，先向硬件发送蓝牙指令，然后立即更新本地状态，更新 UI 界面。
在通信正常，没有干扰，没有数据丢失的情况下，确实没有问题。
异常情况
然而在硬件放到控制柜之后，整体装机之后，诡异的现象就出现了。
20% 的概率出现界面卡住, 或者状态不同步。
根本原因在于概率性通信指令丢失。
新的交互逻辑
- 点击后，弹出 loading 状态框，禁止其他操作。提示，通信中...
- 收到状态变化的蓝牙回复，再允许操作，并去掉 loading 状态框
- 如果蓝牙板子一直没有响应，最多等 10 秒。自动取消 loading 状态框。也方便用户重试。
这种就类似于 tcp / http 式的同步操作，等待有返回才允许进行后续操作。否则就得同时维护一个本地状态，还要兼顾同步硬件的状态。
带来的问题
- 如果设备一直没有响应，怎么办？概率很小
- 如果正好赶上之前，每十秒一次的定时查询。把状态覆盖了怎么办？这个担心多余，因为覆盖也是之前的状态，不影响新的状态。
关于作者 🌱
我是来自山东烟台的一名开发者，有敢兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊， 查看更多联系方式
