企业官网建设流程全解析

做Android开发的人，十有八九在ScrollView里套过RecyclerView，然后被滑动冲突折磨过。这个问题的报错不一定有，但表现很明确：要么RecyclerView滚不动，要么ScrollView滚不动，要么两个一起抢事件、页面滑动像抽风。网上搜“嵌套滑动冲突”，帖子无数，方案五花八门，但很多拿下来要么治标不治本，要么引入新的性能坑。这篇文章不打算只给你贴一段代码就完事，我会把事件分发原理、四种可行方案、每种方案的坑和适用场景，全部拆开讲清楚。看完以后你至少知道：为什么冲突、哪个方案适合哪种页面、以及怎么从根上避免踩坑。

1. 滑动冲突的本质：事件分发与嵌套滑动的底层逻辑

1.1 事件分发三步曲：dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent

安卓的触摸事件从诞生那一刻起，就有一个明确的派发规则，理解这条规则是解决一切冲突的前提。事件从Activity往下走，经过PhoneWindow、DecorView，一路传到各个ViewGroup，最后才能到达具体的View。每一层ViewGroup都有两个核心机会参与决策：dispatchTouchEvent负责派发，onInterceptTouchEvent负责决定要不要把事件拦下来自己处理，onTouchEvent则负责最终消费。这三个方法之间的关系，我常用一个“快递派送”的类比讲给团队新人：

快递到了小区门口，先由门卫（ViewGroup.dispatchTouchEvent）决定要不要直接收下。门卫有自己的判断标准（onInterceptTouchEvent），如果他说“这件快递是我要的”，那快递就直接留在门卫这，楼上的住户（子View）永远摸不到。如果门卫不认得这个快递，那快递继续往楼上送，一层一层往下问，直到某一层住户说“这是我的快递”（onTouchEvent返回true），事件才算有了归属。

这个机制里的关键是：一次完整的手势序列，通常从ACTION_DOWN开始，后续的ACTION_MOVE、ACTION_UP都会跟第一个拿到DOWN事件的View绑定。如果ViewGroup在DOWN时不拦截，但在MOVE时突然改变主意拦截了，系统会先给子View发一个ACTION_CANCEL，然后把后续事件全部交给ViewGroup。这就是很多“滑动到一半突然失灵”现象的根源。

1.2 冲突是怎么产生的：ScrollView的拦截判定

ScrollView是一个纵向滚动的FrameLayout，它的滑动依赖事件拦截机制。简单看一下它的onInterceptTouchEvent逻辑就能明白问题。当手指按下并开始移动时，ScrollView会计算当前事件和上次事件在Y轴上的位移差，一旦这个差值超过了一个叫做TouchSlop的阈值——通常由ViewConfiguration.getScaledTouchSlop()给出，大约是8dp左右——它就认为用户是想滚动页面，于是返回true，把事件拦截下来。

关键在于，ScrollView做这个判断时，根本不在乎手指此刻是按在RecyclerView上还是按在普通TextView上。它只关心自己能不能滚动、位移量是否达标。在一个标准布局里，ScrollView的内容高度大于屏幕高度，所以它永远是“可滚动”的，于是手指在RecyclerView上轻轻一划，ScrollView就把事件抢走了。

事件被抢走之后，RecyclerView会收到一个ACTION_CANCEL，随后所有MOVE事件都由ScrollView消费。结果就是：RecyclerView内部的列表内容纹丝不动，整个页面倒是被ScrollView滚来滚去，这和你把手指放在页面空白区域滑动时的效果一模一样。这就是你遇到的第一个冲突表现。

1.3 NestedScrolling：本该协调的机制为什么还会失效

Android 5.0之后引入了NestedScrolling嵌套滑动机制，为的就是解决这种“父View抢事件、子View没机会”的尴尬。RecyclerView是NestedScrollingChild，它会把自己的滚动意图通过startNestedScroll、dispatchNestedPreScroll等方法通知给实现了NestedScrollingParent的父View。理论上，子View和父View可以协商：先让父View滚动，父View滚不动了再让子View滚，反之亦然。

