拓冰网站定制 
简介一套面向Android开发者的蓝牙开发示例项目覆盖经典蓝牙与BLE低功耗蓝牙的客户端和服务端实现适合快速上手手机间蓝牙通信或低功耗外设对接的初中级开发者。资源共60个文件以Java业务代码、XML界面与配置、PNG运行截图为主体另有Gradle构建脚本、ProGuard规则及README说明压缩包仅406KB体量轻但结构完整便于按模块阅读和二次开发。已有4475人学习下载。通过这份资源可对照两套实现经典蓝牙重点学习搜索、配对、Socket连接与流式数据传输BLE则掌握扫描、GATT服务发现、特征值读写及通知监听。配合截图能快速定位客户端与服务端的交互逻辑目录分层清晰既适合作为蓝牙开发的起步参考也可直接改造成工程模块嵌入项目。 做蓝牙开发这些年被问得最多的一个问题不是“蓝牙怎么连”而是“经典蓝牙和BLE到底该选哪个”。这个问题背后往往是一整套双模开发的实际需求——既要兼容旧设备的经典蓝牙通信又要在新设备上跑低功耗BLE客户端和服务端两头都得顾。今天我就把实际项目中积累的经典蓝牙BLE客户端/服务端开发经验完整梳理一遍覆盖协议选型、GATT服务搭建、MTU协商、Bond绑定、连接参数调优这些核心环节再穿插一些踩坑记录和排查思路给正在做蓝牙方案或者准备入坑的朋友一个可以直接参考的路线图。1. 双模蓝牙开发的整体思路与方案选型1.1 经典蓝牙和BLE同源不同路的两种协议经典蓝牙BR/EDR和低功耗蓝牙BLE虽然都叫“蓝牙”但底层协议栈几乎是两套独立的东西。经典蓝牙从蓝牙2.0时代延续下来核心目标是高吞吐率的大数据量传输比如蓝牙耳机传音频、蓝牙文件传输、车载电话的免提链路。它的射频占用更多信道调制方式也更复杂实际吞吐可以达到1Mbps以上EDR甚至更高代价是功耗明显偏高。BLE是从蓝牙4.0开始加入的新协议栈设计目标刚好反过来低功耗、小数据量、长待机。它的物理层只用了40个信道37个数据信道3个广播信道单包能承载的数据非常有限但连接建立速度快一个纽扣电池可以让传感器跑几个月。所以做双模开发第一件事就是要认清经典蓝牙和BLE在代码层面就是两套不同的协议栈虽然共用天线和射频但连接模型、数据传输模型、功耗模型完全不一样。很多新手在Android上写完BLE的GATT通信转头去连经典蓝牙设备发现完全用不上那套代码就是吃了这个亏。我建议在做方案设计时把经典蓝牙和BLE当成两种独立的技术选型来处理——是否双模不是“多写点代码”的问题而是“要不要同时维护两条技术链路”的问题。很多量产设备为了兼容旧设备最终选择双模方案但在设计之初就明确了哪条链路是主链路哪条是兜底兼容链路这对后续开发和排障会轻松很多。1.2 客户端和服务端角色到底怎么划分蓝牙开发里的“客户端/服务端”和Web开发的概念有些相似但也有明显区别。服务端Server是数据提供方它在广播、等待连接把自己的服务和特征暴露给外界客户端Client是数据消费方它主动去扫描、发起连接然后读写服务端暴露出来的特征。在BLE里服务端又被称为Peripheral外设客户端为Central中心设备。实际项目里一个很常见的误区是觉得“手机永远是客户端设备永远是服务端”。大多数消费场景确实是这样的比如手机App去连接一个BLE心率带App是Central心率带是Peripheral。但反过来也很常见——数字钥匙场景里手机App作为服务端发布密钥信息车机作为客户端去连接手机又比如一些工业调试场景PC端的工具软件作为Central连接嵌入式设备做参数配置。所以做架构设计时角色不能拍脑袋定要根据“谁主动发起连接”“谁持有数据被读取”来倒推。Android上GattServer和GattClient是完全分开的API在动手前没想清楚角色到后面重构成本会非常高。1.3 选型策略什么场景用经典蓝牙什么用BLE我在项目里总结了一条很朴素的选型思路有持续音频流或者大文件传输需求优先经典蓝牙传感器数据、控制指令、状态同步这类小包周期性数据优先BLE如果设备需要兼容旧配件比如老式蓝牙手柄、蓝牙串口模块就得考虑双模。举几个能对上号的场景健康手环和体温贴走BLE因为每秒钟只有几个字节的心率或温度数据而且要求电池撑半年以上蓝牙音箱和TWS耳机走经典蓝牙因为音频流要求连续高吞吐BLE现在的A2DP能力远不够用工业现场用Modbus RTU通过BLE透传是因为现场总线设备只偶尔上报几个寄存器的值用BLE性价比远高于经典蓝牙还有ESP32-S3做BLE配网也是因为配网动作是一次性小数据交换BLE的低功耗和快速连接特性很适配。经典蓝牙和BLE的核心差异我整理成了一张速查表对比维度经典蓝牙BR/EDRBLE低功耗蓝牙设计目标持续大数据量传输低功耗小数据量传输信道数79个40个典型吞吐2Mbps级别数百Kbps级别连接建立速度较慢秒级快百毫秒级功耗偏高极低典型应用音频、文件传输传感器、控制、配网数据模型SPP/RFCOMM流式GATT面向属性2. BLE开发必须吃透的四个核心机制2.1 GATT把数据装进Service和CharacteristicGATTGeneric Attribute Profile是BLE数据交互的基础也是客户端和服务端通信的骨架。没理解GATTBLE开发基本就是抄一段代码跑起来出了问题就抓瞎。理解GATT其实只需要记住一个三级树状结构Service服务、Characteristic特征、Descriptor描述符。一个Service相当于一个功能模块每个Service用128位UUID唯一标识也有短UUID对应蓝牙SIG定义的标准服务比如设备信息服务0x180A、电池服务0x180F。Service下面挂多个Characteristic每个Characteristic也有自己的UUID并携带属性、权限和值。读写操作本质上就是读写Characteristic的value。Descriptor则是对Characteristic的补充说明比如配置Notification开关的CCCDClient Characteristic Configuration Descriptor就是最常用的Descriptor。举个例子做一个温湿度计BLE服务端可以定义一个Service叫“环境数据”下面挂两个Characteristic一个可读可通知的温度值一个可读的湿度值再挂一个“电量”Characteristic读电池百分比。客户端连接后发现这个Service结构就能按UUID去读取数据或者通过开启Notification实时接收温度变化。GATT设计得清晰后续功能扩展、多设备对接都会顺畅很多。2.2 MTU协商一次能发多少字节MTUMaximum Transmission Unit是BLE开发里最容易忽略却最容易出问题的配置。BLE默认的MTU是23字节其中3字节是ATT协议头意味着你一次写操作最多只能带20字节数据。这在传几个传感器值的时候够用但要传字符串、固件包、批量配置参数时就会痛苦不堪——发20字节就要等一个连接间隔的确认一次传2KB数据要拆成100包。MTU协商就是双方在连接建立后通过交换MTU请求来确定一个双方都能支持的最大值。Android端默认会尝试请求517字节iOS则固定在185字节开发者无法修改嵌入式端如果你不主动支持交换MTU就永远停留在23字节。所以服务端必须实现并响应MTU交换请求否则大数据包发送效率极低。实际开发时要注意MTU协商是连接成功后、进行data传输前由客户端发起的操作。Android上调用gatt.requestMtu(200)然后在onMtuChanged回调里拿到最终协商值。服务端这边需要在你的协议栈不管是Android的GattServer还是嵌入式SDK里确认已经支持并正确回复MTU交换。一个很常见的坑是客户端请求MTU 200服务端不加处理最终协商值不变客户端还在按20字节分包发送结果就是发送慢且容易超时。2.3 连接流程从广播到稳定通信BLE的连接流程看起来简单——扫描、连接、发现服务、读写数据——但每个环节都有对应的配置陷阱。先说广播BLE服务端外设要先进入广播状态广播包会携带设备名称、UUID、发射功率等信息。广播类型有可连接广播、不可连接广播、可扫描广播等配错广播类型会导致设备能被扫描到却连不上。很多新手做外设用了个不可连接广播扫描端怎么发起连接都失败查了半天才意识到是广播类型的问题。扫描端同样有讲究。Android的ScanFilter非常有用可以按设备MAC地址、Service UUID过滤避免扫到一堆无关设备。但要注意从Android 6.0开始扫描BLE需要动态申请定位权限在Android 12之后又有新增的蓝牙权限限制刚开始跑项目时权限配置不到位连扫描都扫不到这是个非常常见的入门坑。连接成功后客户端要调用discoverServices()去发现服务端暴露的Service列表然后才能通过UUID找到对应的Characteristic进行读写。完整的时序是广播 → 扫描 → 发起连接 → 连接成功 → 发现服务 → 交换MTU → 读写/订阅通知 → 后续数据交互。任何一环没有按预期完成后面的数据交互就无从谈起。2.4 Bond绑定连接关系怎么长期保持Bond绑定机制解决了“设备之间如何长期记住彼此”的问题。简单说Bond就是一次配对过程后双方把加密密钥和身份信息保存下来下次连接可以直接用存储的密钥完成认证不需要用户再次输入PIN码或确认。这对智能家居、穿戴设备这类需要自动回连的场景特别重要。绑定和配对Pairing是两码事。配对是一次身份认证交互绑定是配对后把密钥持久化的过程。调试耳机、手环的时候手机上那个“开发者选项里的清除配对记录”清理的就是Bond信息。BLE的配对安全性有三个等级Just Works无用户交互、Passkey Entry输入数字PIN码、Out of Band带外方式传递密钥比如NFC。开发时通常根据产品安全等级选择。如果产品对安全性要求不高很多设备直接用Just Works省去用户交互流程但这意味着无法防止中间人攻击。实际开发中Bond相关的坑非常折磨人。比如服务端修改了广播名称或者UUID客户端却还是按旧的Bond信息去连接导致连接失败又比如绑定状态没有正确保存每次断开重连都要重新配对用户体验极其糟糕。所以设计阶段就要想好哪些设备需要自动回连Bond信息保存在哪一端什么时候要求用户手动解除绑定重新配对。3. 经典蓝牙BLE客户端/服务端实现要点3.1 BLE服务端搭一个GATT Server以Android端为例创建BLE服务端最核心的就是BluetoothGattServer。流程分几步先拿到BluetoothManager调用openGattServer()创建服务端实例然后构造Service和Characteristic最后注册到GattServer上再开始广播。代码核心逻辑大概是这样的BluetoothGattServer gattServer bluetoothManager.openGattServer(context, gattServerCallback); BluetoothGattService service new BluetoothGattService(SERVICE_UUID, BluetoothGattService.SERVICE_TYPE_PRIMARY); BluetoothGattCharacteristic characteristic new BluetoothGattCharacteristic( CHAR_UUID, BluetoothGattCharacteristic.PROPERTY_READ | BluetoothGattCharacteristic.PROPERTY_NOTIFY, BluetoothGattCharacteristic.PERMISSION_READ); service.addCharacteristic(characteristic); gattServer.addService(service); // 开始广播 AdvertiseData advertiseData new AdvertiseData.Builder() .setIncludeDeviceName(true) .addServiceUuid(ParcelUuid.fromString(SERVICE_UUID.toString())) .build(); bluetoothLeAdvertiser.startAdvertising(advertiseSettings, advertiseData, advertiseCallback);这里有几个细节很关键。第一Characteristic的属性Property和权限Permission要匹配。你允许客户端读就得同时设置PROPERTY_READ和PERMISSION_READ允许通知要设置PROPERTY_NOTIFY并且在收到客户端订阅CCCD时做好状态记录。第二通知数据的发送要主动调用gattServer.notifyCharacteristicChanged()不是写入服务端的值客户端就能自动收到。第三广播数据如果包含设备名称名字别太长广播包空间非常有限塞不下会直接被截断不如只放Service UUID连接后再通过onCharacteristicRead去读设备名称。3.2 BLE客户端扫描、连接、读写全流程客户端开发是绝大多数人最先接触BLE的方式。扫描用BluetoothLeScanner可以配合ScanFilter和ScanSettings设置扫描模式为低功耗/平衡/高功耗三档。扫描到目标设备后调用connectGatt()连接的回调里要处理连接状态变化、服务发现、MTU协商结果和特征读写结果。private final BluetoothGattCallback gattCallback new BluetoothGattCallback() { Override public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) { if (newState BluetoothProfile.STATE_CONNECTED) { gatt.discoverServices(); gatt.requestMtu(200); } else if (newState BluetoothProfile.STATE_DISCONNECTED) { // 处理断开和重连逻辑 } } Override public void onCharacteristicChanged(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic) { // 服务端主动通知的数据在这里接收 } };客户端代码里最容易踩坑的是对回调线程的理解。BluetoothGattCallback的回调跑在Binder线程不是UI线程直接在这里操作UI控件会崩溃。另外connectGatt的autoConnect参数值得仔细考虑设为true时是自动回连模式设备在范围内系统会自动重连但连接建立速度会稍慢设为false是直接连接模式适合用户主动操作连接。业务上如果做“手环靠近自动回连”这种体验基本要用autoConnect true但要注意这种模式下设备不可达时的回调状态没那么直观需要做一层超时控制。3.3 经典蓝牙SPP服务端和客户端实现经典蓝牙开发里最常被用到的是SPPSerial Port Profile也就是蓝牙串口透传协议。SPP在Android侧对应的API是BluetoothServerSocket和BluetoothSocket两条链路都是基于RFCOMM通道。服务端的核心是监听BluetoothServerSocket serverSocket bluetoothAdapter.listenUsingRfcommWithServiceRecord(MySPPService, SPP_UUID); BluetoothSocket socket serverSocket.accept(); // 阻塞等待客户端连接 InputStream inputStream socket.getInputStream(); OutputStream outputStream socket.getOutputStream();客户端的核心是发起连接BluetoothSocket socket device.createRfcommSocketToServiceRecord(SPP_UUID); socket.connect(); boolean connected socket.isConnected();SPP开发有两点经验特别值得说。第一连接建立后数据交互就是纯粹的流式读写不区分“读特征”和“写特征”所有数据都沿同一个RFCOMM通道双向传输。所以很多嵌入式蓝牙透传模块比如常见的HC-05、HC-06在串口透传模式下和Android的SPP对接就是一套完整的数据管道。第二accept()是阻塞调用必须放到子线程里执行否则主线程直接被卡死。另外SPP的连接建立比较慢第一次配对要进入PIN码确认流程重连时如果系统缓存了Bond信息可以跳过配对直接建链但前提是本次连接的设备地址能被蓝牙权限正常识别。3.4 双模设备中的资源分配与通信策略当设备需要同时支持经典蓝牙和BLE时会涉及一个在单模方案里不需要考虑的权衡射频和协议栈的资源分配。在经典蓝牙通信正在进行比如音频流或SPP大数据传输的时候BLE连接要不要保持在手机芯片里经典蓝牙和BLE通常是共用天线和基带的同时保持两个链路会导致调度开销变大每一路的有效吞吐都会下降。做双模透传设备时我建议把两条链路做成“一主一备”或“按数据特征分流”的策略。比如经典蓝牙链路承载高速数据流固件升级、文件同步BLE链路负责实时状态上报和控制指令。两条链路要各自维护独立的状态机不能在经典蓝牙断线时把BLE连接也一并释放。还要考虑同时连多台设备的情况BLE外设一般支持多个客户端同时连接Android端最多支持多个Central但经典蓝牙SPP同一时刻只允许一个RFCOMM连接。这些都需要在协议设计时提前定义好否则后期联调会非常痛苦。更实际的一点是双模设备往往还要考虑功耗策略。经典蓝牙连接建立后如果长时间没有数据交互功耗会明显偏高。BLE则可以通过调整连接间隔、从机延迟快速进入休眠状态。设计时尽量把周期性的心跳、状态上报都放在BLE链路经典蓝牙链路只在需要传输大量数据时才激活这是目前很多双模产品默认采用的做法。4. 实战中踩过的坑与排查思路速查4.1 连接建立失败的排查套路蓝牙连接失败是双模开发最高频的问题而且原因千奇百怪。我总结了排查优先级先看权限再看广播/扫描参数最后看系统底层日志。权限层面Android 6.0以上扫描BLE需要定位权限Android 12以上还要申请BLUETOOTH_SCAN和BLUETOOTH_CONNECT运行时权限少一个权限都会表现为“扫描不到”或“连接失败”。广播参数层面确认服务端广播是可连接广播、广播里的Service UUID和客户端ScanFilter里的过滤条件一致。如果服务端和客户端在同一台手机上测试还要注意系统可能不会主动扫描本机发出的广播需要换设备交叉验证。还有个容易被忽略的问题连接成功后立刻断开。这种情况通常在BLE协议栈返回133错误GATT_ERROR时出现。原因往往是连接参数被服务端拒绝或者服务端没有正确处理连接事件。排查时优先打开系统的HCI日志Android开发者选项里可以开启蓝牙HCI snoop log抓包看是哪一步断开的是连接完成事件没触发还是加密流程没完成非常直观。4.2 数据分包与MTU不一致导致的问题大数据量传输时最典型的现象是客户端写数据给服务端服务端收到的只有前20字节或者服务端通过Notify发数据客户端收到的数据被截断。这基本就是MTU协商没生效的后遗症。解决分两步第一步确保双方支持MTU交换。客户端主动requestMtu()服务端在协议栈层面要能响应这个请求协商后的MTU值在双方都取最小值。第二步协商完成后所有ATT层的单包写入/通知数据量都不能超过实际协商值如果业务数据超过MTU必须自己实现“分包序号组装”的逻辑。比如MTU是200有效载荷是197字节你要发512字节的数据就拆成3包第一包197字节序号第二包197字节序号第三包118字节结束标识。组装时按序号拼装循环冗余校验再决定是否重传。有些现成GATT库会帮你自动分包但底层机制你得清楚。嵌入式设备端如果只实现了最基本的GATT服务没有处理MTU交换Request那么客户端再积极也无济于事——协商值永远停在23字节。4.3 配对和绑定常见的翻车现场蓝牙配对翻车的概率一点都不低。常见的是客户端发起连接服务端要求配对但两端的安全等级配置不匹配导致密钥协商一直失败或者两端都设置为Just Works但是系统弹窗不出现用户拿不到确认界面连接就挂着不动了。我做数字钥匙类项目时还踩过一个坑手机端和车机端都保存了Bond信息但服务端改了加密密钥存储方式旧Bond信息失效每次连接都触发重新配对配对成功后又因为读取不到服务端的Service UUID列表导致应用层崩溃。排查完发现是绑定信息没有同步清除必须在服务端和客户端同时清理历史Bond记录才能恢复。调试这类问题建议在Android的“蓝牙设置”里删除配对记录并在嵌入式端调用协议栈接口删除本端绑定信息两边一起清才能保证环境干净。经典蓝牙的配对比BLE还要繁琐一些。SPP设备通常需要PIN码输入不同产商模块默认PIN码不一样有的是1234有的是0000少部分模块还要求固定密码长度。联调时最好先把模块手册翻出来确认默认PIN码和配对模式别上来就猜。4.4 连接参数调优稳定性、功耗和时延的平衡BLE连接后的稳定性和体验很大程度上取决于连接参数。连接间隔Connection Interval决定设备多久交换一次数据间隔越短数据交互越及时功耗也越高间隔越长越省电但时延越大。从机延迟Slave Latency允许从设备跳过若干次连接事件进一步省电但设置不合理会导致数据传输非常“钝”。在做穿戴设备时我一般这样配参数需要实时交互的状态通过将连接间隔设为30ms~50ms周期性上报的手环数据连接间隔可以放宽到100ms以上并开启2~4个从机延迟周期深度休眠场景才会用到秒级的连接间隔。参数配好之后还必须在服务端和客户端都确认参数能被接受。iOS对连接参数有较严格的要求Android端则相对宽松但最终还是以协议栈协商结果为准。另外连接参数和经典蓝牙链路的共存问题也要注意。双模设备同时保持经典蓝牙和BLE时如果经典蓝牙在传输大文件BLE链路的调度周期会被挤占如果BLE连接间隔设得太短两端都会出现延迟和丢包。遇到这类问题优先把经典蓝牙的调度优先级降低多数嵌入式协议栈里有RFCOMM QoS参数可以调或者放大BLE连接间隔保证整体链路的稳定性。关于双模开发最后再说几句实在话经过几个项目的来回折腾我最大的体会是蓝牙双模开发的重点不在“怎么写代码”而在“怎么把两条链路的角色和边界划分清楚”。BLE的GATT模型、MTU协商、Bond绑定经典蓝牙的SPP流式通信、配对流程每一块单独拎出来都不算难难的是同时把它们纳入同一个产品的技术架构里还要兼顾功耗、兼容性和用户体验。调试时认真看日志、抓HCI包、利用好蓝牙调试助手的绑定和连接参数查看功能能省掉大量靠猜的排查时间。希望这篇梳理能让准备做双模方案的朋友少走一些弯路也希望有机会和同样在做蓝牙开发的朋友多交流一些实际方案细节。本文还有配套的精品资源点击获取 经典蓝牙与BLE双模开发全攻略：从GATT到MTU调优实战
简介一套面向Android开发者的蓝牙开发示例项目覆盖经典蓝牙与BLE低功耗蓝牙的客户端和服务端实现适合快速上手手机间蓝牙通信或低功耗外设对接的初中级开发者。资源共60个文件以Java业务代码、XML界面与配置、PNG运行截图为主体另有Gradle构建脚本、ProGuard规则及README说明压缩包仅406KB体量轻但结构完整便于按模块阅读和二次开发。已有4475人学习下载。通过这份资源可对照两套实现经典蓝牙重点学习搜索、配对、Socket连接与流式数据传输BLE则掌握扫描、GATT服务发现、特征值读写及通知监听。配合截图能快速定位客户端与服务端的交互逻辑目录分层清晰既适合作为蓝牙开发的起步参考也可直接改造成工程模块嵌入项目。 做蓝牙开发这些年被问得最多的一个问题不是“蓝牙怎么连”而是“经典蓝牙和BLE到底该选哪个”。这个问题背后往往是一整套双模开发的实际需求——既要兼容旧设备的经典蓝牙通信又要在新设备上跑低功耗BLE客户端和服务端两头都得顾。今天我就把实际项目中积累的经典蓝牙BLE客户端/服务端开发经验完整梳理一遍覆盖协议选型、GATT服务搭建、MTU协商、Bond绑定、连接参数调优这些核心环节再穿插一些踩坑记录和排查思路给正在做蓝牙方案或者准备入坑的朋友一个可以直接参考的路线图。1. 双模蓝牙开发的整体思路与方案选型1.1 经典蓝牙和BLE同源不同路的两种协议经典蓝牙BR/EDR和低功耗蓝牙BLE虽然都叫“蓝牙”但底层协议栈几乎是两套独立的东西。经典蓝牙从蓝牙2.0时代延续下来核心目标是高吞吐率的大数据量传输比如蓝牙耳机传音频、蓝牙文件传输、车载电话的免提链路。它的射频占用更多信道调制方式也更复杂实际吞吐可以达到1Mbps以上EDR甚至更高代价是功耗明显偏高。BLE是从蓝牙4.0开始加入的新协议栈设计目标刚好反过来低功耗、小数据量、长待机。它的物理层只用了40个信道37个数据信道3个广播信道单包能承载的数据非常有限但连接建立速度快一个纽扣电池可以让传感器跑几个月。所以做双模开发第一件事就是要认清经典蓝牙和BLE在代码层面就是两套不同的协议栈虽然共用天线和射频但连接模型、数据传输模型、功耗模型完全不一样。很多新手在Android上写完BLE的GATT通信转头去连经典蓝牙设备发现完全用不上那套代码就是吃了这个亏。我建议在做方案设计时把经典蓝牙和BLE当成两种独立的技术选型来处理——是否双模不是“多写点代码”的问题而是“要不要同时维护两条技术链路”的问题。很多量产设备为了兼容旧设备最终选择双模方案但在设计之初就明确了哪条链路是主链路哪条是兜底兼容链路这对后续开发和排障会轻松很多。1.2 客户端和服务端角色到底怎么划分蓝牙开发里的“客户端/服务端”和Web开发的概念有些相似但也有明显区别。服务端Server是数据提供方它在广播、等待连接把自己的服务和特征暴露给外界客户端Client是数据消费方它主动去扫描、发起连接然后读写服务端暴露出来的特征。在BLE里服务端又被称为Peripheral外设客户端为Central中心设备。实际项目里一个很常见的误区是觉得“手机永远是客户端设备永远是服务端”。大多数消费场景确实是这样的比如手机App去连接一个BLE心率带App是Central心率带是Peripheral。但反过来也很常见——数字钥匙场景里手机App作为服务端发布密钥信息车机作为客户端去连接手机又比如一些工业调试场景PC端的工具软件作为Central连接嵌入式设备做参数配置。所以做架构设计时角色不能拍脑袋定要根据“谁主动发起连接”“谁持有数据被读取”来倒推。Android上GattServer和GattClient是完全分开的API在动手前没想清楚角色到后面重构成本会非常高。1.3 选型策略什么场景用经典蓝牙什么用BLE我在项目里总结了一条很朴素的选型思路有持续音频流或者大文件传输需求优先经典蓝牙传感器数据、控制指令、状态同步这类小包周期性数据优先BLE如果设备需要兼容旧配件比如老式蓝牙手柄、蓝牙串口模块就得考虑双模。举几个能对上号的场景健康手环和体温贴走BLE因为每秒钟只有几个字节的心率或温度数据而且要求电池撑半年以上蓝牙音箱和TWS耳机走经典蓝牙因为音频流要求连续高吞吐BLE现在的A2DP能力远不够用工业现场用Modbus RTU通过BLE透传是因为现场总线设备只偶尔上报几个寄存器的值用BLE性价比远高于经典蓝牙还有ESP32-S3做BLE配网也是因为配网动作是一次性小数据交换BLE的低功耗和快速连接特性很适配。经典蓝牙和BLE的核心差异我整理成了一张速查表对比维度经典蓝牙BR/EDRBLE低功耗蓝牙设计目标持续大数据量传输低功耗小数据量传输信道数79个40个典型吞吐2Mbps级别数百Kbps级别连接建立速度较慢秒级快百毫秒级功耗偏高极低典型应用音频、文件传输传感器、控制、配网数据模型SPP/RFCOMM流式GATT面向属性2. BLE开发必须吃透的四个核心机制2.1 GATT把数据装进Service和CharacteristicGATTGeneric Attribute Profile是BLE数据交互的基础也是客户端和服务端通信的骨架。没理解GATTBLE开发基本就是抄一段代码跑起来出了问题就抓瞎。理解GATT其实只需要记住一个三级树状结构Service服务、Characteristic特征、Descriptor描述符。一个Service相当于一个功能模块每个Service用128位UUID唯一标识也有短UUID对应蓝牙SIG定义的标准服务比如设备信息服务0x180A、电池服务0x180F。Service下面挂多个Characteristic每个Characteristic也有自己的UUID并携带属性、权限和值。读写操作本质上就是读写Characteristic的value。Descriptor则是对Characteristic的补充说明比如配置Notification开关的CCCDClient Characteristic Configuration Descriptor就是最常用的Descriptor。举个例子做一个温湿度计BLE服务端可以定义一个Service叫“环境数据”下面挂两个Characteristic一个可读可通知的温度值一个可读的湿度值再挂一个“电量”Characteristic读电池百分比。客户端连接后发现这个Service结构就能按UUID去读取数据或者通过开启Notification实时接收温度变化。GATT设计得清晰后续功能扩展、多设备对接都会顺畅很多。2.2 MTU协商一次能发多少字节MTUMaximum Transmission Unit是BLE开发里最容易忽略却最容易出问题的配置。BLE默认的MTU是23字节其中3字节是ATT协议头意味着你一次写操作最多只能带20字节数据。这在传几个传感器值的时候够用但要传字符串、固件包、批量配置参数时就会痛苦不堪——发20字节就要等一个连接间隔的确认一次传2KB数据要拆成100包。MTU协商就是双方在连接建立后通过交换MTU请求来确定一个双方都能支持的最大值。Android端默认会尝试请求517字节iOS则固定在185字节开发者无法修改嵌入式端如果你不主动支持交换MTU就永远停留在23字节。所以服务端必须实现并响应MTU交换请求否则大数据包发送效率极低。实际开发时要注意MTU协商是连接成功后、进行data传输前由客户端发起的操作。Android上调用gatt.requestMtu(200)然后在onMtuChanged回调里拿到最终协商值。服务端这边需要在你的协议栈不管是Android的GattServer还是嵌入式SDK里确认已经支持并正确回复MTU交换。一个很常见的坑是客户端请求MTU 200服务端不加处理最终协商值不变客户端还在按20字节分包发送结果就是发送慢且容易超时。2.3 连接流程从广播到稳定通信BLE的连接流程看起来简单——扫描、连接、发现服务、读写数据——但每个环节都有对应的配置陷阱。先说广播BLE服务端外设要先进入广播状态广播包会携带设备名称、UUID、发射功率等信息。广播类型有可连接广播、不可连接广播、可扫描广播等配错广播类型会导致设备能被扫描到却连不上。很多新手做外设用了个不可连接广播扫描端怎么发起连接都失败查了半天才意识到是广播类型的问题。扫描端同样有讲究。Android的ScanFilter非常有用可以按设备MAC地址、Service UUID过滤避免扫到一堆无关设备。但要注意从Android 6.0开始扫描BLE需要动态申请定位权限在Android 12之后又有新增的蓝牙权限限制刚开始跑项目时权限配置不到位连扫描都扫不到这是个非常常见的入门坑。连接成功后客户端要调用discoverServices()去发现服务端暴露的Service列表然后才能通过UUID找到对应的Characteristic进行读写。完整的时序是广播 → 扫描 → 发起连接 → 连接成功 → 发现服务 → 交换MTU → 读写/订阅通知 → 后续数据交互。任何一环没有按预期完成后面的数据交互就无从谈起。2.4 Bond绑定连接关系怎么长期保持Bond绑定机制解决了“设备之间如何长期记住彼此”的问题。简单说Bond就是一次配对过程后双方把加密密钥和身份信息保存下来下次连接可以直接用存储的密钥完成认证不需要用户再次输入PIN码或确认。这对智能家居、穿戴设备这类需要自动回连的场景特别重要。绑定和配对Pairing是两码事。配对是一次身份认证交互绑定是配对后把密钥持久化的过程。调试耳机、手环的时候手机上那个“开发者选项里的清除配对记录”清理的就是Bond信息。BLE的配对安全性有三个等级Just Works无用户交互、Passkey Entry输入数字PIN码、Out of Band带外方式传递密钥比如NFC。开发时通常根据产品安全等级选择。如果产品对安全性要求不高很多设备直接用Just Works省去用户交互流程但这意味着无法防止中间人攻击。实际开发中Bond相关的坑非常折磨人。比如服务端修改了广播名称或者UUID客户端却还是按旧的Bond信息去连接导致连接失败又比如绑定状态没有正确保存每次断开重连都要重新配对用户体验极其糟糕。所以设计阶段就要想好哪些设备需要自动回连Bond信息保存在哪一端什么时候要求用户手动解除绑定重新配对。3. 经典蓝牙BLE客户端/服务端实现要点3.1 BLE服务端搭一个GATT Server以Android端为例创建BLE服务端最核心的就是BluetoothGattServer。流程分几步先拿到BluetoothManager调用openGattServer()创建服务端实例然后构造Service和Characteristic最后注册到GattServer上再开始广播。代码核心逻辑大概是这样的BluetoothGattServer gattServer bluetoothManager.openGattServer(context, gattServerCallback); BluetoothGattService service new BluetoothGattService(SERVICE_UUID, BluetoothGattService.SERVICE_TYPE_PRIMARY); BluetoothGattCharacteristic characteristic new BluetoothGattCharacteristic( CHAR_UUID, BluetoothGattCharacteristic.PROPERTY_READ | BluetoothGattCharacteristic.PROPERTY_NOTIFY, BluetoothGattCharacteristic.PERMISSION_READ); service.addCharacteristic(characteristic); gattServer.addService(service); // 开始广播 AdvertiseData advertiseData new AdvertiseData.Builder() .setIncludeDeviceName(true) .addServiceUuid(ParcelUuid.fromString(SERVICE_UUID.toString())) .build(); bluetoothLeAdvertiser.startAdvertising(advertiseSettings, advertiseData, advertiseCallback);这里有几个细节很关键。第一Characteristic的属性Property和权限Permission要匹配。你允许客户端读就得同时设置PROPERTY_READ和PERMISSION_READ允许通知要设置PROPERTY_NOTIFY并且在收到客户端订阅CCCD时做好状态记录。第二通知数据的发送要主动调用gattServer.notifyCharacteristicChanged()不是写入服务端的值客户端就能自动收到。第三广播数据如果包含设备名称名字别太长广播包空间非常有限塞不下会直接被截断不如只放Service UUID连接后再通过onCharacteristicRead去读设备名称。3.2 BLE客户端扫描、连接、读写全流程客户端开发是绝大多数人最先接触BLE的方式。扫描用BluetoothLeScanner可以配合ScanFilter和ScanSettings设置扫描模式为低功耗/平衡/高功耗三档。扫描到目标设备后调用connectGatt()连接的回调里要处理连接状态变化、服务发现、MTU协商结果和特征读写结果。private final BluetoothGattCallback gattCallback new BluetoothGattCallback() { Override public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) { if (newState BluetoothProfile.STATE_CONNECTED) { gatt.discoverServices(); gatt.requestMtu(200); } else if (newState BluetoothProfile.STATE_DISCONNECTED) { // 处理断开和重连逻辑 } } Override public void onCharacteristicChanged(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic) { // 服务端主动通知的数据在这里接收 } };客户端代码里最容易踩坑的是对回调线程的理解。BluetoothGattCallback的回调跑在Binder线程不是UI线程直接在这里操作UI控件会崩溃。另外connectGatt的autoConnect参数值得仔细考虑设为true时是自动回连模式设备在范围内系统会自动重连但连接建立速度会稍慢设为false是直接连接模式适合用户主动操作连接。业务上如果做“手环靠近自动回连”这种体验基本要用autoConnect true但要注意这种模式下设备不可达时的回调状态没那么直观需要做一层超时控制。3.3 经典蓝牙SPP服务端和客户端实现经典蓝牙开发里最常被用到的是SPPSerial Port Profile也就是蓝牙串口透传协议。SPP在Android侧对应的API是BluetoothServerSocket和BluetoothSocket两条链路都是基于RFCOMM通道。服务端的核心是监听BluetoothServerSocket serverSocket bluetoothAdapter.listenUsingRfcommWithServiceRecord(MySPPService, SPP_UUID); BluetoothSocket socket serverSocket.accept(); // 阻塞等待客户端连接 InputStream inputStream socket.getInputStream(); OutputStream outputStream socket.getOutputStream();客户端的核心是发起连接BluetoothSocket socket device.createRfcommSocketToServiceRecord(SPP_UUID); socket.connect(); boolean connected socket.isConnected();SPP开发有两点经验特别值得说。第一连接建立后数据交互就是纯粹的流式读写不区分“读特征”和“写特征”所有数据都沿同一个RFCOMM通道双向传输。所以很多嵌入式蓝牙透传模块比如常见的HC-05、HC-06在串口透传模式下和Android的SPP对接就是一套完整的数据管道。第二accept()是阻塞调用必须放到子线程里执行否则主线程直接被卡死。另外SPP的连接建立比较慢第一次配对要进入PIN码确认流程重连时如果系统缓存了Bond信息可以跳过配对直接建链但前提是本次连接的设备地址能被蓝牙权限正常识别。3.4 双模设备中的资源分配与通信策略当设备需要同时支持经典蓝牙和BLE时会涉及一个在单模方案里不需要考虑的权衡射频和协议栈的资源分配。在经典蓝牙通信正在进行比如音频流或SPP大数据传输的时候BLE连接要不要保持在手机芯片里经典蓝牙和BLE通常是共用天线和基带的同时保持两个链路会导致调度开销变大每一路的有效吞吐都会下降。做双模透传设备时我建议把两条链路做成“一主一备”或“按数据特征分流”的策略。比如经典蓝牙链路承载高速数据流固件升级、文件同步BLE链路负责实时状态上报和控制指令。两条链路要各自维护独立的状态机不能在经典蓝牙断线时把BLE连接也一并释放。还要考虑同时连多台设备的情况BLE外设一般支持多个客户端同时连接Android端最多支持多个Central但经典蓝牙SPP同一时刻只允许一个RFCOMM连接。这些都需要在协议设计时提前定义好否则后期联调会非常痛苦。更实际的一点是双模设备往往还要考虑功耗策略。经典蓝牙连接建立后如果长时间没有数据交互功耗会明显偏高。BLE则可以通过调整连接间隔、从机延迟快速进入休眠状态。设计时尽量把周期性的心跳、状态上报都放在BLE链路经典蓝牙链路只在需要传输大量数据时才激活这是目前很多双模产品默认采用的做法。4. 实战中踩过的坑与排查思路速查4.1 连接建立失败的排查套路蓝牙连接失败是双模开发最高频的问题而且原因千奇百怪。我总结了排查优先级先看权限再看广播/扫描参数最后看系统底层日志。权限层面Android 6.0以上扫描BLE需要定位权限Android 12以上还要申请BLUETOOTH_SCAN和BLUETOOTH_CONNECT运行时权限少一个权限都会表现为“扫描不到”或“连接失败”。广播参数层面确认服务端广播是可连接广播、广播里的Service UUID和客户端ScanFilter里的过滤条件一致。如果服务端和客户端在同一台手机上测试还要注意系统可能不会主动扫描本机发出的广播需要换设备交叉验证。还有个容易被忽略的问题连接成功后立刻断开。这种情况通常在BLE协议栈返回133错误GATT_ERROR时出现。原因往往是连接参数被服务端拒绝或者服务端没有正确处理连接事件。排查时优先打开系统的HCI日志Android开发者选项里可以开启蓝牙HCI snoop log抓包看是哪一步断开的是连接完成事件没触发还是加密流程没完成非常直观。4.2 数据分包与MTU不一致导致的问题大数据量传输时最典型的现象是客户端写数据给服务端服务端收到的只有前20字节或者服务端通过Notify发数据客户端收到的数据被截断。这基本就是MTU协商没生效的后遗症。解决分两步第一步确保双方支持MTU交换。客户端主动requestMtu()服务端在协议栈层面要能响应这个请求协商后的MTU值在双方都取最小值。第二步协商完成后所有ATT层的单包写入/通知数据量都不能超过实际协商值如果业务数据超过MTU必须自己实现“分包序号组装”的逻辑。比如MTU是200有效载荷是197字节你要发512字节的数据就拆成3包第一包197字节序号第二包197字节序号第三包118字节结束标识。组装时按序号拼装循环冗余校验再决定是否重传。有些现成GATT库会帮你自动分包但底层机制你得清楚。嵌入式设备端如果只实现了最基本的GATT服务没有处理MTU交换Request那么客户端再积极也无济于事——协商值永远停在23字节。4.3 配对和绑定常见的翻车现场蓝牙配对翻车的概率一点都不低。常见的是客户端发起连接服务端要求配对但两端的安全等级配置不匹配导致密钥协商一直失败或者两端都设置为Just Works但是系统弹窗不出现用户拿不到确认界面连接就挂着不动了。我做数字钥匙类项目时还踩过一个坑手机端和车机端都保存了Bond信息但服务端改了加密密钥存储方式旧Bond信息失效每次连接都触发重新配对配对成功后又因为读取不到服务端的Service UUID列表导致应用层崩溃。排查完发现是绑定信息没有同步清除必须在服务端和客户端同时清理历史Bond记录才能恢复。调试这类问题建议在Android的“蓝牙设置”里删除配对记录并在嵌入式端调用协议栈接口删除本端绑定信息两边一起清才能保证环境干净。经典蓝牙的配对比BLE还要繁琐一些。SPP设备通常需要PIN码输入不同产商模块默认PIN码不一样有的是1234有的是0000少部分模块还要求固定密码长度。联调时最好先把模块手册翻出来确认默认PIN码和配对模式别上来就猜。4.4 连接参数调优稳定性、功耗和时延的平衡BLE连接后的稳定性和体验很大程度上取决于连接参数。连接间隔Connection Interval决定设备多久交换一次数据间隔越短数据交互越及时功耗也越高间隔越长越省电但时延越大。从机延迟Slave Latency允许从设备跳过若干次连接事件进一步省电但设置不合理会导致数据传输非常“钝”。在做穿戴设备时我一般这样配参数需要实时交互的状态通过将连接间隔设为30ms~50ms周期性上报的手环数据连接间隔可以放宽到100ms以上并开启2~4个从机延迟周期深度休眠场景才会用到秒级的连接间隔。参数配好之后还必须在服务端和客户端都确认参数能被接受。iOS对连接参数有较严格的要求Android端则相对宽松但最终还是以协议栈协商结果为准。另外连接参数和经典蓝牙链路的共存问题也要注意。双模设备同时保持经典蓝牙和BLE时如果经典蓝牙在传输大文件BLE链路的调度周期会被挤占如果BLE连接间隔设得太短两端都会出现延迟和丢包。遇到这类问题优先把经典蓝牙的调度优先级降低多数嵌入式协议栈里有RFCOMM QoS参数可以调或者放大BLE连接间隔保证整体链路的稳定性。关于双模开发最后再说几句实在话经过几个项目的来回折腾我最大的体会是蓝牙双模开发的重点不在“怎么写代码”而在“怎么把两条链路的角色和边界划分清楚”。BLE的GATT模型、MTU协商、Bond绑定经典蓝牙的SPP流式通信、配对流程每一块单独拎出来都不算难难的是同时把它们纳入同一个产品的技术架构里还要兼顾功耗、兼容性和用户体验。调试时认真看日志、抓HCI包、利用好蓝牙调试助手的绑定和连接参数查看功能能省掉大量靠猜的排查时间。希望这篇梳理能让准备做双模方案的朋友少走一些弯路也希望有机会和同样在做蓝牙开发的朋友多交流一些实际方案细节。本文还有配套的精品资源点击获取