很多开发者天天在写蓝牙代码，扫描、连接、发现服务、读写特征、做 OTA、分析 HCI 日志，看起来已经很熟了，但一旦往下追问，常常会卡在这些问题上：

• 电磁波到底是怎么产生出来的？

• 一根天线加高频电流，为什么就能把信息发出去？

• 蓝牙为什么能用“频率变化”表示 0 和 1？

• 为什么数据速率越高，需要的带宽越大？

• BLE 单信道只有 2MHz，为什么还能传 1M、2M？

• BLE 和经典蓝牙到底从哪里开始不一样？

• GATT 只是 BLE 的上层模型，那经典蓝牙又是怎么通信的？

这篇文章的目标，不是只解释某一个知识点，而是想把蓝牙通信从底层到上层串成一条完整链路：

电流 → 电磁波 → 射频载波 → 调制 → 物理层 → 链路层 → 协议层 → 应用层

如果能把这条链路打通，那么以后无论是做 iOS BLE 开发、分析吞吐量、理解经典蓝牙，还是看 HCI 日志、设计 OTA、理解音频蓝牙，本质上都还是在同一个框架里。

---

一、电磁波是如何产生的

先从最底层开始。

1.1 静止电荷不会“发波”，变化的电荷才会

如果一个电荷静止在那里，它周围会有电场，但不会主动向远处“辐射信息”。

真正能产生电磁波的关键，不是“有电”，而是：

电荷的运动状态在变化

比如：

• 加速

• 减速

• 改变方向

• 来回振荡

只要电荷的运动发生变化，它就会扰动周围的电场和磁场，而这种扰动会以波的形式向外传播，这就是电磁波。

1.2 天线为什么能发射电磁波

蓝牙芯片本身不会直接“把信息扔到空气里”，真正和空气耦合的是天线。

天线做的事情，本质上是：

让高频交变电流流过导体结构，从而在空间中形成随时间变化的电场和磁场，并向外辐射。

所以从最简单的角度看，一个蓝牙发射器可以粗略理解成：

• 一段天线

• 一个高频电流源

• 一套把“信息”调制到高频上的机制

1.3 为什么一定是高频

如果电流变化太慢，产生的电磁波频率就太低，天线尺寸、传播效率、可用频谱都会出现问题。

蓝牙工作在 2.4GHz ISM 频段，意味着天线上的电流是在 GHz 级别快速振荡的。这个高频振荡构成了“载波”，真正要传的信息，再叠加到这个载波上。

---

二、蓝牙通信的共同底层模型

不管是 BLE 还是经典蓝牙，它们前半段其实非常相似。

2.1 它们都工作在 2.4GHz 频段

BLE 和经典蓝牙都属于 Bluetooth 标准体系，二者都工作在 2.4GHz ISM 频段附近。

这意味着它们共同拥有这些底层特征：

• 都是无线通信

• 都依赖天线发射/接收电磁波

• 都在 2.4GHz 附近组织频谱

• 都需要面对干扰、噪声、多设备共存问题

2.2 它们都不是“直接发送 0 和 1”

空气里传播的不是抽象的数字 0 和 1，而是连续变化的模拟电磁波。

所以通信系统要做的一件事是：

把数字信息映射到某种可发射的波形变化上

这个过程就是调制。

---

三、蓝牙是怎么用电磁波表达 0 和 1 的

3.1 最直观的理解：不是“发 0 和 1”，而是“改变波的某个属性”

一个无线信号通常有几个可操作的属性：

• 幅度

• 频率

• 相位

如果我们规定：

• 某种变化代表 0

• 另一种变化代表 1

那么接收端就能反推出数据。

3.2 BLE 常见直觉模型：用频率偏移表示 0 和 1

BLE 的物理层使用的是 GFSK，从非常直观的角度理解，可以把它近似想成：

• 频率偏高一些，表示一个比特状态

• 频率偏低一些，表示另一个比特状态

