尧图网页设计 
简介面向Android BLE开发者的实战Demo基于BLE4.0标准演示设备扫描、连接、服务发现、特征值读写与通知订阅的完整通信链路。项目源于Google BluetoothLeGatt示例适合正在学习Android蓝牙低功耗接入的初中级开发者也可作为物联网外设联调时的参考骨架。压缩包共56个文件核心为6个Java源文件与对应class辅以9个XML配置/布局、9个PNG界面资源并包含可直接安装的APK总大小208KB结构紧凑便于快速导入工程分析。已有303人学习下载。通过该Demo可掌握BluetoothGatt、BluetoothLeScanner等核心API的调用方式理解扫描参数配置、连接状态回调、服务发现解析及通知订阅等关键环节同时参考Google官方文档中的最佳实践避免频繁扫描和连接异常带来的功耗与稳定性问题是一份适合对照学习的轻量级BLE入门资料。 GitHub上搜索 “BLE4.0Demo”能翻出几百个仓库但真正能一次跑通的不多。我自己踩过直接把别的工程代码抄过来却连不上设备的坑也见过有人拿4.0的Demo去连5.0的设备然后怀疑人生。BLE4.0不是单纯的“低功耗蓝牙版本号”它背后是一整套完整的协议栈广播、扫描、连接、GATT服务、属性协议每一层都有自己独立的角色和规则。这篇文章就把这条链从原理到代码全部拆开结合我实际做IoT硬件对接的经验讲讲BLE4.0Demo从搭建到跑通的完整过程以及那些文档里不会明说的坑。目标读者分两类一类是第一次接触低功耗蓝牙想快速理解“BLE4.0到底在干什么”的初学者另一类是已经能跑通示例代码但被扫描不到设备、连接频繁断开这类问题折腾过的开发者。看完之后你不仅能把Demo跑起来还能把它当成一个可扩展的项目骨架平滑迁移到门锁、传感器、智能家居这类真实产品上。1. 为什么还有人在搞BLE4.0一个Demo背后的真实价值与适用边界1.1 BLE4.0到底解决了什么问题BLE4.0是蓝牙4.0规范里的低功耗部分2010年前后发布的第一版低功耗蓝牙标准。跟经典蓝牙BR/EDR相比它最大的变化不是“传输更快”而是“传输策略完全不同”。经典蓝牙面向的是持续数据流场景比如音频耳机链路建立后要保持连接、持续传数据BLE4.0面向的是“设备发送少量数据、且大部分时间应该睡觉”的场景比如温湿度传感器每隔几秒报一次数据体脂秤偶尔上传一次测量结果门锁偶尔接收一次开锁指令。这种定位决定了它的几个核心特征峰值功耗远低于经典蓝牙平均功耗能做到微安到毫安级别一颗纽扣电池可以撑几个月甚至几年连接建立速度快从广播到连接通常在几十毫秒到几百毫秒完成数据传输速率不高物理层速率1Mbps应用层实际吞吐量大概在200~300kbps传大文件不现实但传输传感器数据绰绰有余。我用一张表把经典蓝牙和BLE4.0的核心差异列出来方便理解维度经典蓝牙BR/EDRBLE4.0典型功耗持续连接电流较高空闲睡眠微安级活动时毫安级连接建立时间秒级毫秒到百毫秒级应用层吞吐量可达2Mbps左右约200~300kbps典型应用音频、文件传输传感器、控制指令、信标广播通信模型持续连接流式传输广播短连接、间歇性传输这个对比决定了我们做Demo时的一个核心思路BLE4.0Demo优化的不是“数据怎么传得更多”而是“数据怎么传得更省、连得更稳”。1.2 什么时候选BLE4.0什么时候不必纠结版本号蓝牙5.0、5.2甚至5.3已经普及多年很多新模组也支持更高版本为什么还要单独研究BLE4.0原因有两个。第一是兼容性。BLE4.0作为低功耗蓝牙的第一版规范定义了广播、扫描、连接、GATT这套最基础也最通用的框架。后面5.x版本虽然增加了2M PHY、长距离编码、广播扩展等高阶特性但底层核心机制依然是4.0那套。在一台只支持BLE4.0的老设备或者低端模组上你写的代码和协议设计思路完全通用。理解了4.0等于拿到了理解整个低功耗蓝牙体系的钥匙。第二是产品定位。很多量产设备用的芯片仍然是BLE4.0级别比如经典的CC2541、nRF51822以及大量国产兼容芯片。这类芯片成本低、生态成熟、方案稳定在价格敏感的IoT产品里依然大量存在。做这类产品的联调你需要在4.0的约束下工作比如支持的MTU可能更小、连接参数范围更窄、广播数据长度受限。但如果你是在做需要高吞吐量或远距离传输的新产品就没必要死守4.0。BLE5.x的2M PHY和Coded PHY长距离模式在某些场景下收益非常大。这时候Demo可以基于更高版本开发但架构设计上仍然可以沿用4.0那套广播GATT的模型。一句话总结我的经验BLE4.0Demo不是过时技术它是低功耗蓝牙的“最小公因数”是所有复杂应用的基础骨架。2. 核心机制拆解广播、连接与GATT三层结构决定Demo怎么搭2.1 广播这层设备怎么“喊话”数据怎么塞进一个包BLE设备在没有建立连接之前是通过广播让周围设备发现自己的。广播就像一个人站在广场上喊话喊的内容有一个固定格式不能随便说。一个完整的广播事件包含两种数据包广播包Advertising Packet和扫描响应包Scan Response Packet。广播包是必须的扫描响应包是可选的由从机主动提供主机在收到广播包后可以主动请求。每个包的数据部分最多31字节这31字节要包含若干个AD StructureAD Structure 长度 类型 数据。常见的数据类型有这么几个0x01是Flags用来声明设备支持的能力比如LE General Discoverable Mode0x09是Complete Local Name即设备名0xFF是厂商自定义数据用来传自己的业务数据。我实际做Demo时最常用的组合是Flags 设备名 厂商自定义数据。设备名方便用户识别厂商自定义数据里放一个自定义的UUID或者状态字段实现“还没连接就能先知道设备大概在做什么”的效果。广播间隔Advertising Interval是另一个关键参数范围是20ms到10.24s。间隔越短设备被发现越快但功耗越高间隔越长越省电但扫描方要等更久才能发现设备。实际产品中广播间隔通常设置在100ms到1s之间交互类设备偏低传感器类设备偏高。这一层最容易出的问题就是广播包太长。31字节看起来不多但如果你在广播里塞了设备名、服务UUID、厂商数据很容易超限。超限后有的协议栈会直接报错有的则静默截断导致扫描端看到的设备名不完整或者厂商数据对不上。所以设计广播内容时一定要克制能省则省。2.2 连接后怎么通信GATT服务、特征与属性权限一旦两个设备建立了连接通信就不再依赖广播了而是走GATTGeneric Attribute Profile协议。GATT用“服务-特征-属性”三层结构来组织数据。一个设备可以包含多个服务Service每个服务用UUID标识服务内部包含多个特征Characteristic每个特征也有自己的UUID数据实际读写就发生在特征上。特征下面还有描述符Descriptor最常用的是CCCDClient Characteristic Configuration Descriptor用来开启通知或指示功能。举个现实中的例子一个体脂秤Demo可以定义一个“体重服务”UUID自定义服务下有“体重数值”特征属性是可读通知、“测量状态”特征属性是可读、“清零指令”特征属性是可写。App读取体重数值时有两种方式主动读取Read或者订阅通知Notify。传感器这类持续产生数据的设备通常用Notify方式设备主动推数据App被动接收这样最省电。特征上的属性权限决定了这个特征能干什么属性含义典型用途Read主机可以读取该特征值读取设备版本、状态Write主机可以向该特征写入数据发送控制指令Notify设备可以主动推送数据主机不需要应答实时上报传感器数据Indicate设备可以主动推送数据主机必须应答要求可靠传输的状态数据搞清楚这四类属性Demo的协议设计就完成了一半。我在实际中见过不少初学者把所有的特征都设成可读可写导致逻辑混乱维护起来非常痛苦。正确的做法是每个特征只开它需要的能力能读的不要可写能Notify的没必要开Indicate。2.3 几个必须写进代码备注的参数与影响连接建立之后主从双方会协商一组连接参数Connection Parameters这些参数直接影响实时性和功耗连接间隔Connection Interval主机每隔多少毫秒与从机通信一次范围7.5ms到4s。间隔越短双方通信越及时但功耗越高。Android端实际最小可以请求7.5msiOS端最小是15ms部分情况30ms。从机延迟Slave Latency从机可以跳过多少个连接事件。如果设置为4表示从机可以每隔4个连接事件才醒来一次。这个参数能在不影响外部表现的情况下大幅省电。超时时间Supervision Timeout如果在这个时间内没有收到任何包连接就判定为超时断开。范围100ms到32s必须大于连接间隔和从机延迟的组合值否则会出现“连接好好的却莫名断开”的错误。MTUMaximum Transmission Unit也是绕不开的参数。BLE4.0默认MTU是23字节其中包含3字节的ATT头实际用户数据只有20字节。如果一次要发送超过20字节的数据就必须拆包或者协商更大的MTU。BLE4.0协议支持协商到更大的MTU比如247字节但前提是双方芯片都支持。这个细节在Demo阶段最容易被忽略等到你要传一块大于20字节的数据时才发现收不全就是这个原因。3. Demo开发实录从建工程到双向通信的完整链路3.1 硬件准备与工具选型做BLE4.0Demo最少需要两块东西一块BLE外设从机一个带有蓝牙模块的主机设备手机或电脑。外设的选择有两个方向。一是开发板比如经典的TI CC2541开发板、Nordic nRF51822开发板这类板子资料多、例程完整适合学习二是现成的BLE模组比如各类串口透传模组内部已经跑好了完整的协议栈你只需要通过串口发AT指令或者自定义帧就能控制。我的建议是学习阶段用开发板因为你要看的是协议栈的行为产品原型阶段用透传模组省时间符合“基于常见实践的合理选择”。主机端我推荐用Android手机做主力验证设备原因有两个Android对BLE的接口开放度比iOS高可以手动设置扫描参数、请求连接参数、甚至查看MAC地址和广播原始数据同时Android的日志系统比iOS好定位问题。iOS做蓝牙开发很多内部细节被系统锁死了调试体验比较差。调试工具方面推荐准备一个nRF Connect手机App。这个工具可以扫描设备、查看广播数据、发起连接、浏览GATT服务、直接读写特征值是验证协议设计和排查问题的一把好手。我在做任何BLE开发时都会先拿它确认设备的行为再动代码。3.2 Android端的权限与初始化Android做BLE开发权限是第一个坑。不同Android版本对蓝牙权限的要求完全不同我见过很多运行时报错都是权限没配全导致的。Android 6.0到11需要定位权限ACCESS_FINE_LOCATION因为系统认为蓝牙扫描可以推断用户位置Android 12及以上新增了BLUETOOTH_SCAN和BLUETOOTH_CONNECT两个运行时权限不再依赖定位权限。如果你的App最低版本覆盖了Android 6到最新版本需要在Manifest里都声明并在代码里做版本判断。Minifest中需要声明的内容大致如下uses-permission android:nameandroid.permission.BLUETOOTH android:maxSdkVersion30 / uses-permission android:nameandroid.permission.BLUETOOTH_ADMIN android:maxSdkVersion30 / uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION android:maxSdkVersion30 / uses-permission android:nameandroid.permission.BLUETOOTH_SCAN / uses-permission android:nameandroid.permission.BLUETOOTH_CONNECT /初始化蓝牙时先检查设备是否支持BLE再检查蓝牙是否打开。注意从Android 12开始检查蓝牙是否打开需要使用BluetoothAdapter的isEnabled()并且这个调用需要BLUETOOTH_CONNECT权限。有些国产ROM还会在系统层面做额外的蓝牙权限限制这些在真机测试时才能暴露出来。3.3 扫描、连接、发现服务、收发数据的关键代码扫描的核心类是BluetoothLeScanner在Android 5.0之后取代了旧版的startLeScan。下面这段Kotlin代码是一个最基础的扫描实现val bluetoothManager getSystemService(Context.BLUETOOTH_SERVICE) as BluetoothManager val bluetoothAdapter bluetoothManager.adapter val scanner bluetoothAdapter.bluetoothLeScanner val scanCallback object : ScanCallback() { override fun onScanResult(callbackType: Int, result: ScanResult) { val device result.device val rssi result.rssi val scanRecord result.scanRecord // 在这里根据设备名或广播数据里的UUID做过滤 Log.d(BLE, device: ${device.address}, rssi: $rssi) } override fun onScanFailed(errorCode: Int) { // 常见错误码1表示扫描已启动2表示内部错误3表示参数不合法 } } // 启动扫描 scanner.startScan(scanCallback) // 停止扫描 scanner.stopScan(scanCallback)扫描到设备后连接逻辑如下// 注意连接必须在主线程调用但回调发生在Binder线程 val gatt device.connectGatt(context, false, gattCallback)连接回调里需要处理四个关键事件连接状态变化、服务发现、特征值变化、写入完成。private val gattCallback object : BluetoothGattCallback() { override fun onConnectionStateChange(gatt: BluetoothGatt, status: Int, newState: Int) { if (newState BluetoothProfile.STATE_CONNECTED) { gatt.discoverServices() } else if (newState BluetoothProfile.STATE_DISCONNECTED) { gatt.close() } } override fun onServicesDiscovered(gatt: BluetoothGatt, status: Int) { if (status BluetoothGatt.GATT_SUCCESS) { // 找到目标服务 val service gatt.getService(UUID.fromString(0000fff0-0000-1000-8000-00805f9b34fb)) // 找到目标特征这里以写和通知为例 val writeCharacteristic service.getCharacteristic(UUID.fromString(0000fff2-...)) val notifyCharacteristic service.getCharacteristic(UUID.fromString(0000fff1-...)) // 开启通知 gatt.setCharacteristicNotification(notifyCharacteristic, true) val descriptor notifyCharacteristic.getDescriptor(UUID.fromString(00002902-0000-1000-8000-00805f9b34fb)) descriptor.value BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE gatt.writeDescriptor(descriptor) } } override fun onCharacteristicChanged(gatt: BluetoothGatt, characteristic: BluetoothGattCharacteristic) { // 设备主动推送的数据从这里回来 val data characteristic.value } override fun onCharacteristicWrite(gatt: BluetoothGatt, characteristic: BluetoothGattCharacteristic, status: Int) { // 每次写数据的结果在这里确认成功后再写下一条 } }写数据时有一点必须注意写操作是串行且异步的不能在onCharacteristicWrite回调之前连续调用多次writeCharacteristic。否则会有一半写入失败。正确的做法是维护一个发送队列每写完一条、确认成功了再从队列里取下一条。3.4 把收发链路串联起来后的验证方法代码写完验证不能只靠“能连上”。我的验证流程分四步第一步用nRF Connect先连一次设备确认设备广播内容、GATT服务结构、特征UUID都和自己设计的一致。这一步能排除“是设备广播问题还是App问题”。第二步App发起连接确认连接成功后能正常发现服务。如果服务发现失败检查UUID是否匹配、设备是否处在连接状态、芯片是否支持并发多连接。第三步App写入一条指令设备端收到后回一条数据确认onCharacteristicChanged能触发。这一步建议先发长度小于20字节的数据排除MTU问题。第四步连续收发100条数据观察有没有漏包、乱序、断开的情况。如果出现漏包优先检查连接参数和发送频率不要急着改App逻辑。这四步都过了Demo才算真正跑通。4. 实测中必须跨过的几个坑连接掉线、扫描不到与Android/iOS差异4.1 扫描不到设备的完整排查链路扫不到设备是BLE开发里最高频的问题。每次遇到这个问题我按下面这个顺序排查基本都能定位。先看手机蓝牙设置。有些手机在系统蓝牙设置里能看到设备但在App里扫不到这通常是权限问题。Android 6以上没有授予定位权限Android 12以上没有授予附近的设备权限都会导致扫描结果为空。权限问题的特征是startScan不报错但回调永远不来。再看扫描参数。如果代码里设置了ScanFilter检查UUID大小端是否反了。BLE UUID是128位的标准格式是8-4-4-4-12但很多设备厂商用的是16位UUID简写比如0xFFF0实际是0000FFF0-0000-1000-8000-00805F9B34FB。如果简写、大小写、字节序搞错过滤条件就永远匹配不上。然后看广播间隔和设备状态。如果设备已经处于连接状态它就不再广播了除了部分支持多角色的芯片扫描自然看不到。这个情况在开发时经常遇到——上一次连接的连接没断开设备被占着新扫描当然扫不到。解决方法是确认设备没有和别的手机连接或者重启设备让它重新进入广播状态。最后检查扫描窗口和扫描间隔。Android的startScan默认参数是系统最优值遇到电池优化策略严格的机型系统可能会延迟扫描回调。如果使用了ScanSettings把SCAN_MODE_LOW_LATENCY设上回调会更及时代价是功耗高一些。整个排查链路的核心是先确认权限再确认过滤条件再确认设备状态最后才怀疑扫描参数。顺序反了会浪费大量时间。4.2 连接稳定性的杀手连接参数与信号连接上了但过几秒就断这是第二个高频问题。常见原因是连接超时参数不匹配。从机请求的连接参数跟主机实际协商的结果不一致如果设备端的Supervision Timeout设得太小比如100ms而主机的连接间隔是30ms加上从机延迟4那实际可能超过100ms没有数据交换连接就被判定超时。排查方法用nRF Connect查看连接参数确认双方协商后的值是什么。信号问题也很常见。BLE 2.4GHz频段受遮挡和干扰影响大金属外壳、墙体、WiFi路由器都会造成信号衰减。如果设备放得很近但连接不稳定很可能是天线设计问题或者干扰问题而不是软件问题。我在实测时会把设备放在开阔位置试一遍排除环境因素后再查代码。还有一个隐蔽的坑是操作频率。Android端如果短时间内高频读写可能会导致GATT回调堆积、底层缓冲区满然后系统主动断连。遇到这类情况要在代码里做流控写队列串行化、读操作不要并发、避免在onCharacteristicChanged里立刻再发起新的GATT操作。4.3 Android版本差异与iOS策略同样的代码在不同版本Android上可能有完全不同行为。Android 6以前不需要运行时权限Android 6到11需要定位权限Android 12开始新增蓝牙专属权限。这意味着老代码在Android 12以上可能因为没申请BLUETOOTH_SCAN而扫描不到设备。另外Android 7之后系统对扫描行为加了限制一次扫描最多运行30秒之后会收到SCAN_FAILED_APPLICATION_REGISTRATION或超时回调。如果你的App需要长时间扫描必须设计好“扫描-停止-再扫描”的轮询机制。iOS端则是另一套逻辑。iOS不允许App随意扫描后台地理位置权限和蓝牙权限是分开的iOS对连接参数有强制约束最小的连接间隔实际生效时通常为30ms而不是请求的15msiOS系统也不公开底层蓝牙日志调试难度高。如果做跨平台方案最好是Android端做主要联调工具iOS端做兼容性验证。这些差异不是代码能完全抹平的做产品时应该在需求阶段就定义好“最低支持系统版本”在对应系统上做针对性适配。5. 从Demo到产品功耗、重连与协议设计的三板斧5.1 功耗调优怎么算广播间隔与连接间隔的取舍Demo跑通了如果要做成真产品功耗是第一道坎。BLE的功耗主要来自三个地方广播、连接、数据处理。广播电流通常几毫安到几十毫安取决于发射功率连接状态的活动电流类似但睡眠电流可以降到微安级。所以省电的核心思路是减少清醒时间增加睡眠时间。假如设备每秒钟广播一次广播事件约2ms电流15mA占空比0.2%平均电流约0.03mA一年就是约263mAh两节纽扣电池就能撑一年。如果把广播间隔改成500ms平均电流翻倍一年约526mAh。这个计算方式很粗糙但能帮助我们理解参数的量级影响。连接状态同样。连接间隔设为7.5ms和30ms功耗差距是4倍左右。如果数据上报频率很低比如每秒才一次完全可以请求30ms甚至50ms的连接间隔配合从机延迟把功耗降下来代价只是指令响应延迟高一点点。这种取舍在需求阶段就要想清楚。实际产品中我习惯这样设计设备默认处于广播状态间隔500ms到1s用户扫码或App搜索到时才发起连接连接建立后App主动请求一个低功耗连接参数比如连接间隔30ms、从机延迟4、超时5s数据传输结束后App主动断开连接设备回到广播状态。这样把连接状态耗电压缩到了最小。5.2 重连机制产品级可靠性绕不开的部分Demo阶段连接断了就是断了重新扫描重新连。但产品级的蓝牙设备比如手环和手机之间如果每次断开都要用户手动连一次体验会崩。重连机制的核心是“白名单自动扫描”。设备端保存了最近一次成功配对的主机MAC地址进入广播状态后支持只对白名单内的设备响应连接请求App端在扫描时只扫描之前绑定过的设备地址其他设备直接跳过。这样双方都能快速重连。还要处理“设备不在范围内”的情况。App侧应该在连接断开后启动一个后台重连计划第一次30秒后重试第二次2分钟第三次5分钟逐步拉大间隔而不是高频轮询。高频轮询手机耗电设备也被迫频繁响应广播请求双方体验都差。5.3 把协议设计从“能通”推向“不踩坑”Demo阶段的协议只要能收发数据就行但做产品时协议设计决定了后续迭代的难度。一个完整的BLE业务协议至少要有帧头、长度、命令字、包序号、校验和、数据体、帧尾。包序号用来处理数据重复和乱序校验和用来保证数据的完整性虽然BLE链路层有CRC但应用层再校验一次能防止缓存里的脏数据被误用。同时所有写操作要设计应答下发了开锁命令设备必须回一条“收到”或者“执行结果”App收到应答后才算完成否则要超时重发。我见过最大的坑是协议里没版本号。设备固件升级了协议格式变化老App还在用旧的格式发数据两边对不上就只能靠重装App解决。在协议帧头或厂商数据里放一个版本字段能省掉大量后期联调成本。从Demo到产品唯一不变的准则就是协议设计时多花一天后期少踩一个月的坑。这么多年做下来我个人体会最深的一点是BLE4.0的难点从来不在“把代码跑通”而在于你能否清晰地理解每一层协议在什么时候做决定、为什么做这个决定。广播包不够用就少塞点数据连接老断就去看参数协商结果收不到推送就检查通知开关和MTU——一切问题都有迹可循。拿着nRF Connect多看几个设备的广播和GATT结构比读一百篇教程都有用。Demo只是一个开始真正的功夫在连接建立之后。本文还有配套的精品资源点击获取 BLE4.0低功耗蓝牙开发实战：从广播、GATT到Android踩坑全解析
简介面向Android BLE开发者的实战Demo基于BLE4.0标准演示设备扫描、连接、服务发现、特征值读写与通知订阅的完整通信链路。项目源于Google BluetoothLeGatt示例适合正在学习Android蓝牙低功耗接入的初中级开发者也可作为物联网外设联调时的参考骨架。压缩包共56个文件核心为6个Java源文件与对应class辅以9个XML配置/布局、9个PNG界面资源并包含可直接安装的APK总大小208KB结构紧凑便于快速导入工程分析。已有303人学习下载。通过该Demo可掌握BluetoothGatt、BluetoothLeScanner等核心API的调用方式理解扫描参数配置、连接状态回调、服务发现解析及通知订阅等关键环节同时参考Google官方文档中的最佳实践避免频繁扫描和连接异常带来的功耗与稳定性问题是一份适合对照学习的轻量级BLE入门资料。 GitHub上搜索 “BLE4.0Demo”能翻出几百个仓库但真正能一次跑通的不多。我自己踩过直接把别的工程代码抄过来却连不上设备的坑也见过有人拿4.0的Demo去连5.0的设备然后怀疑人生。BLE4.0不是单纯的“低功耗蓝牙版本号”它背后是一整套完整的协议栈广播、扫描、连接、GATT服务、属性协议每一层都有自己独立的角色和规则。这篇文章就把这条链从原理到代码全部拆开结合我实际做IoT硬件对接的经验讲讲BLE4.0Demo从搭建到跑通的完整过程以及那些文档里不会明说的坑。目标读者分两类一类是第一次接触低功耗蓝牙想快速理解“BLE4.0到底在干什么”的初学者另一类是已经能跑通示例代码但被扫描不到设备、连接频繁断开这类问题折腾过的开发者。看完之后你不仅能把Demo跑起来还能把它当成一个可扩展的项目骨架平滑迁移到门锁、传感器、智能家居这类真实产品上。1. 为什么还有人在搞BLE4.0一个Demo背后的真实价值与适用边界1.1 BLE4.0到底解决了什么问题BLE4.0是蓝牙4.0规范里的低功耗部分2010年前后发布的第一版低功耗蓝牙标准。跟经典蓝牙BR/EDR相比它最大的变化不是“传输更快”而是“传输策略完全不同”。经典蓝牙面向的是持续数据流场景比如音频耳机链路建立后要保持连接、持续传数据BLE4.0面向的是“设备发送少量数据、且大部分时间应该睡觉”的场景比如温湿度传感器每隔几秒报一次数据体脂秤偶尔上传一次测量结果门锁偶尔接收一次开锁指令。这种定位决定了它的几个核心特征峰值功耗远低于经典蓝牙平均功耗能做到微安到毫安级别一颗纽扣电池可以撑几个月甚至几年连接建立速度快从广播到连接通常在几十毫秒到几百毫秒完成数据传输速率不高物理层速率1Mbps应用层实际吞吐量大概在200~300kbps传大文件不现实但传输传感器数据绰绰有余。我用一张表把经典蓝牙和BLE4.0的核心差异列出来方便理解维度经典蓝牙BR/EDRBLE4.0典型功耗持续连接电流较高空闲睡眠微安级活动时毫安级连接建立时间秒级毫秒到百毫秒级应用层吞吐量可达2Mbps左右约200~300kbps典型应用音频、文件传输传感器、控制指令、信标广播通信模型持续连接流式传输广播短连接、间歇性传输这个对比决定了我们做Demo时的一个核心思路BLE4.0Demo优化的不是“数据怎么传得更多”而是“数据怎么传得更省、连得更稳”。1.2 什么时候选BLE4.0什么时候不必纠结版本号蓝牙5.0、5.2甚至5.3已经普及多年很多新模组也支持更高版本为什么还要单独研究BLE4.0原因有两个。第一是兼容性。BLE4.0作为低功耗蓝牙的第一版规范定义了广播、扫描、连接、GATT这套最基础也最通用的框架。后面5.x版本虽然增加了2M PHY、长距离编码、广播扩展等高阶特性但底层核心机制依然是4.0那套。在一台只支持BLE4.0的老设备或者低端模组上你写的代码和协议设计思路完全通用。理解了4.0等于拿到了理解整个低功耗蓝牙体系的钥匙。第二是产品定位。很多量产设备用的芯片仍然是BLE4.0级别比如经典的CC2541、nRF51822以及大量国产兼容芯片。这类芯片成本低、生态成熟、方案稳定在价格敏感的IoT产品里依然大量存在。做这类产品的联调你需要在4.0的约束下工作比如支持的MTU可能更小、连接参数范围更窄、广播数据长度受限。但如果你是在做需要高吞吐量或远距离传输的新产品就没必要死守4.0。BLE5.x的2M PHY和Coded PHY长距离模式在某些场景下收益非常大。这时候Demo可以基于更高版本开发但架构设计上仍然可以沿用4.0那套广播GATT的模型。一句话总结我的经验BLE4.0Demo不是过时技术它是低功耗蓝牙的“最小公因数”是所有复杂应用的基础骨架。2. 核心机制拆解广播、连接与GATT三层结构决定Demo怎么搭2.1 广播这层设备怎么“喊话”数据怎么塞进一个包BLE设备在没有建立连接之前是通过广播让周围设备发现自己的。广播就像一个人站在广场上喊话喊的内容有一个固定格式不能随便说。一个完整的广播事件包含两种数据包广播包Advertising Packet和扫描响应包Scan Response Packet。广播包是必须的扫描响应包是可选的由从机主动提供主机在收到广播包后可以主动请求。每个包的数据部分最多31字节这31字节要包含若干个AD StructureAD Structure 长度 类型 数据。常见的数据类型有这么几个0x01是Flags用来声明设备支持的能力比如LE General Discoverable Mode0x09是Complete Local Name即设备名0xFF是厂商自定义数据用来传自己的业务数据。我实际做Demo时最常用的组合是Flags 设备名 厂商自定义数据。设备名方便用户识别厂商自定义数据里放一个自定义的UUID或者状态字段实现“还没连接就能先知道设备大概在做什么”的效果。广播间隔Advertising Interval是另一个关键参数范围是20ms到10.24s。间隔越短设备被发现越快但功耗越高间隔越长越省电但扫描方要等更久才能发现设备。实际产品中广播间隔通常设置在100ms到1s之间交互类设备偏低传感器类设备偏高。这一层最容易出的问题就是广播包太长。31字节看起来不多但如果你在广播里塞了设备名、服务UUID、厂商数据很容易超限。超限后有的协议栈会直接报错有的则静默截断导致扫描端看到的设备名不完整或者厂商数据对不上。所以设计广播内容时一定要克制能省则省。2.2 连接后怎么通信GATT服务、特征与属性权限一旦两个设备建立了连接通信就不再依赖广播了而是走GATTGeneric Attribute Profile协议。GATT用“服务-特征-属性”三层结构来组织数据。一个设备可以包含多个服务Service每个服务用UUID标识服务内部包含多个特征Characteristic每个特征也有自己的UUID数据实际读写就发生在特征上。特征下面还有描述符Descriptor最常用的是CCCDClient Characteristic Configuration Descriptor用来开启通知或指示功能。举个现实中的例子一个体脂秤Demo可以定义一个“体重服务”UUID自定义服务下有“体重数值”特征属性是可读通知、“测量状态”特征属性是可读、“清零指令”特征属性是可写。App读取体重数值时有两种方式主动读取Read或者订阅通知Notify。传感器这类持续产生数据的设备通常用Notify方式设备主动推数据App被动接收这样最省电。特征上的属性权限决定了这个特征能干什么属性含义典型用途Read主机可以读取该特征值读取设备版本、状态Write主机可以向该特征写入数据发送控制指令Notify设备可以主动推送数据主机不需要应答实时上报传感器数据Indicate设备可以主动推送数据主机必须应答要求可靠传输的状态数据搞清楚这四类属性Demo的协议设计就完成了一半。我在实际中见过不少初学者把所有的特征都设成可读可写导致逻辑混乱维护起来非常痛苦。正确的做法是每个特征只开它需要的能力能读的不要可写能Notify的没必要开Indicate。2.3 几个必须写进代码备注的参数与影响连接建立之后主从双方会协商一组连接参数Connection Parameters这些参数直接影响实时性和功耗连接间隔Connection Interval主机每隔多少毫秒与从机通信一次范围7.5ms到4s。间隔越短双方通信越及时但功耗越高。Android端实际最小可以请求7.5msiOS端最小是15ms部分情况30ms。从机延迟Slave Latency从机可以跳过多少个连接事件。如果设置为4表示从机可以每隔4个连接事件才醒来一次。这个参数能在不影响外部表现的情况下大幅省电。超时时间Supervision Timeout如果在这个时间内没有收到任何包连接就判定为超时断开。范围100ms到32s必须大于连接间隔和从机延迟的组合值否则会出现“连接好好的却莫名断开”的错误。MTUMaximum Transmission Unit也是绕不开的参数。BLE4.0默认MTU是23字节其中包含3字节的ATT头实际用户数据只有20字节。如果一次要发送超过20字节的数据就必须拆包或者协商更大的MTU。BLE4.0协议支持协商到更大的MTU比如247字节但前提是双方芯片都支持。这个细节在Demo阶段最容易被忽略等到你要传一块大于20字节的数据时才发现收不全就是这个原因。3. Demo开发实录从建工程到双向通信的完整链路3.1 硬件准备与工具选型做BLE4.0Demo最少需要两块东西一块BLE外设从机一个带有蓝牙模块的主机设备手机或电脑。外设的选择有两个方向。一是开发板比如经典的TI CC2541开发板、Nordic nRF51822开发板这类板子资料多、例程完整适合学习二是现成的BLE模组比如各类串口透传模组内部已经跑好了完整的协议栈你只需要通过串口发AT指令或者自定义帧就能控制。我的建议是学习阶段用开发板因为你要看的是协议栈的行为产品原型阶段用透传模组省时间符合“基于常见实践的合理选择”。主机端我推荐用Android手机做主力验证设备原因有两个Android对BLE的接口开放度比iOS高可以手动设置扫描参数、请求连接参数、甚至查看MAC地址和广播原始数据同时Android的日志系统比iOS好定位问题。iOS做蓝牙开发很多内部细节被系统锁死了调试体验比较差。调试工具方面推荐准备一个nRF Connect手机App。这个工具可以扫描设备、查看广播数据、发起连接、浏览GATT服务、直接读写特征值是验证协议设计和排查问题的一把好手。我在做任何BLE开发时都会先拿它确认设备的行为再动代码。3.2 Android端的权限与初始化Android做BLE开发权限是第一个坑。不同Android版本对蓝牙权限的要求完全不同我见过很多运行时报错都是权限没配全导致的。Android 6.0到11需要定位权限ACCESS_FINE_LOCATION因为系统认为蓝牙扫描可以推断用户位置Android 12及以上新增了BLUETOOTH_SCAN和BLUETOOTH_CONNECT两个运行时权限不再依赖定位权限。如果你的App最低版本覆盖了Android 6到最新版本需要在Manifest里都声明并在代码里做版本判断。Minifest中需要声明的内容大致如下uses-permission android:nameandroid.permission.BLUETOOTH android:maxSdkVersion30 / uses-permission android:nameandroid.permission.BLUETOOTH_ADMIN android:maxSdkVersion30 / uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION android:maxSdkVersion30 / uses-permission android:nameandroid.permission.BLUETOOTH_SCAN / uses-permission android:nameandroid.permission.BLUETOOTH_CONNECT /初始化蓝牙时先检查设备是否支持BLE再检查蓝牙是否打开。注意从Android 12开始检查蓝牙是否打开需要使用BluetoothAdapter的isEnabled()并且这个调用需要BLUETOOTH_CONNECT权限。有些国产ROM还会在系统层面做额外的蓝牙权限限制这些在真机测试时才能暴露出来。3.3 扫描、连接、发现服务、收发数据的关键代码扫描的核心类是BluetoothLeScanner在Android 5.0之后取代了旧版的startLeScan。下面这段Kotlin代码是一个最基础的扫描实现val bluetoothManager getSystemService(Context.BLUETOOTH_SERVICE) as BluetoothManager val bluetoothAdapter bluetoothManager.adapter val scanner bluetoothAdapter.bluetoothLeScanner val scanCallback object : ScanCallback() { override fun onScanResult(callbackType: Int, result: ScanResult) { val device result.device val rssi result.rssi val scanRecord result.scanRecord // 在这里根据设备名或广播数据里的UUID做过滤 Log.d(BLE, device: ${device.address}, rssi: $rssi) } override fun onScanFailed(errorCode: Int) { // 常见错误码1表示扫描已启动2表示内部错误3表示参数不合法 } } // 启动扫描 scanner.startScan(scanCallback) // 停止扫描 scanner.stopScan(scanCallback)扫描到设备后连接逻辑如下// 注意连接必须在主线程调用但回调发生在Binder线程 val gatt device.connectGatt(context, false, gattCallback)连接回调里需要处理四个关键事件连接状态变化、服务发现、特征值变化、写入完成。private val gattCallback object : BluetoothGattCallback() { override fun onConnectionStateChange(gatt: BluetoothGatt, status: Int, newState: Int) { if (newState BluetoothProfile.STATE_CONNECTED) { gatt.discoverServices() } else if (newState BluetoothProfile.STATE_DISCONNECTED) { gatt.close() } } override fun onServicesDiscovered(gatt: BluetoothGatt, status: Int) { if (status BluetoothGatt.GATT_SUCCESS) { // 找到目标服务 val service gatt.getService(UUID.fromString(0000fff0-0000-1000-8000-00805f9b34fb)) // 找到目标特征这里以写和通知为例 val writeCharacteristic service.getCharacteristic(UUID.fromString(0000fff2-...)) val notifyCharacteristic service.getCharacteristic(UUID.fromString(0000fff1-...)) // 开启通知 gatt.setCharacteristicNotification(notifyCharacteristic, true) val descriptor notifyCharacteristic.getDescriptor(UUID.fromString(00002902-0000-1000-8000-00805f9b34fb)) descriptor.value BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE gatt.writeDescriptor(descriptor) } } override fun onCharacteristicChanged(gatt: BluetoothGatt, characteristic: BluetoothGattCharacteristic) { // 设备主动推送的数据从这里回来 val data characteristic.value } override fun onCharacteristicWrite(gatt: BluetoothGatt, characteristic: BluetoothGattCharacteristic, status: Int) { // 每次写数据的结果在这里确认成功后再写下一条 } }写数据时有一点必须注意写操作是串行且异步的不能在onCharacteristicWrite回调之前连续调用多次writeCharacteristic。否则会有一半写入失败。正确的做法是维护一个发送队列每写完一条、确认成功了再从队列里取下一条。3.4 把收发链路串联起来后的验证方法代码写完验证不能只靠“能连上”。我的验证流程分四步第一步用nRF Connect先连一次设备确认设备广播内容、GATT服务结构、特征UUID都和自己设计的一致。这一步能排除“是设备广播问题还是App问题”。第二步App发起连接确认连接成功后能正常发现服务。如果服务发现失败检查UUID是否匹配、设备是否处在连接状态、芯片是否支持并发多连接。第三步App写入一条指令设备端收到后回一条数据确认onCharacteristicChanged能触发。这一步建议先发长度小于20字节的数据排除MTU问题。第四步连续收发100条数据观察有没有漏包、乱序、断开的情况。如果出现漏包优先检查连接参数和发送频率不要急着改App逻辑。这四步都过了Demo才算真正跑通。4. 实测中必须跨过的几个坑连接掉线、扫描不到与Android/iOS差异4.1 扫描不到设备的完整排查链路扫不到设备是BLE开发里最高频的问题。每次遇到这个问题我按下面这个顺序排查基本都能定位。先看手机蓝牙设置。有些手机在系统蓝牙设置里能看到设备但在App里扫不到这通常是权限问题。Android 6以上没有授予定位权限Android 12以上没有授予附近的设备权限都会导致扫描结果为空。权限问题的特征是startScan不报错但回调永远不来。再看扫描参数。如果代码里设置了ScanFilter检查UUID大小端是否反了。BLE UUID是128位的标准格式是8-4-4-4-12但很多设备厂商用的是16位UUID简写比如0xFFF0实际是0000FFF0-0000-1000-8000-00805F9B34FB。如果简写、大小写、字节序搞错过滤条件就永远匹配不上。然后看广播间隔和设备状态。如果设备已经处于连接状态它就不再广播了除了部分支持多角色的芯片扫描自然看不到。这个情况在开发时经常遇到——上一次连接的连接没断开设备被占着新扫描当然扫不到。解决方法是确认设备没有和别的手机连接或者重启设备让它重新进入广播状态。最后检查扫描窗口和扫描间隔。Android的startScan默认参数是系统最优值遇到电池优化策略严格的机型系统可能会延迟扫描回调。如果使用了ScanSettings把SCAN_MODE_LOW_LATENCY设上回调会更及时代价是功耗高一些。整个排查链路的核心是先确认权限再确认过滤条件再确认设备状态最后才怀疑扫描参数。顺序反了会浪费大量时间。4.2 连接稳定性的杀手连接参数与信号连接上了但过几秒就断这是第二个高频问题。常见原因是连接超时参数不匹配。从机请求的连接参数跟主机实际协商的结果不一致如果设备端的Supervision Timeout设得太小比如100ms而主机的连接间隔是30ms加上从机延迟4那实际可能超过100ms没有数据交换连接就被判定超时。排查方法用nRF Connect查看连接参数确认双方协商后的值是什么。信号问题也很常见。BLE 2.4GHz频段受遮挡和干扰影响大金属外壳、墙体、WiFi路由器都会造成信号衰减。如果设备放得很近但连接不稳定很可能是天线设计问题或者干扰问题而不是软件问题。我在实测时会把设备放在开阔位置试一遍排除环境因素后再查代码。还有一个隐蔽的坑是操作频率。Android端如果短时间内高频读写可能会导致GATT回调堆积、底层缓冲区满然后系统主动断连。遇到这类情况要在代码里做流控写队列串行化、读操作不要并发、避免在onCharacteristicChanged里立刻再发起新的GATT操作。4.3 Android版本差异与iOS策略同样的代码在不同版本Android上可能有完全不同行为。Android 6以前不需要运行时权限Android 6到11需要定位权限Android 12开始新增蓝牙专属权限。这意味着老代码在Android 12以上可能因为没申请BLUETOOTH_SCAN而扫描不到设备。另外Android 7之后系统对扫描行为加了限制一次扫描最多运行30秒之后会收到SCAN_FAILED_APPLICATION_REGISTRATION或超时回调。如果你的App需要长时间扫描必须设计好“扫描-停止-再扫描”的轮询机制。iOS端则是另一套逻辑。iOS不允许App随意扫描后台地理位置权限和蓝牙权限是分开的iOS对连接参数有强制约束最小的连接间隔实际生效时通常为30ms而不是请求的15msiOS系统也不公开底层蓝牙日志调试难度高。如果做跨平台方案最好是Android端做主要联调工具iOS端做兼容性验证。这些差异不是代码能完全抹平的做产品时应该在需求阶段就定义好“最低支持系统版本”在对应系统上做针对性适配。5. 从Demo到产品功耗、重连与协议设计的三板斧5.1 功耗调优怎么算广播间隔与连接间隔的取舍Demo跑通了如果要做成真产品功耗是第一道坎。BLE的功耗主要来自三个地方广播、连接、数据处理。广播电流通常几毫安到几十毫安取决于发射功率连接状态的活动电流类似但睡眠电流可以降到微安级。所以省电的核心思路是减少清醒时间增加睡眠时间。假如设备每秒钟广播一次广播事件约2ms电流15mA占空比0.2%平均电流约0.03mA一年就是约263mAh两节纽扣电池就能撑一年。如果把广播间隔改成500ms平均电流翻倍一年约526mAh。这个计算方式很粗糙但能帮助我们理解参数的量级影响。连接状态同样。连接间隔设为7.5ms和30ms功耗差距是4倍左右。如果数据上报频率很低比如每秒才一次完全可以请求30ms甚至50ms的连接间隔配合从机延迟把功耗降下来代价只是指令响应延迟高一点点。这种取舍在需求阶段就要想清楚。实际产品中我习惯这样设计设备默认处于广播状态间隔500ms到1s用户扫码或App搜索到时才发起连接连接建立后App主动请求一个低功耗连接参数比如连接间隔30ms、从机延迟4、超时5s数据传输结束后App主动断开连接设备回到广播状态。这样把连接状态耗电压缩到了最小。5.2 重连机制产品级可靠性绕不开的部分Demo阶段连接断了就是断了重新扫描重新连。但产品级的蓝牙设备比如手环和手机之间如果每次断开都要用户手动连一次体验会崩。重连机制的核心是“白名单自动扫描”。设备端保存了最近一次成功配对的主机MAC地址进入广播状态后支持只对白名单内的设备响应连接请求App端在扫描时只扫描之前绑定过的设备地址其他设备直接跳过。这样双方都能快速重连。还要处理“设备不在范围内”的情况。App侧应该在连接断开后启动一个后台重连计划第一次30秒后重试第二次2分钟第三次5分钟逐步拉大间隔而不是高频轮询。高频轮询手机耗电设备也被迫频繁响应广播请求双方体验都差。5.3 把协议设计从“能通”推向“不踩坑”Demo阶段的协议只要能收发数据就行但做产品时协议设计决定了后续迭代的难度。一个完整的BLE业务协议至少要有帧头、长度、命令字、包序号、校验和、数据体、帧尾。包序号用来处理数据重复和乱序校验和用来保证数据的完整性虽然BLE链路层有CRC但应用层再校验一次能防止缓存里的脏数据被误用。同时所有写操作要设计应答下发了开锁命令设备必须回一条“收到”或者“执行结果”App收到应答后才算完成否则要超时重发。我见过最大的坑是协议里没版本号。设备固件升级了协议格式变化老App还在用旧的格式发数据两边对不上就只能靠重装App解决。在协议帧头或厂商数据里放一个版本字段能省掉大量后期联调成本。从Demo到产品唯一不变的准则就是协议设计时多花一天后期少踩一个月的坑。这么多年做下来我个人体会最深的一点是BLE4.0的难点从来不在“把代码跑通”而在于你能否清晰地理解每一层协议在什么时候做决定、为什么做这个决定。广播包不够用就少塞点数据连接老断就去看参数协商结果收不到推送就检查通知开关和MTU——一切问题都有迹可循。拿着nRF Connect多看几个设备的广播和GATT结构比读一百篇教程都有用。Demo只是一个开始真正的功夫在连接建立之后。本文还有配套的精品资源点击获取