关于android:RecyclerView预加载

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

监听列表滚动状态
第一个想到的计划是监听列表滚动状态，当列表快滚动到底部时执行预加载，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 = {// 预加载业务逻辑}
}

这个计划有如下长处：

不须要关怀列表滑动的快慢，因为所有表项都会经验 onBindViewHolder()，索引值和预加载阈值就能够用 == 做判断。
不要放心用户在列表底部屡次上拉导致回调屡次预加载，因为这种状况下 onBindViewHolder()不会执行屡次。当 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 只单纯地提供预加载机会，它就不须要关怀业务层加载何时完结。

您的点赞珍藏就是对我最大的激励！
欢送关注我，分享 Android 干货，交换 Android 技术。
对文章有何见解，或者有何技术问题，欢送在评论区一起留言探讨！

文末