3. BLE角色与拓扑：广播者与观察者、中央设备与外围设备、主从一体模式、Mesh网络拓扑
BLE的通信角色，说白了就是设备之间怎么「打招呼」、怎么「聊天」。我刚入行时，总觉得这些角色定义就是些理论概念，直到第一次调试两个设备死活连不上——才发现是角色没配对。嗯，这章咱们就把这些角色和拓扑结构彻底理清楚。
3.1 广播者与观察者：最基础的「喊话」模式
BLE里最简单的通信方式，就是广播。一个设备不停地往外发数据包，另一个设备在旁边听着。这就是广播者（Broadcaster）和观察者（Observer）。
广播者：只管发，不管有没有人收。它不建立连接，也不关心谁在听。典型场景就是信标（Beacon），比如商场里推送优惠券的蓝牙信标。
观察者：只管收，不回复。它扫描周围的广播包，解析里面的数据。比如手机上的蓝牙扫描功能，就是在扮演观察者。
核心要点：广播者和观察者之间没有连接，是单向通信。广播者不能知道观察者是否存在，观察者也不能回复广播者。
我在项目中遇到过一个问题：客户要求用BLE做室内定位，设备每隔100ms发一次广播包。结果发现广播间隔太短，功耗飙升。后来我建议把间隔调到500ms，配合低功耗扫描，续航从2天延长到了2周。你想想看，广播间隔对功耗的影响有多大。
3.2 中央设备与外围设备：建立连接后的「主从」关系
当两个设备需要双向通信时，就得建立连接。这时候角色就变成了中央设备（Central）和外围设备（Peripheral）。
外围设备：负责发广播，等待连接。它通常是小功耗设备，比如传感器、手环、体温贴。外围设备会周期性地广播自己的存在，告诉别人「我在这儿，快来连我」。
中央设备：负责扫描广播，发起连接。它通常是主控设备，比如手机、平板、网关。中央设备可以同时连接多个外围设备。
| 特性 | 外围设备（Peripheral） | 中央设备（Central） |
|---|---|---|
| 角色 | 从设备 | 主设备 |
| 功能 | 广播自身，等待连接 | 扫描广播，发起连接 |
| 功耗 | 低（可休眠） | 较高（需持续扫描） |
| 连接数 | 通常只连1个中央 | 可连多个外围 |
| 典型设备 | 心率带、温度传感器 | 手机、树莓派 |
这里有个坑：一个外围设备只能被一个中央设备连接。我曾经调试一个项目，两个手机同时去连同一个蓝牙手环，结果手环只响应了第一个连接请求，第二个手机一直报错。后来才意识到，外围设备在连接状态下不再广播，其他设备自然找不到它。
个人经验：设计产品时，如果设备需要被多个终端控制，可以考虑用「主从一体模式」或者「多角色切换」。别死磕单角色。
3.3 主从一体模式：一个设备身兼两职
有些场景下，一个设备既要当中央设备去连别的传感器，又要当外围设备被手机控制。这就是主从一体模式（Central & Peripheral Combined）。
举个例子：一个智能网关，它需要作为中央设备连接家里的温湿度传感器、门磁传感器，同时又要作为外围设备，让手机App能连上来查看数据。这时候网关就得同时扮演两个角色。
BLE协议栈是支持这种模式的，但要注意几点：
- 时间片分配：设备需要在扫描/连接（中央角色）和广播/等待连接（外围角色）之间切换。时间片分配不好，可能导致连接不稳定。
- 内存开销：同时维护多个连接需要更多RAM。我见过一个项目，芯片只有64KB RAM，同时连3个设备就崩了。
- 功耗控制：两个角色同时工作，功耗肯定比单一角色高。需要仔细设计休眠策略。
避坑指南：我曾经在一个项目中，让一个设备同时作为中央和外围，结果发现广播间隔和扫描窗口冲突了。广播间隔设得太短，扫描窗口就来不及打开，导致连不上其他设备。后来我把广播间隔调到1秒，扫描窗口设成30ms，才稳定下来。
3.4 Mesh网络拓扑：从「一对一」到「多对多」
传统BLE是星型拓扑——一个中央设备连多个外围设备。但如果你想覆盖整栋楼、整个工厂，星型拓扑就不够用了。这时候就需要Mesh网络。
BLE Mesh的核心思想是：每个节点都可以转发消息。消息从一个节点发出，经过其他节点接力，最终到达目标节点。这样就能覆盖很大的范围。
Mesh网络有几个关键概念：
- 节点（Node）：参与Mesh网络的设备，可以收发和转发消息。
- 中继（Relay）：负责转发消息的节点。不是所有节点都必须做中继，但中继越多，网络覆盖越好。
- 好友（Friend）：低功耗节点（LPN）的「代理」。LPN可以休眠，好友帮它缓存消息，等它醒来再转发。
- 发布/订阅（Publish/Subscribe）：消息不是发给某个具体设备，而是发给一个「主题」。订阅了这个主题的设备都能收到。
下面这张图展示了BLE Mesh的基本结构：
Mesh网络的好处很明显：覆盖范围大、可靠性高（消息有多条路径可达）、支持大量设备。但代价是复杂度高、延迟比星型拓扑大、功耗也更高。
我的建议：如果你的设备数量少于10个，且都在同一房间，用星型拓扑就够了。别为了「先进」而上Mesh，那会让你的开发周期翻倍。我见过太多团队在Mesh上踩坑了。
3.5 角色选择与拓扑设计：实战中的决策
好了，现在你知道了所有角色和拓扑。那实际项目中怎么选？我一般按这几个维度来决策：
- 通信方向：单向还是双向？单向用广播者/观察者，双向用中央/外围。
- 设备数量：1对1还是1对多？1对多用中央/外围，1对多用星型拓扑。
- 覆盖范围：同一房间还是整栋楼？同一房间用星型，整栋楼用Mesh。
- 功耗要求：设备能不能频繁唤醒？不能的话，考虑用LPN+好友模式。
- 开发周期：时间紧不紧？时间紧就别碰Mesh，用星型拓扑快速出活。
举个例子：做一个智能家居系统。灯控开关用外围设备（低功耗、只连网关），网关用主从一体模式（连灯控开关+被手机控制），全屋覆盖用Mesh网络。这样每个角色都发挥了自己的优势。
最后提醒一句：角色和拓扑的选择，直接影响后续的协议栈配置、内存分配、功耗优化。别等到代码写了一半才想起来改角色——那代价太大了。我早期一个项目就是吃了这个亏，后来重写了整个协议栈配置，多花了两周时间。