第2章 蓝牙多设备数据场景分析
蓝牙多设备数据场景是 Room 数据库介入蓝牙通信的核心应用背景。本章从设备发现、连接建立、数据流模型、数据冲突类型以及存储需求五个维度，拆解多设备蓝牙通信的全链路数据特征，为后续章节的 Room 表结构设计与数据同步策略奠定场景基础。
2.1 多设备发现机制
蓝牙设备发现是多设备数据交互的起点。经典蓝牙（BR/EDR）与低功耗蓝牙（BLE）采用不同的发现模型，直接影响发现效率、功耗和数据采集时机。
| 对比维度 | 经典蓝牙 (BR/EDR) | 低功耗蓝牙 (BLE) |
|---|---|---|
| 发现模式 | 查询（Inquiry）+ 应答（Inquiry Response） | 广播（Advertising）+ 扫描（Scanning） |
| 典型延迟 | 3–10 秒 | 20–200 毫秒 |
| 功耗等级 | 高（~100 mW） | 低（~10 mW） |
| 数据承载 | 仅携带设备地址与类 | 广播包可携带 31 字节自定义数据 |
| 拓扑适应性 | 点对点或微微网 | 广播、点对点、Mesh |
场景影响： BLE 广播模式允许设备在不建立连接时直接发送小数据包，适用于周期性传感器数据上报；经典蓝牙适用于高吞吐的流式数据传输（如音频、文件）。Room 数据库在存储发现记录时，需要标记发现类型（广播/查询）和时间戳，以区分数据来源的实时性等级。
2.2 数据场景全景图
下图将多设备发现、连接、数据流、冲突与存储串联为完整链路，帮助建立全局视角。
读图指引： 全景图采用蛇形阅读顺序（左上→右上→右下→左下），覆盖“设备层 → 发现层 → 连接层 → 数据流层 → 冲突层 → 存储层”六层结构，每层对应后续小节的深度分析。
2.3 连接管理与拓扑结构
连接建立后的拓扑形态决定了数据流的路径、带宽分配和冲突概率。在蓝牙多设备场景中，常见三种拓扑结构：
| 拓扑类型 | 连接方式 | 最大设备数 | 数据流向 | 典型场景 |
|---|---|---|---|---|
| 点对点 | 1 主设备 ↔ 1 从设备 | 2 | 双向全双工 | 手环 ⇄ 手机 |
| 星型（一主多从） | 1 主设备 ↔ n 个从设备 | 7（经典）/ 20+（BLE） | 主 → 从：广播；从 → 主：轮询或通知 | 手机 ⇄ 多传感器 |
| 受限网状 | 多设备 ⇄ 多设备（需路由） | 理论无限 | 多跳转发 | 智能家居节点组网 |
连接参数陷阱： 连接间隔（Connection Interval）设定过小会加剧功耗与总线拥塞，过大则导致数据实时性下降。在 Room 数据库写入频繁的场景（如日志落盘），建议将连接间隔控制在 30–50 ms，并启用数据长度扩展（DLE）以降低传输次数。
2.4 数据流模型
蓝牙多设备场景中存在三种基本数据流模型，每种模型对 Room 数据库的写入模式与并发控制策略有直接影响：
- 命令/响应流（CMD/RSP）： 主设备发起请求，从设备回复响应，数据量小但要求有序性。Room 操作宜采用同步 DAO 调用，避免乱序。
- 通知流（Notification）： 从设备主动推送数据到主设备，无应答确认，适合高频传感器数据。Room 写入需使用异步
@Insert(onConflict = REPLACE)防止写入阻塞。 - 广播流（Broadcast）： 设备在非连接状态下发送广播包，数据单向且不可靠。Room 仅作为离线缓存层，需配合时间戳去重。
数据速率参考： BLE 4.2 理论吞吐量约 800 Kbps，BLE 5.0 可达 2 Mbps。多设备并发通知时，每增加一台从设备，有效吞吐量下降约 15%–20%。设计 Room 批量写入阈值时，建议单次事务不超过 50 条记录，以避免链路层积压。
2.5 数据冲突类型
多设备同时读写同一数据域时，产生数据冲突。根据冲突成因，可分为以下四种类型：
| 冲突类型 | 触发条件 | 影响范围 | Room 层解决策略 |
|---|---|---|---|
| 写写冲突 | 多设备同时修改同一条记录的同一字段 | 单行数据 | @Transaction + 乐观锁（版本号） |
| 读写冲突 | 读取过程中另一设备执行写入 | 查询结果集 | 快照隔离 + @Query 加 LIMIT 分页 |
| 时间戳冲突 | 各设备系统时钟不同步，导致写入顺序错乱 | 多条记录排序 | 统一使用主设备时间戳，或 NTP 校准 |
| 版本冲突 | 本地缓存版本与远程版本不一致 | 整表同步 | 版本号递增 + 增量同步 |
真实案例： 某健康监测项目中，三台血压计同时向手机写入测量记录，由于未处理写写冲突，Room 数据库出现“最后写入者胜出”的隐性数据丢失。解决方案是引入 version 字段，每次更新前检查版本号，不匹配则回退并重新拉取最新记录。
2.6 存储需求分析
基于上述场景分析，Room 数据库需要至少四张核心表来支撑蓝牙多设备数据管理。每张表的设计直接对应一种场景需求：
| 表名（Entity） | 核心字段 | 场景对应 | 主键策略 |
|---|---|---|---|
DeviceEntity | deviceId, name, type, lastSeen, rssi | 设备发现与连接管理 | 设备 MAC 地址 |
DataRecordEntity | recordId, deviceId, timestamp, payload, version | 数据流写入与同步 | 自增 ID + 时间戳联合 |
ConflictLogEntity | logId, deviceId, fieldName, localVal, remoteVal, resolvedAt | 数据冲突记录与审计 | 自增 ID |
SyncStateEntity | deviceId, lastSyncSeq, lastSyncTime, status | 增量同步与断点续传 | 设备 ID |
设计建议： 所有时间戳字段统一存储为 Long 类型（Unix 毫秒值），而非 Date 或 String，以消除时区歧义并加速 Room 的 ORDER BY 排序与 BETWEEN 范围查询。