1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

rvList.addOnScrollListener(new RecyclerView.OnScrollListener() {
    @Override
    public void onScrolled(@NonNull RecyclerView recyclerView, int dx, int dy) {
        super.onScrolled(recyclerView, dx, dy);
        // 获取 LayoutManger
        RecyclerView.LayoutManager layoutManager = recyclerView.getLayoutManager();
        // 如果 LayoutManager 是 LinearLayoutManager
        if (layoutManager instanceof GridLayoutManager) {
            GridLayoutManager manager = (GridLayoutManager) layoutManager;
            int nextPreloadCount = 8;
            int previousPreloadCount = 4;
            if (dy > 0
                    && manager.findLastVisibleItemPosition()
                    == layoutManager.getItemCount() - 1 - nextPreloadCount) {
                mViewModel.loadNext();
            } else if (dy > 0 && manager.findFirstVisibleItemPosition() == previousPreloadCount) {
                mViewModel.loadPrevious();
            }
        }
    }
});

通过给列表页的 RecyerView 增加这一段代码，我们就可以很轻松的实现列表的预加载，在有本地本地数据缓存排除网络状态的情况下，和之前通过框架的 loadMore 触发有着显而易见的差别。但于此同时，在查看日志是就很容易发现， onScrolled 方法会在一次滑动中多次重复调用，造成同一个页面加载的多次调用，网络加载下对性能以及数据流量有很大的影响，需要业务逻辑上做去重处理。

接下来我们就使用 Adpater 的 onBindViewHolder 来实现以下预加载：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

public class ListAdapter extends RecyclerView.Adapter<ViewHolder> {

	private int nextPreloadCount = 8;

	private int previousPreloadCount = 4;
	
	private boolean isScroll

	public void onBindViewHolder(@NonNull VH holder, int position,
                @NonNull List<Object> payloads) {
			checkPreload(position);
  }

	public void bindRecyelerView(@NonNull RecyclerView recyclerView ) {
		 if (newState == RecyclerView.SCROLL_STATE_IDLE) {
         isScroll = false;
     } else {
			 	 isScroll = true;
		 }
	}
	
	private void checkPreload(int position) {
		 if (!isScroll){
				return;
		 }
     if (position == previousPreloadCount) {
          mViewModel.loadPrevious();
     } else if (position == getItemCount() - 1 - nextPreloadCount) {
          mViewModel.loadNext();
     }
    }
}

代码整体实现也简单易懂，列表滑动过程中所有的列表项的加载都会经过 Adapter.onBindViewHolder
从而触发预加载检测一致，由于 RecyclerView 的逻辑处理， onBindViewHolder 不会存在单次滑动中被多次调用的情况。且由于 Adpater 的 position 获取是与 layoutManger 无关的，所以也不需要 layoutManger 相关的代码逻辑。但是这个方案也仍然优缺点，那就是当触发预加载的 viewHolder 在列表加载过程中被向上滑出了 RecyclerView 的缓存区域时，再向下滑动到页尾时会再次被绑定导致 onBindViewHolder 触发，从而使得预加载重复触发。

BRVAH 整体对加载的方案采用的是 ConcatAdapter ，加载的头部和尾部通过独立的 adapter 来做逻辑控制，所以两部的代码基本一致，这里我们就拿加载下一页的逻辑来梳理。 contentAdapter 就是实际的列表 adapter ， trailingLoadStateAdapter 则是专门负责列表尾部逻辑处理的 adapter ，可以看到它创建了一个 OnViewAttachStateChangeListener 用来监听 viewHolder 的 onViewAttachedToWindow , 其具体实现是绑定了 Adapter 的 onViewAttachedToWindow ，通过这个契机触发预加载监测机制。具体实现就不在深究了，我们知道它的触发契机和大致实现即可，感兴趣的可以直接去查阅对应的源码，其实际实现也并不复杂。

可以看到 BRVAH 虽然采用了对 Adapter 进行封装处理预加载逻辑，但它并没有采用 Adpater 的 onBindViewHolder 当作触发契机而是采用了 onViewAttachedToWindow 造成这样的差异是什么，我们可以看下这两者的实际差别:

onViewAttachedToWindow 方法在RecyclerView中显示一个ViewHolder时被调用。当RecyclerView需要显示一个新的ViewHolder时，它会调用Adapter的 onCreateViewHolder 方法来创建一个ViewHolder，然后将这个ViewHolder绑定到数据源中对应的数据上，最后调用ViewHolder的 onBindViewHolder 方法将数据显示在ViewHolder的视图上。这时，如果ViewHolder被成功添加到RecyclerView中， onViewAttachedToWindow 方法就会被调用。

因此， onViewAttachedToWindow 方法在ViewHolder显示在RecyclerView上时触发，而** onBindViewHolder 方法则是在RecyclerView需要更新ViewHolder数据时触发。

从我们的业务场景出发—— 预加载的目的是通过滑动来判断用户可能有向下滑动的意图，提前补充列表数据，避免用户等待。业务场景其实并不太依赖当前视图是否真的展示在界面上了，所以这里没有用生命周期更靠前的 onBindViewHolder 而用了更靠后的 onViewAttachedToWindow 从源码角度上来看并没有得到好的解释，去查看仓库也没有相关的提交注释。只能后续看是否能联系上作者询问了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

/** 监听onBindViewHolder事件 */
    var onBindViewHolderListener = object : OnBindViewHolderListener {
        override fun onBindViewHolder(
            rv: RecyclerView,
            adapter: BindingAdapter,
            holder: BindingAdapter.BindingViewHolder,
            position: Int,
        ) {
            if (mEnableLoadMore && !mFooterNoMoreData &&
                rv.scrollState != SCROLL_STATE_IDLE &&
                preloadIndex != -1 &&
                (adapter.itemCount - preloadIndex <= position)
            ) {
                post {
                    if (state == RefreshState.None) {
                        notifyStateChanged(RefreshState.Loading)
                        onLoadMore(this@PageRefreshLayout)
                    }
                }
            }
        }
    }

可以看到与我们编写 onBindViewHolder 的监听逻辑基本如出一辙，通过当前的触发的　bindViewHolder position 来判断是否要触发预加载，而加载的头部和尾部则是基于 SmartRefreshLayout 来的，通过 ViewGruop 单独的 add 添加和 remove 掉。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

/**
     * Processes the hint coming from UI.
     */
    fun processHint(viewportHint: ViewportHint) {
        state.modify(viewportHint as? ViewportHint.Access) { prependHint, appendHint ->
            if (viewportHint.shouldPrioritizeOver(
                    previous = prependHint.value,
                    loadType = PREPEND
                )
            ) {
                prependHint.value = viewportHint
            }
            if (viewportHint.shouldPrioritizeOver(
                    previous = appendHint.value,
                    loadType = APPEND
                )
            ) {
                appendHint.value = viewportHint
            }
        }
    }

prependHint , appendHint 本质也分别是一个 Flow ，当前符合预加载机制后，它们会将 viewportHint 发送到专门用于处理此类数据的 PageFetcherSnapshot 将来转换成一个刷新事件从而融入整个数据加载流程。

Paging3 的预加载机制大致就是如此，更详细的机制由于代码量太多不变深入，如果对 Paging3 不熟悉和感兴趣的可以放下边官方的 CodeLab 做深入了解

选择哪种方案实现列表预加载，需要根据具体的业务需求和性能要求进行综合评估和比较，从而选择最合适的方案来实现列表预加载功能。