📚 课程目录第4章 BLE协议栈分层与DI边界映射

第4章 BLE协议栈分层与DI边界映射

4.1 分层概述

BLE协议栈从逻辑上划分为三个主要层次：应用层（App）、Host层（主机）和Controller层（控制器）。Host层和Controller层之间通过标准HCI（Host Controller Interface）交互，而应用层则通过Host提供的API完成业务逻辑。引入依赖注入（DI）后，各层之间的具体实现可以被替换、模拟或定制，从而实现真正的解耦。

4.1.1 各层职责

层次	主要职责	典型组件	DI注入点
应用层	用户业务逻辑、外设控制、传感器读取、UI交互	GATT Profile、设备发现管理器、配置管理	应用可通过DI注入数据源（如传感器适配器）、网络策略、存储实现
Host层	L2CAP、SMP、ATT/GATT、HCI命令解析、连接管理	L2CAP Manager、GATT Server/Client、SM引擎、HCI Transport	Host可通过DI注入底层HCI Transport、配对算法、加密策略
Controller层	链路层（LL）状态机、物理层（RF）、时序调度、HCI事件生成	Link Layer Engine、RF前端驱动、Timer Scheduler	Controller可通过DI注入定时器实现、RF接口抽象、电源管理策略

关键认知：传统嵌入式BLE协议栈往往硬编码层间调用（如Host直接调用Controller的HCI发送函数），导致单体和模拟测试困难。通过DI，三层之间只需依赖接口契约，任何实现都可以在编译期或运行期替换。

4.2 依赖关系与双向边界

虽然协议栈在功能上呈现自上而下的调用链，但实际控制流和数据流存在上行（Controller→Host→App）和下行（App→Host→Controller）两个方向。DI边界应分别处理两个方向的抽象：

下行边界：App调用Host服务（如GATT写操作），Host调用Controller的HCI操作。DI在此处注入服务代理或硬件驱动适配器。
上行边界：Controller通过HCI事件通知Host，Host通过回调/事件通知App。DI在此处注入事件分发器、消息队列或测试桩。

4.2.1 依赖反转示例

在Host层内部，传统设计会直接实例化某个HCI Transport对象（如UART驱动）。DI改造后，Host只依赖一个 IHciTransport 接口：

// 接口定义（Host层仅依赖此抽象）
interface IHciTransport {
    Result Send(byte[] data);
    Callback OnEventReceived { get; set; }
}

// Host初始化时通过DI容器注入具体实现
class BleHost {
    public BleHost(IHciTransport transport) {
        _transport = transport;
        _transport.OnEventReceived += HandleEvent;
    }
}

注意：接口的粒度要平衡——过细的接口会导致层间调用频繁、性能损失；过粗的接口又会削弱解耦优势。一般每个子系统（如L2CAP、GATT、LL）提供各自的DI接口，而不是用一个巨型接口代替所有。

4.3 数据流与控制流

下图展示了BLE协议栈三层之间的典型数据流（红色箭头表示下行命令，蓝色箭头表示上行事件），以及DI注入点如何介入层间通信：

4.4 选型权衡

在嵌入式BLE方案中采用DI并非零成本，需要权衡以下因素：

评估维度	采用DI的优势	不采用DI的风险/缺点
可测试性	每层可独立Mock，无需硬件依赖	单元测试必须烧录固件或使用硬件loopback，效率低
代码复用	同一Host代码可配不同Controller驱动（UART/SPI/USB）	Host与Controller强耦合，换芯片需重写大部分代码
性能开销	虚函数/函数指针引入微小性能损失（通常<1% CPU）	硬编码调用无间接跳转，性能略有优势
内存占用	接口表、DI容器（若使用）增加少量ROM/RAM	代码体积最小化，适合极度资源受限场景

推荐策略：对于BLE应用，优先对Host⇔Controller边界（HCI Transport）和App⇔Host边界（Profile回调）使用DI；内部L2CAP等模块若不变更，可暂缓DI化，待重构需求出现时再引入。

4.5 风险点与验收标准

风险点

接口膨胀：每增加一个层间调用就需要一个新的接口方法，导致接口版本管理困难。
时序耦合残留：即使接口抽象完善，层的时序依赖（如Host必须在Controller就绪后才能发送命令）仍需要通过状态机或协程管理。
回调地狱：上行事件链过长（Controller→Host→App）时，DI容器中回调注册的先后顺序可能导致死锁或错过事件。

验收标准

接口隔离验证：任意层替换为Mock实现后，上下行数据流仍能通过接口正确传递。
编译期/运行期切换：至少有一个实例在编译期（条件编译）和运行期（配置注入）切换实现，且功能不变。
性能基准：DI引入后，单次HCI命令往返时间增加不超过5%，且不增加额外内存碎片。
跨层测试：使用Controller模拟器（Fake）完成含完整连接、配对、GATT操作的全路径测试。

总结：BLE协议栈分层与DI边界映射的本质是将“层间调用的硬依赖”转化为“接口契约的软依赖”。Host层、Controller层、应用层各守其责，通过DI容器在初始化阶段绑定具体实现，从而获得可测试性、可替换性和模块独立性。