ESP32 BLE 设备命名实战：从广播名称到设备名称的API详解与应用场景

1. 从零开始：为什么你的ESP32设备需要两个名字？

刚接触ESP32 BLE开发的朋友，可能都踩过这样一个坑：明明在代码里给设备起好了名字，比如“我的智能温湿度计”，但用手机一搜，发现要么搜不到，要么显示一堆乱码，或者干脆就是个冷冰冰的MAC地址。好不容易连上了，在手机的蓝牙设置里看到的设备名又变成了另一个样子。这到底是怎么回事？

这里其实涉及BLE世界里两个核心但不同的概念：广播名称和设备名称。你可以把它们想象成一个人的两种身份标签。

广播名称，就像是你在一个嘈杂的派对里，为了让别人远远地就能认出你而举着的名牌。这个名牌大小有限（传统广播只有31个字节），所以名字太长就得截断。手机在不连接你的设备时，通过扫描周围环境收到的就是这个“名牌”上的信息。它的唯一目的就是吸引注意，告诉别人“我在这里，我是谁”。

设备名称，则更像是你身份证上的法定姓名。它更正式、更完整，但需要别人走近你、和你建立连接（握手）之后，才能通过查阅你的“证件”（即GATT服务）看到。这个名称可以更长一些（最大31字节），并且是设备更稳定、更持久的身份标识。

在ESP32上开发BLE应用，比如我们场景里的智能温湿度传感器，正确设置这两个名字至关重要。广播名称决定了用户能否在手机蓝牙列表里一眼找到你，名字起得直观友好（如“LivingRoom_TempHumid”），用户体验就好。设备名称则确保了连接后，在各种设备管理界面里显示的统一和准确。如果搞混了API，或者只设置了一个，就会出现“扫描时一个名，连接后另一个名”的割裂感，甚至导致设备无法被正常发现。

接下来，我们就深入ESP32的两种蓝牙协议栈，看看如何亲手为你的设备打造这两块关键的“身份牌”。

2. 协议栈选择：Bluedroid与NimBLE的命名API江湖

ESP-IDF作为ESP32的开发框架，历史上提供了两套蓝牙协议栈供开发者选择：经典的Bluedroid和更轻量现代的NimBLE。这两者不仅仅是内部实现不同，它们在设置设备名和广播名时使用的API也完全不同，选错了协议栈，代码可就完全对不上了。

Bluedroid 是ESP-IDF早期版本中默认的蓝牙协议栈，它功能全面、稳定，经过了市场的长期考验。如果你接手的是一个老项目，或者参考的例程比较早期，大概率遇到的就是它。Bluedroid的API前缀通常是 esp_ble_gap_*，风格上更贴近传统的ESP-IDF命名方式。

NimBLE 则是一个基于Apache MyNewt项目的开源蓝牙协议栈，以其轻量、高效和模块化著称。ESP-IDF在v4.0之后大力推荐使用NimBLE，特别是在资源相对紧张或对功耗有更高要求的场景下。它的API前缀通常是 ble_*，显得更加简洁。

我个人的经验是，对于新项目，尤其是使用ESP32-C3、S3、H2等新款芯片时，优先推荐NimBLE。它不仅是未来的趋势，而且内存占用更小，对于我们的智能传感器这类设备来说非常友好。当然，如果你需要兼容旧有代码或某些特定功能，Bluedroid依然是可靠的选择。

下面的表格清晰地对比了在两种协议栈下，针对不同“命名”需求所对应的核心API，你可以先有个整体印象：