可惜这套机制救不了ScrollView嵌套RecyclerView的经典场景。标准ScrollView虽然实现了NestedScrollingParent接口（API 21起），但它的onInterceptTouchEvent拦截逻辑并没有在嵌套场景下做特殊优化。它照样在位移超过TouchSlop的那一刻直接拦截，连协商的机会都不给。而且事件一旦被拦截，后续的嵌套滑动回调基本都没有意义了。

这也是为什么很多人从ScrollView换成androidx.core.widget.NestedScrollView之后，冲突现象有所缓解。NestedScrollView本身就是针对嵌套滚动场景设计的，它对子View的滚动能力有更多感知，配合RecyclerView的嵌套滑动通知，确实能形成一套相对顺滑的协商流程。但官方组件之间能处理好，不代表业务代码不用管：如果RecyclerView不关闭嵌套滑动，在复杂的页面层级里仍然会出现“滚动不跟手”或者“两个滚动容器来回拉扯”的感觉。这里面的细节，我会在后面的方案实战里详细说。

2. 方案选型：从“能跑”到“彻底”的四种思路

先声明我个人的立场：既然冲突的根源是“两个垂直方向都能滚动的容器叠在一起”，那最彻底的办法就是“别叠在一起”。基于这个立场，我把社区里常见的方案分成四个梯队，按照推荐程度从高到低排下来。

2.1 方案一：单一RecyclerView加多ItemType，架构上消灭冲突

这个方案我放在第一位，因为它是让我感觉最踏实的。做法很直接：把原来ScrollView里的一大坨内容，拆成一个RecyclerView的几个ItemType。比如页面顶部原来是Banner、中间是一组宫格入口、下面是一段普通图文列表，那就把这些内容都塞进同一个RecyclerView，用不同的ViewHolder承载不同视觉区块。

好处是显性的：整个页面只有一个可滚动容器，事件分发路径变得极其干净，压根不存在“两个容器抢事件”的问题。性能也比嵌套方案好得多，RecyclerView的复用机制会在滚动过程中回收不可见Item，内存占用和初始化速度都远优于“一次性渲染所有子View”的嵌套方案。缺点只有一个：你需要把原来的静态内容改造成Adapter的Item，代码结构上会多一些类型判断和ViewHolder类。

这个方案的适用面其实比想象中大。电商首页、新闻详情页、信息流Feed，天然就是多区块组合，用单一RecyclerView管理再合适不过。甚至连“下拉刷新、吸顶标签、加载更多”这些交互，都可以通过多ItemType加监听器的方式在同一个RecyclerView里实现。

2.2 方案二：NestedScrollView加RecyclerView，快速但需控数据量

如果页面结构已经定死，短期内又不想大改，NestedScrollView嵌套RecyclerView是一个能落地的快速方案。核心就两行代码：布局里用NestedScrollView替换ScrollView，代码里给RecyclerView调用setNestedScrollingEnabled(false)。

但我要提醒一句：这个方案的本质是“关闭RecyclerView的嵌套协作能力，让它老老实实接受父容器的高度测量”。这会导致RecyclerView把所有可滚动区域一次性测量并渲染出来，不再复用ViewHolder。列表数据量是几十条、Item又简单，那没问题；一旦是几百上千条、每项还带图片和复杂布局，初次加载就能让你感受到明显的卡顿，极端情况下还会直接OOM。所以这个方案适合“确认数据量不大”的场景，比如商品详情页底部的那几个相关推荐、个人信息页里的几个设置分组。

2.3 方案三：自定义ScrollView，按触摸目标决定是否拦截

