BLE低功耗蓝牙IoT实战：扫描、连接与数据收发全流程解析

万物互联喊了这么多年，真正落地最多、最常见、也最容易上手的通信方式，其实不是Wi-Fi，而是BLE蓝牙低功耗。我做过不少IoT小项目，从传感器采集到设备控制，BLE几乎是绕不开的一环。这篇就把我实际踩过的坑和跑通的思路整理出来，从扫描、连接到收发数据，一步步拆一个能直接复现的IoT简易Demo，帮你把BLE这套基础通信链路彻底吃透。

很多人一上来就啃协议栈，结果被GATT、ATT、L2CAP这些术语劝退。我的建议是反过来，先跑通一个能扫描到设备、能连上、能收发数据的Demo，再回头补理论，你会发现那些概念一下就活了。这篇文章就是按这个思路写的，适合刚接触BLE的嵌入式开发者、做IoT应用的同学，以及想快速验证硬件方案的硬件工程师。

1. 项目核心拆解：从标题看BLE通信的本质

1.1 为什么IoT场景偏爱BLE而不是Wi-Fi

先想明白一个问题：为什么我手头这些IoT小项目几乎清一色选了BLE，而不是更成熟的Wi-Fi？

最核心的原因是功耗。一个纽扣电池供电的传感器节点，如果用Wi-Fi，可能几天就没电了；但用BLE，广播和连接时的峰值电流虽然也有几十毫安，但平均电流可以压到微安级别，一节CR2032电池撑几个月甚至一年都很常见。这个差异对很多电池供电的IoT节点来说是决定性的。

第二个原因是成本。BLE模组的价格普遍比Wi-Fi模组便宜，而且天线设计和射频前端更简单，板子做起来也小。很多国产BLE SoC已经把射频、协议栈、MCU集成到一颗芯片里，外围器件少得可怜，硬件设计难度大幅下降。

第三个原因是连接模型。BLE的广播机制天然适合“一对多发现、按需连接”的场景，而且连接后的通信是面向连接的、确认式的，比纯广播的可靠性高很多。对于智能家居里的门锁、温湿度计、体脂秤这类设备，BLE这种“平时睡觉、需要时唤醒、短数据快速交互”的模式几乎是为它们量身定做的。

1.2 一条完整的BLE数据链路长什么样

标题里的“扫描、连接、收发数据”其实对应了BLE通信的三个核心阶段，也是整个工作流的骨架。

第一阶段是广播与扫描。外设（Peripheral）周期性地在三个广播信道上发送广播包，里面带着设备名称、服务UUID、厂商自定义数据等信息。中心设备（Central）则在扫描窗口内监听这些信道，收到广播包后可以解析出设备信息。这个阶段本质上是“发现彼此”。

第二阶段是连接建立。中心设备发起连接请求，双方协商一组连接参数，包括连接间隔、从机延迟、超时时间等。连接建立后，广播停了，双方切换到专用的数据信道上通信。

第三阶段是数据交互。这里跑的是GATT协议，逻辑上把数据组织成服务（Service）和特征（Characteristic）。特征支持读、写、通知、指示等操作，平时的数据收发基本都是围绕特征展开的。

我在做Demo时最深刻的体会是：BLE这套设计把复杂留给了协议栈，把简单留给了开发者。你不需要关心射频怎么跳频、数据怎么重传，只要理解“广播发现”“连接建立”“通过特征读写数据”这三件事，就能做出一个能用的产品原型。

1.3 Demo的整体技术选型思路

先明确我们做的是什么：一个最简单的IoT演示项目，目的是跑通“手机/中心设备扫描到一个传感器节点，连接它，然后实时读取它的数据，并下发一些控制指令”的完整链路。

我的选择如下：

中心设备（Central，也就是GATT Client）用手机App来实现，具体环境是Android，用的系统自带的BLE API。选手机当中心设备的原因很实际——开发调试方便，交互直观，不需要额外的USB dongle，而且Android的BLE API虽然有些坑，但网上资料多，出了问题容易查。

外设（Peripheral，也就是GATT Server）用一块集成BLE功能的开发板来模拟，上面跑一个自定义的GATT服务，里面包含一个只读的传感器数据特征（用来模拟上报温度）和一个可写的控制特征（用来控制LED开关）。

