换一个思路,超简单的RecyclerView预加载

14,847 阅读5分钟

列表的内容是由服务器返回的分页数据,每次浏览到当前页的尾部,都会拉取下一页的数据。这中断用户的浏览,不免产生等待。产品希望让这个过程无感知。一种实现方案是预加载,即在一页数据还未看完时就请求下一页数据,让用户感觉列表的内容是无穷的。

监听列表滚动状态

第一个想到的方案是监听列表滚动状态,当列表快滚动到底部时执行预加载,RecyclerView.OnScrollListener提供了两个回调:

public class RecyclerView {
    public abstract static class OnScrollListener {
        public void onScrollStateChanged(@NonNull RecyclerView recyclerView, int newState){}
        public void onScrolled(@NonNull RecyclerView recyclerView, int dx, int dy){}
    }
}

onScrolled()可以拿到LayoutManager,它提供了很多和表项位置有关的方法:

// 为 RecyclerView 新增扩展方法,用于监听预加载事件
fun RecyclerView.addOnPreloadListener(preloadCount: Int, onPreload: () -> Unit) {
    // 监听 RecyclerView 滚动状态
    addOnScrollListener(object : RecyclerView.OnScrollListener() {
        override fun onScrolled(recyclerView: RecyclerView, dx: Int, dy: Int) {
            super.onScrolled(recyclerView, dx, dy)
            // 获取 LayoutManger 
            val layoutManager = recyclerView.layoutManager
            // 如果 LayoutManager 是 LinearLayoutManager
            if (layoutManager is LinearLayoutManager) {
            	// 如果列表正在往上滚动,并且表项最后可见表项索引值 等于 预加载阈值
                if (dy > 0 && layoutManager.findLastVisibleItemPosition() == layoutManager.itemCount - 1 - preloadCount) {
                    onPreload()
                }
            }
        }
    })
}

当列表滚动时,实时检测列表中最后一个可见表项索引 和 预加载阈值 是否相等,若相等则表示列表快滚动到底部了,则触发预加载回调。 然后就可以像这样实现预加载:

recyclerView.addOnPreloadListener(3) {// 当距离列表底部还有 3 个表项时执行预加载
    // 预加载业务逻辑
}

一运行 Demo 就测出 bug:当快速滚动列表时onPreload()没有执行,当慢慢滚动列表时onPrelaod()会执行多次。

原因是RecyclerView并不保证每个表项出现时onScrolled()都会被调用,若滚动非常快,某个表项错过该回调是有可能发生的。

为了避免错过,只能放宽条件:

if (dy > 0 && layoutManager.findLastVisibleItemPosition() >= layoutManager.itemCount - 1 - preloadCount) {
    onPreload()
}

==改成>=,条件是放宽了,但多次调用的问题更加严重了。在正常滑动过程中,这个方案无法做到精准匹配预加载阈值,即无法实现只回调一次onPreload(),因为onScroll()是像素粒度的回调,而预加载要做的表项粒度的检测。

这个方案还有一个缺点:和LayoutManager类型耦合。代码中使用了if (layoutManager is LinearLayoutManager)这样的判断,如果要适配StaggeredGridLayoutManager则必须新增else分支,如果又多了一个自定义LayoutManager呢?

类型无关预加载

判断是否预加载的关键是获取表项索引,刚才通过layoutManager.findLastVisibleItemPosition()获取,其实饶了一大圈。

列表在被显示之前必然经历了onBindViewHolder(holder: ViewHolder, position: Int),该方法中就能轻松的获取表项索引,可以把刚才的判断逻辑移到RecyclerView.Adapter中:

class PreloadAdapter: RecyclerView.Adapter<ViewHolder>() {
    // 预加载回调
    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 = {
       // 预加载业务逻辑
    }
}

这个方案有如下优点:

  1. 不需要关心列表滑动的快慢,因为所有表项都会经历onBindViewHolder(),索引值和预加载阈值就可以用==做判断。

  2. 不要担心用户在列表底部多次上拉导致回调多次预加载,因为这种情况下onBindViewHolder()不会执行多次。

  3. RecyclerView更换LayoutManager时,也不需要修改代码。

唯一需要担心的是,列表滚动到底部触发了一次预加载后,又往回滚动(阈值位表项滚出屏幕),假设预加载迟迟没有完成,此时再次滚动到底部,移出屏幕的阈值位表项需要重新执行onBindViewHolder(),会再触发一次预加载。

当然可以通过增加标记位解决这个问题:

class VarietyAdapter: RecyclerView.Adapter<ViewHolder>() {
    // 增加预加载状态标记位
    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 系列文章目录如下:

  1. RecyclerView 缓存机制 | 如何复用表项?

  2. RecyclerView 缓存机制 | 回收些什么?

  3. RecyclerView 缓存机制 | 回收到哪去?

  4. RecyclerView缓存机制 | scrap view 的生命周期

  5. 读源码长知识 | 更好的RecyclerView点击监听器

  6. 代理模式应用 | 每当为 RecyclerView 新增类型时就很抓狂

  7. 更好的 RecyclerView 表项子控件点击监听器

  8. 更高效地刷新 RecyclerView | DiffUtil二次封装

  9. 换一个思路,超简单的RecyclerView预加载

  10. RecyclerView 动画原理 | 换个姿势看源码(pre-layout)

  11. RecyclerView 动画原理 | pre-layout,post-layout 与 scrap 缓存的关系

  12. RecyclerView 动画原理 | 如何存储并应用动画属性值?

  13. RecyclerView 面试题 | 列表滚动时,表项是如何被填充或回收的?

  14. RecyclerView 面试题 | 哪些情况下表项会被回收到缓存池?

  15. RecyclerView 性能优化 | 把加载表项耗时减半 (一)

  16. RecyclerView 性能优化 | 把加载表项耗时减半 (二)

  17. RecyclerView 性能优化 | 把加载表项耗时减半 (三)

  18. RecyclerView 的滚动是怎么实现的?(一)| 解锁阅读源码新姿势

  19. RecyclerView 的滚动时怎么实现的?(二)| Fling

  20. RecyclerView 刷新列表数据的 notifyDataSetChanged() 为什么是昂贵的?