有些场景绕不开原生ScrollView，或者项目历史包袱太重。这种时候可以自己写一个ScrollView子类，在onInterceptTouchEvent里判断当前触摸点是否落在RecyclerView区域内，如果是就放行，让RecyclerView自己处理事件。这个方案的思路是“按需分发”，实现起来不复杂，但它有一个天然缺陷：RecyclerView被放行之后，如果它已经滚动到自己内容的边界——比如顶部或者底部——剩下的滑动距离该怎么交给外层ScrollView，这个“交接”逻辑很繁琐，你做不好就会出现“滑到边界后页面愣住不动”的新问题。

所以我通常建议：这个方案只适用于“RecyclerView本身就占了ScrollView里将近全部高度，基本不需要两层协作滚动”的情况，一旦需要两层有来有回地接力，就老老实实回到方案一或者方案二。

2.4 方案四：CoordinatorLayout联动，复杂页面交给Behavior

当页面需求远不止“滚动”这么简单，比如顶部要有一个可折叠的头部，滚动过程中头部逐渐消失、标签吸顶、底部还有个跟手面板，这时候NestedScrollView和自定义ScrollView都撑不住，应该直接上CoordinatorLayout。CoordinatorLayout配合AppBarLayout和RecyclerView提供的AppBarScrollingViewBehavior，可以靠Behavior来协调两个滚动组件的嵌套滑动关系。

这个方案的优势是场景覆盖率极高，很多大型App的首页和详情页就是这套组合撑起来的；代价是理解成本高，Behavior的自定义开发有门槛，布局层级也比普通方案复杂。如果你的页面未来会往“复杂动效、吸顶、折叠”方向演进，早点迁到CoordinatorLayout比等需求来了再重构要省事得多。

2.5 四方案对比：短板和适用边界一目了然

这张表看着简单，但它背后是一个选型逻辑：先看页面复杂度，再看数据量级，最后评估改造成本。如果没有特殊硬性约束，单选或多项RecyclerView的组合永远是我的第一选择顺序。

3. 方案一实战：用多ItemType重构页面，彻底告别嵌套

这一章直接给你一套可以抄走用的核心代码。场景假设是这样的：页面顶部有一块Banner轮播，中间是一排四个入口宫格，下面是一条条普通列表内容。老代码大概率是ScrollView套一层LinearLayout，里面手写Banner、宫格和ListView。我这里把它全部改成单一RecyclerView。

3.1 布局改造：外层只剩一个RecyclerView

新布局非常简单，一个Activity的根布局直接就是一个RecyclerView，下面这段XML就是全部：

<?xml version="1.0" encoding="utf-8"?> <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent"> <androidx.recyclerview.widget.RecyclerView android:id="@+id/main_recycler" android:layout_width="match_parent" android:layout_height="match_parent" android:overScrollMode="never" android:clipToPadding="false" android:paddingTop="0dp" /> </FrameLayout>

注意我给RecyclerView设置了overScrollMode为never，目的是在部分机型上避免滚动到边缘时的蓝色光晕，这个纯属审美习惯，不设也不影响功能。clipToPadding设为false的用途是“允许内容延伸到padding区域”，如果后面要给列表底部留出虚拟导航条间距或者安全区域的空白，这个属性会很关键。

3.2 Adapter核心代码：多个ViewHolder共存

接下来是Adapter的定义。我建议写成静态内部类的形式，每个ViewHolder对应一种ItemType。下面这段代码你可以直接复制到工程里，然后把布局文件换成你自己项目的就行：