注意，这只是直觉化理解。更精确地说，BLE 并不是简单地“两个固定频点硬跳”，而是围绕中心载波附近进行平滑的频率偏移变化。

3.3 为什么不是固定的“两个点”那么简单

很多人第一次理解 GFSK 时，会形成这样的模型：

• 0 = 某个固定频率

• 1 = 某个固定频率

这个模型方便入门，但不够真实。

真实系统里：

• 信号存在过渡过程

• 频率变化是连续的

• 还会受到滤波、噪声、接收判决窗口等影响

所以更好的理解是：

在一个 symbol 时间内，信号整体表现为“偏高”或“偏低”的频率状态，而不是某一个理想数学点。

---

四、为什么变化越快，需要的带宽越大

这几乎是通信里最核心、也最容易卡住的一个问题。

4.1 低频负责轮廓，高频负责细节

如果一个信号变化很慢，它的波形很平滑，只需要低频成分就能描述。

如果一个信号变化很快，边缘很陡，细节很多，那么仅靠低频已经描述不出来了，必须引入更高频的成分。

所以可以记一句很重要的话：

低频负责整体轮廓，高频负责边缘和细节。

4.2 为什么“突变”一定意味着高频

理想方波、理想跳变，表面看只是“从 0 一下到 1”，但本质上是：

在极短时间内完成极大变化

变化越快，所需的高频成分越多；理想突变要求无限快变化，因此数学上需要无限高频成分。

这也是为什么现实中任何系统只要带宽有限，信号边缘就不可能无限陡。

4.3 变化越快，频谱越宽

把前两点合起来，就是通信中的一条核心规律：

时间上变化越快，频域上占的范围越宽。

所以：

• 速率越高

• 切换越快

• 频谱越宽

• 对带宽要求越高

---

五、BLE 单信道为什么是 2MHz，以及它如何限制速率

5.1 BLE 的信道划分

BLE 在 2.4GHz 频段上定义了 40 个信道：

• 3 个广播信道

• 37 个数据信道

每个信道宽度是 2MHz。

这意味着，在单个 BLE 信道上，系统可容纳的有效频谱范围是有限的。

5.2 2MHz 限制了什么

它限制的不是“你中心频率能不能乱跑”，而是：

围绕该信道中心频率展开的频谱宽度不能无限扩张。

如果调制变化太快，频谱就会向外扩展，泄漏到邻近信道，形成邻道干扰。

所以 2MHz 的含义不是“只能存在两个频点”，而是：

你的整个调制信号所形成的频谱，必须主要落在这个 2MHz 窗口内。

5.3 为什么 BLE 只能做到 1M / 2M 量级

因为在这种信道宽度下：

• 速率越高，频谱越宽

• 物理层必须控制在允许的频谱模板内

• 同时还要兼顾低功耗、抗干扰和便宜的硬件实现

因此 BLE 的设计目标不是追求极限吞吐，而是追求：

• 足够低功耗

• 足够稳定

• 足够简单

• 对 IoT 场景够用

---

六、BLE 和经典蓝牙的共同部分到哪里结束

讲到这里，可以说 BLE 和经典蓝牙的共同部分主要集中在这些层面：

6.1 共同部分

1. 都基于电磁波传播

2. 都依赖天线和高频交变电流

3. 都工作在 2.4GHz 频段

4. 都需要调制，把数字信息映射到波形上

5. 都要考虑带宽、噪声、干扰、跳频等问题

6.2 从哪里开始分叉

真正开始分叉的地方，不是“有没有 GATT”，也不是“有多少信道”，而是：

从物理层（PHY）开始，整套设计思路就分叉了。

也就是说：

• 调制方式不同

• 信道组织方式不同

• 数据调度方式不同

• 链路行为不同

• 上层协议生态也不同

---

七、BLE 与经典蓝牙的真正区别，不只是“40 个信道”

很多初学者容易形成一个误解：

BLE 的本质区别，是用了 40 个信道；经典蓝牙不一样。

