SQLite离线数据持久化对比教程 - 第3节

### 第3章 Android平台SQLite集成方案对比：SQLiteOpenHelper vs Room

Android 平台持久化本地数据时，SQLiteOpenHelper 为原生 API，Room 则是在其之上的官方 ORM 抽象层。两者底层均依赖 SQLite，但在初始化流程、版本迁移与编译时校验三个维度存在显著差异。本章通过流程对比、关键代码分解与编译时机制分析，帮助开发者在工程中做出合理选择。

一、三种维度对比总览

对比维度	SQLiteOpenHelper	Room
初始化流程	需手动继承 SQLiteOpenHelper，重写 onCreate/onUpgrade；每次 getWritableDatabase() 触发回调。	定义 @Database 抽象类，调用 Room.databaseBuilder()；首次访问 DAO 时触发创建。
版本迁移	onUpgrade() 中执行 ALTER TABLE / DROP 等 DDL，需自行管理迁移逻辑与数据保护。	支持 Migration 对象 + AutoMigration（需要出口注解）；迁移失败可回滚。
编译时校验	无。SQL 字符串仅在运行时执行，语法错误或表结构不一致只能通过 crash 发现。	注解处理器在编译时验证 @Query SQL 语法、表字段映射、外键约束等。

二、初始化流程对比

两种方案的初始化策略均围绕懒加载原则，但触发时机与实现细节不同。

public class MyDbHelper extends SQLiteOpenHelper {
    private static final String DB_NAME = "app.db";
    private static final int DB_VERSION = 1;

    public MyDbHelper(Context context) {
        super(context, DB_NAME, null, DB_VERSION);
    }

    @Override
    public void onCreate(SQLiteDatabase db) {
        db.execSQL("CREATE TABLE user (id INTEGER PRIMARY KEY, name TEXT)");
    }

    @Override
    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
        // 手动处理版本变化
    }
}
// 使用时：
SQLiteDatabase db = new MyDbHelper(context).getWritableDatabase();

@Database(entities = {User.class}, version = 1)
public abstract class AppDatabase extends RoomDatabase {
    public abstract UserDao userDao();
}

// 构建实例（单例模式）
AppDatabase db = Room.databaseBuilder(
        getApplicationContext(),
        AppDatabase.class,
        "app.db"
    ).build();
// 第一次调用 userDao().getAll() 时触发数据库创建与表生成

三、版本迁移方案对比

数据库版本升级是最易出错的环节。Room 提供了声明式迁移，SQLiteOpenHelper 则要求完全手写迁移脚本。

SQLiteOpenHelper 迁移模式

@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
    // 逐版本迁移
    if (oldVersion < 2) {
        db.execSQL("ALTER TABLE user ADD COLUMN email TEXT");
    }
    if (oldVersion < 3) {
        db.execSQL("CREATE TABLE post (id INTEGER PRIMARY KEY, title TEXT)");
    }
}

核心风险：旧版本直接跳多级时，若迁移逻辑未覆盖全部中间版本，会导致数据丢失或结构不一致。

Room 迁移模式

// 定义从版本 1 到 2 的迁移
static final Migration MIGRATION_1_2 = new Migration(1, 2) {
    @Override
    public void migrate(@NonNull SupportSQLiteDatabase database) {
        database.execSQL("ALTER TABLE user ADD COLUMN email TEXT NOT NULL DEFAULT ''");
    }
};

AppDatabase db = Room.databaseBuilder(getApplicationContext(),
        AppDatabase.class, "app.db")
    .addMigrations(MIGRATION_1_2)
    .build();

Room 还支持 自动迁移（AutoMigration）：在 @Database 中设置 autoMigrations = true，并通过 @AutoMigration 注解指定 from/to 版本，Room 根据 schema 差异自动生成迁移脚本。

// 在 @Database 中启用自动迁移
@Database(entities = {User.class}, version = 2, autoMigrations = {
    @AutoMigration(from = 1, to = 2)
})
public abstract class AppDatabase extends RoomDatabase { ... }

四、编译时校验机制

这是 Room 区别于 SQLiteOpenHelper 的杀手级能力。在编译阶段，Room 的注解处理器检查以下内容：

• @Query SQL 语法合法性：表名、列名是否存在，类型是否匹配
• @Insert/@Update/@Delete 参数类型：实体字段与表列是否对应
• 外键与索引引用：跨表关系是否存在
• 返回类型与查询结果列：POJO 字段能否被 SQL 结果集填充

若校验失败，Gradle 构建直接报错，阻止生成 APK。例如以下错误会在编译时产生：

error: The query returns a column that doesn't exist in the result set.
public abstract List<User> getAllUsersInCity(@Query("SELECT * FROM user WHERE city = :city") String city);

SQLiteOpenHelper 只能在运行时通过 try-catch 捕获异常，或通过单元测试提前暴露问题。

五、初始化流程对比示意图

六、总结与选择建议

• 快速开发 / 团队规范要求：使用 Room，充分利用编译时校验与自动迁移。
• 遗留项目 / 极致性能要求：保留 SQLiteOpenHelper，但需编写完善的 DAO 单元测试覆盖 SQL 逻辑。
• 混合使用：可基于 SQLiteOpenHelper 实现自定义 Helper，再封装为 Room 的 SupportSQLiteOpenHelper，以在 Room 生态中复用旧代码。