public class HomeAdapter extends RecyclerView.Adapter<RecyclerView.ViewHolder> { private static final int TYPE_BANNER = 0; private static final int TYPE_GRID = 1; private static final int TYPE_ITEM = 2; private final List<Object> data = new ArrayList<>(); public HomeAdapter() { data.add(new BannerData()); data.add(new GridData()); // 后面继续添加普通列表数据 data.add(new ItemData("第一条")); data.add(new ItemData("第二条")); } @NonNull @Override public RecyclerView.ViewHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) { LayoutInflater inflater = LayoutInflater.from(parent.getContext()); switch (viewType) { case TYPE_BANNER: return new BannerViewHolder( inflater.inflate(R.layout.item_banner, parent, false)); case TYPE_GRID: return new GridViewHolder( inflater.inflate(R.layout.item_grid, parent, false)); default: return new ItemViewHolder( inflater.inflate(R.layout.item_list, parent, false)); } } @Override public void onBindViewHolder(@NonNull RecyclerView.ViewHolder holder, int position) { Object item = data.get(position); if (holder instanceof BannerViewHolder) { // 绑定Banner数据，比如RecyclerView内部再嵌套一个横向滚动列表 } else if (holder instanceof GridViewHolder) { // 绑定宫格数据 } else if (holder instanceof ItemViewHolder) { ((ItemViewHolder) holder).title.setText(((ItemData) item).title); } } @Override public int getItemViewType(int position) { Object item = data.get(position); if (item instanceof BannerData) { return TYPE_BANNER; } if (item instanceof GridData) { return TYPE_GRID; } return TYPE_ITEM; } @Override public int getItemCount() { return data.size(); } static class BannerViewHolder extends RecyclerView.ViewHolder { BannerViewHolder(@NonNull View itemView) { super(itemView); } } static class GridViewHolder extends RecyclerView.ViewHolder { GridViewHolder(@NonNull View itemView) { super(itemView); } } static class ItemViewHolder extends RecyclerView.ViewHolder { TextView title; ItemViewHolder(@NonNull View itemView) { super(itemView); title = itemView.findViewById(R.id.item_title); } } }

这段代码里有几个容易被忽略的细节。第一个是getItemViewType里我直接用instanceof判断，这个方法简捷，但缺点是每调一次都要遍历判断，数据量大的时候可以改成用position范围判断，比如“position == 0就是Banner，position == 1就是宫格，其余都是列表”，性能更好也更好读。第二个是onCreateViewHolder里每个类型都Inflate自己的布局，这里千万注意parent参数不能传null，否则生成的布局参数会丢失，RecyclerView会按错误尺寸去摆放Item。

3.3 数据绑定的位置陷阱：position不等于列表下标

很多从ListView时代转过来的开发者在RecyclerView里最容易踩的坑，就是把onBindViewHolder里的position当成普通列表的下标直接用。这个习惯在现代RecyclerView里很危险，因为多ItemType的页面里，position是包含所有类型Item的总序号，不是某种子列表的序号。

比如数据源里有两个Banner、五个宫格、三十条列表，你在绑定列表Item时发现position=7，那它对应的其实是宫格里的第五个数据还是列表里的第五条？只有你自己心里清楚。我的建议是：不要在列表里维护一个单独的ArrayList然后靠position去映射，而是把所有类型都放进同一个List里，像示例代码那样用Object的统一容器，绑定的时候用instanceof判断类型，再取对应的数据对象。这样虽然多了一点类型判断，但整个数据模型清晰多了。

另一个细节是刷新数据时不要用notifyDataSetChanged无脑通知。多ItemType的页面里，闪现、跳动、整体重绘的概率本来就高，正确的做法是使用DiffUtil或者手动计算变更范围，用notifyItemRangeInserted和notifyItemRangeRemoved精准更新。对于列表较长、Item较多的页面，这一条几乎是必须的。

3.4 加载更多与上拉刷新怎么融入多ItemType结构

单一RecyclerView方案里还有一个经常被问到的问题：加载更多怎么办？最简单的做法是再加一种TYPE_LOAD_MORE，在ItemType里单独留一个底部状态位。滚动到底部时由滑动监听触发放数据，数据回来后把加载更多Item从“加载中”变成“没有更多了”，或者直接移除。

这里我强烈建议用addOnScrollListener而不是OnScrollListener的旧接口。AndroidX的新接口把回调拆分成了更细粒度的方法，在onScrolled里判断canScrollVertically(1)是否返回false就能知道是不是到底了。实际开发中，滚动到底部的判断我会加一个提前量：当lastVisibleItemPosition >= itemCount - 3时就触发预加载，用户体验比完全到底再加载要顺滑得多。

4. 方案二实战：NestedScrollView嵌套的正确姿势和性能红线

如果你接手的是一个短期要上的页面，不想大改，NestedScrollView嵌套RecyclerView是最快的降级方案。这一章把正确姿势和性能红线讲透。

4.1 布局和代码：只差一个关键开关

改法非常简单，先把外层ScrollView标签换成androidx.core.widget.NestedScrollView，它的子容器照旧是LinearLayout，里面放你原来的Banner、宫格等内容，最下面放RecyclerView，高度写wrap_content。然后给RecyclerView加一行：

recyclerView.setNestedScrollingEnabled(false);

这行代码是整套方案的核心。关闭嵌套滑动之后，RecyclerView不会再向父NestedScrollView发送滚动前的预通知，而是把自己当成一个普通的、高度为wrap_content的内容区块，老老实实待在NestedScrollView里。手指滑动时，NestedScrollView作为唯一的外层滚动容器，接管整个页面的滚动，RecyclerView不再尝试自己滚动。

你可能要问：那列表内容还能不能滚？答案是能，但它是跟着整个页面一起滚的，没有独立的滚动区域，这也正是这个方案和普通滚动行为最大的区别。

4.2 为什么要关掉嵌套滑动，而不是好好开着一个官方组件

很多人不理解为什么用了NestedScrollView还要关掉RecyclerView的嵌套滑动。原因是：如果开着嵌套滑动，RecyclerView和NestedScrollView会同时参与事件的协商，在页面里来回扯皮。实际体验到的情况是，手指在RecyclerView上滑动时，列表内容先滚，滚到边界后页面再滚，这个“接力”过程需要精确的位移量计算，一旦某个版本号、某个机型上计算出偏差，就会出现滚动不跟手、划一下页面飞出去一大截的现象。

关闭嵌套滑动则让整个页面的行为退化为一个朴素的ScrollView：手指滑动，页面滚动，没有中间态，体验和之前的“ScrollView套ListView”的老时代完全一致。同时这个关闭操作也让RecyclerView变成彻底的一次性测量渲染，因为父容器NestedScrollView的高度测量模式会给子View一个UNSPECIFIED的MeasureSpec，RecyclerView会把所有Item的高度全加起来，当成自己的高度。

4.3 性能红线：数据量多少算“不能忍”

一次性渲染带来的性能代价是这套方案最需要警惕的地方。RecyclerView不复用ViewHolder，意味着每一个Item，包括每一条数据对应的布局都要被实例化。50条以内你可能感知不到差异，但到了200条以上，初次加载就会从原来的“碎片化渲染”变成“一次性全部Inflate”，卡顿是必然的。

我自己的判断标准很粗暴：Item类型简单（单个TextView、ImageView加一行文字）、数据量小于100条，可以用这个方案；Item带复杂布局、有网络图片、数据量可能增长到几百上千条，想都不要想。

另外提醒一个隐蔽坑：RecyclerView的数据在NestedScrollView方案里如果加载了全量数据，而且Item高度不固定，那页面底部的内容会随着图片异步加载不断“顶下去”，用户滑动到底部时可能发现内容还在增长。解决这类问题，要么固定Item高度，要么改用占位图保证布局稳定，这在电商详情页里特别常见。

4.4 适合用这套方案的典型页面

我自己实际用过并且觉得舒服的场景有这么三类：第一类是App设置页，这种页面Item数量少、结构固定、不需要复杂滚动动画，用NestedScrollView嵌套一个两三层的小列表非常轻量。第二类是电商商品详情页，顶部是商品大图、中间是属性参数表格、底部是一些推荐商品，内容整体高度可控且数据量不会爆炸。第三类是登录注册、用户协议这种简单页面，内容固定，完全可以在ScrollView里放一个RecyclerView展示条款列表。

反过来说，如果你的页面是“无限刷新”的Feed流、聊天记录、订单列表，就算短期内数据量不大，也千万别用这个方案，因为产品不会答应数据量永远不涨。

5. 方案三实战：自定义ScrollView按触摸目标放行事件

如果项目里确实没办法把ScrollView换成NestedScrollView或者改成单RecyclerView，自定义ScrollView是一个“针对性规避”的招法，实现起来比较直接。我放在第三个讲，因为它虽然代码少，但局限性明显。

5.1 核心实现：在onInterceptTouchEvent里判断触摸点

思路是重写onInterceptTouchEvent，当手指按下的目标是RecyclerView时，直接返回false不拦截，把事件直接交给RecyclerView去消费。下面是核心代码：

public class InterceptScrollView extends ScrollView { public InterceptScrollView(Context context) { super(context); } public InterceptScrollView(Context context, AttributeSet attrs) { super(context, attrs); } @Override public boolean onInterceptTouchEvent(MotionEvent ev) { if (isTouchOnRecyclerView(ev)) { return false; } return super.onInterceptTouchEvent(ev); } private boolean isTouchOnRecyclerView(MotionEvent ev) { if (getChildCount() == 0) { return false; } View content = getChildAt(0); if (!(content instanceof ViewGroup)) { return false; } ViewGroup container = (ViewGroup) content; float x = ev.getX(); float y = ev.getY(); for (int i = 0; i < container.getChildCount(); i++) { View child = container.getChildAt(i); if (child instanceof RecyclerView && x >= child.getLeft() && x <= child.getRight() && y >= child.getTop() && y <= child.getBottom()) { return true; } } return false; } }

这段代码没什么高深技巧，就是把event坐标和RecyclerView的边界做一次包含判断。要注意的是getX和getY拿到的是相对于ScrollView自身的坐标，所以判断子View边界时直接用child.getLeft和getTop即可，不需要再做坐标转换。如果你的ScrollView里嵌套了两层布局，再用坐标循环判断会更稳妥。

5.2 局限性：RecyclerView滚到边界后的“交接”难题

这套方案最大的坑，是RecyclerView滚动到边界时的处理。假设页面结构是“上方一大段说明文案，中间是RecyclerView，下方是其他内容”。用户手指在RecyclerView上向下滑，RecyclerView内部滚动，一直滑到列表末尾，这时候用户继续往下滑，期望的是外层ScrollView接管，让整个页面向下翻动，把RecyclerView下面的内容露出来。但我的代码是“只要触摸点在RecyclerView区域内就不拦截”，事件全部给了RecyclerView，RecyclerView已经没有可滚动的距离了，于是页面卡住。

解决这个问题的思路是在RecyclerView这边做增强，重写它的onTouchEvent或者dispatchTouchEvent，检测到canScrollVertically(1)为false时，主动请求父ScrollView处理后续事件。但这个“主动请求”的处理非常繁琐，要在MOVE事件里实时判断、动态修改拦截状态，稍不留神就会引入新的跳跃和抖动。我试过的实际做法是先判断RecyclerView能否继续向下滚动，不能的话调用getParent().requestDisallowInterceptTouchEvent(false)，允许父View重新获得拦截权，但代码的健壮性还需要多机型验证。

5.3 什么时候才值得用这个方案

我个人对这个方案的使用态度很保守。它只适合一种情况：RecyclerView在ScrollView里占据了几乎整屏的高度，而且列表数据量本身不小，不能关掉嵌套滑动，但又没有时间做大改造的临时项目。比如一个直播间的消息滚动列表，上面是一个视频区域，下面是RecyclerView聊天消息，消息量很大且滚动频繁，中间还有大量消息不断插入。这种场景里，用户的大部分交互都发生在RecyclerView区域内，外层ScrollView只是给了一个有限的剩余空间，事件“偶尔”需要分给外层，用自定义ScrollView按目标放行是合理的。一旦页面需要两层频繁接力滚动，别犹豫，直接切回方案一。

6. 实战中的坑与排查记录：我从项目里踩过的那些坑

滑动冲突类问题在开发中最容易让人破防的，是“现象一堆，原因藏在很底层”。这一章我把这几年在真实项目里遇到过的代表性坑和排查思路整理一下，给你当速查手册。

6.1 滑动乱象快速排查表

下面这几条是我自己整理的最常见问题对照表，发现问题先对着找，能省很多时间。

6.2 为什么手指在RecyclerView上“不跟手”

有段时间我在开发一个详情页，里面的RecyclerView放在NestedScrollView里，默认开着嵌套滑动。用户反馈“列表滑动很绵，手指都快划出屏幕了列表才慢慢走，松手后还会滑好久”。排查的时候我先怀疑是不是LayoutManager设置了smoothScroll，查了一圈发现不是，最后定位到问题出在嵌套滑动的消费比例上。

NestedScrollView作为父View会参与RecyclerView的滚动过程，RecyclerView每次滚动一段距离，都会先询问父View要不要消费，父View消费掉一部分，剩下的再由RecyclerView执行。如果父View消费的位移量计算有偏差，手指移动的物理距离和列表实际滚动的距离就会对不上，造成“不跟手”的感觉。这个问题的正解就是在不需要双层滚动的页面里直接setNestedScrollingEnabled(false)，让RecyclerView和父容器彻底解耦。

6.3 数据刷新后位置跳动的根源

多ItemType页面里，新手最容易遇到的一个问题是：下拉刷新或者插入新数据后，整个列表突然跳到顶部或者跳到奇怪的position。原因通常是直接调用notifyDataSetChanged，所有Item被整体重绘，而getItemViewType和onBindViewHolder里如果用了旧的position逻辑，数据位置就乱了。

我的处理习惯是：重写getItemViewType时不用总索引去猜类型，而是用数据对象本身携带的类型字段，绑定数据时也不依赖position和ArrayList的映射，而是从统一List里取出对象再分支处理。刷新时优先用DiffUtil，它会把新旧列表的差异算清楚，再调用精准的notifyItemRangeInserted、notifyItemRangeRemoved，这样列表的滚动位置自然稳定。这个坑看着不大，但排查起来非常浪费时间。

6.4 滑动验证还不完善的边缘场景

最后说几个容易漏掉的边缘场景，都是我在测试中踩过的。第一，RecyclerView放在ScrollView中时，外层ScrollView滚动到边界后继续下拉，部分机型的阻尼效果表现不一致，不要在这个阶段做过于复杂的自定义阻尼动画。第二，如果页面嵌入了EditText，软键盘弹出、收起会导致ScrollView重新测量高度，RecyclerView如果有固定高度可能会出现内容偏移，排查时需要关注adjustResize相关配置和软键盘监听。第三，多ItemType页面如果嵌入了ViewPager2或者横向滚动的子RecyclerView，事件方向不同会带来新的二级冲突，排查时优先确认为什么方向的事件会被错误消费。

7. 我的最终建议与一点实话

这篇文章从事件分发原理讲到了四种方案的代码，核心只有一句话：能不用嵌套就不用嵌套，能用一个RecyclerView装下所有内容就别整ScrollView。嵌套方案不是不能碰，但它需要你清楚数据量的边界、版本兼容的范围和滚动体验的取舍。

如果你现在的页面正好是电商首页、内容详情页这种“Banner加宫格加列表”的结构，大胆用多ItemType重构，把嵌套彻底删掉，你会回来感谢这个决定。如果只是临时要上线的小模块，就用NestedScrollView加setNestedScrollingEnabled(false)顶住，同时心里要有一条明确的数据量警戒线，一旦产品说“再加一点推荐位”、“列表数据量再翻一倍”，立刻切换到单一RecyclerView方案。

最后再分享一个小技巧：排查滑动冲突时，不要只看onInterceptTouchEvent，记得在dispatchTouchEvent和onTouchEvent里打上日志，把每一次事件的动作、坐标、返回值都记录下来。事件分发这条链路很短，但变量很多，日志里的一次ACTION_CANCEL，往往就是问题真正的起点。这条经验我用了好几年，比翻源码高效得多。