这套选型的好处是两端隔离：硬件端专注实现服务和广播，软件端专注扫描和交互，链路出问题时可以快速定位是哪一侧的问题。

2. 环境准备与硬件选型

2.1 开发板和模组的挑选逻辑

市面上的BLE方案很多，选哪款取决于你的目标是什么。如果是纯学习，想尽快跑通协议逻辑，我推荐用自带协议栈和示例代码的开发板，把官方例程拿来改一改就能跑。如果是做产品预研，则要考虑量产成本、功耗、天线设计等因素。

我自己在Demo里用的是ESP32系列的开发板，主要看中三点：一是协议栈成熟，BLE和Wi-Fi都能用，切换方便；二是Arduino和原生IDF两套环境都支持，出问题可以换着调；三是板载USB转串口，烧录和日志都方便，不需要额外买调试器。

如果你更追求极致功耗，可以看nRF52832这类专业BLE SoC，它们的睡眠电流能做到微安级别，射频性能也更好，但开发门槛稍高，需要额外的调试器，工具链配置也更折腾。我的建议很简单：先别纠结最好，用你手上最容易上手的板子把链路跑通，再根据产品需求迭代硬件。

2.2 开发环境的搭建与确认

我这边开发环境分三块，实际搭起来十分钟以内能搞定。

硬件端，ESP32用Arduino IDE开发，在“开发板管理器”里安装esp32支持包，然后选一块对应的开发板型号就行。需要注意USB驱动，新版系统一般免驱，但如果串口识别不了，大概率是CH340/CP2102驱动问题，装上就好。

软件端，Android Studio装好SDK后，新建一个空Activity工程，目标是API 21以上，因为BLE API从Android 5.0开始才稳定，更早的版本问题很多，没必要自找麻烦。

调试工具端，强烈建议装一个蓝牙抓包工具。手机端可以用nRF Connect这个App，能看广播包、能连设备、能读写特征，甚至能模拟外设；电脑端如果有蓝牙适配器，可以用Wireshark配合特定驱动抓HCI层的数据。这个工具会在排查问题时省下大量时间。

环境搭好之后，建议先分别做两个自检：硬件端烧一个官方BLE示例，确认能广播；手机端用nRF Connect随便扫一下，确认能看到附近设备。这两步都通过，前置条件就算齐了。

3. 扫描阶段：找到周围所有的BLE设备

3.1 扫描机制与关键参数的理解

扫描看起来只是点一下“开始扫描”然后等回调，但背后的机制决定了你能不能高效、准确地找到目标设备。

BLE扫描不是连续监听的，而是周期性进行。你可以把扫描理解为“每隔一段时间睁开眼看一下，然后又闭上一会儿”。两个核心参数分别是扫描窗口（Scan Window）和扫描间隔（Scan Interval）。窗口表示一次扫描持续多久，间隔表示两次扫描开始之间的时间间隔。窗口越大，越容易抓到广播包，但耗电也越大；间隔越大，越省电，但发现设备的延迟越高。

还有一个容易忽略的参数是扫描超时。Android的startScan()方法里的ScanCallback在超时前会持续回调，超过超时时间自动停止。实际使用中，如果扫描超时设得太短，可能错过正在休眠的设备；设得太长，又一直占用资源。我的习惯是先设10秒，如果设备列表里没看到目标，再延长到30秒重扫。

Android 7.0之后，系统对扫描做了限制：一次扫描最多跑30秒，之后会强制停止。这在调试时很容易让人误以为是代码写错了。此时可以用startScan(List filters, ScanSettings settings, ScanCallback callback)配合ScanFilter，通过Service UUID过滤，既可减少回调量，也能缩短“发现目标”的时间。

3.2 扫描代码的核心实现

Android端扫描代码其实不复杂，关键是把回调和生命周期处理好。

基本流程是：先拿到BluetoothManager和BluetoothAdapter，检查蓝牙是否打开，然后检查权限，最后启动扫描。

权限这块要注意，Android 6.0以上需要动态申请定位权限，因为系统认为扫描蓝牙会暴露你的位置信息。Android 12以上还需要加BLUETOOTH_SCAN和BLUETOOTH_CONNECT这两个运行时权限。我在这踩过好几次坑，表现都是扫描无结果或直接崩溃，排查下来全是权限没到位。

