Android结合ViewPager2和Paging3按条件生成分页日期列表问题

1. 版本行为差异的根源 #

Paging 3从alpha测试版到正式稳定版，修改了两个核心的默认逻辑，直接导致你遇到的索引异常：

• alpha09版本中，未显式指定Pager的initialKey参数时，会直接使用PagingSource中params.key ?: 0作为唯一的初始加载页，加载完成后直接将该页作为ViewPager2的起始展示页，和你的预期逻辑对齐。
• 3.0.1稳定版调整了初始加载策略：
  1. 默认initialLoadSize（初始加载的总数据量）从和pageSize一致改为3 * pageSize，会一次性加载当前页、前后各一页的内容；
  2. 开启占位符（你代码中enablePlaceholders = true）时，Paging会默认将加载到的最早内容页对齐到ViewPager2的滚动起始位置，因此你设置初始key为0时，Paging加载了page=-1、0、1三页内容后，把最早的page=-1（对应初始日期前5天）作为第一页展示，原本预期的page0就被推到了第二页的位置。

你将默认key改为1后恢复正常的原因是：此时初始加载page=0、1、2三页内容，page0刚好对应你要的初始日期页，被对齐到ViewPager2的第一页位置，刚好符合你的预期。

2. 分页索引的规范写法 #

不存在0或1作为初始索引的统一规范，索引规则完全取决于你业务侧的分页逻辑定义。更稳妥的写法是不要依赖params.key ?: xx的 fallback 逻辑，而是在构造Pager时显式传入initialKey参数，明确指定初始加载的分页key：

Pager(
    config = PagingConfig(
        pageSize = 5,
        enablePlaceholders = true
    ),
    initialKey = 0, // 显式指定初始加载key为0，和你的DataSource逻辑对齐
    pagingSourceFactory = {
        ViewPagerPagingSource(dataSource)
    }
).flow

这样无论Paging版本的默认逻辑怎么调整，都不会出现初始页错位的问题。

另外你可以优化ViewPagerDataSource的getStartDate方法，去掉冗余的分支判断：

private fun getStartDate(pageNumber: Int): Date {
    return Calendar.getInstance().let {
        it.time = initialDate
        it.add(Calendar.DATE, pageNumber * pageSize)
        it.time
    }
}

pageNumber为0时偏移量为0，会直接返回初始日期，和原有逻辑完全一致。

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