家里的智能灯泡换个颜色，靠的是手机发指令；共享单车解锁那一声“嘀”，背后也有蓝牙在跑。这些不起眼的操作，其实都离不开嵌入式系统中的蓝牙应用。它不像电脑或手机那么显眼，却悄悄藏在各种小设备里，让它们能“说话”、能联动。
为什么嵌入式系统偏爱蓝牙？
嵌入式系统通常资源有限，处理器弱、内存小、供电靠电池。Wi-Fi 虽快，但耗电高、连接复杂，对很多小型设备来说是“杀鸡用牛刀”。而蓝牙，尤其是低功耗蓝牙（BLE），功耗低、体积小、成本便宜，特别适合传感器、手环、门锁这类长时间运行的小玩意。
比如你戴的运动手环，每隔几秒就把心率数据传到手机，一节纽扣电池能撑两周。这背后就是 BLE 在高效工作——短时间连接、快速传输、立马休眠，几乎不耗电。
典型应用场景就在身边
智能家居里，温湿度传感器通过蓝牙把数据传给网关，再由网关上传云端。整个过程不需要布线，安装灵活。工厂里的设备状态监测模块也常用蓝牙，工人拿手机靠近一下就能读取故障码，省去接线调试的麻烦。
还有常见的电子价签，超市货架上的价格变动能统一无线更新。这些价签内部就是个微型嵌入式系统，靠蓝牙接收指令，屏幕刷新内容，几年不用换电池。
开发中常碰见的问题
实际做项目时，信号干扰是个头疼事。2.4GHz 频段太拥挤，Wi-Fi、微波炉、蓝牙全挤在一起。解决办法之一是合理设置发射功率和信道跳频策略。另外，不同手机对蓝牙协议的支持程度不一，测试时得多机型覆盖。
配对方式也得考虑用户体验。传统输入配对码太麻烦，现在流行“无感配对”——设备上电后广播特定标识，APP 自动识别并连接，用户点一下确认就行。
一段简单的蓝牙服务定义示例
在嵌入式端用 Nordic SDK 开发时，常需要自定义一个 GATT 服务。下面是个简化版本：
// 定义服务 UUID
#define MY_SERVICE_UUID 0x180F
#define MY_CHAR_UUID 0x2A19
// 添加服务
ble_uuid_t service_uuid = {MY_SERVICE_UUID, BLE_UUID_TYPE_BLE};
sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY, &service_uuid, &service_handle);
// 添加特征值
ble_gatts_char_md_t char_md = {0};
char_md.char_props.read = 1;
char_md.char_props.write = 1;
ble_gatts_attr_t attr_char_value = {0};
attr_char_value.p_uuid = &(ble_uuid_t){MY_CHAR_UUID, BLE_UUID_TYPE_BLE};
attr_char_value.init_len = sizeof(uint8_t);
attr_char_value.max_len = sizeof(uint8_t);
sd_ble_gatts_characteristic_add(service_handle, &char_md, &attr_char_value, &char_handle);这段代码在设备端注册了一个可读可写的服务，手机 APP 可以通过该接口发送控制命令或读取状态。
网络优化角度怎么看？
从网络角度看，蓝牙不是要替代 Wi-Fi，而是补足“最后一米”的连接空白。它减轻了主网络的接入压力——大量低频次、小数据量的设备走蓝牙中转，避免挤占路由器带宽。
合理规划蓝牙拓扑结构也很关键。比如用中心节点汇聚多个终端数据，再通过 Wi-Fi 或 4G 上报，形成多级协同，整体更稳定也更省电。