依赖隔离的总体架构策略
蓝牙多连接场景下，多个并发链接（如 LE Audio 广播同步、GATT 多连接、HCI 多任务）共享同一套协议栈与硬件资源。若未进行有效的依赖隔离，任一连接上的协议异常、内存泄漏或调度死锁都可能扩散至整个系统。本章从分层思想、依赖方向、隔离边界与核心原则四个维度展开，为后续章节的模块设计奠定架构基础。
1. 分层思想：从物理到应用的职责划分
蓝牙协议栈天然具备分层特性（HCI → L2CAP → ATT/GATT → GAP），但在多连接架构中还需要增加一层连接管理层（Connection Manager），以隔离不同链接的生命周期与资源。推荐的分层模型如下：
| 层级 | 名称 | 核心职责 | 隔离要求 |
|---|---|---|---|
| L4 | 应用层 | 业务逻辑、Profile 回调、用户态状态机 | 不直接访问 HCI，通过 Manager 接口回调 |
| L3 | 连接管理层（CM） | 连接句柄分配、超时管理、重连调度 | 每连接独立状态对象，互不共享锁 |
| L2 | 蓝牙协议栈抽象层 | ATT/GATT、L2CAP 信道复用 | 按连接句柄分发数据，禁止跨连接共享缓冲区 |
| L1 | HCI 与控制器抽象层 | ACL 数据收发、事件分发 | 硬件中断处理与协议栈线程分离 |
分层要点：每层只能依赖其紧邻的下层，且下层不得反向调用上层回调（通过事件队列或异步通知解耦）。这一约束正是“依赖方向”原则的体现。
2. 依赖方向：单向向下，事件向上
依赖箭头必须从上层指向下层，即 L4 → L3 → L2 → L1。数据流向（命令/数据）与依赖方向一致；而控制流（事件、回调、通知）则反向向上传递，但必须通过接口队列间接传递，禁止上层函数指针直接注入下层。这样能保证下层不感知上层的变化，实现替换与测试隔离。
- 命令路径： App → CM → Protocol → HCI（写队列）
- 事件路径： HCI → Protocol → CM → App（异步回调队列）
- 信任链路： 链接句柄作为唯一标识贯穿各层，下层只认句柄，不关心上层业务。
3. 隔离边界：模块的“围墙”
在多连接系统中，隔离边界定义在以下三个维度：
- 连接句柄隔离： 每个链接拥有独立的句柄 ID，所有资源（缓冲区、状态机、定时器）均以句柄为 Key 分配，互不共享。
- 回调执行隔离： 应用层回调必须在独立任务或协程中执行，避免在协议栈线程中直接阻塞。
- 内存区域隔离： 每个连接预分配固定大小的内存池（或使用 slab 分配器），避免一个连接持续申请耗尽全局堆。
常见风险： 若使用全局锁保护多个连接的共享对象，则单连接高负载会导致所有连接卡顿。隔离边界要求“无共享锁”或按句柄分桶加细粒度锁。
4. 核心原则
- 单向依赖： 依赖只能自上而下，同层或跨环依赖被禁止。
- 接口契约化： 层间通信使用固定结构体（如
conn_cmd_t、conn_evt_t），避免直接传裸指针。 - 错误隔离： 某链接的协议错误仅影响该链接状态机，不污染全局链路调度。
- 资源独立： 每链接拥有独立的定时器、缓冲区、任务 ID，内存回收与链接关闭同步。
5. 架构总览与隔离边界示意
6. 选型权衡
在实际产品选型中，需要在隔离粒度与性能之间做权衡：
| 方案 | 隔离度 | 内存开销 | 适用场景 |
|---|---|---|---|
| 每连接独占任务 | 高 | 较大 | 9 连接以上、低延迟要求 |
| 共享任务+句柄分片 | 中 | 中等 | 3~5 连接、中等延迟 |
| 全局单线程+协程 | 低（需严格契约） | 小 | 2 连接以内、资源受限 |
7. 风险点
- 环形依赖： 若下层持有上层回调，且上层又依赖下层对象，则形成环，导致死锁或内存泄漏。
- 回调抢占： 多个连接的回调争抢同一互斥锁，优先级反转。
- 内存泄漏扩散： 某连接泄漏，若使用全局内存池，最终影响所有链接的分配。
8. 落地步骤
- 架构评审： 明确分层边界与接口契约，绘制依赖方向图（参考上文的 SVG）。
- 句柄生成器： 实现原子化的连接句柄分配，句柄内携带链接索引与世代计数。
- 抽象接口定义： 为每层定义纯虚结构体（C 中使用函数指针表），确保无跨层裸指针。
- 内存池独立化： 按最大连接数预分配独立内存区域，并加入溢出保护。
- 单元测试： 使用 mock 下层验证每层隔离性；模拟单连接异常，检验其他连接是否受影响。
9. 验收标准
- 单链接断开： 其余链接的吞吐量下降不超过 5%（调度抖动容忍）。
- 内存独立回收： 某链接关闭后，其所有资源（堆、定时器）完全释放，全局堆无碎片增长。
- 错误传播阻断： 恶意触发某链接的协议错误（如无效 PDU），其他链接正常收发，统计零中断。