扫描代码里有一个细节值得注意：回调里拿到的BluetoothDevice对象，在连接前可以先读它的name和address，用于UI展示。但有些设备为了省电，广播包里不带设备名称，此时getName()返回的是null，界面就会显示空。解决办法是扫描到设备后，等连接成功再获取远程设备名称，或者直接用广播包里解析出来的本地名称。

我用的是一个比较清爽的写法：

private ScanCallback scanCallback = new ScanCallback() { @Override public void onScanResult(int callbackType, ScanResult result) { BluetoothDevice device = result.getDevice(); String name = device.getName(); String address = device.getAddress(); int rssi = result.getRssi(); Log.d("BLE-Scan", "发现设备: " + name + " / " + address + " / 信号强度: " + rssi + "dBm"); // 这里把device加入列表并刷新UI } @Override public void onScanFailed(int errorCode) { Log.e("BLE-Scan", "扫描失败，错误码: " + errorCode); } };

启动扫描时加一个ScanFilter，只捞包含指定Service UUID的设备，这是我推荐的做法：

UUID serviceUuid = UUID.fromString("0000ffe0-0000-1000-8000-00805f9b34fb"); ScanFilter filter = new ScanFilter.Builder() .setServiceUuid(new ParcelUuid(serviceUuid)) .build(); bluetoothAdapter.getBluetoothLeScanner().startScan( Collections.singletonList(filter), new ScanSettings.Builder().setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY).build(), scanCallback );

SCAN_MODE_LOW_LATENCY对应更短的间隔和更大的窗口，适合调试阶段；等产品上线了，要省电再用SCAN_MODE_LOW_POWER。

3.3 扫描阶段最容易踩的坑

扫描阶段的坑主要集中在权限、过滤和回调频率这三块，我把排查心得列成了一张速查表：

另外我强烈建议：不要在onScanResult里直接做耗时操作，比如创建对话框、数据库写入、网络请求。这个回调频率极高，任何耗时操作都会拖垮主线程，表现为列表刷新卡顿或者App假死。正确做法是把ScanResult塞进列表后，用一个Handler或者RecyclerView的notifyDataSetChanged去刷新UI。

4. 连接阶段：建立稳定链路的关键

4.1 连接参数里藏着稳定性的秘密

扫描到设备后，很多人急着调用connectGatt()，结果发现要么连不上，要么连上了动不动就断开。连接稳定性很大程度取决于连接参数是否匹配外设的配置。

连接参数指的是连接间隔（Connection Interval）、从机延迟（Slave Latency）和超时时间（Supervision Timeout）。连接间隔决定两个设备之间多久交换一次数据；从机延迟允许外设在指定次数内不响应，从而省电；超时时间是双方允许的最长无响应时间，超过就判定连接丢失。

我在外设端设置广播参数时会故意广播连接参数建议，让中心设备在连接时参考。比如传感器节点希望2秒更新一次数据，连接间隔就设到200ms左右；LED控制这种需要快速响应的，连接间隔就设短一点，比如30ms。这里有一个权衡：连接间隔越短，实时性越好，但功耗和射频占用都上去了。

Android端在调用connectGatt()时的autoConnect参数也值得说。如果设为false，手机只会对当前已发现的设备发起快速连接；如果设为true，手机会持续监听目标设备，即使它暂时不在广播范围内，等它再次出现时也会自动连上。这个参数我建议按场景选择，不要在每次扫描后都用autoConnect，否则断开后重连逻辑容易失控。

4.2 连接过程的完整代码框架

Android侧连接的核心是BluetoothGattCallback，连接结果、服务发现结果、数据读写结果全都回到这个回调里。

我的代码结构大致如下：

private BluetoothGatt bluetoothGatt; private BluetoothGattCallback gattCallback = new BluetoothGattCallback() { @Override public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) { if (newState == BluetoothProfile.STATE_CONNECTED) { Log.d("BLE-Gatt", "连接成功，开始发现服务"); gatt.discoverServices(); } else if (newState == BluetoothProfile.STATE_DISCONNECTED) { Log.d("BLE-Gatt", "连接断开"); bluetoothGatt.close(); } } @Override public void onServicesDiscovered(BluetoothGatt gatt, int status) { if (status == BluetoothGatt.GATT_SUCCESS) { // 到这里才能操作服务与特征 List<BluetoothGattService> services = gatt.getServices(); for (BluetoothGattService service : services) { Log.d("BLE-Gatt", "发现服务: " + service.getUuid()); service.getCharacteristics().forEach(c -> Log.d("BLE-Gatt", " 特征: " + c.getUuid() + " 属性: " + c.getProperties())); } } } }; private void connectToDevice(BluetoothDevice device) { bluetoothGatt = device.connectGatt(context, false, gattCallback); }

连接成功后，系统回调的status需要特别留意。有时候status不是GATT_SUCCESS，即使newState是已连接，也要当成异常情况处理。最常见的是status = 133，这个错误码的意思是连接被外设拒绝或链路建立失败，多半是连接参数不兼容，或者外设的广播已经停了、连接窗口错过。

有个经验我提一下：连接失败后不要马上重连，最好间隔2-3秒，给外设一点重置的时间。有一次我调试时外设固件崩溃重启，手机这边疯狂重连就是连不上，后来加了重连延迟就正常了。这种小细节在Demo阶段无所谓，但放到真实产品里影响很大。

4.3 连接稳定性的几个实操建议

做连接稳定性的优化，我是按这个顺序来的，亲测有效：

第一，确认外设端的连接参数设置合理，且广播中包含正确的连接参数建议值。很多国产BLE芯片的SDK都有默认参数，但默认值往往偏保守，比如连接间隔设到了500ms以上，导致手机端操作起来有明显延迟感。

第二，Android端不要频繁调用connectGatt()。连续多次发起连接会让蓝牙协议栈卡住，后面所有的连接都会失败。比较好的做法是每次连接前，先close掉上一个BluetoothGatt实例。

第三，监控连接掉线的回调错误码。不同的错误码代表不同的问题：134表示连接已经断掉、139表示底层错误、133表示链路拒绝。把这些错误码记录下来，和硬件同事沟通时能精准定位问题。

第四，外设端如果长时间没有数据交互，很多协议栈会自动断开连接以省电。如果希望保持连接，可以在应用层做定期的心跳交互，比如每隔几秒写一个无意义的读请求，或者让外设发一个Notification。

第五，连接过程和服务发现过程要设超时。Android的connectGatt在极端情况下可能一直卡在连接中，此时用户可以再点一次连接按钮，但我们需要在业务层加自己的超时机制，比如连接超过10秒还未成功，就主动断开并提示用户重试。系统API没有内置这个超时，不加的话用户体验会很差。

5. 数据收发：读写、通知与自定义服务

5.1 GATT结构：服务、特征、描述符一口气讲透

BLE的数据组织方式可以类比成一本字典。最顶层是服务（Service），相当于一个大分类；服务下面有特征（Characteristic），相当于具体的条目；特征下面还有描述符（Descriptor），相当于条目的注释或者开关。

一个服务用UUID唯一标识，比如0xFFE0就是很多透传模块常用的自定义服务。一个服务下面可以挂多个特征，每个特征也有自己的UUID和属性。属性的含义表示这个特征支持什么操作，比如可读（READ）、可写（WRITE）、可通知（NOTIFY）、可指示（INDICATE）等。

描述符里有一个非常重要且绕不开的：Client Characteristic Configuration Descriptor，简称CCCD，它的UUID是固定的0x2902。你想接收外设主动推送的数据，就得先往这个描述符写入0x0001（启用通知）或0x0002（启用指示）。如果不写这个值，即使外设一直在发数据，手机也收不到。这是我见过新手最容易漏掉的一步。

举一个具体例子：假设有个特征名为“温度”，它的UUID是0xAAAA，属性是可读和可通知。要读取当前温度，直接调用蓝牙API的读取操作，服务器返回的字节数组里就是温度数据；要让设备温度变化时主动上报，则要先找到该特征下面的0x2902描述符，写入0x0001，之后每次温度变化，回调里都会收到通知数据。

5.2 读写操作与数据包设计

读操作在Android端非常直接，调用bluetoothGatt.readCharacteristic(characteristic)即可，结果在onCharacteristicRead回调里拿到。

写操作分两种：带响应写（Write with Response）和无响应写（Write without Response）。带响应写会等待外设确认，可靠性高但速度慢；无响应写不需要确认，速度快但可能丢包。实际上，如果数据量小（单包20字节以内）、又希望保证不丢，就用带响应写；如果是高频控制指令，且允许偶发丢帧，比如灯效的连续调色，用无响应写更合适。

BLE传统的单次数据传输允许的最大长度是20字节。原因是最小MTU（最大传输单元）为23字节，减去3字节ATT头部，剩20字节给应用数据。这个限制在新版本协议里可以通过协商更大MTU来突破，但基础教学中，你最好先按20字节来设计数据包。

我在设计自定义协议时通常会这么定义一帧数据：

byte[0] = 0xAA; // 帧头，用于校验 byte[1] = command; // 命令码，表示操作类型 byte[2] = length; // 后续数据长度 byte[3..N] = payload; // 实际数据 byte[N+1] = checksum; // 校验值

我曾因为嫌麻烦不写校验字节，结果在信号差的时候收到了错乱的控制指令，灯一会儿亮一会儿灭，排查了很久才发现是数据链路层偶尔会丢字节，加上校验后问题立即消失。奉劝所有做IoT通信的，先定协议，再写逻辑，不要跳过校验。

5.3 通知（Notify）模式的完整实现

通知模式是BLE数据被动接收最常用的方式，没有之一。它能让数据“主动”从外设流向手机，避免手机频繁轮询，大幅降低功耗。

Android端启用通知的步骤我拆成了三步：

第一步，在onServicesDiscovered里，根据UUID找到目标Service和Characteristic：

BluetoothGattService service = gatt.getService(UUID.fromString("0000ffe0-0000-1000-8000-00805f9b34fb")); BluetoothGattCharacteristic notifyChar = service.getCharacteristic(UUID.fromString("0000ffe1-0000-1000-8000-00805f9b34fb"));

第二步，设置通知并使能：

gatt.setCharacteristicNotification(notifyChar, true); BluetoothGattDescriptor descriptor = notifyChar.getDescriptor(UUID.fromString("00002902-0000-1000-8000-00805f9b34fb")); descriptor.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE); gatt.writeDescriptor(descriptor);

第三步，在onCharacteristicChanged里接收数据：

@Override public void onCharacteristicChanged(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic) { byte[] data = characteristic.getValue(); Log.d("BLE-Notify", "收到通知数据: " + bytesToHex(data)); // 这里解析数据并刷新UI }

这里有一个非常容易被忽略的点：setCharacteristicNotification和writeDescriptor都需要外设的协议栈配合，如果外设端没有正确实现CCCD的处理，第二步会失败。排查时可以看写入描述符的回调成功与否。

收到数据后建议立刻拷贝一份字节数组，不要直接持有characteristic.getValue()的引用。外设频繁发送数据时，这个数组会被复用或者被后续回调覆盖。这个坑我印象很深，当时就因为在异步任务里读了旧引用的数组，拿到的一直是最后一份数据。

5.4 我在数据收发中总结的细节经验

数据收发看似简单，但真实场景下有很多微妙的问题。我把自己踩过的一些细节列在下面：

字节序问题。外设端是MCU，用的字节序可能和手机端不一样。比如一个16位的温度值，MCU以高字节在前的顺序发来，手机端如果按低字节在前解析，读出来的温度就是错的。做协议时一定要约定好字节序。

数据解析的时机问题。通知回调在主线程执行，如果直接在里面做复杂解析和UI更新，会阻塞界面。我的做法是回调里只做数据拷贝，然后用Handler或LiveData把数据扔到工作线程解析，解析完再回到主线程刷新UI。

多个通知同时到达的问题。如果一个服务里有多个可通知的特征，onCharacteristicChanged回调里需要根据characteristic.getUuid()区分数据的来源。不要假设只有自己关心的特征才会回调，系统会把所有已启用通知的特征数据都回调过来。

发送频率问题。外设端发通知的频率不能太高。BLE协议规定一个连接间隔内通常只能有一个数据包，如果连接间隔是30ms，那每秒最多也就30多包。硬要每秒发100包，数据必然在链路层排队或者丢弃。需要高吞吐量时，要么缩短连接间隔，要么协商更大的MTU，不要闷头多发。

6. 完整IoT简易Demo：从零到跑通

6.1 Demo的需求定义与数据流设计

我做的这个Demo需求定得很简单，目的是覆盖BLE通信的全部基本环节，同时留出扩展空间。

硬件端假装是一个温湿度传感器节点，跑在ESP32开发板上。它周期性地采集一个模拟温度值（就是内部变量加一点随机波动），并实时通过通知推送给手机。同时它还提供一个可写的控制特征，手机往里面写一个字节，0x01开灯，0x00关灯，外设端收到后翻转板载LED状态。

数据流分两个方向。上行：外设每秒生成一个新温度值，通过通知推给手机；下行：手机发送一条控制指令，外设收到后解析并响应。同时我还设了一个读取响应路径，手机主动发起读取，外设返回当前温度和灯的状态。

这个Demo虽然简单，但“外设主动上报”和“手机下发指令”两个方向都有了，覆盖了IoT场景中最典型的双向通信模型。

6.2 ESP32外设端的核心代码

ESP32端用Arduino编写，核心逻辑是初始化BLE、创建服务和特征、处理写事件、周期发送通知。

关键代码如下：

#include <BLEDevice.h> #include <BLEUtils.h> #include <BLEServer.h> #define SERVICE_UUID "0000ffe0-0000-1000-8000-00805f9b34fb" #define CHAR_TEMP_UUID "0000ffe1-0000-1000-8000-00805f9b34fb" #define CHAR_CONTROL_UUID "0000ffe2-0000-1000-8000-00805f9b34fb" BLEServer* pServer = NULL; BLECharacteristic* pTempChar = NULL; BLECharacteristic* pControlChar = NULL; bool deviceConnected = false; float tempValue = 25.0; class MyServerCallbacks : public BLEServerCallbacks { void onConnect(BLEServer* server) { deviceConnected = true; } void onDisconnect(BLEServer* server) { deviceConnected = false; } }; class MyControlCallbacks : public BLECharacteristicCallbacks { void onWrite(BLECharacteristic* characteristic) { std::string value = characteristic->getValue(); if (value.length() > 0) { if (value[0] == 0x01) { digitalWrite(LED_BUILTIN, HIGH); } else if (value[0] == 0x00) { digitalWrite(LED_BUILTIN, LOW); } Serial.printf("收到控制指令: 0x%02X\n", value[0]); } } }; void setup() { Serial.begin(115200); pinMode(LED_BUILTIN, OUTPUT); BLEDevice::init("BLE_Demo_Node"); pServer = BLEDevice::createServer(); pServer->setCallbacks(new MyServerCallbacks()); BLEService* service = pServer->createService(SERVICE_UUID); pTempChar = service->createCharacteristic( CHAR_TEMP_UUID, BLECharacteristic::PROPERTY_READ | BLECharacteristic::PROPERTY_NOTIFY); pControlChar = service->createCharacteristic( CHAR_CONTROL_UUID, BLECharacteristic::PROPERTY_WRITE); pControlChar->setCallbacks(new MyControlCallbacks()); service->start(); BLEAdvertising* advertising = pServer->getAdvertising(); advertising->addServiceUUID(SERVICE_UUID); advertising->start(); Serial.println("BLE外设已启动"); } void loop() { if (deviceConnected) { tempValue += random(-10, 10) / 100.0; // 模拟温度波动 pTempChar->setValue((uint8_t*)&tempValue, sizeof(tempValue)); pTempChar->notify(); delay(1000); } }

注意这段代码里把温度值用float的字节数组直接发出去了，这意味着手机端需要按照同样的字节序和浮点格式解析。实际项目中这种做法不安全，因为大小端和浮点格式在不同平台上可能有差异。改进做法是先把float转成整数（温度乘以100），再按固定字节序发送，例如发送两个字节的整数。我在Demo里用了float直传是为了代码简洁，但正式项目绝不建议这么干。

6.3 Android中心的UI与逻辑整合

手机端App我用一个单Activity实现，做三块区域：扫描结果列表、实时数据区、控制按钮区。

扫描结果列表用RecyclerView展示扫描设备，每项显示设备名、MAC地址和RSSI。点击某个设备就发起连接，连接成功后进入已连接状态，此时扫描列表隐藏，切换到数据交互界面。实时数据区有一个TextView不断显示最新温度，由onCharacteristicChanged回调更新。控制按钮区就两个按钮，一个开灯一个关灯，点击后向控制特征写入0x01或0x00。

整个交互逻辑的状态机其实只有三个状态：空闲（未扫描）、扫描中、已连接。我建议写代码前先把这几个状态和跳转条件理清楚，否则很容易出现“连接中断后界面还停在已连接状态”这类逻辑错误。

一个我反复强调的细节是：在Activity的onDestroy里一定要断开连接并关闭gatt。

@Override protected void onDestroy() { super.onDestroy(); if (bluetoothGatt != null) { bluetoothGatt.disconnect(); bluetoothGatt.close(); bluetoothGatt = null; } }

不这么做，蓝牙协议栈里的连接不会自动释放，可能导致后续所有连接都失败，只能重启手机才能恢复。

6.4 实测结果与验证方法

Demo跑起来后，我重点验证了四件事：

第一，扫描能看到外设，并且名字正确。如果列表里出现设备名空或者MAC对不上，排查广播配置。

第二，连接稳定不掉线。让App跑10分钟，期间不断查看连接状态，正常情况一次都不该断。如果有断连，按上一章的排查方法处理。

第三，温度数据持续更新。每秒收到一次通知，UI上的温度值持续变化，且数值序列合理，没有跳变异常。

第四，控制指令及时生效。点开灯按钮后，板载LED立即点亮，点关灯立即熄灭。同时外设串口打印出收到指令的日志。

我还用nRF Connect这个App做过交叉验证：用它连接同一块开发板，手动读写特征，确认外设端本身的收发逻辑是正常的。这样如果自家App有问题，可以快速判断是外设的锅还是App的锅。

最终跑通的链路图可以这么理解：手机扫描发现ESP32广播的服务，连接后依次发现ffe0服务下的ffe1和ffe2特征，然后写ffe2控制灯，收ffe1的温度通知。整个流程不到十分钟就能跑通一遍，作为学习BLE的定级Demo再合适不过。

7. 常见问题与排查技巧实录

7.1 高频问题速查表

我把实际开发和辅导别人时遇到的BLE通信问题整理成了一张表，按频率排序：

7.2 一份通用的调试套路

遇到问题不要瞎猜，我总结了一套固定的排查步骤，节省了大量时间。

第一步，区分问题在哪一层。先用nRF Connect这样的通用工具进行同样的操作。如果通用工具也失败，问题基本在外设端或协议栈配置；如果通用工具成功而自己App失败，问题在代码逻辑。

第二步，打开两端日志。手机端打印所有GATT回调结果，包括status、UUID、数据内容。外设端打印连接事件、写事件、通知发送事件。两边日志对比，很多问题一眼就能看出来。

第三步，关注错误码。BLE错误码很有讲究，不要只看到失败就放弃。133常见于连接参数问题，134是连接断开，257是GATT内部错误，这些都是信号灯。

第四步，抓包确认。如果前两步都定位不了，有条件就上抓包工具。电脑端用USB蓝牙适配器配合Wireshark抓HCI层封包，能看到广播、连接、数据交互的每个细节。这个属于终极手段，不过用一次就再也回不去盲调的状态了。

7.3 几个根治过的疑难杂症

这里分享三个花了不少时间才解决的案例，每个都值得记进笔记本。

第一个是关于“连接成功但读特征永远超时”。当时外设端串口显示已经收到读请求，但手机端一直收不到读响应。折腾了很久才发现外设端的ATT响应缓冲区配置太小，导致响应包被协议栈丢掉了。解决办法是调整外设端MTU协商流程，确保双方协商出的MTU足以容纳响应数据。

第二个是“同一块板子，某些手机能连，某些手机连不上”。排查发现能连上的手机蓝牙版本都较新，连不上的都是老版本。老手机不支持某些连接参数组合，协商过程直接失败。最终解决方案是让外设端在广播包中提供的连接参数做得更保守，兼容老旧中心设备，同时新手机也能正常工作。

第三个是“外设发通知频率高时，手机端偶发收不到”。原因不是丢包，而是手机端在频繁回调时主线程阻塞，导致处理不及时。后来把数据处理搬到工作线程，并增大通知发送间隔，问题才彻底消失。这说明高频IoT数据流量的瓶颈往往不是协议栈，而是应用层的处理能力。

7.4 BLE调试的整理心得

写到最后，我把这些年做BLE调试的心得浓缩成几句话。

不要指望一次就能调通，合理的预期是先跑一个最小闭环，再逐步加功能。小步快走比一次性憋大招有效得多。

日志永远是你的第一生产力。每一个回调、每一次数据变化，都要有清晰的日志输出。不要觉得打印日志拖慢运行速度，调试时宁可过度打印。

不要忽略外设端的日志。很多问题根源在外设固件，手机端再怎么排查也没有意义。两端同步日志是定位效率最高的方式。

尤其重要的一点：手头至少准备一个nRF Connect或者同类工具，它能独立验证你的外设、你的服务、你的特征。很多你以为的“App问题”，一测发现是外设广播字段配错了。这个工具帮我在无数个项目中避免了App和外设互相甩锅的局面，性能强且免费，值得常驻手机。

8. 从Demo走向产品：BLE进阶方向建议

8.1 安全与加密

Demo里没有加密，但真实产品必须考虑。BLE提供配对和绑定机制，配对后有链路加密，能防止数据被窃听和中间人攻击。Android端可以通过BluetoothGatt的security requirements来设置加密要求，外设端在创建特征时也可以标记需要加密访问。

如果设备处理的是敏感数据，比如门锁密码、健康数据，配对是红线，不可省略。这里有个折中：使用Just Works配对虽然不需要输入PIN，但安全性较弱；Passkey配对更安全，但交互上多了一步。根据产品形态灵活选择。

8.2 连接参数的动态调整

进阶玩法是动态调整连接参数。外设低功耗时，应用层可以请求增大连接间隔和从机延迟；需要高吞吐时，再请求缩短连接间隔。Android端有一个requestConnectionPriority()方法，但它的实际效果取决于外设能否响应参数更新请求。

真实产品里，连接参数调整通常是外设端主导的，手机端只能做配合。设计协议时，可以增加一个“参数请求”命令，让手机端告诉外设“我现在需要低延迟”或者“我现在要休眠”，外设决定是否调整。这样做比在两端写死参数更灵活。

8.3 连接管理的健壮性设计

一个成熟产品绝不能只有连接成功那条路，还要把异常路径处理干净。比如扫描超时后提示用户检查设备电量；连接失败后自动重试但带上限；正在重连时，用户点击设备要有防呆处理；断链后自动重连要设置最大重试次数和退避策略。

Android端很多连接问题都源于“连接对象和回调的混乱”。我建议用一个专门的管理类来封装所有BLE操作，而不是把逻辑散落在Activity里。Activity只管UI，BluetoothLeManager负责扫描、连接、数据交互和回调分发。这个分层在Demo阶段看不出价值，但一旦功能多起来，维护成本天差地别。

8.4 低功耗优化思路

等Demo跑通，还想榨干外设的功耗，核心思路就一条：在不做事的时候尽量让射频休眠。

外设端的低功耗主要靠减少广播次数和数据发送次数。比如按一下按键才广播几秒，而不是一直广播；温度变化超过阈值才发通知，而不是每秒都发。手机端的低功耗则体现在合理设置扫描策略：主动扫描时用低功耗模式，闲置时主动停扫。

做得好的产品，一个BLE传感器节点用纽扣电池跑半年是标配，一年也不稀奇。做Demo时不用过度优化，但设计协议结构时就要预留低功耗的空间，比如支持“休眠-唤醒”的指令。

这个项目做到这里，我觉得已经覆盖了BLE开发最核心的骨架。后续你要做的，就是把骨架往自己的业务场景上套：是做一个可穿戴设备的数据通道，还是做一套室内定位的信标系统，原理都是一样的，变的就是服务和特征的定义，以及上层协议的设计。

如果你按照这篇的顺序从头到尾把一个Demo跑通了，恭喜，你已经跨过了BLE开发最陡的那个坎。剩下的路，就是往细节深处走了。