NestedScrollView嵌套RecyclerView加载新项滑动卡顿延迟如何解决

卡顿的本质不是滑动嵌套属性配置错误，而是你将高度设为match_parent的RecyclerView放入垂直滚动的NestedScrollView后，RecyclerView自带的视图回收复用机制会完全失效。每次追加新项时，RecyclerView会强制测量、布局所有子项（包括屏幕外未展示的全部条目），数据量越大、新增条目越多，主线程测量耗时越长，就会出现数秒的滑动卡顿、响应延迟。
你之前尝试设置nestedScrolling=false、配置blocksDescendants都没有触及核心问题，这两个配置只能解决滑动冲突、焦点抢占问题，完全解决不了全量布局带来的性能损耗。另外你当前XML里给RecyclerView写的layout_constraintXxx系列约束属性是无效的——它的父布局是LinearLayout，约束属性会被系统直接忽略。

你要实现的滑动到底部展示ProgressBar的加载更多功能，完全不需要嵌套NestedScrollView，RecyclerView原生就支持通过滚动监听+多类型Item实现该效果，不会破坏回收复用机制，滑动流畅度和你单独使用RecyclerView时完全一致：

• 删掉外层的NestedScrollView和包裹用的LinearLayout，直接将RecyclerView作为页面的根布局，不要把ProgressBar放在RecyclerView外部。
• 将底部加载用的ProgressBar做成RecyclerView的最后一个Item类型，和你现有的多类型视图逻辑统一管理：加载中时展示该底部Item，加载完成后隐藏，加载失败时还可以替换成重试提示布局。
• 给RecyclerView添加滚动监听，判断滑动位置触发加载逻辑，参考代码如下：

// 标记当前是否处于加载更多状态，避免重复触发
var isLoading = false

recyclerView.addOnScrollListener(object : RecyclerView.OnScrollListener() {
    override fun onScrolled(recyclerView: RecyclerView, dx: Int, dy: Int) {
        super.onScrolled(recyclerView, dx, dy)
        // 仅向下滑动时做触底判断
        if (dy <= 0) return
        val layoutManager = recyclerView.layoutManager as LinearLayoutManager
        val lastVisiblePos = layoutManager.findLastVisibleItemPosition()
        val totalCount = layoutManager.itemCount
        // 距离最后一个Item还差2个位置、且当前不在加载状态时触发加载
        if (lastVisiblePos >= totalCount - 2 && !isLoading) {
            isLoading = true
            // 通知适配器展示底部加载ProgressBar
            adapter.showLoadMoreFooter()
            // 执行下一页数据请求逻辑
            requestNextPageData()
        }
    }
})

如果你一定要保留NestedScrollView嵌套结构，只能做以下调整缓解卡顿，但数据量大时依然会有性能问题，本质上没有解决回收失效的问题：

• 将RecyclerView的高度从match_parent改为wrap_content
• 删除LinearLayout上冗余的focusable、focusableInTouchMode、descendantFocusability属性，这些配置和滑动性能无关
• 删除RecyclerView上无效的layout_constraintXxx系列属性

内容的提问来源于stack exchange，提问作者Shivam Kumar