标签：表项 onPreload 源码 position 列表 RecyclerView 加载
recyclerView.addOnPreloadListener(3) {// 当距离列表底部还有 3 个表项时执行预加载
// 预加载业务逻辑
}
一运行 Demo 就测出 bug：当快速滚动列表时onPreload()没有执行，当慢慢滚动列表时onPrelaod()会执行多次。
原因是RecyclerView并不保证每个表项出现时onScrolled()都会被调用，若滚动非常快，某个表项错过该回调是有可能发生的。
为了避免错过，只能放宽条件：
if (dy > 0 && layoutManager.findLastVisibleItemPosition() >= layoutManager.itemCount - 1 - preloadCount) {
onPreload()
}
将==改成>=，条件是放宽了，但多次调用的问题更加严重了。在正常滑动过程中，这个方案无法做到精准匹配预加载阈值，即无法实现只回调一次onPreload()。
这个方案还有一个缺点：和LayoutManager类型耦合。代码中使用了if (layoutManager is LinearLayoutManager)这样的判
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享
断，如果要适配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。
标签：表项,onPreload,源码,position,列表,RecyclerView,加载 来源： https://blog.csdn.net/zuihao12366/article/details/122027843
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。