将==
改成>=
,条件是放宽了,但多次调用的问题更加严重了。在正常滑动过程中,这个方案无法做到精准匹配预加载阈值,即无法实现只回调一次onPreload()
,因为onScroll()
是像素粒度的回调,而预加载要做的表项粒度的检测。
这个方案还有一个缺点:和LayoutManager
类型耦合。代码中使用了if (layoutManager is LinearLayoutManager)
这样的判断,如果要适配StaggeredGridLayoutManager
则必须新增else
分支,如果又多了一个自定义LayoutManager
呢?
类型无关预加载
判断是否预加载的关键是获取表项索引,刚才通过layoutManager.findLastVisibleItemPosition()
获取,其实饶了一大圈。
列表在被显示之前必然经历了onBindViewHolder(holder: ViewHolder, position: Int)
,该方法中就能轻松的获取表项索引,可以把刚才的判断逻辑移到RecyclerView.Adapter
中:
class PreloadAdapter: RecyclerView.Adapter() {
// 预加载回调
var onPreload: (() -> Unit)? = null
// 预加载偏移量
var preloadItemCount = 0
// 列表滚动状态
private var scrollState = SCROLL_STATE_IDLE
override fun onBindViewHolder(holder: ViewHolder, position: Int) {
checkPreload(position)
}
override fun onAttachedToRecyclerView(recyclerView: RecyclerView) {
recyclerView.addOnScrollListener(object : RecyclerView.OnScrollListener() {
override fun onScrollStateChanged(recyclerView: RecyclerView, newState: Int) {
// 更新滚动状态
scrollState = newState
super.onScrollStateChanged(recyclerView, newState)
}
})
}
// 判断是否进行预加载
private fun checkPreload(position: Int) {
if (onPreload != null
&& position == max(itemCount - 1 - preloadItemCount, 0)// 索引值等于阈值
&& scrollState != SCROLL_STATE_IDLE // 列表正在滚动
) {
onPreload?.invoke()
}
}
}
然后就可以像这样使用:
val preloadAdapter = PreloadAdapter().apply {
// 在距离列表尾部还有2个表项的时候预加载
preloadItemCount = 2
onPreload = {
// 预加载业务逻辑
}
}
这个方案有如下优点:
-
不需要关心列表滑动的快慢,因为所有表项都会经历
onBindViewHolder()
,索引值和预加载阈值就可以用==
做判断。 -
不要担心用户在列表底部多次上拉导致回调多次预加载,因为这种情况下
onBindViewHolder()
不会执行多次。 -
当
RecyclerView
更换LayoutManager
时,也不需要修改代码。
唯一需要担心的是,列表滚动到底部触发了一次预加载后,又往回滚动(阈值位表项滚出屏幕),假设预加载迟迟没有完成,此时再次滚动到底部,移出屏幕的阈值位表项需要重新执行onBindViewHolder()
,会再触发一次预加载。
当然可以通过增加标记位解决这个问题:
class VarietyAdapter: RecyclerView.Adapter() {
// 增加预加载状态标记位
var isPreloading = false
override fun onBindViewHolder(holder: ViewHolder, position: Int) {
checkPreload(position)
}
// 判断是否进行预加载
private fun checkPreload(position: Int) {
if (onPreload != null
&& position == max(itemCount - 1 - preloadItemCount, 0)// 索引值等于阈值
&& scrollState != SCROLL_STATE_IDLE // 列表正在滚动
&& !isPreloading // 预加载不在进行中
) {
isPreloading = true // 表示正在执行预加载
onPreload?.invoke()
}
}
}
然后在业务层中控制该标记位,列表内容请求成功、失败或者超时时将该标记位置为false
。
但我更倾向于让业务层维护这个标记位,因为若Adapter
只单纯地提供预加载时机,它就不需要关心业务层加载何时结束。
Talk is cheap, show me the code
推荐阅读
RecyclerView 系列文章目录如下:
-
RecyclerView 缓存机制 | 如何复用表项?
-
RecyclerView 缓存机制 | 回收些什么?
-
RecyclerView 缓存机制 |
回收到哪去? -
RecyclerView缓存机制 | scrap view 的生命周期
-
读源码长知识 | 更好的RecyclerView点击监听器
-
代理模式应用 | 每当为 RecyclerView 新增类型时就很抓狂
. 读源码长知识 | 更好的RecyclerView点击监听器 -
代理模式应用 | 每当为 RecyclerView 新增类型时就很抓狂