1. BLE 概述：蓝牙技术演进、BLE 与经典蓝牙区别、BLE 应用场景、BLE 协议栈架构概览
各位同学，欢迎来到《BLE协议适配从入门到实战》的第一章。
咱们不绕弯子，直接聊蓝牙。很多人一听到「蓝牙」，脑子里蹦出来的就是手机连耳机、传文件。其实蓝牙这技术，发展到现在已经快三十年了，里面的门道远比你想的要多。尤其是我们今天要讲的 BLE——低功耗蓝牙，它几乎重新定义了「蓝牙」这个词。
1.1 蓝牙技术演进：从“线缆替代”到“万物互联”
蓝牙技术最早是爱立信在 1994 年搞出来的，初衷很简单：干掉 RS232 数据线。那时候手机和笔记本之间传个名片、同步个通讯录，还得插根线，麻烦得要死。蓝牙 1.0 在 1999 年正式发布，传输速率只有 1 Mbps 左右，但已经让很多人觉得「哇，无线好方便」。
后来蓝牙 2.0 + EDR 把速率提到了 3 Mbps，蓝牙 3.0 + HS 甚至能借用 Wi-Fi 物理层跑到 24 Mbps。但问题来了——功耗也跟着上去了。你想想看，一个蓝牙耳机用 2.0 版本，听歌两三个小时就没电，谁受得了？
真正的转折点在 2010 年。蓝牙 4.0 发布，它干了一件大事：把蓝牙分成了三种模式——经典蓝牙（BR/EDR）、低功耗蓝牙（BLE）、以及双模蓝牙。BLE 就是那个「低功耗」的版本。我记得当时我在做一款运动手环，用经典蓝牙的话，一颗纽扣电池撑不过一周；换成 BLE 之后，直接干到半年以上。嗯，这就是差距。
之后蓝牙 4.2 加了隐私保护和数据包长度扩展，蓝牙 5.0 把广播容量翻了 8 倍、传输距离翻了 4 倍，蓝牙 5.2 又引入了 LE Audio 和 LC3 编解码器。到现在蓝牙 5.4，已经支持了带响应的周期性广播（PAwR），专门给电子货架标签这类海量设备用的。
核心演进脉络：
- 蓝牙 1.0–3.0：经典蓝牙时代，主打音频流和文件传输，功耗高、连接慢。
- 蓝牙 4.0–4.2：BLE 诞生，低功耗 IoT 设备开始爆发。
- 蓝牙 5.0–5.4：BLE 增强，长距离、大广播、LE Audio、定位服务全面铺开。
1.2 BLE 与经典蓝牙的区别：它们根本不是同一个物种
很多人以为 BLE 就是经典蓝牙的「省电版」，其实没那么简单。说白了，它们俩虽然都叫蓝牙，但协议栈、物理层、应用场景几乎完全不同。我刚开始接触 BLE 时也踩过坑——拿着经典蓝牙的开发板去跑 BLE 的例程，结果连广播都发不出来。
下面这张表，我建议你直接截图保存，面试和做方案选型时经常用得到。
| 对比维度 | 经典蓝牙 (BR/EDR) | 低功耗蓝牙 (BLE) |
|---|---|---|
| 设计目标 | 连续数据流（音频、文件） | 间歇性小数据包（传感器、控制） |
| 功耗 | ~1W（持续连接） | ~0.01W–0.5W（大部分时间休眠） |
| 峰值速率 | 2–3 Mbps (EDR) | 1–2 Mbps (LE 2M PHY 可达 2 Mbps) |
| 连接建立时间 | ~3 秒 | ~3 毫秒 |
| 网络拓扑 | 点对点（Piconet） | 点对点、广播、Mesh |
| 典型设备 | 耳机、音箱、车载免提 | 手环、传感器、信标、门锁 |
看到没？经典蓝牙适合「一直连着、一直传」的场景，比如听歌、打电话。而 BLE 适合「大部分时间睡觉、偶尔醒来说句话」的场景，比如温度传感器每 5 分钟上报一次数据。你非要用 BLE 去传无损音频，那叫用错地方；反过来，用经典蓝牙去做一个纽扣电池供电的温湿度计，那叫自找麻烦。
避坑指南： 我曾经在一个智能门锁项目里，产品经理非要「兼容所有手机」，结果选了双模蓝牙模块。后来发现 90% 的用户只用 BLE 开锁，经典蓝牙那部分电路一直在空转耗电。最后我们不得不重新设计，把经典蓝牙部分在固件里彻底关掉。所以，选型时先想清楚你的设备到底需不需要音频流。
1.3 BLE 应用场景：你身边到处都是
BLE 的应用场景，比你想象的要广得多。我随便列几个，你看看是不是都见过：
- 可穿戴设备：手环、手表、血氧仪。这些设备电池小，但需要长期佩戴，BLE 的低功耗特性是刚需。
- 智能家居：智能门锁、灯泡、窗帘电机。用 BLE Mesh 组网，一个手机就能控制全屋设备。
- 医疗健康：血糖仪、血压计、体温贴。BLE 的配对简单、数据安全，医院里大量在用。
- 位置服务：蓝牙信标（Beacon）、室内导航。商场里给你推送优惠券的，大概率就是 BLE 广播。
- 工业与商业：电子货架标签（ESL）、资产追踪、传感器网络。蓝牙 5.4 的 PAwR 就是专门为这个场景优化的。
我个人习惯把 BLE 的应用场景分成三类：数据采集（传感器上报）、控制指令（开关、调光）、广播通知（信标、推送）。你只要搞清楚你的产品属于哪一类，协议栈的配置方向就清晰了。
1.4 BLE 协议栈架构概览：分层，是为了让你好干活
BLE 协议栈是分层的。为什么要分层？说白了，就是为了让不同的人只关心自己那一层。做芯片的不用管应用层怎么写，做应用的不用管射频怎么调。我刚开始学 BLE 时，看到那一堆层（Controller、HCI、L2CAP、ATT、GATT……）头都大了。后来做项目多了才发现，其实核心就三层：
- 物理层（PHY）和链路层（LL）：负责发数据、收数据、跳频、重传。这部分通常由蓝牙芯片硬件搞定，你基本不用碰。
- 主机（Host）协议栈：包括 L2CAP（数据分包重组）、ATT（属性协议）、GATT（属性分组管理）、SM（安全管理）。这部分是软件实现的，也是你做协议适配时打交道最多的。
- 应用层（Application）：你的业务逻辑。比如温度到了 30 度就开风扇，这就是应用层的事。
下面这张图，是我自己画的一个 BLE 协议栈分层结构，你一看就明白。
这张图里，我特意标出了「你主要在这里干活」的区域——就是 Host 层和 Application 层。Controller 层通常由蓝牙芯片厂商以固件形式提供，你只需要通过 HCI 命令跟它交互就行。而 GATT/ATT 和 L2CAP，才是你做协议适配时真正要手写代码的地方。
注意： 很多初学者一上来就扎进 GATT 的 UUID 和 Characteristic 定义里，结果连 L2CAP 的 MTU 协商都没搞明白，导致数据收发总出问题。我的建议是：先理解分层，再动手编码。每一层解决什么问题、数据怎么流下去的，心里要有数。
好了，第一章就聊这么多。你不需要现在就记住所有层的名字，但至少要明白：BLE 不是经典蓝牙的简单升级，它是一个为低功耗、小数据量、间歇性通信而生的全新协议栈。后面的章节，我们会一层一层把它拆开，手把手带你做适配。