这不准确。

7.1 信道数量不是本质，设计目标才是本质

BLE 和经典蓝牙的真正分水岭在于：

BLE 的目标

• 低功耗

• 小数据量

• 间歇通信

• 适合传感器 / IoT

经典蓝牙的目标

• 更高吞吐

• 连续数据流

• 适合音频、串口、文件传输等场景

7.2 信道设计只是整体设计的一部分

BLE 采用：

• 40 个信道

• 2MHz/信道

• 3 广播 + 37 数据

经典蓝牙采用：

• 79 个信道

• 1MHz/信道

这些都是各自设计目标下的结果，而不是定义本质的唯一因素。

---

八、为什么经典蓝牙可以用更复杂的调制，而 BLE 不用

8.1 BLE：简单调制，优先低功耗与可靠性

BLE 主要采用 GFSK。它的优势是：

• 实现简单

• 接收判决相对稳

• 功耗低

• 对噪声更耐受

8.2 经典蓝牙：更高阶调制，换取更高数据速率

经典蓝牙中的 BR/EDR 可采用：

• GFSK

• π/4-DQPSK

• 8DPSK

这类调制方式可以让每个符号承载更多 bit，因此在相近带宽下得到更高吞吐。

8.3 为什么高阶调制需要更高信噪比

这个问题非常关键。

可以把调制状态想成平面上的点：

• 状态越少，点之间距离越大

• 状态越多，点之间距离越小

噪声本质上会把接收点往旁边推。

如果点之间距离很大，稍微推一下也不容易误判。
如果点之间距离很小，轻微偏移就可能掉进旁边状态的判决区域。

所以：

高阶调制本质上是在单位带宽内塞更多信息，但代价是状态更密，更容易受噪声影响，因此需要更高信噪比。

这也是为什么 BLE 不追求这些高阶调制：

• 它的目标不是极限吞吐

• 它更需要低功耗和高鲁棒性

---

九、从 Layer 角度分开看：BLE 与经典蓝牙

下面开始正式分层展开。

---

十、BLE 的 Layer 体系

10.1 PHY：低功耗、有限带宽、平滑频移

BLE 物理层的关键点：

• 工作在 2.4GHz

• 单信道 2MHz

• 使用 GFSK

• 强调控制频谱扩展

• 典型速率为 1M / 2M

这里最重要的理解是：

BLE 不是通过无限增大频偏来提速，而是在有限频宽里，尽量平衡速率、功耗和频谱。

---

10.2 Link Layer：BLE 的灵魂

如果说 PHY 决定“怎么发波”，那么 Link Layer 决定：

• 什么时候发

• 在哪个信道发

• 什么时候跳频

• 什么时候建立连接

• 一次通信持续多久

10.2.1 广播

BLE 设备可以先在 3 个广播信道上发广播包，让中心设备发现它。

10.2.2 扫描

中心设备在广播信道上监听。
可以是：

• 被动扫描：只听

• 主动扫描：听到后还会发 Scan Request

10.2.3 建立连接

中心设备在合适时机发连接请求，之后双方进入连接态。

10.2.4 Connection Event

BLE 的连接通信不是持续不断的，而是以“事件窗口”的方式进行。

例如：

• 每 30ms 打开一次通信窗口

• 在这个窗口内双方快速交换若干个包

• 窗口结束后双方休眠

这正是 BLE 低功耗的关键原因之一：

不是一直在线高频通信，而是“集中通信 + 长时间休眠”。

10.2.5 跳频

进入连接后，双方会在 37 个数据信道之间按规则跳频，以降低干扰、提升共存能力。

---

10.3 L2CAP / ATT / GATT

这是 iOS BLE 开发者最熟悉的部分。

10.3.1 L2CAP

负责承载更高层数据，多路复用、分段等。

10.3.2 ATT

Attribute Protocol，定义了属性的访问方式。

10.3.3 GATT

