前言
蓝牙耳机第一次连接手机时，往往要长按按键，等指示灯闪烁，再到手机里找到它。以后再用，拿出耳机就可能自动连上，不必每次都重新搜索。
还有一种熟悉的情况：耳机明明已经连上电脑，音乐听起来也正常，一打开会议软件使用耳机麦克风，声音却变了。为什么同一副耳机，听歌和通话会有不同的表现？
这些现象背后，既有“怎样找到并接通设备”的过程，也有“接通之后使用什么功能”的约定。经典蓝牙把这些工作分开处理。理解它们的关系，才能知道手机里一个简单的“已连接”，究竟说明了什么。
一、经典蓝牙是什么
经典蓝牙是通常所说的 BR/EDR 蓝牙技术，常用于无线音乐、免提通话和串口式数据通信。 BR 是 Basic Rate，即基本速率；EDR 是 Enhanced Data Rate，即增强数据速率，是 BR 系统的可选扩展。
这里的“经典”是在区分技术体系，不是说它只能用于老设备。今天的耳机、音箱、车载系统和某些工业设备，仍会使用经典蓝牙。
BR/EDR 工作在 2.4 GHz 频段，使用 79 个、间隔 1 MHz 的无线电信道。BR 的空中比特率为 1 Mb/s，EDR 可使用 2 Mb/s 或 3 Mb/s。这些数字描述无线传输方式，不能直接当成应用每秒能收到多少文件数据：协议开销、收发安排、重传和设备实现都会影响实际结果。
Bluetooth LE，即低功耗蓝牙，是另一套蓝牙技术。两者都使用 2.4 GHz，但发现设备和建立连接的过程不同，也不能因为频段相同就直接互通。一台只支持 LE 的传感器，不会因为旁边的电脑支持经典蓝牙，就自动变成一个经典蓝牙设备。
双模设备同时具备 BR/EDR 和 LE 能力，但具体功能仍要看双方共同支持什么。 手机可以用经典蓝牙连接音箱，同时用 LE 与手环交换数据；某副耳机也可能用经典蓝牙传音乐、用 LE 配合应用读取状态。不能只看到产品上一个蓝牙版本号，就断定它的所有功能使用同一种方式。蓝牙技术概览
二、搜索设备与建立连接，是两件事
2.1 Inquiry 找到附近设备，Page 联系指定设备
Inquiry，通常译为“查询”，是经典蓝牙用于发现附近设备的过程。发起方发送查询，处于可发现状态的设备监听查询，并按规则响应。
例如，手机开始搜索新耳机，耳机则进入允许被找到的状态。手机通过这个过程取得耳机的蓝牙地址等信息，才知道附近有哪些候选设备。
蓝牙地址用于标识设备，设备名则是方便人识别的名称。两副耳机可以叫同一个名字，因此“名称相同”不能作为连接到同一台设备的充分依据。设备类型和图标也只提供线索，不能证明它一定支持某项功能。
Page，通常译为“寻呼”，是针对已知目标建立连接的过程。发起方使用目标设备的信息联系它，目标设备需要进行 Page Scan，监听针对自己的连接请求。
Inquiry 面向的是“附近有哪些设备”，Page 面向的是“我要联系这台设备”。找到设备，不等于已经和它建立通信链路。
经典蓝牙的 Inquiry 也不是 LE 的广播扫描。产品界面可能都把它们叫作“搜索蓝牙设备”，底层却使用不同的过程。用一个只接收 LE 广播的扫描工具，没有看到经典蓝牙音箱，并不能据此判断音箱损坏。
2.2 可发现与可连接，要分别看
可发现，表示设备能够参与相应的发现过程；可连接，表示设备能够响应相应的连接过程。这是两种不同的状态。
耳机长按按键后，产品通常会让它进入便于新设备发现、配对的状态。指示灯怎样闪、持续多久、连接容量满了以后怎样处理，是产品行为，不能当成所有经典蓝牙设备都遵守的固定规则。
如果手机已经保存了耳机地址，后来就可能直接联系它，不必先重复执行 Inquiry。耳机此时可以不响应发现查询，却仍处于可连接状态。
这和认识一个人后保存了联系方式类似：再次联系他，不需要先重新打听他是谁。但保存了联系方式，并不保证此刻一定能联系上；设备仍要开机、处于合适状态，并满足连接条件。
所以，“搜索列表里没有它”与“它绝不可能连接”不能画等号；“以前配对过”与“现在一定能连上”也不能画等号。
三、连接、配对、绑定与加密分别做什么
“连接蓝牙”在日常表达里，经常把几件事放在一起。拆开后，它们各有明确的作用。
| 概念 | 解决的问题 | 不代表什么 |
|---|---|---|
| 连接 | 建立双方按蓝牙规则交换数据的链路 | 不代表音乐、通话等功能都已就绪 |
| 配对（Pairing） | 按安全过程建立双方使用的密钥关系 | 不代表以后每次都要重新配对 |
| 绑定（Bonding） | 保存供后续使用的密钥等关系信息 | 不代表设备之间一直保持连接 |
| 加密（Encryption） | 使用密钥保护当前链路上的数据 | 不等于只在设备列表里显示“已配对” |
经典蓝牙把相关的共享密钥称为链路密钥，即 Link Key。密钥不是显示给用户看的设备名，而是设备进行安全验证时使用的数据。双方保存好相应信息后，之后连接时就可以按要求使用已有密钥进行认证，验证对方是否持有相应密钥，再启用加密，不需要每次都从头建立密钥关系。
例如，耳机第一次与手机配合时，双方通过配对建立密钥，再通过绑定保存下来。耳机关机后，无线连接会断开，保存的密钥却可以留下。下次开机，双方就能使用已有密钥验证，而不是因为手机列表里还显示耳机名称，就直接认定它可信。
配对也不一定表现为输入固定密码。采用安全简单配对（Secure Simple Pairing，SSP）的设备，会根据双方的显示、输入能力和安全要求选择相应方式：数字比较让人确认两端显示的数字是否一致；输入口令是在一端显示、另一端输入相应数字；带外方式则通过蓝牙无线链路以外的途径交换相关信息。
没有合适显示或输入能力的设备还可能采用 Just Works，通常不需要用户核对数字。它仍会建立密钥，但不提供防中间人攻击的认证保护。这里的“中间人”，是指攻击者夹在两台设备之间，分别冒充对方。因此，“已经有了密钥”和“配对时已防止这种冒充”也是两回事。
绑定保存的是以后可用的关系，连接描述的是当前通信状态。 耳机放回盒子断开连接后，手机仍可显示它“已配对”；反过来，某一端删除了绑定信息或两端密钥不一致，也可能影响后续连接与认证。
图中把未知目标和已知目标分开，是为了说明再次连接不必重复发现。建立基础链路后，还要确认服务信息、满足相应安全条件，才能使用目标功能。
这些工作不是每次都按照“搜索、配对、连接、使用”的固定顺序发生。配对可以在建立链路后、访问受保护服务时触发；有的服务发现不要求先配对。再次使用时还可能复用已保存的信息。实际先后取决于所用的安全模式、功能规则及实现。GAP 的接入与安全规则
四、连接以后，设备怎样在空中配合
4.1 微微网、时隙与跳频
Piconet，通常译为“微微网”，是一组按共同的时钟和跳频规则协作的设备。提供同步基准的一方叫 Central，其他按这个基准协作的设备叫 Peripheral；一些旧资料使用 Master 和 Slave。
这些名称描述的是底层通信角色，不是产品类别，也不是数据只能从哪一边流向哪一边。不能把“手机永远是 Central、耳机永远是 Peripheral”当成定义，更不能据此推断谁一定发送音乐。经典蓝牙在规定条件下还可以切换底层角色。
双方按照时隙安排发送和接收。时隙可以理解为通信时间被划分成的小段：数据包占用相应时间，有的包会连续占用多个时隙。设备遵守共同安排，才不会都在等待，或都只顾着发。
跳频则让传输按规则在不同频率之间切换，而不是一直停在同一个频点。采用自适应跳频时，可以避开一部分受干扰的频率，但仍不能保证没有丢包、没有延迟。
同一微微网里的普通连接，分别建立在 Central 与各个 Peripheral 之间；不能因为两个外设都连接了同一台电脑，就认为它们之间已经有一条可直接交换业务数据的链路。
一个设备支持多个连接，也不表示每条连接都能独占全部带宽。“耳机能同时连接两台手机”，更不等于“能同时播放两台手机的音乐”：连接维持、音频来源切换与多路混音，是不同的能力。
4.2 ACL 与 SCO、eSCO 为什么分开
蓝牙传输的不只是内容，还有不同的时间要求。一条配置命令晚一点到，应用可能还能等；电话里的一句话过了很久才补回来，交谈就已经接不上了。
ACL 是经典蓝牙常用的一种逻辑传输，中文称为“异步面向连接逻辑传输”，用来承载链路控制和上层数据。它会按规则安排数据包，支持相应的确认与重传，不要求像连续通话那样周期性预留传输机会。这里的“逻辑传输”，说的是在无线链路上怎样组织数据的发送和接收，不是一根额外的实体电线。
在它之上，L2CAP，即逻辑链路控制与适配协议，提供不同的逻辑信道，让多个上层协议共用底层链路。发送时，它把各个信道的数据交给底层传送；接收时，再把数据分给对应的上层协议处理。因此，同一对设备不必为了播放控制、服务查询等每项工作，各建一套无线电连接。
SCO 是同步面向连接逻辑传输，eSCO 是其扩展形式。它们按周期预留传输机会，适合有连续时间要求的数据，常见于经典蓝牙通话。SCO 不进行数据包重传，eSCO 则可以在限定的重传窗口中重传，不能无限等待旧数据补齐。
ACL 不等于“只能传普通文件”，SCO、eSCO 也不等于“所有声音的统一通路”。 经典蓝牙的音乐传输通常使用 ACL，通话声音常使用 SCO 或 eSCO；接听、挂断等控制消息又可以通过 ACL 传送。选择哪种通路，取决于所用功能的协议规则，不能只看数据是不是声音。
保持连接也不表示设备必须始终以同样的频率监听。例如 Sniff 模式允许按约定的间隔监听，减少 ACL 通路的活跃时间。这是经典蓝牙自身的省电机制，不表示设备已经断开，也不会把它变成 LE。经典蓝牙的架构与传输
五、为什么连上之后，还需要 SDP 与 Profile
5.1 SDP 查询对方提供什么服务
SDP 是服务发现协议，用来查询另一台设备提供哪些服务，以及使用这些服务需要的信息。
发现设备，相当于知道附近有一家店；发现服务，则是在查询店里具体提供什么业务。例如，一家打印店能否彩印、能否装订，要看它实际提供哪些服务。SDP 类似查询这份业务清单，还会给出使用相应服务所需的入口信息。
在蓝牙里，服务端保存服务记录，客户端按规则查询。记录中可以包含服务类型、相关协议、访问参数等信息。UUID 是标识服务类型等内容的一类标识符；它不是配对密码，也不是设备的蓝牙地址。
例如，某台设备提供串口式数据服务，应用可以按相应的服务 UUID 查询，取得服务入口信息，再建立对应的数据通道。常用于这类通信的 RFCOMM 是一种串口仿真协议，服务记录会给出相应的服务端信道号。这个编号帮助应用找到对端的具体服务入口，和“79 个无线电信道”不是一回事。
SDP 的任务是查询服务信息。就像查到打印店提供装订服务，还不等于资料已经装订好；查询到了蓝牙服务，也不代表已经开始播放音乐或交换数据，仍要建立相应通道并按规则使用服务。设备发现时也可能取得部分服务信息，但搜索列表里的一行名称，不能当成完整的功能清单。SDP 服务发现协议
5.2 Profile 约定怎样完成一类功能
Profile，通常译为“配置文件”，是完成某类蓝牙功能时，双方共同遵守的角色、行为和协议使用规则，不是硬盘里的一个配置文件。
只有“能交换字节”还不够。以音乐播放为例，发送方需要按双方支持的格式发送音频，接收方也要按相同约定接收、解码；不能一方发送压缩音频，另一方却把它当作按键指令。Profile 约定各方的分工和使用的协议，才能把数据传输变成可互通的功能。
| 常见 Profile | 主要用途 | 一组典型角色或分工 |
|---|---|---|
| A2DP，高级音频分发配置文件 | 传输音乐等音频流 | 手机作为音源 Source，音箱作为接收方 Sink |
| AVRCP，音视频远程控制配置文件 | 播放控制，以及按双方能力提供曲目信息等 | 耳机控制手机的播放；具体命令与角色按功能确定 |
| HFP，免提配置文件 | 通话控制和双向语音 | 手机作为音频网关 Audio Gateway，车机作为免提设备 Hands-Free |
| SPP，串口配置文件 | 通过 RFCOMM 提供串口线缆式通信 | 应用连接对方提供的串口式服务，双向交换数据 |
Profile 角色与微微网中的 Central、Peripheral 不是同一套角色。一个描述功能上谁提供什么，另一个描述底层如何同步和收发。
同样是 A2DP，如果两个产品都只提供音源能力，而没有接收能力，也不能仅凭“都支持 A2DP”就保证它们能互相播放。双方还要有可配合的角色、共同支持的参数和实际可用的功能。
六、听歌、按键和通话，怎样一起工作
6.1 音乐传输还需要共同支持的编码
在一条典型的 A2DP 音乐通路中，手机先把音频编码，按约定的格式和参数传送；音箱接收并解码，再交给扬声器播放。用于把声音编码、再恢复出来的规则，称为编解码器，即 Codec。
A2DP 要求支持 SBC 作为基础编解码器，发送方实现相应编码，接收方实现相应解码。其他可选编解码器只有双方都支持，并在当前连接中实际选择了，才会起作用。产品单方面宣传支持某种高质量编码，并不能保证连接任何手机都会使用它。
这条音乐通路中，音频数据通过 L2CAP、ACL 传输。A2DP 约定音乐功能如何配合，L2CAP 和 ACL 则承担相应的数据承载工作。它们是上下层配合的关系，不是三种互相替代的播放方式。
音频能否及时播放，还受编码耗时、缓冲、链路调度、丢包和重传影响。空中比特率为 3 Mb/s，不代表声音没有延迟；连接双方标注的蓝牙版本号，也不能直接换算成听感或延迟。A2DP 规范
6.2 能听音乐，不代表麦克风也通过 A2DP 工作
A2DP 负责相应的音频流，并不自动提供完整的免提通话功能。耳机上按下暂停键，常见的是 AVRCP 传递控制；打开耳机麦克风进行通话，经典蓝牙产品通常还要使用 HFP。
因此，在电脑上听歌时，可能正在使用 A2DP；会议软件需要耳机麦克风时，系统可能改用 HFP 的通话音频通路。通话采用的编解码器、采样参数和系统路由可能与听歌不同，声音表现也就可能改变。
这解释了前言中的一种常见情况，但不能据此认定“打开任何蓝牙耳机麦克风都一定变成同一种低音质”。具体表现取决于双方能力、实际选择的通路和操作系统；使用 LE Audio 的设备也不能直接套用这条经典音频路径。
HFP 本身也把控制和声音分开。接听、挂断等控制通过 RFCOMM 通道交换，再由 L2CAP、ACL 承载；实际通话声音则通过 SCO 或 eSCO 传输。所以，能看到来电或执行接听，不足以单独证明语音已经正确送达。
图中两处 HFP 对应同一项免提功能里的两类数据：接听、挂断是控制消息，双方说话的声音是音频数据，它们使用不同的通路。前三行虽然都用到 ACL，也不表示音乐、按键和通话控制可以互相替代；它们仍按各自的协议规则处理。因此，“耳机里能听到歌”和“麦克风能用于通话”，需要分别确认。
七、SPP 为什么像串口，却不能代替所有蓝牙功能
SPP 约定怎样通过 RFCOMM 建立仿真串口连接。RFCOMM 则提供串口仿真相关的传输能力，让应用能以串口或类似接口交换数据。具体是否显示成电脑里的 COM 端口，由操作系统和软件接口决定。
例如，一个电子秤提供 SPP 服务，电脑程序可以连接该服务，收到重量数据。但 SPP 解决的是通道怎样建立、数据怎样传递，不会替产品规定“这几个字节代表多少千克”。
双方仍要约定数据格式：使用什么编码，怎样表示一条完整消息，数值的单位是什么，以及错误或超时怎么处理。接收端不能假定一次读取就一定得到发送端一次写入的完整业务消息。
假设电子秤连续发送两条重量记录，接收程序可能分几次读完第一条，也可能一次读到两条记录的一部分。程序要根据约定的长度、结束符或其他分帧规则，把字节重新整理成完整记录，再解释重量。
串口式通道解决“字节能怎样传”，应用协议解决“这些字节是什么意思”。 即使 RFCOMM 通道正常，应用仍可能因为格式、消息边界或单位理解错误而显示错误数据。SPP 规范
RFCOMM 与 SPP 也不是同一个名字：SPP 使用 RFCOMM，而 HFP 的控制通道同样会用到 RFCOMM，但遵循的是通话控制规则。看到一个设备有 RFCOMM 通道，不能直接把它当成任意串口设备，更不能把音乐字节写进去就期待音箱播放。
八、遇到问题，先说清哪项功能没有完成
“蓝牙不工作”范围太大。把目标说具体，才容易找到下一步应该检查什么。
| 现象 | 优先确认的事情 |
|---|---|
| 搜索新耳机时找不到它 | 使用的是经典蓝牙发现还是 LE 扫描；耳机是否处于可发现状态；平台权限和无线环境是否允许发现 |
| 以前配对过，现在连不上 | 设备是否开机、可连接、容量是否允许，以及已有密钥关系是否仍一致 |
| 音乐正常，但耳机按键控制不了播放器 | 相应 AVRCP 能力、播放器响应和当前控制通路，而不只看 A2DP 音乐是否正常 |
| 音乐能听，会议软件却用不了耳机麦克风 | HFP 能力、当前输入输出设备选择、麦克风权限与音频通路 |
| 串口式设备连上了，数值却乱码或不完整 | 是否连接正确服务，以及编码、消息分帧、单位与产品协议 |
这些是定位方向，不是凭一个现象就下结论。例如，找不到设备可能与状态、工具或权限有关，不能直接认定无线电坏了；读到了错误的重量，也不应首先靠反复重新配对来解决。
选技术时同样要从要完成的任务出发。需要与现有经典蓝牙音箱或串口式设备互通，先确认双方对应的 Profile 和平台支持；需要低频传感器数据、广播或 LE Audio，则应核对相应的 LE 技术与功能规范。
LE 也能够传音频，LE Audio 与经典音频使用的无线电及协议体系不同。不能把经典蓝牙简单归纳为“能传声音”，把 LE 归纳为“只能传小数据”。经典音频与 LE Audio
九、总结
经典蓝牙通常指 BR/EDR。Inquiry 用于发现附近设备，Page 面向已知目标建立连接；可发现与可连接是不同状态，因此再次连接不一定要重新搜索。
配对建立密钥关系，绑定把相关信息留待以后使用，加密保护当前链路上的数据。它们与当前是否连接、某项功能是否可用，需要分别判断。
连接后，设备按共同的时钟、收发时序和跳频规则协作，ACL 与 SCO、eSCO 提供不同特点的逻辑传输。SDP 帮助查找服务，Profile 则约定功能如何完成。音乐、播放控制、通话和串口式通信不能仅凭一个“已连接”互相替代。
判断两台设备能否配合，应该确认共同的技术、匹配的功能角色、可用参数和应用数据规则。排查时从具体失败的功能出发，比反复搜索、配对和重连更有方向。
十、测试题
- 一台设备只支持 LE，另一台只支持经典蓝牙。它们都工作在 2.4 GHz，能否据此认定能直接连接？双模又表示什么？
- 耳机没有出现在新设备搜索列表里，却能被之前使用过的手机自动连上。这是否矛盾？请用 Inquiry、Page、可发现和可连接解释。
- 耳机已经关机，手机列表中仍显示“已配对”。这个状态可能保存了什么？为什么不能说明双方现在有连接或正在加密传输？
- 手机在一个连接中是底层 Central，能否据此认定它一定是 A2DP 音源？这两种角色分别描述什么？
- 为什么不能说“ACL 只传文件，所有声音都走 SCO”？A2DP 音乐和 HFP 通话声音通常分别使用什么通路？
- SDP 找到了某项服务，是否意味着已经能使用它？服务 UUID、设备地址、RFCOMM 服务端信道号各用于区分什么？
- 音箱只支持 SBC，手机还支持另一种可选编解码器。能否认定双方会使用那个可选编码？为什么 3 Mb/s 也不能保证播放没有延迟？
- 电脑用耳机听音乐正常，会议软件却无法使用耳机麦克风。除了是否“已连接”，还应该检查哪些条件？
- 电子秤通过 SPP 发来了字节，程序却读出错误重量。为什么要检查分帧、编码和单位，而不只是反复重新配对？
