概述

观察者模式（Observer Pattern）是分布式软总线连接模块的核心架构模式，它定义了一种一对多的依赖关系：当一个对象（被观察者/Subject）的状态发生改变时，所有依赖于它的对象（观察者/Observer）都会收到通知并自动更新。

在连接模块中，连接管理器（ConnManager）是被观察者，各业务模块（认证、通道、代理等）是观察者。这种设计使得连接状态的变化能够自动、透明地传播给所有关心的业务方，实现了松耦合的事件驱动架构。

一、观察者模式原理深度解析

1.1 模式定义与角色

观察者模式属于行为型设计模式，其经典结构包含四个角色：

角色	英文	职责
主题接口	Subject	定义注册、删除、通知观察者的方法
具体主题	ConcreteSubject	维护观察者列表，状态变化时通知
观察者接口	Observer	定义接收通知的更新方法
具体观察者	ConcreteObserver	实现具体的响应逻辑

1.2 经典UML类图

1.3 核心机制

1.4 两种通知方式

方式	特点	适用场景
Push推送	被动接收，Subject主动传递数据	数据确定且需要立即处理
Pull拉取	主动获取，Observer按需查询	数据量大或需要选择性获取

二、连接模块观察者模式的具体实现

2.1 核心数据结构

2.1.1 观察者回调接口（ConnectCallback）

定义在 softbus_conn_interface.h：

这是观察者接口的定义，每个业务模块必须实现这四个回调函数来响应连接事件。

2.1.2 观察者节点（ConnListenerNode）

定义在 softbus_conn_manager.c：

每个节点代表一个已注册的业务观察者：

moduleId — 唯一标识该观察者（如 MODULE_AUTH_CHANNEL、MODULE_PROXY_CHANNEL）
callback — 该观察者提供的四个事件处理函数

2.1.3 被观察者全局容器

2.2 注册与注销机制

2.2.1 注册观察者（AddListener）

关键设计点：

✅ 互斥锁保护 — 多线程环境下安全注册
✅ 去重机制 — 同一模块ID只允许注册一次
✅ 动态内存分配 — 支持运行时增删观察者

2.2.2 注销观察者（DelListener）

2.2.3 对外接口

2.3 事件通知机制（核心分发逻辑）

连接管理器实现了四种不同粒度的事件通知：

2.3.1 广播式通知（连接建立/断开）

场景：连接建立或断开时，所有业务模块都需要知道

特点：

📡 一对多广播 — 一个事件通知所有观察者
🔄 无差别通知 — 所有观察者都收到相同的信息
📦 快照拷贝 — 先复制链表再遍历，减少锁持有时间

2.3.2 选择性通知（数据接收）

场景：数据到达时，只有发送数据的源模块应该收到

特点：

🎯 精确路由 — 按 moduleId 定位唯一目标观察者
📊 数据解包 — 自动剥离协议头（ConnPktHead），只传递有效载荷
⚡ 高效查找 — O(n)线性搜索，但实际观察者数量少（通常<20个）

2.3.3 可选通知（连接复用）

场景：连接复用时，部分模块可能不关心此事件

特点：

🔒 空指针保护 — 允许观察者不实现可选回调
🎛️ 渐进式接口 — 核心回调必填，扩展回调可选

2.4 观察者管理辅助函数

2.5 初始化时的桥接设置

架构意义：

各底层连接实现（BR/BLE/TCP）通过这个统一回调向上报告事件
连接管理器作为中介者，将事件分发给正确的业务观察者

2.6 完整的事件流转图

三、为什么采用这种观察者模式设计？

3.1 解决的核心问题

问题1：多对多的复杂依赖关系

没有观察者模式时的问题：

使用观察者模式后：

✅ 将 N×M 的网状依赖简化为 N+M 的星形依赖

问题2：连接状态的实时同步需求

分布式软总线的多个子系统需要实时感知连接状态变化：

认证模块：连接建立后启动认证流程
通道模块：连接可用后创建通道
代理模块：连接变化时调整代理策略
P2P模块：WiFi Direct连接状态监控

如果采用轮询方式，会导致：

❌ 延迟高（轮询间隔限制）
❌ 浪费CPU资源（无效轮询）
❌ 实现复杂（各模块自行维护定时器）

观察者模式实现即时推送，完美解决此问题。

3.2 设计优势分析

优势1：松耦合（Loose Coupling）

耦合程度对比：

维度	直接调用	观察者模式
编译期依赖	强（需include头文件）	弱（只需函数指针）
运行期依赖	硬编码	动态绑定
修改影响范围	大（改一处可能影响多处）	小（新增观察者无需改动被观察者）

优势2：开放封闭原则（OCP）

开放：对扩展开放 — 新增业务模块只需：

封闭：对修改封闭 — 新增观察者不需要修改连接管理器的任何代码！

优势3：单一职责原则（SRP）

各组件职责清晰分离：

组件	职责
BR/BLE/TCP模块	只负责底层连接的建立、维护、断开
连接管理器	只负责事件收集和分发
业务模块	只负责自身业务逻辑

优势4：动态可配置性

观察者可以在运行时动态注册和注销：

3.3 设计权衡与取舍

权衡1：性能开销

开销项	影响	缓解措施
函数指针间接调用	微小延迟	C语言函数指针开销极小
链表遍历查找	O(n)时间复杂度	观察者数量有限(<20)，可忽略
内存拷贝快照	少量内存分配	快照只在事件发生时创建
互斥锁竞争	可能阻塞	锁持有时间极短（微秒级）

结论：对于连接事件的频率（秒级），这些开销完全可接受。

权衡2：调试难度增加

问题：间接调用导致调用栈不够直观

缓解措施：

日志记录每次回调调用（CONN_LOGI）
DFX打点追踪事件传播路径
HiDump工具支持查看当前注册的观察者列表

权衡3：内存管理复杂性

问题：动态分配的观察者节点需要正确释放