1. 蓝牙数据持久化场景分析

蓝牙持久化的场景与后端 Web 持久化截然不同：数据流具有 高频率、小数据包、强实时性 的特征，同时受到移动设备 功耗、内存和磁盘 I/O 的三重约束。本章将深入剖析蓝牙数据的模型设计、存储需求评估方法以及性能瓶颈的识别路径，为后续的持久化优化和内存泄漏治理奠定基础。

1.1 数据模型设计

蓝牙业务层的数据通常分为三类：配置状态、设备特征值与原始扫描记录。不同的数据类型适用不同的存储模型。

以下是一个使用 Room 持久化蓝牙扫描结果的典型实体设计，通过索引和主键保证查询效率：

@Entity(tableName = "scan_results",
        indices = [Index(value = ["device_address", "timestamp"], unique = false)])
data class ScanResultEntity(
    @PrimaryKey(autoGenerate = true)
    val id: Long = 0,
    @ColumnInfo(name = "device_address")
    val deviceAddress: String,
    @ColumnInfo(name = "device_name")
    val deviceName: String?,
    @ColumnInfo(name = "rssi")
    val rssi: Int,
    @ColumnInfo(name = "raw_scan_record")
    val rawScanRecord: ByteArray?,
    @ColumnInfo(name = "timestamp")
    val timestamp: Long = System.currentTimeMillis()
)

1.2 存储需求评估

评估存储需求是性能优化的前置步骤。我们需要根据蓝牙参数计算理论上的数据吞吐量。

计算公式： 存储量 = Σ(有效负载 + 开销) × 频率 × 保留时间

1. 扫描场景： BLE 扫描回调每发现一个设备产生约 60-100 字节。若每秒扫描到 50 个设备，持续 24 小时：(80 + 16) × 50 × 86400 ≈ 414 MB/天。
2. GATT 通知场景： 传感器数据以 20 字节/包、间隔 10ms 发送，每秒产生 2KB 数据。长时间监测将产生大量时序记录。
3. 日志场景： 调试日志包含时间戳、地址、操作码和状态码，每条约 200 字节。高频打印时，1 小时即可超过 100MB。

1.3 性能瓶颈识别

蓝牙持久化主要面临三大瓶颈：写入放大、上下文饥饿 和 堆外泄漏。

具体瓶颈分析如下：

• 写入放大： SQLite 默认事务需要 fsync，单次提交吞吐量仅有 50-200 tps。当蓝牙回调频率超过此阈值时，应用进程会持续阻塞在 I/O 上。
• 上下文饥饿： onLeScan 和 onCharacteristicChanged 运行在 Binder 线程池中。如果在回调内直接执行数据库写入，会耗尽系统中的 Binder 线程，导致整个蓝牙服务无响应。
• 堆外泄漏： 使用内存映射文件 (MappedByteBuffer) 处理大块特征数据时，若取消映射不及时，会导致虚拟地址空间泄漏，最终触发 OutOfMemoryError。

1.4 调试与监控命令

在项目初期，建议将以下诊断集成到持续集成或单元测试流程中，用于及早发现持久化性能问题。

# 查看蓝牙唤醒锁与电量消耗（间接反映持久化开销）
adb shell dumpsys batterystats --bluetooth

# 检查磁盘读写流量与应用存储使用量
adb shell dumpsys diskstats

# 查看当前蓝牙堆栈线程状态（是否发生阻塞）
adb shell dumpsys bluetooth_manager

# 启用 SQLite 查询日志（仅用于 Debug 版本）
adb shell setprop log.tag.SQLiteLog V
adb logcat -s SQLiteLog