2. 持久化方案选型与对比：SharedPreferences、SQLite、Room、文件存储

在蓝牙应用开发中，持久化数据的性能直接影响连接稳定性、配对记录恢复速度和日志分析效率。本章从工程选型角度出发，对比四种最常用的 Android 持久化方案：SharedPreferences、SQLite、Room 和 直接文件存储。我们将通过基准测试数据和适用场景分析，帮助你在蓝牙项目中做出正确选择。

2.1 四方案核心特征速览

2.2 方案分析：从蓝牙场景出发

2.2.1 SharedPreferences

适用于少量非敏感配置数据，例如蓝牙扫描间隔、设备筛选黑名单列表（少量条目）。整个文件在 Application 启动时被读取并缓存到内存中——当配置项超过 500 个键时，启动速度和内存占用会显著劣化。

// 典型使用：保存最后一次连接的设备地址
SharedPreferences sp = getSharedPreferences("bt_config", MODE_PRIVATE);
String lastAddr = sp.getString("last_device_addr", null);
sp.edit().putString("last_device_addr", "AA:BB:CC:DD:EE:FF").apply();

2.2.2 SQLite（原生 API）

适合存储中等规模的蓝牙设备数据库（例如已发现设备列表、历史连接日志）。原生 SQLite 不依赖 ORM，直接执行 SQL 语句，适合对查询性能有极致要求的场景，如按时间戳分页查询最近100条日志。

// 创建表与插入
db.execSQL("CREATE TABLE IF NOT EXISTS device_log (" +
           "id INTEGER PRIMARY KEY AUTOINCREMENT," +
           "address TEXT UNIQUE," +
           "rssi INTEGER," +
           "timestamp INTEGER)");
ContentValues cv = new ContentValues();
cv.put("address", "AA:BB:CC:DD:EE:FF");
cv.put("rssi", -65);
cv.put("timestamp", System.currentTimeMillis());
db.insertWithOnConflict("device_log", null, cv, SQLiteDatabase.CONFLICT_REPLACE);

2.2.3 Room

Google 官方推荐的 Android 关系型持久化库，本质是 SQLite 的编译时安全封装。适合复杂查询、多表关联、与 LiveData/Flow 响应式交互的蓝牙项目。缺点是引入额外的 APK 体积（约60KB）和初次启动的数据库迁移开销。

// Room Entity & DAO
@Entity(tableName = "ble_device")
data class BleDevice(
    @PrimaryKey val address: String,
    val name: String?,
    val rssi: Int,
    val lastSeen: Long
)

@Dao
interface BleDeviceDao {
    @Query("SELECT * FROM ble_device ORDER BY lastSeen DESC LIMIT :limit")
    suspend fun getRecentDevices(limit: Int): List<BleDevice>
}

使用 Room 时，务必启用 AutoMigrations 或编写清晰的迁移脚本（Migration），否则蓝牙 App 升级时可能因表结构变更而崩溃。

2.2.4 文件存储

适用于大型非结构化数据，如蓝牙抓包日志、固件升级缓存、自定义协议 dumps。JSON、Protocol Buffers 或自定义二进制格式均可。最大的灵活性和最低的框架约束，但需要自行处理并发写入、缓冲和索引。

// 使用 JSON 序列化保存设备列表到内部存储
val file = File(context.filesDir, "bt_devices.json")
val json = Gson().toJson(deviceList)
file.writeText(json)

// 读取并反序列化
val text = file.readText()
val list = Gson().fromJson(text, Array<BleDevice>::class.java).toList()

2.3 选型决策流程

2.4 性能基准测试报告（关键指标）

我们在蓝牙扫描与连接高频场景下模拟了三种负载，记录 CPU 峰值、主线程耗时和 P50 延迟。负载 B：每2秒写入一条设备信息；负载 C：应用启动时读取最近500条日志。

2.5 常见错误与排错

1. 在蓝牙 GATT 回调中同步写 SharedPreferences：引发 ANR。解决：使用 apply() 或切到 HandlerThread。
2. SQLite 无 WAL 模式导致读写锁冲突：蓝牙扫描线程写入日志的同时，UI 线程读取日志可能导致 SQLiteBusyException。解决：在 SQLiteDatabase 开启 enableWriteAheadLogging()。
3. Room AutoMigrations 未升级导致崩溃：升级蓝牙 App 数据库版本时没有提供对应 Migration，应用闪退。解决：编写测试 MigrationTestHelper 覆盖所有版本变更。
4. 文件存储全量读写阻塞：JSON 序列化10MB日志时，主线程卡顿。解决：使用 Dispatchers.IO 执行，或改用 protobuf 流式写入。