1. 从一次数据库迁移事故说起为什么Room升级值得单独拎出来讲做Android开发的人几乎都经历过这样的场景App上线了一个版本本地数据库表结构设计得不太合理产品经理又提了新需求需要加字段、改类型、拆表。你改完Entity编译运行直接崩了——IllegalStateException: Room cannot verify the data integrity。更让人头疼的是用户手机上已经存了几百兆的本地数据你不可能让用户卸载重装。这就是Room升级要解决的核心问题在保证用户数据不丢失的前提下安全地完成数据库Schema的版本迁移。很多人对Room的印象停留在一个ORM框架写写注解就能用觉得升级无非就是改个version数字、加个Migration对象。但真正在线上环境跑过几个版本迭代之后你会发现Room的迁移机制远比想象中复杂。一个不小心轻则数据丢失重则线上大面积崩溃。而且Room的报错信息往往非常隐晦它只会告诉你迁移失败但具体哪张表、哪个字段、哪条SQL出了问题需要你自己一步步排查。这篇文章适合所有正在使用或准备使用Room的Android开发者。不管你是刚接触Room的新手还是已经写过几个Migration的老手我都会从底层原理到实战操作把Room升级这件事彻底讲透。包括Schema验证机制、Migration的正确写法、自动化迁移工具的使用、迁移测试方案、以及我在实际项目中踩过的那些坑。读完你至少能搞清楚三件事Room升级到底在升什么、怎么升才安全、出了问题怎么排查。2. Room的Schema验证机制升级失败的根源在哪里2.1 编译期与运行期的双重校验要理解Room升级为什么会失败首先得搞清楚Room的Schema验证是怎么工作的。Room的校验分为两个阶段编译期校验和运行期校验。编译期Room的注解处理器会扫描所有Entity、Dao、Database注解生成对应的Java实现类。同时它会把当前数据库的Schema信息导出成一个JSON文件存放在app/schemas/目录下。这个JSON文件非常关键它记录了每个版本数据库的完整结构表名、字段名、字段类型、主键、索引、外键、默认值等等。运行期当App启动、Room第一次访问数据库时它会做一次校验读取设备上现有数据库的user_versionSQLite内置的版本号和你代码中Database(version N)声明的版本号做对比。如果设备上的版本低于代码版本Room就会触发迁移流程如果版本一致Room会进一步校验设备上数据库的实际Schema是否和schema JSON文件中记录的一致。如果不一致直接抛出IllegalStateException。这里有个很多人忽略的细节Room在运行期校验Schema时比对的是设备上数据库的真实结构而不是你代码里的Entity定义。也就是说即使你的Entity改对了但如果Migration执行后数据库的实际结构和Schema JSON对不上照样崩溃。2.2 Schema JSON文件的作用与生成逻辑Schema JSON文件是Room升级体系的核心枢纽。它的默认导出路径是app/schemas/你的数据库类全限定名/版本号.json。比如你的数据库类叫AppDatabase包名是com.example.myapp那么版本1的Schema文件就在app/schemas/com.example.myapp.AppDatabase/1.json。这个文件的内容大致长这样{ formatVersion: 1, database: { version: 1, identityHash: abc123..., entities: [ { tableName: users, createSql: CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, name TEXT NOT NULL, age INTEGER NOT NULL), fields: [ {fieldPath: id, columnName: id, affinity: INTEGER, notNull: true}, {fieldPath: name, columnName: name, affinity: TEXT, notNull: true}, {fieldPath: age, columnName: age, affinity: INTEGER, notNull: true} ], primaryKey: {columnNames: [id], autoGenerate: true} } ], views: [], setupQueries: [...] } }其中identityHash是一个关键字段。它是Room根据整个Schema内容计算出来的哈希值。每次你修改Entity重新编译后生成的Schema JSON的identityHash都会变化。Room在运行期就是通过比对这个哈希值来判断Schema是否发生了变更。如果你没有正确配置Schema的导出路径或者把exportSchema设成了false那么Room在运行期就无法进行完整的Schema校验迁移出问题的概率会大大增加。所以我的建议是永远把exportSchema设为true并且把app/schemas/目录纳入版本控制。2.3 版本号不匹配时的三种走向当设备上的数据库版本和代码声明的版本不一致时Room会根据情况走三条不同的路径第一条路径设备版本 代码版本且找到了对应的Migration。Room会按照版本号从小到大依次执行Migration比如从版本1升到版本3它会先执行MIGRATION_1_2再执行MIGRATION_2_3。每一步执行完毕后Room会更新数据库的user_version。第二条路径设备版本 代码版本但没有找到对应的Migration。这时候Room会检查你是否启用了fallbackToDestructiveMigration()。如果启用了Room会直接删除所有表然后重建数据全部丢失。如果没有启用直接抛出IllegalStateExceptionApp崩溃。第三条路径设备版本 代码版本。这种情况通常发生在用户安装了旧版本App比如从应用商店回滚了版本。Room同样会抛出异常因为它不知道如何处理降级。你可以通过fallbackToDestructiveMigrationOnDowngrade()来处理这种情况但同样会丢失数据。理解了这三条路径你就明白了Migration的本质就是告诉Room从版本A到版本B数据库结构发生了哪些变化需要执行哪些SQL来完成这个变化。3. Migration的正确写法从手动迁移到自动化方案3.1 手动编写Migration的完整流程手动Migration是最基础也最可控的方式。假设我们有一个users表版本1的结构是id name版本2需要增加一个email字段同时给name字段加一个索引。第一步修改EntityEntity(tableName users, indices [Index(value [name])]) data class User( PrimaryKey(autoGenerate true) val id: Long 0, val name: String, val email: String )第二步升级数据库版本号Database(entities [User::class], version 2, exportSchema true) abstract class AppDatabase : RoomDatabase() { abstract fun userDao(): UserDao }第三步编写Migrationval MIGRATION_1_2 object : Migration(1, 2) { override fun migrate(database: SupportSQLiteDatabase) { // 添加新字段注意设置默认值 database.execSQL(ALTER TABLE users ADD COLUMN email TEXT NOT NULL DEFAULT ) // 创建索引 database.execSQL(CREATE INDEX IF NOT EXISTS index_users_name ON users (name)) } }第四步在构建数据库时注册MigrationRoom.databaseBuilder(context, AppDatabase::class.java, app_database) .addMigrations(MIGRATION_1_2) .build()这四步看起来简单但每一步都有坑。我逐个说。关于ALTER TABLE ADD COLUMN的坑SQLite的ALTER TABLE能力非常有限它只支持ADD COLUMN、RENAME TABLE、RENAME COLUMN这几种操作。如果你想删除字段、修改字段类型、修改约束SQLite是不支持的。这时候你需要用创建新表 - 拷贝数据 - 删除旧表 - 重命名新表的方式来完成。关于NOT NULL字段的默认值如果你新增的字段是NOT NULL的必须提供DEFAULT值否则已有数据的行会违反约束。而且这个默认值必须和Entity中声明的defaultValue一致否则Schema校验会失败。关于索引命名Room生成的索引名有固定格式index_表名_字段名。如果你手动创建的索引名和Room期望的不一致Schema校验同样会失败。所以最稳妥的方式是先写好Entity编译一次然后去生成的Schema JSON文件里看Room期望的createSql是什么照着写Migration。3.2 复杂迁移场景拆表、合表与数据转换实际项目中简单的加字段只是冰山一角。更复杂的情况包括把一张宽表拆成两张表、把两张表合并成一张、修改主键、修改字段类型并转换数据。以拆表为例。假设版本1有一个users表包含id, name, email, phone。版本2需要把email和phone拆到单独的contacts表中。这种迁移没法用一条ALTER TABLE搞定需要分步骤val MIGRATION_1_2 object : Migration(1, 2) { override fun migrate(database: SupportSQLiteDatabase) { // 1. 创建新表 database.execSQL( CREATE TABLE IF NOT EXISTS contacts ( id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, user_id INTEGER NOT NULL, email TEXT NOT NULL DEFAULT , phone TEXT NOT NULL DEFAULT , FOREIGN KEY(user_id) REFERENCES users(id) ON DELETE CASCADE ) ) // 2. 从旧表拷贝数据 database.execSQL( INSERT INTO contacts (user_id, email, phone) SELECT id, email, phone FROM users ) // 3. 重建users表去掉email和phone字段 database.execSQL( CREATE TABLE users_new ( id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, name TEXT NOT NULL ) ) database.execSQL(INSERT INTO users_new (id, name) SELECT id, name FROM users) database.execSQL(DROP TABLE users) database.execSQL(ALTER TABLE users_new RENAME TO users) // 4. 创建索引 database.execSQL(CREATE INDEX IF NOT EXISTS index_contacts_user_id ON contacts (user_id)) } }这段代码有几个关键点第一创建新表时的SQL必须和Room生成的完全一致包括字段顺序、类型、约束、外键。第二拷贝数据时要注意字段映射关系别搞错了列。第三删除旧表之前一定要确保数据已经完整拷贝否则就是不可逆的数据丢失。3.3 AutoMigration让Room帮你写迁移代码从Room 2.4.0开始官方提供了AutoMigration功能。你只需要在Database注解中声明autoMigrationsRoom就会在编译期自动生成Migration代码。Database( entities [User::class], version 2, exportSchema true, autoMigrations [ AutoMigration(from 1, to 2) ] ) abstract class AppDatabase : RoomDatabase()AutoMigration能处理大部分常见场景添加字段、删除字段、创建索引、删除索引、重命名表、重命名字段。但它也有局限性它无法处理需要数据转换的场景比如把String类型的日期转成Long时间戳或者拆表合表。对于AutoMigration无法处理的场景你可以提供一个AutoMigrationSpec来补充RenameColumn(tableName users, fromColumnName username, toColumnName name) static class MyAutoMigrationSpec : AutoMigrationSpec然后在Database中引用autoMigrations [ AutoMigration(from 1, to 2, spec MyAutoMigrationSpec::class) ]我的建议是能用AutoMigration就用AutoMigration但一定要检查生成的Schema JSON和迁移测试结果。AutoMigration虽然方便但它生成的SQL不一定是最优的而且在复杂场景下可能生成错误的迁移逻辑。4. 迁移测试上线前的最后一道防线4.1 为什么必须写迁移测试我见过太多团队Migration写完就直接上线结果线上崩溃率飙升。原因很简单Migration的代码路径在开发阶段几乎不会被触发。你本地开发时数据库版本永远是最新的除非你手动降级或者用旧版本App覆盖安装否则根本走不到Migration逻辑。而线上用户的情况千奇百怪有人从版本1直接升到版本5有人从版本3升到版本4有人卸载重装有人清除了数据。每一种路径都可能触发不同的Migration组合。如果不写测试你根本不知道这些组合能不能正常工作。Room官方提供了一个room-testing库专门用来做迁移测试。它的原理是用旧版本的Schema创建一个数据库插入一些测试数据然后执行Migration最后校验新数据库的结构和数据是否符合预期。4.2 用MigrationTestHelper搭建测试用例首先添加依赖androidTestImplementation androidx.room:room-testing:2.6.1然后编写测试RunWith(AndroidJUnit4::class) class MigrationTest { private val TEST_DB migration-test get:Rule val helper: MigrationTestHelper MigrationTestHelper( InstrumentationRegistry.getInstrumentation(), AppDatabase::class.java.canonicalName, FrameworkSQLiteOpenHelperFactory() ) Test fun migrate1To2() { // 1. 用版本1的Schema创建数据库 helper.createDatabase(TEST_DB, 1).apply { execSQL(INSERT INTO users (name) VALUES (张三)) execSQL(INSERT INTO users (name) VALUES (李四)) close() } // 2. 执行迁移到版本2 val db helper.runMigrationsAndValidate(TEST_DB, 2, true, MIGRATION_1_2) // 3. 校验数据 val cursor db.query(SELECT * FROM users) assertEquals(2, cursor.count) cursor.moveToFirst() assertEquals(张三, cursor.getString(cursor.getColumnIndex(name))) assertEquals(, cursor.getString(cursor.getColumnIndex(email))) cursor.close() } }runMigrationsAndValidate这个方法非常关键。它做了三件事执行Migration、校验新数据库的Schema是否和Schema JSON一致、返回可查询的数据库对象。如果Schema校验失败测试会直接报错告诉你哪里不一致。4.3 多版本跳跃迁移的测试策略实际项目中用户可能从任意一个历史版本升级到最新版本。你需要测试所有可能的迁移路径。比如当前最新版本是4历史版本有1、2、3那么需要测试的路径包括1-4、2-4、3-4。Room的MigrationTestHelper支持传入多个MigrationTest fun migrate1To4() { helper.createDatabase(TEST_DB, 1).apply { execSQL(INSERT INTO users (name) VALUES (王五)) close() } val db helper.runMigrationsAndValidate( TEST_DB, 4, true, MIGRATION_1_2, MIGRATION_2_3, MIGRATION_3_4 ) // 校验数据... }这里有个经验不要只测试相邻版本的迁移一定要测试跨版本迁移。因为跨版本迁移会依次执行多个Migration中间任何一步出问题都会导致最终失败。而且跨版本迁移时数据会经过多次转换更容易出现数据丢失或类型不匹配的问题。5. 线上环境迁移失败的排查链路5.1 从崩溃日志定位问题线上Migration失败时崩溃日志通常长这样java.lang.IllegalStateException: Room cannot verify the data integrity. Looks like youve changed schema but forgot to update the version number. You can simply fix this by increasing the version number. Expected: TableInfo{nameusers, columns{idColumn{nameid, typeINTEGER, affinity3, notNulltrue, primaryKeyPosition1}, nameColumn{namename, typeTEXT, affinity2, notNulltrue, primaryKeyPosition0}}, foreignKeys[], indices[]} Found: TableInfo{nameusers, columns{idColumn{nameid, typeINTEGER, affinity3, notNulltrue, primaryKeyPosition1}, nameColumn{namename, typeTEXT, affinity2, notNulltrue, primaryKeyPosition0}, emailColumn{nameemail, typeTEXT, affinity2, notNulltrue, primaryKeyPosition0}}, foreignKeys[], indices[]}这段日志的关键信息在Expected和Found两个部分。Expected是Room期望的Schema来自Schema JSONFound是设备上数据库的实际Schema。对比两者你就能发现差异Found中多了一个email字段说明Migration执行了添加字段的操作但Schema JSON中没有这个字段说明你忘记升级版本号或者忘记重新编译导出Schema。常见的崩溃原因和排查方向崩溃信息关键词可能原因排查方向cannot verify the data integritySchema不一致对比Expected和Found的差异A migration from X to Y was required but not found缺少Migration检查addMigrations是否注册了对应版本no such table表未创建检查Migration中是否创建了新表no such column字段未添加检查ALTER TABLE语句UNIQUE constraint failed唯一约束冲突检查数据是否有重复值FOREIGN KEY constraint failed外键约束冲突检查关联数据是否存在5.2 用Schema JSON做差异比对当崩溃日志不够清晰时最有效的排查方式是直接比对Schema JSON文件。假设你从版本2升到版本3失败了你可以打开app/schemas/com.example.AppDatabase/2.json和3.json逐字段对比。我通常会关注这几个地方表名是否一致、字段名是否一致、字段类型是否一致、notNull约束是否一致、默认值是否一致、索引是否一致、外键是否一致。任何一处不一致都会导致校验失败。有个小技巧你可以用diff命令或者IDE的对比工具来快速找出两个JSON文件的差异。如果差异很多说明你的Entity改动很大需要仔细检查每一处。5.3 降级与异常兜底方案即使做了充分的测试线上仍然可能出现意料之外的迁移失败。这时候你需要一个兜底方案。最常见的做法是捕获迁移异常降级到 destructive migration。Room.databaseBuilder(context, AppDatabase::class.java, app_database) .addMigrations(MIGRATION_1_2, MIGRATION_2_3) .fallbackToDestructiveMigrationOnDowngrade() .build()但fallbackToDestructiveMigration会丢失所有数据只适合那些本地数据不重要、可以从服务器重新拉取的场景。如果本地数据很重要你需要更精细的兜底策略比如在迁移失败时把旧数据库文件备份到另一个路径然后创建一个新数据库再尝试从备份中恢复数据。还有一种做法是在Application启动时先检查数据库版本如果发现异常提前处理。比如try { val db Room.databaseBuilder(...).build() db.openHelper.writableDatabase } catch (e: IllegalStateException) { // 迁移失败执行兜底逻辑 handleMigrationFailure() }6. 那些年我踩过的Room升级坑6.1 忘记导出Schema导致的连锁反应早期做项目时我觉得exportSchema没什么用就设成了false。结果有一次线上迁移失败我想排查问题发现根本没有Schema JSON文件可以对比。只能靠猜效率极低。后来我把所有项目的exportSchema都改成了true并且把app/schemas/目录提交到了Git。这里有个细节如果你用的是KSP而不是KAPTSchema的导出路径可能需要在build.gradle中额外配置ksp { arg(room.schemaLocation, $projectDir/schemas) }另外Schema JSON文件必须纳入版本控制。因为迁移测试需要用到历史版本的Schema文件如果你不提交CI上跑测试时会找不到旧版本的Schema测试直接失败。6.2 字段默认值与Entity声明不一致这个问题非常隐蔽。假设你在Entity中声明了一个字段ColumnInfo(defaultValue 0) val age: Int 0然后在Migration中写database.execSQL(ALTER TABLE users ADD COLUMN age INTEGER NOT NULL DEFAULT 1)注意Entity中声明的默认值是0但Migration中写的默认值是1。这两个不一致Schema校验会失败。而且报错信息不会直接告诉你默认值不一致只会说Schema不匹配你需要自己去对比JSON文件才能发现。所以我的经验是Migration中的SQL语句最好直接从Schema JSON文件中复制createSql然后稍作修改。这样能最大程度保证一致性。6.3 主键自增与数据拷贝的冲突在做拆表迁移时我遇到过一个问题新表的主键是AUTOINCREMENT的我从旧表拷贝数据时手动指定了id值。结果新表的sqlite_sequence没有更新后续插入数据时自增ID从1开始导致主键冲突。解决方案是在拷贝数据后手动更新sqlite_sequenceUPDATE sqlite_sequence SET seq (SELECT MAX(id) FROM contacts) WHERE name contacts或者更简单的做法拷贝数据时不指定id让SQLite自动生成。但这样会丢失旧表中的ID关联关系需要根据实际情况权衡。6.4 多模块项目中的Schema路径冲突在组件化项目中数据库可能被多个模块引用。如果每个模块都配置了room.schemaLocation可能会出现Schema文件路径冲突或者覆盖的问题。我的做法是只在app模块中配置Schema导出路径其他模块通过api依赖传递Room的注解处理器。同时确保所有模块使用的Room版本一致避免因为版本差异导致Schema格式不兼容。6.5 迁移耗时过长导致的ANR当数据库数据量很大时Migration可能会执行很长时间。如果Migration在主线程执行直接ANR。Room默认的databaseBuilder是在主线程构建的但实际的数据库操作是在子线程执行的。不过Migration本身是在打开数据库时执行的如果你在Application的onCreate中直接访问数据库Migration就会在主线程执行。解决方案是不要在Application启动时同步访问数据库。把数据库的初始化放到子线程或者使用RoomDatabase.Builder的setQueryExecutor和setTransactionExecutor来指定执行器。Room.databaseBuilder(context, AppDatabase::class.java, app_database) .setQueryExecutor(Executors.newFixedThreadPool(4)) .setTransactionExecutor(Executors.newSingleThreadExecutor()) .build()另外对于大数据量的迁移可以考虑分批处理。比如每次只迁移1000条数据迁移完一批就更新一次版本号避免一次性迁移太多导致超时。7. 面向未来的Room升级策略7.1 建立Schema变更的规范流程经过多个项目的迭代我总结了一套Schema变更的规范流程团队里每个人都必须遵守修改Entity之前先确认当前数据库版本号。修改Entity之后立即升级版本号并编写对应的Migration。编译项目检查生成的Schema JSON文件确认identityHash已更新。编写迁移测试覆盖相邻版本和跨版本迁移。在CI上运行迁移测试确保所有历史版本的迁移路径都能通过。Code Review时重点检查Migration的SQL语句和Schema JSON的差异。这套流程看起来繁琐但能避免90%以上的迁移问题。尤其是第3步和第4步很多团队会忽略结果上线后才发现问题。7.2 用CI自动化迁移测试手动跑迁移测试容易遗漏最好把它集成到CI流程中。在build.gradle中配置android { testOptions { unitTests { includeAndroidResources true } } }然后在CI脚本中添加./gradlew connectedAndroidTest这样每次提交代码时CI会自动运行所有迁移测试。如果某个迁移路径失败了CI会直接报错阻止合并。对于没有条件跑仪器化测试的团队可以考虑用Robolectric来跑迁移测试。Room的MigrationTestHelper也支持Robolectric虽然不如真机测试准确但能覆盖大部分场景。7.3 数据库版本管理的长期维护建议随着App迭代数据库版本会越来越多Migration文件也会越积越多。如果不加以管理最终会变成一团乱麻。我的建议是第一为每个Migration写注释说明这个版本做了什么变更、为什么做这个变更。比如// 版本2 - 3新增用户头像字段用于支持个性化推荐 val MIGRATION_2_3 object : Migration(2, 3) { ... }第二定期整理Migration文件把相关的Migration放在同一个文件中按版本号排序。不要把所有Migration都堆在一个文件里。第三考虑使用Room的AutoMigration来减少手动代码。对于简单的加字段、加索引AutoMigration完全够用。只有复杂的数据转换才需要手动写Migration。第四保留所有历史版本的Schema JSON文件。这些文件是迁移测试的基础也是排查线上问题的关键依据。不要因为文件多就删除它们。第五在数据库版本达到一定数量后考虑做一次基线合并。比如当前最新版本是10你可以把版本1到10的Migration合并成一个从1直接到10的Migration减少迁移路径的复杂度。但这样做的前提是你确定没有用户还在使用版本1到9的App。