自定义DataSource的Paging Library在Room更新后无法自动刷新列表行

我完全理解你的痛点——自定义DataSource时没法像DAO自动生成的那样联动Room变更，手动调用invalidate()又要处理多列表的重复操作，而ViewHolder绑定LiveData的方案确实存在不少隐患。下面给你推荐两种更简洁高效的解决方案，从数据源层面解决问题：

方案一：利用Room的InvalidationTracker直接监听表变更 #

这是最底层、最高效的方式，直接绑定Room的数据库变更通知，不需要依赖LiveData，逻辑也更简洁：

实现步骤 #

1. 在自定义PageKeyedDataSource中，通过Room数据库实例获取InvalidationTracker，注册一个监听目标表的观察者；
2. 当表数据发生插入/更新/删除时，自动触发invalidate()，让Paging库重新加载数据；
3. 在DataSource失效时移除观察者，避免内存泄漏。

代码示例 #

class CustomPageKeyedDataSource(
    private val yourDatabase: YourDatabase,
    private val repository: YourRepository
) : PageKeyedDataSource<Int, YourEntity>() {

    // 监听目标数据表的变更
    private val tableObserver = object : InvalidationTracker.Observer("your_table_name") {
        override fun onInvalidated(tables: MutableSet<String>) {
            // 表数据变更时，触发DataSource失效，Paging自动刷新列表
            invalidate()
        }
    }

    init {
        // 注册观察者
        yourDatabase.invalidationTracker.addObserver(tableObserver)
    }

    override fun onInvalidated() {
        super.onInvalidated()
        // 失效时移除观察者，防止内存泄漏
        yourDatabase.invalidationTracker.removeObserver(tableObserver)
    }

    // 实现你的loadInitial、loadBefore、loadAfter逻辑
    override fun loadInitial(
        params: LoadInitialParams<Int>,
        callback: LoadInitialCallback<Int, YourEntity>
    ) {
        // 从网络拉取数据插入Room，再从Room读取返回的逻辑不变
    }

    override fun loadBefore(
        params: LoadParams<Int>,
        callback: LoadCallback<Int, YourEntity>
    ) {
        // 你的分页逻辑
    }

    override fun loadAfter(
        params: LoadParams<Int>,
        callback: LoadCallback<Int, YourEntity>
    ) {
        // 你的分页逻辑
    }
}

方案二：通过LiveData监听Room列表变更 #

如果你已经在Repository中通过LiveData暴露了Room的查询结果，也可以直接复用这个LiveData来触发DataSource失效：

实现步骤 #

1. 在DAO中定义返回LiveData<List<YourEntity>>的查询方法；
2. 在Repository中暴露这个LiveData；
3. 在自定义DataSource中观察该LiveData，数据变更时调用invalidate()；
4. 同样要在DataSource失效时移除观察者。

代码示例 #

// DAO层
@Dao
interface YourDao {
    @Query("SELECT * FROM your_table_name")
    fun observeAllItems(): LiveData<List<YourEntity>>
}

// Repository层
class YourRepository(private val yourDao: YourDao) {
    fun observeItemsChange(): LiveData<List<YourEntity>> = yourDao.observeAllItems()
    // 其他网络拉取、插入Room的方法不变
}

// 自定义DataSource
class CustomPageKeyedDataSource(
    private val repository: YourRepository,
    private val lifecycleOwner: LifecycleOwner? = null
) : PageKeyedDataSource<Int, YourEntity>() {

    private var dataObserver: Observer<List<YourEntity>>? = null

    init {
        setupDataChangeListener()
    }

    private fun setupDataChangeListener() {
        dataObserver = Observer {
            invalidate()
        }
        // 有LifecycleOwner时用绑定生命周期的观察，否则用observeForever
        lifecycleOwner?.let {
            repository.observeItemsChange().observe(it, dataObserver!!)
        } ?: run {
            repository.observeItemsChange().observeForever(dataObserver!!)
        }
    }

    override fun onInvalidated() {
        super.onInvalidated()
        // 移除观察者
        dataObserver?.let { observer ->
            lifecycleOwner?.let {
                repository.observeItemsChange().removeObserver(observer)
            } ?: run {
                repository.observeItemsChange().removeObserver(observer)
            }
        }
        dataObserver = null
    }

    // 实现分页加载逻辑...
}

为什么这两个方案比ViewHolder绑定LiveData更好？ #

• 资源开销低：每个DataSource只需要一个观察者，而不是每行一个，避免大量观察者带来的内存和计算负担；
• 多列表自动同步：只要用了同一个DataSource的列表，都会在数据变更时自动刷新，不需要分别调用invalidate()；
• 无无效通知：Paging库会自动管理列表的加载范围，失效后只会重新加载当前可见的页面，不会给不可见的行发送无用通知。

推荐优先选择方案一，因为它直接和Room的底层变更机制绑定，不需要依赖LiveData的生命周期处理，性能更优，逻辑也更简洁。

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