现代智能汽车中的无线技术45——BT与BLE（4）

我们在前面解到，**传统蓝牙（Classic）和低功耗蓝牙（BLE）**在物理层和链路层讲的是两种完全不同的"语言"。那么问题来了：为什么你的手机既能连老旧的蓝牙音箱（Classic），又能连最新的小米手环（BLE），甚至还能同时连着它们工作？

这一切的幕后功臣，就是双模架构（Dual Mode Topology）。

双模架构 ------ 手机里的秘密

1 什么是单模（Single Mode）与双模（Dual Mode）？

在蓝牙芯片的世界里，存在着极其严格的阶级划分。这也是产品经理做选型时最容易踩的坑。

2 智能手机的蓝牙栈：安卓与iOS是如何处理两种协议共存的？

手机操作系统内部的蓝牙协议栈（Bluetooth Stack）是极其庞大且复杂的软件工程。它必须像一个分裂人格的管理者，同时维护两套逻辑。

一、宏观架构：HCI 的分界线

无论是 Android 还是 iOS，蓝牙架构都分为两层：

Host（主机，运行在手机CPU上）：处理高层逻辑（如电话本、GATT服务、音频解码）。
Controller（控制器，独立的蓝牙芯片）：处理底层射频（跳频、重传、加密）。两者通过 HCI (Host Controller Interface) 接口通信（通常是UART或USB）。

二、 Android 的双重人格 (Fluoride / Gabeldorsche)

Android 的蓝牙栈历史上叫 BlueDroid，后来由 Google 重写为 Fluoride。

逻辑分离：在 Android 的源码中，Classic 和 BLE 的逻辑是平行的：
Classic 路径：处理 HFP（电话）、A2DP（音乐）、PBAP（通讯录）。这些数据流对实时性要求极高。
BLE 路径：处理 GATT（数据）、Scan（扫描）。这由系统的 BluetoothLeScanner 和 BluetoothGatt 类管理。
应用层表现：你在 Android 设置里点"蓝牙"，看到的一长串列表里，既有耳机（Classic），也有手环（BLE）。Android 在后台混合扫描（Interleaved Scan），把结果混在一起展示给你。

三、 iOS 的优雅封装 (CoreBluetooth)

iOS 的策略完全不同，它试图对开发者屏蔽底层的分裂。

Classic 的围墙： iOS 对传统蓝牙（Classic）限制极严。普通开发者不能随意开发 Classic 的数据传输（SPP协议被封杀），除非你通过 MFi (Made for iPhone) 认证，使用专用的 iAP2 协议。
只有系统级应用（如Apple Music、电话）能直接调用 A2DP/HFP。
BLE 的开放：苹果推出了 CoreBluetooth 框架，这是专门给 BLE 用的。它极其优雅，开发者根本不需要关心底层的跳频和连接细节，只需要操作对象（Peripheral, Service, Characteristic）。
共存策略：如果你做了一个双模设备（如耳机），连上 iPhone 后：
音频通道（Classic）：自动接管，出现在"设置->蓝牙"里。
数据通道（BLE）：默默连接，出现在你的 App 里（CoreBluetooth），用户在系统设置里可能根本看不到 BLE 的连接状态。

3 经典蓝牙与BLE的时分复用机制

这是双模架构中最硬核的技术难点。

手机里只有一颗蓝牙芯片，只有一根天线。

答案是：时分复用 (Time Division Multiplexing, TDM)，也就是**"微秒级的时间管理大师"**。

蓝牙控制器的底层固件里有一个调度器。它掌管着无线电资源的时间表。

由于传统蓝牙传输音频是有规律的（比如每 10ms 发一个包），调度器会计算出 Classic 传输的"空闲间隙"。

这种复用机制并非完美，如果业务太繁忙，就会"撞车"。

现象：当你戴着蓝牙耳机听歌（Classic），同时打开 App 疯狂同步手环的历史数据（BLE 大吞吐量传输）。
结果：调度器为了保证 BLE 的数据不丢，可能会被迫挤占 Classic 的时间片。 -> 你的音乐会出现卡顿、爆音。
工程师对策：在开发 App 时，如果检测到用户正在听歌（A2DP Active），应主动降低 BLE 的数据同步速度（增大 Connection Interval），主动避让，把路权让给音频。

小结