在 ATT 之上构建了 Service / Characteristic 模型。

所以 BLE 并不是“只有 GATT”，而是：

GATT 是 BLE 上最常用、最典型的应用数据模型。

---

10.4 BLE 的通信哲学

BLE 的数据模型本质上像什么？

像一个远程属性数据库。

你操作的不是“字节流管道”，而是：

• 某个 Service

• 某个 Characteristic

• 对它进行 Read / Write / Notify

所以可以用一句话总结：

BLE 是属性访问模型。

---

十一、经典蓝牙的 Layer 体系

---

11.1 PHY：更偏高速连续数据

经典蓝牙同样工作在 2.4GHz 频段，但它的 PHY 设计目标不同：

• 支持更高吞吐

• 支持连续流式通信

• 在 BR/EDR 中可使用更复杂调制方式

---

11.2 Link Layer：持续连接、时隙通信、快速跳频

经典蓝牙的 Link Layer 风格和 BLE 很不一样。

11.2.1 没有 BLE 那种“广播 + GATT”主导的使用方式

经典蓝牙更偏向先配对、建立连接，再持续传输数据。

11.2.2 时隙机制

经典蓝牙采用时隙组织通信，设备按照节奏轮流发包，形成持续的数据流。

11.2.3 快速跳频

在较多信道上持续跳频，以减少干扰影响。

11.2.4 面向流式传输

它更适合：

• 音频

• 串口替代

• 文件传输

而不是 BLE 那种“短属性读写”。

---

11.3 上层协议：不是 GATT，而是多协议生态

这也是经典蓝牙最容易让 BLE 开发者不适应的地方。

它没有一个“全世界都走 Service/Characteristic”的统一模型，而是根据用途分不同协议。

11.3.1 L2CAP

底层承载，多路复用。

11.3.2 RFCOMM

非常重要。可以把它理解为：

蓝牙上的虚拟串口

这也是很多蓝牙串口模块、MFi 附件的核心基础。

11.3.3 A2DP

用于高质量音频流传输。

11.3.4 HFP / HSP

用于通话耳机、车载通话等。

11.3.5 HID

用于键盘、鼠标等输入设备。

所以经典蓝牙的本质更像：

多种专用协议 + 流式通道模型

---

11.4 经典蓝牙的通信哲学

如果说 BLE 是“属性访问模型”，那么经典蓝牙更像什么？

更像：

• 串口

• socket

• 持续数据流

你关心的不是某个 Characteristic，而是：

• 打开连接

• 建立通道

• 持续收发字节流

所以可以用一句话总结：

经典蓝牙是流式通信模型。

---

十二、BLE 与经典蓝牙的一个核心差别：属性模型 vs 数据流模型

这是对实际开发最有帮助的理解之一。

12.1 BLE

思维方式是：

• 有哪些服务

• 有哪些特征

• 这个特征能不能读

• 能不能写

• 能不能通知

它更像一个结构化的数据接口系统。

12.2 经典蓝牙

思维方式是：

• 有没有建立连接

• 有没有打开通道

• 我现在往里写多少字节

• 对方收到了什么字节流

它更像一个传输管道。

---

十三、从 iOS 开发者视角看，为什么会“觉得经典蓝牙不存在”

很多 iOS 开发者对经典蓝牙没感觉，原因很简单：

13.1 CoreBluetooth 只开放 BLE

iOS 开发中，绝大多数蓝牙功能都走 CoreBluetooth，而 CoreBluetooth 对应的是 BLE 世界。

13.2 经典蓝牙在 iOS 上通常不开放给第三方 App

普通 RFCOMM、A2DP、HFP 等经典蓝牙能力，并不像 BLE 那样直接开放给开发者自由使用。

13.3 但 MFi + ExternalAccessory 是经典蓝牙世界的一扇门

如果公司有 MFi 蓝牙模块，iOS 端通过 ExternalAccessory 通信，那它本质上就是经典蓝牙体系的一种受控接入方式。

