Android Room预填充数据库发版更新时如何保留用户书签数据

核心思路是放弃「整库替换+破坏性迁移」的逻辑，将预置只读数据和用户生成数据在同库内做表级隔离，通过Room版本迁移完成商品数据更新，同时完整保留用户数据、维持外键约束。

具体实现步骤 #

1. 调整表结构与初始化配置 #

• 同库保留两类表：
  • Product表：仅存储爬虫抓取的预置商品数据，属于只读更新表，不存储任何用户生成内容
  • ProductBookmark表：存储用户书签数据，通过product_id字段关联Product表主键，保留完整外键约束，该表不需要在assets预置的初始数据库中创建，由Room首次启动时自动创建
• 移除数据库初始化代码中的fallbackToDestructiveMigration()配置，该配置会在版本升级时删除全库所有数据，是书签丢失的核心诱因。调整后的初始化代码参考：

private static AppDatabase create(final Context context) {
    return Room.databaseBuilder(context, AppDatabase.class, DB_NAME)
            .createFromAsset("database/app_v1.db") // 仅首次安装时加载初始预置商品库
            .addMigrations(MIGRATION_1_2, MIGRATION_2_3) // 每个版本对应独立的商品更新迁移逻辑
            .allowMainThreadQueries()
            .build();
}

2. 通过版本迁移更新商品数据 #

每次爬虫抓取到新的商品数据后，按以下流程发版：

• 将Room的数据库版本号+1
• 把包含最新商品数据的预置db文件放入assets目录
• 编写对应版本的Migration迁移逻辑，仅替换Product表数据，不触碰ProductBookmark表。迁移逻辑参考：

// 示例：从版本1升级到版本2（更新第一批商品数据）
static final Migration MIGRATION_1_2 = new Migration(1, 2) {
    @Override
    public void migrate(@NonNull SupportSQLiteDatabase database) {
        // 1. 将assets中存储的新版本预置db拷贝到临时目录，附加到当前数据库连接
        String tempDbPath = copyAssetDbToTemp(context, "app_v2.db");
        database.execSQL("ATTACH DATABASE ? AS temp_product_db", new Object[]{tempDbPath});
        
        // 2. 开启事务提升批量操作效率
        database.beginTransaction();
        try {
            // 3. 清空旧商品数据
            database.execSQL("DELETE FROM Product");
            // 4. 导入最新商品数据
            database.execSQL("INSERT INTO Product SELECT * FROM temp_product_db.Product");
            // 5. 可选：清理新商品库中已下架商品对应的无效书签，避免脏数据
            database.execSQL("DELETE FROM ProductBookmark WHERE product_id NOT IN (SELECT id FROM Product)");
            
            database.setTransactionSuccessful();
        } finally {
            database.endTransaction();
            // 6. 分离临时库，删除临时文件
            database.execSQL("DETACH DATABASE temp_product_db");
            new File(tempDbPath).delete();
        }
    }
};

方案优势 #

• 所有表存在于同一个数据库文件内，ProductBookmark和Product的外键约束完全生效，不会出现跨库的数据一致性问题
• 升级过程仅操作商品表，用户书签数据全程保留，不会被覆盖
• 迁移过程中可自动清理无效关联数据，避免用户看到已经下架的无效商品书签
• 性能开销低，即使商品数据量达到万级，整个迁移过程也可在百毫秒级完成

避坑提示 #

• 正式版本禁止开启fallbackToDestructiveMigration()，只要配置该参数，任何未匹配到迁移规则的版本升级都会直接删库重建，用户数据必然丢失
• 迁移过程必须包裹在事务中，避免中途异常导致商品数据损坏
• 不要采用「先导出书签、再覆盖整库、最后导回书签」的逻辑，该流程在应用闪退、进程被杀等异常场景下极易出现书签丢失问题，稳定性远低于原生迁移方案

内容的提问来源于stack exchange，提问作者User9728