Android Jetpack 之 Paging3的一些踩坑记录

本文链接：https://blog.csdn.net/2401_84912041/article/details/138654879

PagingDataAdapter

比起普通的Adapter要额外提供一个 DiffUtil.ItemCallback 实例用于数据比较更新列表。

坑点一、该怎么做跳页功能

Paging3在构建完Pager完成数据观察后就是内部自身的运作了，根据PagingConfig来自动加载顶部或底部的数据。那么遇到有跳页需求的时候该如何做，在以上的组件中并没有为开发者提供跳往指定page的方法。

查不到api就去源码里看看。在 Pager 类注释中有提到，每个 PagingData 代表支持分页数据的快照，数据刷新时应该提供一个新的 PagingData 实例，其实在各个教程中并没有提到该如何实现跳页功能，通过这段描述就可以想到跳页功能就需要提供一个新的 PagingData 实例。

那么 PagingData 实例是在什么时候提供的，在类 PageFetcher 中有具体的实现

val flow: Flow<PagingData> = channelFlow {

refreshChannel.asFlow()

.onStart {

//…

}

.scan(null) { previousGeneration: PageFetcherSnapshot<Key, Value>?,

triggerRemoteRefresh ->

//…

PageFetcherSnapshot(

initialKey = initialKey,

pagingSource = pagingSource,

config = config,

retryFlow = retryChannel.asFlow(),

triggerRemoteRefresh = triggerRemoteRefresh,

remoteMediatorAccessor = remoteMediatorAccessor,

invalidate = this@PageFetcher::refresh

)

}

.filterNotNull()

.mapLatest { generation ->

PagingData(generation.pageEventFlow, PagerUiReceiver(generation, retryChannel))

}

.collect { send(it) }

}

可以看到在 flow 先是创建了分页快照，最后通过该对象的 pageEventFlow 和一个 PagerUiReceiver 实例来创建了 PagingData 并发送出来供外部使用。此时可以再看 PageFetcherSnapshot 的 pageEventFlow，说实话里面太多协程内容，并看不太懂，但是能清楚 PagingSource 的 load 方法是在里面执行。

综合上面的线索，PagingData 能够通过触发刷新来提供，而刷新通过调用 PagingDataAdapter 的 refresh 方法，然后层层深入，最终通过 PagerUiReceiver 对象的 refresh 方法调用 refreshChannel.offer(true)来触发(又是协程的东西…)。

接下来是页码的处理。在 PageFetcherSnapshot 的 pageEventFlow 中可以发现在触发刷新的时候会通过以下方法构建 LoadParams 并调用 PagingSource 的 load 方法加载数据。

//部分参数就是当初配置PagingConfig的数据，包括key也是构建Pager时传入的initialKey(默认值null)

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,

pageSize = config.pageSize

)

也就是说需要跳页的时候只要触发刷新，然后在 PagingSource 的 load 方法中加载数据的时候使用个人期望的页码，而不是使用通过LoadParams带过来的初始页面的页码即可。

坑点二、在界面不可见后一段时间切回来时会重新加载数据。

这点算不算是坑不知道，但是影响了APP的使用体验(因为监听了加载状态，所以每次切换回来的时候都会出现加载圈)，所以必须排查一下。

首先想到的是不是因为 PageFetcher 的 refresh 方法被调用了。观察调用掉一个是 PagerUiReceiver 对象，专门提供给adapter那边的方法的。遂从 PageFetcherSnapshot 的调用点入手，经过几次调试发现整个刷新行为是因为PageFetcher的flow被重新构建，在继续往外扒最终发现是LiveData搞的鬼。但个人印象中哪怕页面出现切换，LiveData中的数据不发生变化的话也不会出现发送数据的情况。

有一点值得让人注意的是Paging3提供的对象是协程中的flow，最后是通过 asLiveData 方法转到 LiveData对象。

@JvmOverloads

fun Flow.asLiveData(

context: CoroutineContext = EmptyCoroutineContext,

timeoutInMs: Long = DEFAULT_TIMEOUT

): LiveData = liveData(context, timeoutInMs) {

collect {

emit(it)

}

看到了一个很有意思的参数 timeoutInMs，默认值刚好是界面不可见的时间，而后面最终提供了一个CoroutineLiveData对象，此时真相大白。