ARTICLE · 1067730
机电高阶课程·APP设计开发篇·第29期 |蓝牙BLE实战:机电产品绕不开的通信层
上两期我们聊了机电产品APP到底该做什么、跨平台怎么选。现在到了最关键的环节——APP怎么和你的硬件设备通信？
答案90%是BLE，也就是蓝牙低功耗。
老舅见过太多机电团队在BLE上栽跟头——不是芯片不行，是协议层没搞透。今天这期把BLE协议栈拆开讲，不聊概念，只聊你实际做产品时会遇到的问题。
GATT：你得先看懂这份"通信说明书"
BLE通信的核心是GATT协议。说白了，它定义了一套"设备和APP之间怎么组织数据"的规则。
三个关键概念，记住就够了：
●Service（服务）：设备对外暴露的一组功能。比如你的电机控制器有一个"电机控制服务"，里面包含了所有和电机相关的操作。
●Characteristic（特征值）：服务于下面的具体数据项。比如"目标转速"是一个特征值，"当前温度"是另一个。每个特征值都有自己的读写权限——有的只能读，有的能写，有的还能主动通知APP。
●Descriptor（描述符）：特征值的"附加说明"。最常用的是CCCD（客户端特征配置描述符），APP通过它告诉设备："我要订阅你的通知，数据变了直接推给我。"
实际开发中你不需要从零实现这些，蓝牙芯片厂商（Nordic、TI、Silicon Labs）都给你准备好了SDK。但你得知道数据是怎么组织的，不然APP写出来的通信逻辑全是bug。
连接管理：最容易被低估的环节
BLE连接看起来简单——搜索、连接、通信，三步完事。
实际上呢？
老舅当年做的第一个BLE产品，在实验室里跑得完美，一上产线就出问题。后来才发现，产线上几十台设备同时广播，手机扫描列表里全是乱七八糟的名字，根本分不清哪个是自己的。
问题1：设备太多，扫不到目标怎么办？
解法有三层：
●第一层——过滤广播名。最简单，但不够可靠，因为名字可以重复。
●第二层——过滤广播数据里的自定义字段。在广播包的Manufacturer Specific Data里塞一个产品唯一标识，APP端按这个字段过滤。比名字靠谱。
●第三层——信号强度排序+近场优先。RSSI值大的优先显示，让用户拿手机靠近目标设备再连接。这个在产线环境里特别实用。
问题2：连接上了，但经常断线怎么办？
BLE断线的原因无非几种：距离过远、射频干扰、设备端固件bug、手机系统回收蓝牙资源。
前两个是物理层的事，你能做的有限。后两个才是协议层该解决的。
连接参数是关键。BLE的连接间隔（Connection Interval）决定了多久通信一次。间隔太短，耗电；间隔太长，数据延迟高，看起来就像"断了"。
老舅的建议：对于电机控制类实时性要求高的产品，连接间隔设在15-30ms；对于数据监控类，75-150ms够用。具体的值要和固件工程师一起调，别在APP端自己瞎设。
问题3：断线了怎么自动重连？
Android和iOS的重连机制不一样，这是个大坑。
Android可以用BluetoothDevice.connectGatt()的autoConnect参数设为true，系统会在后台持续尝试重连。但不同厂商的Android系统表现差异巨大——华为、小米、OPPO各有各的"优化"，把蓝牙后台进程杀掉的策略完全不同。
iOS相对省心，CoreBluetooth框架的重连机制比较可靠，但App被用户手动杀掉后就彻底断了，系统不会再帮你连。
实操建议：APP端维护一个重连队列，记录断线设备的信息。断线后用指数退避策略重试（1秒、2秒、4秒、8秒……最大间隔30秒），不要死循环狂连，手机蓝牙模块扛不住。
数据传输：MTU是绕不过去的坎
BLE单次传输的数据量受MTU（Maximum Transmission Unit）限制。默认MTU是23字节，减去3字节协议头，有效载荷只有20字节。
你要传一个传感器波形数据，一帧256字节，怎么办？
分包传输是标配方案。把256字节拆成13包（每包20字节），每包带一个序号，接收端按序号重组。看起来简单，坑不少：
第一个坑——丢包。BLE传输不保证100%到达，丢了一包，后面的序号全对不上。解法：每包带序号+最后一包带校验和，接收端发现缺失就请求重传。
第二个坑——速度。20字节一包，传256字节要13包，如果连接间隔是30ms，传一帧数据要390ms。如果你的数据量大（比如OTA固件升级），这个速度会让你怀疑人生。
解法是MTU交换。连接建立后，APP可以主动和设备协商增大MTU。Android 5.0+和iOS 10+都支持，最大可以到512字节。协商之后，256字节一包搞定，不用分包。
但注意：MTU交换不是所有蓝牙芯片都支持。便宜的BLE SoC可能只支持默认的23字节。选型的时候一定看清楚规格。
OTA：BLE最考验功力的场景
固件升级（OTA）是机电产品绕不过去的环节。通过BLE做OTA，是对上面所有知识点的综合考验。
流程大概是这样的：
●APP把固件文件分包，逐包发给设备
●设备端把收到的数据写入Flash
●全部写完后，设备校验固件完整性
●校验通过→重启进入新固件；校验失败→回滚到旧版本
两个核心问题：
传输速度：BLE的带宽本来就窄，一个200KB的固件，按默认MTU算，要传1万包。如果每包间隔30ms，光传输就要5分钟。MTU协商到512字节后能缩短到2分钟以内，但还是慢。
断电恢复：升级过程中设备没电了怎么办？必须支持断点续传——设备端记录已接收的包序号，重新上电后告诉APP从哪包继续。不支持断点续传的OTA，在产线上就是灾难。
老舅见过一个团队做的OTA方案，升级过程中设备断电，重新上电后直接变砖。原因很简单——固件已经擦掉了，新固件只写了一半，旧固件没了。这种低级错误在产品发布前一定要模拟测试。
踩坑总结
最后说一句掏心窝的话：BLE开发最难的从来不是写代码，而是调试。
因为BLE的通信过程你看不到、摸不着，出了问题只能靠抓包分析。老舅推荐你用Nordic的nRF Connect APP——能直接看到广播包内容、GATT服务结构、收发数据，相当于BLE的"X光机"。免费的，省你几百小时debug时间。
#老舅机电产品进化论#机电高阶课程#嵌入式 #BLE蓝牙 #GATT协议 #机电产品开发 #APP硬件通信 #蓝牙OTA #MTU #硬件量产踩坑
点赞 + "在看" + 转发
是对我最好的支持！👇
✅ 每周一/周二/周四/周五：机电高级课程连载 · 进阶必看
✅ 关注我，每天蹲干货，机电进阶不迷路。
机电高级课程无限期连载，稳步提升，帮你从只会画图成长为独立落地的机电设计师。
明日预告：机电高阶课程·APP设计开发篇·第30期 |机电产品APP的UI/UX：工程师别被花哨设计害了
我是老舅，只讲一线实战干货，踏踏实实做设计，安安稳稳搞开发，咱们下周见。
声明：文章中所用插图均为AI辅助生成，观点为个人观点，仅供参考！
机电产品进化论 · 机电高级课程连载系列
APP设计开发篇· 第3期 · 2026.09.24