使用 Room 引用复杂数据

Room 可以转换基元类型和盒装类型，但不允许在实体之间进行对象引用。了解如何使用类型转换器，以及 Room 为何不支持对象引用。

使用类型转换器

有时，您需要应用将自定义数据类型存储在单个数据库列中。您可以通过提供类型转换器来支持自定义类型。这些函数用于告知 Room 如何将自定义类型与 Room 可以保留的已知类型相互转换。您可以使用 @ColumnTypeConverter 注解来识别类型转换器。

假设您需要在 Room 数据库中保留 Date 的实例。Room 无法原生保留 Date 对象，因此您需要定义类型转换器：

object Converters {
    @ColumnTypeConverter
    fun fromTimestamp(value: Long?): Date? {
        return value?.let { Date(it) }
    }

    @ColumnTypeConverter
    fun dateToTimestamp(date: Date?): Long? {
        return date?.time
    }
}

此示例定义了两个类型转换器函数：一个用于将 Date 对象转换为 Long 对象，另一个用于将 Long 对象转换回 Date 对象。由于 Room 可以保留 Long 对象，因此可以使用这些转换器保留 Date 对象。

接下来，您将 @ColumnTypeConverters 注解添加到 AppDatabase 类，以便 Room 可以使用您已定义的转换器类：

@Database(entities = [User::class], version = 1)
@ColumnTypeConverters(Converters::class)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

定义这些类型转换器后，您就可以在实体和 DAO 中使用自定义类型，就像使用基元类型一样：

@Entity
data class User(
    @PrimaryKey val id: Long,
    val name: String,
    val birthday: Date?
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user WHERE birthday = :targetDate")
    suspend fun findUsersBornOnDate(targetDate: Date): List<User>
}

由于您在本示例中为 AppDatabase 添加了 @ColumnTypeConverters 注解，因此 Room 可以在所有位置使用定义的类型转换器。如需将类型转换器的范围限定为特定的实体或 DAO，请使用 @ColumnTypeConverters 为您的 @Entity 或 @Dao 类添加注解。

控件类型转换器初始化

通常，Room 会为您实例化类型转换器。不过，如果您需要将其他依赖项传递给类型转换器类，则应用必须直接控制它们的初始化。在这种情况下，您可以为转换器类添加 @ProvidedColumnTypeConverter 注解：

@ProvidedColumnTypeConverter
class ExampleConverter {
    @ColumnTypeConverter
    fun stringToExample(string: String?): ExampleType? {
        return string?.let { ExampleType() }
    }

    @ColumnTypeConverter
    fun exampleToString(example: ExampleType?): String? {
        return example?.toString()
    }
}

除了在 @ColumnTypeConverters 中声明转换器类之外，您还可以使用 RoomDatabase.Builder.addColumnTypeConverter 函数将转换器类的实例传递给 RoomDatabase 构建器：

val db = Room.databaseBuilder<MyDatabase>(applicationContext, "database-name")
    .addColumnTypeConverter(exampleConverterInstance)
    .build()

了解 Room 为何不允许对象引用

要点：Room 不允许在实体类之间进行对象引用。因此，您必须明确请求您的应用所需的数据。

映射从数据库到相应对象模型之间的关系是一种常见做法，非常适合服务器端。即使程序在访问属性时加载属性，服务器仍然可以正常工作。

但在客户端，这种延迟加载是不可行的，因为它通常发生在界面线程上，并且在界面线程上查询磁盘上的信息会导致严重的性能问题。界面线程通常需要大约 16 毫秒来计算和绘制 Activity 的更新后的布局，因此，即使查询只用了 5 毫秒，您的应用仍然可能会用尽剩余的时间来绘制框架，从而导致明显的显示故障。如果有一个并行运行的单独事务，或者设备正在运行其他磁盘密集型任务，则查询可能需要更多时间才能完成。不过，如果您不使用延迟加载，则应用会抓取一些不必要的数据，从而导致内存消耗问题。

对象关系型映射通常将决定权留给开发者，以便他们可以针对自己的应用用例执行最合适的操作。开发者通常会决定在应用和界面之间共享模型。但是，这种解决方案不能很好地扩展，因为界面会不断发生变化，共享模型会出现开发者难以预测和调试的问题。

例如，假设界面加载了 Book 对象的列表，其中每本图书都有一个 Author 对象。您最初可能设计让查询使用延迟加载，从而让 Book 实例检索作者。对 author 属性的第一次检索会查询数据库。一段时间后，您会发现还需要在应用界面中显示作者姓名。您可以访问此名称，如以下代码段所示：

Text(text = book.author.name)

但是，这种看似无害的更改会导致在主线程上查询 Author 表格。

如果您事先查询了作者信息，但不需要这些信息，则很难更改数据的加载方式。例如，如果应用界面不再需要显示 Author 信息，则应用会有效地加载不再显示的数据，从而浪费宝贵的内存空间。如果 Author 类引用其他表格（例如 Books），则应用的效率会进一步下降。

如需使用 Room 同时引用多个实体，请创建一个包含每个实体的数据对象，然后编写用于联接相应表格的查询。这种结构合理的模型与 Room 强大的查询验证功能相结合，可让您的应用在加载数据时消耗较少的资源，从而改善应用的性能和用户体验。