Android中Paging3为何采用低效的Offset Limit分页而非Keyset分页？

首先要纠正一个误解：Android Paging3 并没有强制使用 Offset Limit 分页，它是一个抽象的分页框架，完全支持 Keyset（键集）分页——甚至可以说，框架的设计就是为了适配各种分页策略。

为什么 Offset Limit 看起来更常见？ #

• 后端兼容性：很多服务端接口一开始就采用 Offset + Limit 的设计，尤其是早期的 RESTful 接口，这种方式实现简单，前端对接成本低，所以很多示例代码会用它来演示 Paging3 的基础用法。
• 场景适配性：对于数据变动频率低、不需要严格保证列表顺序一致性的场景（比如静态内容列表），Offset Limit 足够用，不需要额外维护上一页的最后一个标识。

如何在 Paging3 中实现 Keyset 分页？ #

你只需要自定义 PagingSource（本地数据）或 RemoteMediator（远程数据），在加载逻辑中用上一页最后一条数据的唯一标识（比如 id、时间戳）来替代 Offset。举个简单的例子：

class KeysetPagingSource(private val api: ApiService) : PagingSource<Int, DataItem>() {
    override suspend fun load(params: LoadParams<Int>): LoadResult<Int, DataItem> {
        try {
            // 首次加载用 null，后续用上一页最后一条的 id
            val lastId = params.key ?: 0
            // 调用接口时用 lastId 作为查询条件，而非 offset
            val response = api.fetchItemsAfter(lastId, params.loadSize)
            
            val nextKey = if (response.data.isNotEmpty()) {
                response.data.last().id // 下一页的 key 是当前页最后一条的 id
            } else {
                null // 没有更多数据
            }
            
            return LoadResult.Page(
                data = response.data,
                prevKey = null, // Keyset 分页一般不需要上一页（除非支持双向滑动）
                nextKey = nextKey
            )
        } catch (e: Exception) {
            return LoadResult.Error(e)
        }
    }
}

关于 Paging3 的底层优化 #

Paging3 本身的优化是通用的，和你用哪种分页策略无关：

• 内存缓存：自动缓存已加载的页面，避免重复请求
• 请求去重：防止同一页的重复加载
• 预加载：提前加载下一页数据，提升滑动流畅度
• 状态管理：统一处理加载、错误、空数据等状态

而数据库/接口层面的查询效率，完全取决于你选择的分页策略——Keyset 分页的性能优势（比如避免 Offset 带来的全表扫描），只要你在接口或 SQL 查询中实现了，就能在 Paging3 中享受到。

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