简介面向Android开发者的BLE4.0通信示例工程完整演示低功耗蓝牙从设备扫描、连接、服务发现到数据读写与通知订阅的闭环流程。代码基于Android 4.3官方API编写覆盖BluetoothLeScanner、BluetoothGatt、BluetoothGattCharacteristic等核心类并针对扫描参数配置、连接状态回调、特征值读写等关键环节给出可直接落地的写法资源描述对设备扫描、连接、服务发现、数据交互、通知订阅、断开连接六大流程均有细致拆解适合需要快速集成蓝牙通信或入门IoT设备互联的开发者。压缩包共56个文件包含Java源码、XML布局与配置、PNG图片资源以及可直接安装的APK包整体仅208KB结构紧凑便于逐文件对照学习和二次开发。已有303人学习下载。通过这个Demo可直观理解BLE通信状态机与常见异常处理同时结合源码梳理服务发现、通知订阅等完整流程为可穿戴设备、传感器数据采集等场景提供可复用的参考实现。 做嵌入式这些年陆陆续续点过不少灯、调过不少协议栈。坦白说真正让我觉得“模块间能说话”这事变得有实用价值的不是串口也不是CAN而是BLE。BLE 4.0这个版本的Demo到今天依然是很多物联网产品验证原型的第一站。这篇就围绕一个典型的“BLE4.0Demo”把从方案选型、GATT结构设计、连接参数配置到实际调试踩坑的完整路径捋一遍。适合刚接触蓝牙低功耗的硬件工程师、嵌入式软件开发者以及被WiFi功耗折磨得没脾气、想转BLE做产品原型的朋友。1. 项目概述与方案选型1.1 为什么到现在还在聊BLE 4.0每次提到BLE总有人第一时间想到BLE 5.0甚至5.4觉得4.0是过时产物。但很多实际产品设计里BLE 4.0仍然占据一席之地。原因并不复杂BLE 4.0定义了低功耗蓝牙的基础框架广播、扫描、连接、GATT服务、配对绑定这一套核心机制从4.0到现在几乎没有颠覆性变化。而BLE 5.0增加的2Mbps物理层速率、Coded PHY长距离模式、扩展广播都是在4.0的地基上新增的可选项。从需求出发如果一个Demo只需要传输温湿度、计步数据、开关状态这类小包数据BLE 4.0的1Mbps有效吞吐量已经足够。而且4.0的协议栈更精简对MCU的Flash和RAM占用更小在很多成本敏感的芯片上比如CC2541、nRF51822时期的老平台跑4.0的协议栈比跑5.x更轻松。更重要的是BLE 4.0对Android 4.3以上、iOS 5以上系统有良好的兼容性做产品验证时不需要担心老设备的兼容性问题。1.2 硬件平台与开发板选型做BLE4.0Demo硬件选型几乎决定了后面开发的顺畅程度。我列几个常用的平台方便你对着自己的需求挑nRF52832虽然是BLE 5.0芯片但完全兼容4.0协议SDK成熟文档丰富适合做原型验证。缺点是管脚较少外设扩展需要细心安排。CC2541TI的经典BLE 4.0 SoC51内核跑协议栈后剩余资源有限但胜在成本低、资料多适合量产的简单场景。ESP32乐鑫的芯片支持BLE 4.2编程模型简单用ESP-IDF或Arduino都能快速上手。我遇到过不少开发者用它做Demo再根据需求换到更专用芯片。AT32 / AP6256 等模块方案直接用透传模块发送AT指令控制省去协议栈开发适合硬件工程师快速出原型。如果你是第一次做BLE项目我的建议是别一上来就啃协议栈源码先用成熟的SDK和开发板把一个最简单的“从机广播、主机扫描连接、收发数据”跑通再慢慢往里加东西。这个思路和学单片机先点灯、学Linux先跑hello world是一回事。选型时重点看三点① 是否有现成的SDK和示例工程② 芯片是否满足功耗目标睡眠电流、峰值电流③ 是否有足够的Flash一个带OTA的BLE 4.0工程通常需要128KB以上FlashRAM至少8-16KB。2. GATT结构与连接参数设计2.1 GATT服务结构怎么定BLE通信绕不开GATT。简单说GATT定义了一个“属性(Attribute)”的表格服务(Service)是一组属性的集合特征(Characteristic)是服务里的具体数据项属性(Property)决定这个特征可读、可写还是可通知。设计Demo时很多人上来就随便起UUID结果真机调试时被自己坑了——有些手机系统对标准服务有特殊处理自定义服务建议使用自定义的128位UUID避免和Bluetooth SIG定义的16位UUID比如电池服务0x180F、设备信息服务0x180A冲突。我常用的做法是用一个自定义服务比如0xFFF0承载业务数据把数据分成两个特征Write特征0xFFF1手机端给设备下发命令。Notify特征0xFFF2设备主动上报数据比如传感器采集结果、状态变化。为什么这样拆因为BLE的规范中Write和Notify分别对应下行控制与上行数据上报拆开后主从两端逻辑清晰调试时也能通过属性权限快速判断是哪一步出了问题。另外如果后续要支持“读”操作可以再加一个Read特征但注意一个特征不建议同时挂太多属性否则部分手机在枚举服务时会表现异常。2.2 连接参数规范与功耗的权衡连接参数是BLE4.0Demo中最容易被忽略、但又最影响体验和功耗的部分。连接参数主要由四个值决定Connection Interval两个连接事件之间的时间间隔单位是1.25ms的整数倍。范围7.5ms到4s。Slave Latency从机可以跳过多少个连接事件不监听。跳过的次数越多从机越省电但数据延迟也会变大。Supervision Timeout超过这个时间没收到连接事件链路就断开。范围100ms到32s。实际发送数据时有效吞吐量 每个连接事件可发送的数据包数 / (Connection Interval × (1 Slave Latency))。这里有一个关键矛盾间隔越短数据收发越及时但主机和从机都要频繁醒来功耗越高。间隔越长整体越省电但发一个包可能要等几百毫秒。iOS系统对连接参数有一整套审核逻辑如果App请求的Connection Interval不在系统允许的范围内通常是15ms到30ms系统会忽略请求并使用默认参数。如果你在做iOS配套App务必在请求连接参数之前查一下当前系统版本对参数的限制。我在实际项目里一般这样配需要低延迟控制时Connection Interval设为15msSlave Latency设为0如果只是周期性上报传感器数据则把Connection Interval设为100ms左右Slave Latency设为4这样从机大部分时间可以睡大觉。实测下来前者单次通信延迟大约在10-20ms后者能把平均电流从几十毫安降到几毫安视具体外设而定。提示连接参数的修改时机有讲究。主机可以在连接稳定后发起参数更新请求从机也可以通过L2CAP层主动请求更新。但不要一连接上就立刻改参数部分协议栈会报错。稳妥的做法是建立连接后等1秒左右再发起参数更新。3. 实操从零搭一个可用的BLE4.0Demo3.1 广播包设计与ADV配置广播是BLE设备的身份名片。设计广播包时核心问题不是“我要广播什么”而是“我要让对端在扫描时一眼认出我且不被系统过滤掉”。广播包的结构是多个AD Structure的组合每个Structure由Length、Type、Data组成。常用字段包括Flags0x01声明设备是LE Limited Discoverable Mode还是General Discoverable Mode通常设为0x06同时支持BR/EDR和LE。Complete Local Name0x09设备名称比如“MyBLEDemo”或产品的品牌名。Service UUID0x02/0x03/0x06/0x07服务UUID按128位还是16位、是否完整列表选择对应的Type值。Manufacturer Specific Data0xFF厂商自定义数据可以塞一些简单状态标志比如固件版本号、设备ID方便App扫描时直接识别。广播间隔建议设置在100ms到500ms之间。间隔越短被发现越迅速但广播期间的电流消耗也会增加。做低功耗产品时广播间隔拉长到1s以上也常见代价是连接体验变差用户拿手机扫半天扫不到设备就会想卸载你的App。这里分享一个调试技巧用nRF Connect的“Scanner”页面扫到设备后不要只看名字点进去看广播包的具体字节。你会发现有些手机系统会对广播包做缓存或过滤比如Android系统在部分版本上会缓存广播包导致扫描不到新增的Service UUID。真机调试时只要发现广播内容和你配置的不一致优先怀疑缓存问题而不是协议栈配置。3.2 主从通信流程与数据收发一个完整的BLE4.0Demo通信流程可以抽象成这个链路设备上电 初始化协议栈和GATT服务 开始广播 手机主机扫描到设备 发起连接 连接成功后双方交换MTU大小 手机写入命令Write 设备处理并返回结果Notify 断开连接或进入睡眠。MTU交换是个值得留意的细节。BLE 4.0默认MTU是23字节其中包含3字节的L2CAP头意味着单包用户数据只有20字节。如果你的业务字段稍长比如一次要传50字节的日志或传感器批量数据就必须在连接成功后主动请求MTU交换把MTU提到247字节常见值部分协议栈支持更高。这个操作一旦漏掉你会发现明明协议栈支持长包但数据就是发不出去或者被系统自动分包接收端拼接顺序错乱。我在Demo里实现数据帧格式时习惯用最简的“帧头长度命令字数据CRC”0xAA 0x55 | Length(2B) | Cmd(1B) | Data(N) | CRC16(2B)为什么加CRCBLE底层虽然有CRC校验但GATT层的传输是“每包确认”的底层丢包重传并不代表上层业务封装完整。尤其当App和固件不是同一拨人开发时一个清晰的帧格式能减少大量“数据对不上”的扯皮。CRC算法不用自造选CRC-16/CCITT或CRC-32都行我习惯用CRC32虽然多两个字节但碰撞概率更低调试时内心更踏实。3.3 与GPIO联动的外设控制场景很多Demo的价值不仅在于“能收发字符串”更在于“收到命令后真的能控制硬件”。我在做BLE4.0Demo时最喜欢加的一个示例就是通过BLE控制LED灯或继电器的通断这个看似简单的功能把BLE从“数据通道”变成了“控制通道”正好衔接到不少热词里提到的“ble主从模块gpio”场景。实现思路很简单在Notify/Write特征的回调里解析命令比如收到{0xAA 0x55, 0x00 0x03, 0x01, 0x01, CRC}就把GPIO1置高收到0x00就把GPIO1置低。但这里有个坑BLE回调函数的执行上下文往往是在协议栈的任务/线程中如果直接在回调里做delay或复杂运算会把协议栈卡死甚至触发看门狗。正确做法是回调里只做消息记录和标志位设置真正的GPIO操作放到主循环或单独的任务里去执行。另外要注意GPIO的电平匹配和驱动能力。BLE开发板的GPIO通常只支持几毫安的驱动电流直接驱动继电器线圈或功率LED很容易烧管脚。我一般会在中间加一个三极管或MOS管做开关或者用ULN2003这类达林顿驱动芯片。这不是BLE特有的问题但实际做Demo时十个里总有两个人会在这上面烧掉几个IO口。4. 调试、踩坑与常见问题速查4.1 Linux下用bluetoothctl调试的实用姿势做BLE调试手机端有nRF Connect电脑端我推荐Linux下的bluetoothctl配合bluez协议栈使用。很多人用它只执行scan on和connect其实它能做的事远不止这些。常用调试流程打开一个终端运行bluetoothctl然后按顺序执行power on agent on default-agent scan on # 等几秒看到目标设备MAC地址记下来 scan off connect MAC地址连接成功后不需要退出bluetoothctl直接敲menu gatt进入GATT子菜单然后list-attributes查看服务列表select-attribute UUID选到目标特征后用read或write操作特征值。这些操作能帮你在不写一行代码的情况下验证从机端GATT结构和读写属性是否正确。这里还有个小技巧如果你只想开BLE、不想让系统在扫描时同时处理传统的BR/EDR即蓝牙经典模式可以通过bluetoothctl或配置文件把BR/EDR关掉。这在调试时会减少很多干扰。具体命令为power off adapter set-privacy on adapter set-adv-data ...需要注意不同bluez版本命令格式有差异实际操作时先执行help看当前版本支持的命令再操作。调试时如果发现设备扫描不到先检查广播是否真的在发用另一台设备或逻辑分析仪抓包再看systemctl status bluetooth确认服务状态不要一开始就怀疑射频参数。4.2 跨平台调试的典型差异BLE4.0Demo验收的时候至少要在iOS和Android两个平台上各跑一遍因为两边的行为差异很大。在iOS端主要是连接参数的审核问题。App通过CoreBluetooth发起连接后调setDesiredConnectionInterval请求期望参数但最终生效的参数由系统决定。如果你的设备需要低延迟但系统给了你100ms的间隔延迟体验会明显变差。这种情况要么调低设备的通信频率要么检查自己请求的参数是否在系统允许的合理范围内。在Android端最大的坑是扫描过滤和动态权限。从Android 6.0开始应用扫描BLE设备需要定位权限而Android 12及以上进一步收紧了对附近设备NEARBY_WIFI_DEVICES的权限要求。不少人写完App在手机上跑扫不到设备第一反应是模块坏了实际上是没授权或者权限策略把扫描结果拦了。另一个Android的老毛病是扫描回调在某些手机上会被系统批量延迟触发处理时不要把每次扫描回调都当成实时事件去刷新UI对结果做去重和过滤会稳妥很多。如果你在Windows上用WinForms.NET Framework 4.7.2做上位机想和BLE 4.0设备通信可用的第三方库不算太多。我目前用下来比较顺的是32feet.NET老牌蓝牙库对经典蓝牙RFCOMM支持好但BLE支持一般某些场景需要扩展。Windows.Devices.BluetoothWinRT API这是系统自带的API在.NET Framework 4.7.2中通过包引用也能调用功能完整但UWP/WinRT的异步API和WinForms的同步模型有冲突需要用AsTask()等机制桥接。InTheHand.Net.Bluetooth这是32feet.NET的新版本支持UWP API的调用方式同时兼容.NET Framework。我的经验是在.NET Framework 4.7.2项目里优先用Windows.Devices.Bluetooth那套API虽然写起来繁琐但功能最完整也别想着省事老老实实处理好async/await的线程切换否则UI会卡到怀疑人生。4.3 常见问题速查表把我在Debug过程中遇到的高频问题汇总成一个表格方便你开发时随时翻查现象可能原因解决思路手机扫描不到设备广播没开启或广播包被缓存确认advertising已启动清蓝牙缓存或用新MAC测试能扫描到但连接不上设备已与其他主机连接检查从机是否只有单连接能力断开旧连接或开启多连接支持连接后发送无响应MTU未交换或特征权限不对确认特征属性是Write/Notify检查MTU协商结果数据收发乱码/截断单包数据超长或封包错误启用长包支持使用自定义帧格式长度字段iOS下延迟明显高连接参数被系统覆盖调整请求参数的优先级优先适配iOS系统推荐区间Android上首次连接后收到重复数据系统通知回调机制在固件侧处理去重或App端记录并过滤重复seq/包号电流异常偏高广播间隔太短或GPIO拉高功耗加大广播间隔检查外设供电和GPIO状态这些问题的共同点是初期看起来像“硬件坏了”或“协议栈崩了”最终排查下来80%都是配置和时序问题。遇到问题别急着换硬件先把日志打开看协议栈事件流转确认连接是否建立、特征是否枚举成功、数据通路是否闭合再动手改代码。5. 从Demo走向产品几个实用扩展建议如果这个BLE4.0Demo只是为了学习跑到“能收发数据”就可以收工了。但如果你想往产品方向走还有几个点值得提前考虑。第一个是安全性与配对绑定。BLE 4.0的“Just Works”配对方式虽然能加密链路但无法防中间人攻击。如果产品涉及门锁、支付、医疗数据等场景必须升级到MITM保护模式Passkey Entry或Numeric Comparison并实现长期密钥存储LTK。很多人在Demo阶段图省事不绑定量产时发现安全问题再来改成本会成倍增加。第二个是OTA升级。做过一次你就知道没有OTA的BLE设备就是一块砖。Demo阶段可以把固件升级接口预留出来比如用额外的Service和Characteristic承载升级数据或者选择支持bootloader的芯片。哪怕先不做升级逻辑也建议在协议栈里预留好Flash分区别等产品卖出去了才想着改。第三个是功耗的精细优化。BLE4.0Demo跑通了之后用万用表量一下整机电流广播状态 vs 连接状态 vs 深睡眠状态三者的电流差别可能是一百倍。这时候再去优化广播间隔、连接参数、外设供电才是真正的低功耗设计。我见过不少项目Demo阶段没关注功耗后面发现电池续航远低于预期最后只能换个两倍大的电池纯属给自己挖坑。我在实际调这些项目的时候一个比较深的体会是BLE本身只是个管道真正决定产品好坏的是管道两端的数据设计和状态管理。你把GATT服务定义清楚、连接参数配合理、状态机梳理明白哪怕用的是老掉牙的BLE 4.0芯片体验也不会差。而一旦这些细节没想清楚换再新的蓝牙版本也一样会翻车。以后做新的Demo也不妨拿这个项目当模板先通后精再逐步往BLE 5.x的扩展广播、Coded PHY、Mesh这些方向迁移。本文还有配套的精品资源点击获取