[移动开发]Paging3踩坑

记录一下Paging3在使用中遇到的问题
Paging是Google推出的一个应用于Android平台的分页加载库。学习Paging可以参考郭霖的文章郭霖-Jetpack新成员，Paging3从吐槽到真香

1.拉取数据的pageSize与自己设置的不同

object Repository {
	//设置一页加载20条数据
    private const val PAGE_SIZE = 20

    fun getMyCustomerList():Flow<PagingData<MyCustomerVo>>{
        return Pager(
            config = PagingConfig(PAGE_SIZE),
            pagingSourceFactory = { MyCustomerPagingSource()}
        ).flow
    }

class MyCustomerPagingSource():PagingSource<Int,MyCustomerVo>(){
    override suspend fun load(params: LoadParams<Int>): LoadResult<Int, MyCustomerVo> {
        return try {
            val page=params.key?:1
            val pageSize=params.loadSize//读取pageSize
            val paramMap= hashMapOf<String,Any>()
            paramMap["pageIndex"]=page
            paramMap["pageSize"]=pageSize
            val data=ApiManager.getRequestKtHome().get(paramMap).data
            //...
        } catch (e: Exception) {
            LoadResult.Error(e)
        }
    }
}

按我们上文的写法 应该每次拉去20条数据，但是通过抓包发现，参数pageSize为60，与设置不同。顺着load方法可以找到原因

    private fun loadParams(loadType: LoadType, key: Key?) = LoadParams.create(
        loadType = loadType,
        key = key,
        loadSize = if (loadType == REFRESH) config.initialLoadSize else config.pageSize,
        placeholdersEnabled = config.enablePlaceholders,
    )
    
    @JvmField
    @IntRange(from = 1)
    public val initialLoadSize: Int = pageSize * DEFAULT_INITIAL_PAGE_MULTIPLIER
	internal const val DEFAULT_INITIAL_PAGE_MULTIPLIER = 3

在判断为刷新操作时，会默认传给load方法一个三倍于我们定义的pageSize。如果不想要这个逻辑的话，可以在创建PagingConfig的时候主动声明initialLoadSize的值PagingConfig(PAGE_SIZE,initialLoadSize= PAGE_SIZE)

2、不好设置列表Header
PagingDataAdapter虽然提供了withLoadStateHeaderAndFooter和分别设置header与footer的方法，但这里的head并不是我们理解的那种显示汇总信息的item（我也没有搞清楚，但应该是和加载相关的，平时是看不到的）。想要实现我们想要的Header，只能通过别的方法了。我是直接给每个item都通过ViewStub加了Header的布局，然后重写getItemViewType方法

    override fun getItemViewType(position: Int): Int {
        return if (position==0) HEAD else OTHER
    }

在onCreateViewHolder方法中判断viewType 来inflate这个ViewStub，如果不是Header的话 因为viewType不同不会复用布局，所以也不用管他了。

3、筛选列表后再刷新数据时，列表可能不是position=0的状态，而是保持在筛选列表项的位置
（条件是刷新时返回的列表数据中有与筛选列表相同的项），这个可能比较难理解，举个例子吧，完整的列表数据是从1开始累加的数字，屏幕中能显示5个列表项，所以正常情况，刷新完列表后显示的是1、2、3、4、5。
但是如果我们通过某些方法 比如搜索5，这时第一个列表项就会是5。
然后我们刷新，会发现刷新后显示的列表项并不是1、2、3、4、5，而是5、6、7、8、9并且可以向上方滑动。
因为paging3的adapter是实现了Diff的， 如果areItemsTheSame判断之前的第一个item与刷新后的list中有相同的内容，那么就会停留在第一个item的位置。让areItemsTheSame直接返回false的话应该可以解决这个问题。
或者我在adapter.submitData(it)的地方后面判断是否为刷新，如果是的话手动recyclerView延迟滑动到顶部。

            viewModel.getPagingData().collect {
                adapter.submitData(it)
                if (binding.srlContact.isRefreshing){
                    binding.srlContact.isRefreshing=false
                    if (adapter.count>0){
                        binding.rvContact.postDelayed({
                            binding.rvContact.scrollToPosition(0)
                        },500)
                    }
                }
            }

延迟500毫秒是因为submitData里貌似是一个异步的操作，同步滑动是没有用的