可以粗略理解为：

• iOS App

• ExternalAccessory

• iAP 协议

• RFCOMM/经典蓝牙链路

• 蓝牙附件

所以 ExternalAccessory 这种通信方式，本质上更接近：

经典蓝牙上的流式串口模型

而不是 BLE 的 GATT 模型。

---

十四、HCI 日志是不是只针对 BLE

不是。

14.1 HCI 是 Host 和 Controller 之间的接口

HCI 的本质，是主机侧协议栈与蓝牙控制器之间的控制与数据接口。

因此：

• BLE 走 HCI

• 经典蓝牙也走 HCI

14.2 为什么很多开发者只在日志里感受到 BLE

因为在 iOS 开发中，开发者主要接触的是 CoreBluetooth 体系，自然看到和分析最多的是 BLE 相关行为。

但从体系结构上讲：

HCI 并不是 BLE 专属。

---

十五、为什么 BLE 不做成像经典蓝牙那样的“流”

这也是一个很常见的问题。

15.1 流模型的优点

• 简单直接

• 连续数据方便

• 适合音频、串口、文件

15.2 BLE 为什么更偏 GATT

因为 BLE 的目标从一开始就不是“替代串口做大流量传输”，而是：

• 低功耗

• 小数据

• 结构化

• 易于互操作

对传感器、Beacon、配网、小控制命令来说，GATT 的模型非常合适。

15.3 BLE 真能不能做流

能做近似流，但它天然不是为这个而生。

所以在 BLE 上做大量数据传输、做 OTA、做高速双向收发时，经常会遇到这些现实限制：

• MTU 限制

• DLE 限制

• Connection Event 限制

• 平台调度限制

• 吞吐不稳定

这不是你代码写得不够巧，而是它的体系设计决定了它不是原生流式协议。

---

十六、把 BLE 和经典蓝牙统一成一张总图

现在可以把整个体系统一成下面这种理解。

16.1 共同前半段

• 电流变化

• 电磁波产生

• 天线发射

• 2.4GHz 载波

• 调制数字信息

16.2 分叉点：PHY

从物理层开始，设计目标不同，走向不同。

BLE

• 简单调制

• 低功耗

• 小数据

• 短连接事件

• 属性模型

经典蓝牙

• 更高吞吐

• 连续流

• 多专用协议

• 更像串口/音频链路

---

十七、给开发者的一个最终理解框架

如果你是应用开发者，可以把这两套体系记成下面这样：

17.1 BLE

像一个低功耗、分层清晰、结构化的远程属性系统

你要思考的是：

• 广播

• 扫描

• 连接

• Service

• Characteristic

• Notify

• 吞吐量受 Link Layer 约束

17.2 经典蓝牙

像一个更接近持续连接和字节流通道的无线传输系统

你要思考的是：

• 建立连接

• 打开通道

• 连续数据流

• RFCOMM / A2DP / HFP 等不同协议用途

---

十八、结语：真正重要的不是“背协议名”，而是建立整体模型

对蓝牙的理解，如果只停留在：

• BLE 有 Service / Characteristic

• 经典蓝牙能传音频

• BLE 低功耗

其实是非常碎片化的。

真正有价值的理解，是把它们放回同一条主线里：

电流变化 → 电磁波 → 载波 → 调制 → 物理层 → 链路层 → 协议层 → 应用模型

当你这样看时，会发现：

• BLE 和经典蓝牙并不是两个毫无关系的世界

• 它们前面共享同样的物理基础

• 只是从 PHY 开始，为了不同目标，走向了不同的设计路线

于是很多零散问题也都会自然串起来：

• 为什么 BLE 低功耗

• 为什么 BLE 吞吐有限

• 为什么经典蓝牙适合流式传输

• 为什么高阶调制更快但更脆弱

• 为什么 GATT 和 ExternalAccessory 完全不像同一套东西

它们其实都只是同一个大系统，在不同设计目标下的不同实现。

---