企业官网建设流程全解析

遇到跨界滚动的崩溃现场，几乎每个做Android的人都被问过这么一句：RecyclerView能不能嵌进ScrollView里。早期答案是别嵌，嵌了不是卡顿就是事件被吃掉，后来有了NestedScrolling机制，这套"父子互相抢事件"的死局才算真正打开。这篇就想把Android NestedScrolling这套机制从头到尾拆开，讲清楚它到底解决什么问题，Child和Parent之间靠什么约定协作，一次真实的手势滑动从按下到抬起经历过哪些方法调用，再带大家手写一个"头部折叠联动列表"的自定义嵌套滚动容器，最后把我在真机上踩过的坑一并列出来。适合那些已经在用CoordinatorLayout和AppBarLayout、但遇到诡异滚动问题只能靠试的开发者，也适合想深入理解View体系协作方式的读者。

1. 嵌套滚动到底在解决什么问题

1.1 从一场最经典的滑动冲突说起

先回到没有NestedScrolling的年代。那时候想在页面上实现"上半部分是一个可以收缩的头部，下半部分是一长串列表"，最粗暴的写法是直接用ScrollView包一个LinearLayout，列表用不带滚动能力的LinearLayout往里填。数据量小看着还行，数据一多就开始卡，因为整个线性布局全被一次性测量布局了。

后来有人换成ScrollView里嵌ListView，又踩进另一个坑：两者都有滚动能力，手势方向稍微偏一点，事件就被内层ListView吃掉了，外层ScrollView根本滚不动；偶尔外层动了，内层又完全不听使唤。当时的通用解法是重写ListView的onMeasure，把高度算成所有item之和，让它"永远不滚动"，彻底失去列表复用。这种方案等于为了让外层能滚，牺牲掉了内层的全部滚动优化。

问题根源在于，Android传统的事件分发模型里，ViewGroup和子View对一次触摸事件的争夺是零和博弈：onInterceptTouchEvent要么拦截，要么不拦，没有"分我一点"的空间。而真正复杂的业务页面需要的是两个滚动容器协同工作，比如"头部先收起，收起完了列表再滚"这种明确的先后顺序。

1.2 事件分发机制里嵌套滚动的先天缺陷

传统分发链路上，一次ACTION_DOWN先走ViewGroup的dispatchTouchEvent，再决定是分发给子View还是自己处理。如果ViewGroup决定不拦截，之后同一序列的ACTION_MOVE默认继续发给子View，ViewGroup中途想抢回事件，只能在onInterceptTouchEvent里返回true。

这种设计有几道硬伤：

• 父View和子View无法在同一个move事件里共同消费一段滚动距离。要么父滚，要么子滚，想做到"先父后子"或者"父消费一部分、子消费剩余部分"，没有直接的表达方式。
• 子View滚动到边界后，没有接口告诉父View"我已经到头了，剩下的你接着滚"。子View只能自己吞掉多余的距离，对外表现为滚动被"吃掉"了一截。
• 惯性滑动（fling）阶段的协作更无从谈起。手指松开之后的Animator是子View内部自己起飞的，父View既不知道也拦不住。

这也是为什么有个经典帖子把这种问题总结为"要么掐死内层，要么放弃外层"。直到API 21引入NestedScrolling机制，才把这两个在概念上本来应该协同工作的滚动容器，从互相竞争变成了一场有协议的分工。

1.3 NestedScrolling的设计目标：把"竞争"变成"协作"

NestedScrolling不是要替代事件分发，它是在事件分发之上搭了一层"滚动协作协议"。它的核心思路是：滚动手势发生时，先问父View要不要消费，父View消费完剩下的才给子View；子View消费完如果还有剩，再回过头问父View要不要兜底。整个过程发生在一次move事件的时间窗口里，父和子通过接口回调交换"我消费了多少、还剩多少"。

这个设计直接回答了上一节的三道硬伤：用Pre和Post两个阶段实现了同一事件的多方消费；用dispatchNestedScroll把剩余滚动距离向上抛；用dispatchNestedPreFling和dispatchNestedFling把惯性阶段也纳入协作范围。

外界经常把NestedScrolling简单理解成"为了让ScrollView能包RecyclerView"，其实它的覆盖面广得多。CollapsingToolbarLayout的头部收起、BottomSheetBehavior的拖拽、ViewPager2内部对横竖方向滚动的协调，底层全是这一套协议在工作。你平时遇到的很多"不知道哪里冒出来的滚动联动"，其实都是某个组件默默实现了NestedScrolling相关接口。

2. 核心角色与接口约定：Child和Parent各自的分工

2.1 四个角色是谁

直接看名字容易懵，先给一张角色对照表：

Helper不是可有可无的封装，它承担了绝大部分脏活：Child要调startNestedScroll时，Helper负责沿ViewParent链向上找第一个实现了NestedScrollingParent的父View；同时要维护当前正在协作的Parent引用，避免一次手势里跟多个Parent建立关系导致事件重复分发。

理论上你可以不用Helper自己写一套状态机，但实际没人这么干。原因很简单，Helper处理了很多边界情况，比如嵌套滚动期间Parent被移除、多个嵌套层级同时请求协作、触摸滚动和非触摸滚动两种模式的状态切换，自己搞很容易在冷门场景崩一脚。

2.2 NestedScrollingChild的六个关键方法

Child接口里最重要的是这六个：

• setNestedScrollingEnabled(boolean)：总开关。关掉之后Child完全不参与嵌套协作，所有滚动距离自己硬吞。
• startNestedScroll(int axes)：向父View发起协作请求。axes一般取ViewCompat.SCROLL_AXIS_VERTICAL或SCROLL_AXIS_HORIZONTAL，父View通过onStartNestedScroll决定接不接受。
• dispatchNestedPreScroll(int dx, int dy, int[] consumed, int[] offsetInWindow)：在Child自己处理滚动之前，先把距离抛给父View。consumed数组是输出参数，父View消费的量会累加进去。假设dy是10，父View在onNestedPreScroll里消费了7，那Child自己只能滚3。
• dispatchNestedScroll(int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed, int[] offsetInWindow)：Child自己消费完之后，把没消费掉的量抛给父View兜底。
• dispatchNestedPreFling(float velocityX, float velocityY, boolean consumed)：把惯性速度先给父View过一道。父View可以在onNestedPreFling里返回true表示自己全权接管。
• dispatchNestedFling(float velocityX, float velocityY, boolean consumed)：Child自己处理不完全部惯性时，把剩余fling速度抛给父View。

注意dispatchNestedPreScroll里consumed数组的初始值由Child保证为0，或者每次重新new一个长度为2的数组，父View消费多少就累加多少到对应的下标。0号下标对应x方向，1号下标对应y方向。

2.3 NestedScrollingParent的八个回调

Parent端的核心回调比Child还多几个，我按生命周期阶段分组：

建立阶段：

• onStartNestedScroll(View child, View target, int axes)：返回true表示接受这次协作。child是直接子View，target是真正发起滚动的那个View，两者可能隔了好几层。这个区分很关键，判断时通常用target，因为target才是真正滚动的对象。
• onNestedScrollAccepted(View child, View target, int axes)：确认接受之后调用，可以在这里初始化状态。
• onStopNestedScroll(View target)：手势结束，协作关系断开。

预滚动阶段：

• onNestedPreScroll(View target, int dx, int dy, int[] consumed)：在target自己滚动前调用。返回true表示消费了部分或全部滚动。

后滚动阶段：

• onNestedScroll(View target, int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed)：target自己消费完之后调用。unconsumed是target剩下的量，Parent可以在这一层接着滚。

惯性阶段：

• onNestedPreFling(View target, float velocityX, float velocityY)：预惯性，返回true代表Parent接管所有fling。
• onNestedFling(View target, float velocityX, float velocityY, boolean consumed)：target自己fling完之后，如果Parent想追加一个自己的fling动画就处理这里。

观察这套方法命名能发现一个规律：所有带Pre的方法都发生在target自己动手之前的，"先让父辈挑剩下的才轮到我"；不带Pre的带Unconsumed参数，发生在target动手之后，"我吃不完的你接着吃"。

2.4 为什么要有Pre和Post两个阶段

刚开始接触这套接口的开发者最容易问：直接统一走一个回调不就行了，分两段干什么。

原因在于业务上存在两种截然不同的联动顺序需求。第一种需求是"父View优先"，典型场景是CollapsingToolbarLayout：手指下滑时，头部要先把折叠高度收缩完，之后的距离才轮到列表滚动。这种必须走onNestedPreScroll，父View先把dy消费掉一部分，RecyclerView只拿到剩下来的量。如果RecyclerView先滚，列表动一下就到底了，头部还没收缩，体验完全是反的。

第二种需求是"子View优先"，典型场景是普通的嵌套翻页：列表自身还能滚时，所有的dy都该给列表，只有当列表已经滚到边界、剩下来的dy无处可去，才交回给父View做整页滑动。这种就得靠onNestedScroll里的unconsumed参数实现。

还有更微妙的混合场景，比如QQ空间的头部下拉效果：下拉时先让头部跟着位移一段，到达临界值后变成刷新；上滑时则列表先滚，滚到顶了头部再展开。这种需求里Pre和Post两个回调一个都省不了。没有两阶段分发，这些先后逻辑全部得靠Parent在事件分发层自己去抢，抢完再手动把距离交给子View，代码很快会烂到没法维护。

3. 手指滑动的完整链路：一次move事件的全过程拆解

3.1 startNestedScroll：建立协作关系的时机

一次完整滑动，从Child收到的ACTION_DOWN开始。RecyclerView在自己的onTouchEvent里，处理的第一个事件是DOWN。它做的第一件事不是滚动，而是调startNestedScroll(ViewCompat.SCROLL_AXIS_VERTICAL)，告诉父View"我准备开始一场垂直方向的手势，你要不要一起玩"。

这个调用会沿着ViewParent链往上找，找到第一个实现了NestedScrollingParent的对象并调它的onStartNestedScroll。如果父View返回true，Helper就把这个父View记为当前协作对象，紧接着调onNestedScrollAccepted。

之所以放在DOWN而不是等MOVE才建立关系，是因为滑动方向在DOWN阶段还不明确，而到了第一个MOVE再临时找Parent，手势的前几个像素就可能因为缺少协作而出现跳动。提前建立关系，Parent可以在后续事件里全部介入。

需要注意的是，一次触摸序列只会调用一次startNestedScroll，不会在每一个move都重新建立。结束有两个触发点：ACTION_UP和ACTION_CANCEL时，Child会调stopNestedScroll，通知Parent协作结束；或者Parent自己在onStopNestedScroll里做状态清理。

3.2 一次move的三方博弈

先给出一条完整链路的调用顺序，然后再逐环解释。

1. RecyclerView在onTouchEvent里收到ACTION_MOVE，计算本次要滚动的deltaY。
2. Child先调dispatchNestedPreScroll(0, deltaY, consumed, offset)，把距离抛给Parent的onNestedPreScroll。
3. Parent在onNestedPreScroll里消费了一部分距离，写入consumed[1]。
4. Child计算剩余滚动距离：remain = deltaY - consumed[1]。
5. Child自己执行滚动逻辑，比如layoutManager.scrollBy(0, remain)，真正让item滚动的就是这一步。
6. 如果remain没有被完全消费，Child把剩余部分通过dispatchNestedScroll抛给Parent的onNestedScroll，Parent在这里接着滚。
7. 整个过程可能在一个move事件里反复出现多次，比如RecyclerView的fling过程中，非触摸产生的滚动也会走同样的协议，只是调用的是带type参数的接口版本。

这套流程里的关键认知是：无论Parent还是Child，在onNestedPreScroll和onNestedScroll里返回true还是false，都不影响事件分发本身。它只是告知"我是否消费了滚动距离"，而是否把事件继续发给对方，完全由事件分发机制天然保证。这就是嵌套滚动容易上手成习惯后产生误解的地方——很多人以为返回false会被踢出协作，其实不是，甚至返回true也不代表事件被拦截。

3.3 offsetInWindow到底是什么鬼

dispatchNestedPreScroll和dispatchNestedScroll的最后一个参数int[] offsetInWindow都是输出参数，里面装两个值：x方向的窗口偏移和y方向的窗口偏移。很多人第一次看到这个参数直接懵了，明明滚动距离都算清楚了，这个偏移到底拿来干嘛。

想明白它，关键在于理解"滚动"和"位置变化"的区别。如果一个Parent在onNestedPreScroll里消费了距离，它通常会让自己的内容或者某个header发生位置移动。这个移动不会改变Child在自身坐标系里的位置，但是会导致Child整个View在屏幕窗口里的实际位置发生变化。

举例：外层容器消费了100px，把自己的header向上顶了100px。对RecyclerView来说，它自己没有滚，但整个控件在窗口里上移了100px。如果触摸事件坐标是基于窗口的，而RecyclerView内部计算点击、拖拽的坐标是基于自身坐标系的，两者就会差出这100px的错位。不修正的话，用户会感到"我按住的item在手指下滑动时位置对不上"。

解决方式就是offsetInWindow：Child调用dispatchNestedPreScroll得到这个偏移量之后，会把它应用到触摸事件坐标修正上。这也是为什么在多层嵌套滚动场景里，父容器处理完预滚动后，子View需要调整event的offset，再继续后续逻辑。这个数组在Helper内部已经有默认处理，但如果你自己实现跨层级的嵌套滚动，就得手动把偏移量持续往上传递。

3.4 Fling惯性冲刺怎么分配

手指松开后的惯性阶段，很多人以为跟NestedScrolling无关，因为事件都停了。实际上惯性滚动是RecyclerView内部的OverScroller在驱动，每一帧产生的位移仍然会走一遍嵌套滚动协议。

RecyclerView在接收到ACTION_UP、计算出初速度之后，会调dispatchNestedPreFling。Parent的onNestedPreFling有机会表示"这次惯性我自己全包了"，如果返回true，RecyclerView就不会再启动自己的fling动画，而是由Parent自己起一个OverScroller或者Animator。

如果Parent在onNestedPreFling里返回false，RecyclerView会继续启动自己的fling，同时调dispatchNestedFling把速度透传给Parent。Parent的onNestedFling里如果返回true，也可以自己追加一个动画，两个动画并行运行。CoordinatorLayout的AppBarLayout抬手收起、BottomSheet的自动吸附动画，很多都是靠这一环实现的。

需要注意的是，惯性阶段的协作是"非触摸滚动"模式。接口上对应的是NestedScrollingChild2里的TYPE_NON_TOUCH，以及NestedScrollingChild3里的完整新方法。如果只实现了老的接口，很多系统组件仍然能工作，因为RecyclerView内部有兼容处理，但做一些精细化的惯性衔接时会缺信息，这也是为什么新项目建议直接实现NestedScrollingChild3那套。

4. 实战：手写一个可折叠Header联动RecyclerView

4.1 业务需求与设计方案

直接拿一个真实业务场景：个人主页顶部是品牌展示区，高度从200dp收起后变成80dp，下面跟着一个RecyclerView。交互要求分三段、顺序要完全符合直觉：

1. 手指下滑（内容向下移动，dy > 0）时，头部先收起，收起完成之后，列表才开始滚动。
2. 手指上滑（内容向上移动，dy < 0）时，列表先滚回顶部，列表回到顶部之后，头部再展开。
3. 惯性滑动时也遵循同样的先后顺序。

这个需求就是经典的"父View优先消费 + 子View到达边界后父View兜底"，正好把Pre和Post两个阶段都用上。实现方案有两个：

方案A：用现成的CoordinatorLayout + AppBarLayout + CollapsingToolbarLayout，配置好Behavior，几行XML搞定。这个方案当然推荐给生产环境，但要注意它背后的信息量巨大，出问题很难查。

方案B：自己实现一个NestedScrollingParent容器，手动控制头部高度。代码量多一些，但能把整套机制看得通透。下面的实战走方案B，代码用Java写，方便直接对照接口。

4.2 自定义NestedHeaderLayout的骨架

先写布局结构。NestedHeaderLayout继承FrameLayout，内部有一个header区域和一个RecyclerView。RecyclerView作为Child实现NestedScrollingChild，正好拿来测试。

<com.example.widget.NestedHeaderLayout android:layout_width="match_parent" android:layout_height="match_parent"> <com.example.widget.CollapsingHeader android:id="@+id/header" android:layout_width="match_parent" android:layout_height="200dp" android:background="@color/primary" /> <androidx.recyclerview.widget.RecyclerView android:id="@+id/recycler" android:layout_width="match_parent" android:layout_height="match_parent" android:layout_marginTop="200dp" /> </com.example.widget.NestedHeaderLayout>

注意RecyclerView的layout_marginTop设成了200dp，让它的初始位置从头部底部开始。头部高度变化时，需要同步调整这个margin，或者直接在onLayout里重新计算子View的位置。

容器自身实现NestedScrollingParent，内部用一个NestedScrollingParentHelper管理状态：

public class NestedHeaderLayout extends FrameLayout implements NestedScrollingParent { private static final int HEADER_EXPANDED = dp2px(200); private static final int HEADER_COLLAPSED = dp2px(80); private View header; private RecyclerView recyclerView; private NestedScrollingParentHelper helper; private int currentHeaderHeight = HEADER_EXPANDED; public NestedHeaderLayout(Context context, AttributeSet attrs) { super(context, attrs); helper = new NestedScrollingParentHelper(this); } @Override protected void onFinishInflate() { super.onFinishInflate(); header = findViewById(R.id.header); recyclerView = findViewById(R.id.recycler); } @Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { super.onMeasure(widthMeasureSpec, heightMeasureSpec); // 让header和recycler都按当前头部高度参与测量 ViewGroup.LayoutParams headerLp = header.getLayoutParams(); headerLp.height = currentHeaderHeight; header.setLayoutParams(headerLp); ViewGroup.LayoutParams recyclerLp = recyclerView.getLayoutParams(); ((ViewGroup.MarginLayoutParams) recyclerLp).topMargin = currentHeaderHeight; recyclerView.setLayoutParams(recyclerLp); } }

后面的小节都在这个类里补。为了不占篇幅，先默认你已经处理了dp2px之类的工具方法。

4.3 onNestedPreScroll：头部先折叠的逻辑

先实现建立协作关系的两个方法：

@Override public boolean onStartNestedScroll(View child, View target, int axes) { return (axes & ViewCompat.SCROLL_AXIS_VERTICAL) != 0 && target == recyclerView; } @Override public void onNestedScrollAccepted(View child, View target, int axes) { helper.onNestedScrollAccepted(child, target, axes); }

关键是onNestedPreScroll。这里要处理两种情况：

下滑（dy > 0）：只要头部还没完全收起，就优先把距离给头部。头部的折叠速度可以做成跟手指1:1，也可以加个阻尼系数比如0.5，看产品需求。这里用1:1。

上滑（dy < 0）：只有当RecyclerView已经滚到顶部时，才开始展开头部。判断条件用recyclerView.canScrollVertically(-1)，它返回false代表列表已经不能向下滚动了，也就是处于顶部。

@Override public void onNestedPreScroll(View target, int dx, int dy, int[] consumed) { if (dy > 0) { // 向下滑，优先折叠头部 if (currentHeaderHeight > HEADER_COLLAPSED) { int delta = Math.min(dy, currentHeaderHeight - HEADER_COLLAPSED); currentHeaderHeight -= delta; consumed[1] = delta; requestLayout(); } } else if (dy < 0) { // 向上滑，列表到顶之后头部再展开 if (currentHeaderHeight < HEADER_EXPANDED && !recyclerView.canScrollVertically(-1)) { int delta = Math.min(-dy, HEADER_EXPANDED - currentHeaderHeight); currentHeaderHeight += delta; consumed[1] = -delta; requestLayout(); } } }

这一段写完之后，前两个交互规则已经生效：下滑头部先收，上滑列表先滚。但这里有个细节要小心：consumed[1]必须赋值成实际消费掉的dy。onNestedPreScroll里的dy如果为10，currentHeaderHeight只差5就到了折叠高度，consumed[1]只能填5，不然RecyclerView会凭空少滚5px，手感就是"列表被莫名吃了距离"。

4.4 onNestedScroll：溢出距离的兜底

头部已经折叠到最小值时，用户继续下滑，此刻的滚动距离已经被RecyclerView自己消费了。问题来了：RecyclerView滚到顶部之后，继续下滑的dy怎么办？如果没有人接管，这一段delta就丢了，用户会感觉列表被粘住。

这种情况就到onNestedScroll的用武之地。RecyclerView把剩余距离通过dispatchNestedScroll传上来，我们在onNestedScroll里判断dyUnconsumed是不是大于0，如果是，就手动滚动外层容器或者把整个页面往上推：

@Override public void onNestedScroll(View target, int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed) { // 列表滚到底后，剩余距离交给父容器滚动内容 if (dyUnconsumed > 0) { int remain = dyUnconsumed; // 这里可以滚外层的ScrollView，或者让当前页面整体移动 scrollBy(0, remain); } }

需要注意这里的scrollBy是让NestedHeaderLayout整体内容发生滚动，并不是改变头部高度。实际项目中，这个剩余距离通常被CoordinatorLayout用来做整体页面位移。关于偏移量的一个经验是：如果你发现子View位置出现抖动，优先检查onNestedScroll里有没有正确处理offsetInWindow相关的修正。

还有一个很容易忽略的点：onNestedScroll方法列表里的dxConsumed和dyConsumed是target自身消费掉的距离，不是剩余距离。老版本接口里第3、4个参数名字容易使人误判，写代码时一定看准参数名。

4.5 惯性滑动的联动处理

如果只实现Pre和Post滚动，真机测试很快会发现一个怪象：手指慢慢滑时，头部折叠很顺畅；一旦快速甩一下松手，列表自己飞出去，头却停在原地不动，或者头部瞬间弹回。

原因就是fling没有接入。RecyclerView在惯性阶段产生的每一帧位移，依然会走dispatchNestedPreScroll和dispatchNestedScroll的标准通道，但它能不能启动fling，取决于onNestedPreFling。默认情况下，Parent接口的默认实现对这个方法是走Component回调的，如果我们不处理，RecyclerView会正常fling，但头部的联动动画不会跟上。

处理方案是接管PreFling，让头部和列表的速度保持一致：

@Override public boolean onNestedPreFling(View target, float velocityX, float velocityY) { if (velocityY > 0) { // 快速下滑，先把头部收完的动画跑一次 startHeaderCollapseAnimation(); return true; // 父View接管这次fling } return false; // 上滑的fling让RecyclerView自己跑 } @Override public boolean onNestedFling(View target, float velocityX, float velocityY, boolean consumed) { return true; }

这里有个设计取舍：如果return true表示父View全权接管fling，RecyclerView就不自己滚了。你可以利用这个机制，在头部还没收起时，让整个惯性动画完全由头部完成，等头部到位再手动触发剩下的距离。在写的时候遇到"头部动画完成后列表要接着滚"这种连续衔接需求，可以用Child的fling接口再次发起一次，或者用ValueAnimator把速度按比例分配给两个容器。

4.6 为什么不建议生产环境直接手写

这段代码跑通之后，能感受到NestedScrolling的完整协作流程，但我要泼一盆冷水：生产环境里，除非页面极其简单且性能要求极端，否则不建议自己维护NestedScrollingParent。原因有三条。

第一，边界条件太多。上面例子只处理了垂直方向，横向、双指缩放、碰撞检测、item移除动画、嵌套多级滚动，这些场景一套手写代码很难覆盖完全。CoordinatoryLayout用一个Behavior模型把所有滚动策略收口了，你只需要关注自己在哪个阶段做什么。

第二，可维护性问题。手写的NestedScrollingParent相当于自己实现了一套微型Behavior，代码量看着不大，但半年后回来改需求时，新同事看到onNestedPreScroll和onNestedScroll里塞满判断，很容易改崩。换成CoordinatorLayout + AppBarLayout + CollapsingToolbarLayout，行为逻辑外置到LayoutParams的Behavior里，结构清晰得多。

第三，帮大家建立个认知：手写这套练习最大的价值是排查Bug。真遇到CoordinatorLayout的联动异常，你得能判断出它是在哪个回调里出了问题，是onNestedPreScroll没有拿到预期dy，还是onNestedScroll的unconsumed没传上来。底层机制通了，上层配置问题才能一眼定位。

5. 真机踩坑与调优经验：嵌套滚动最容易翻车的几个场景

5.1 consumed数组复用导致的"漂移"

这个坑我在社区里见过好几次，自己也踩过一次。场景是自定义Child时为了省内存，复用了同一个consumed数组：

int[] consumed = new int[2]; // move事件里循环调用 recyclerView.dispatchNestedPreScroll(dx, dy, consumed, null); // 下一个move又直接传同一个consumed

问题在于dispatchNestedPreScroll内部不会清空consumed，如果方法里没有每次清零，上一次move的消费量会保留下来，导致Parent以为本次已经消费了之前那么多距离。最终表现就是滚动手感忽快忽慢，甚至往下拉的时候列表根本不动。

规范做法是每次调用前都new一个新数组，或者手动Arrays.fill(consumed, 0)。虽然垃圾回收压力略有增加，但滚动性能几乎无感，正确性优先。

5.2 漏掉onNestedScrollAccepted和onStopNestedScroll

很多人写完onStartNestedScroll就直接进入业务逻辑，这两个方法不重写，以为协作关系不成立。

实际上onNestedScrollAccepted是Parent确认参与协作后做初始化的合适位置，比如记录是否已经消费过某个方向的滚动、重置头部动画状态。漏掉它虽然不一定崩，但会丢失状态。

onStopNestedScroll更关键。惯性滚动可能在子View滚动到边界后仍在继续，如果Parent不在onStopNestedScroll里停掉自己的动画，会出现"手指松了，头部还在自己抖"的现象。有一个通用技巧：任何你在onStartNestedScroll里启动的动画或监听，都应该在onStopNestedScroll里有一个对称的停止逻辑。生命周期不对称是这类Bug最常见的根因。

5.3 嵌套层级深了以后offsetInWindow传给谁

项目里如果嵌套滚动层级超过两层，比如外层CoordinatorLayout里又塞了一个自定义NestedScrollingParent容器，容器里再放RecyclerView，offsetInWindow的传递就特别容易出错。

这种情况下，自定义容器的onNestedPreScroll里如果消费了距离，要主动调用View#offsetTopAndBottom来修正子View的位置，而不是只改layoutParams。因为只有真正修改了子View在窗口中的偏移量，后续的dispatchNestedScroll的offsetInWindow计算才能对齐。你可以在Chrome DevTools风格的Layout Inspector里观察，或者用Log打印event.getRawY和事件里的坐标，一旦发现手指下按位置跟item高亮位置偏差超过一个手掌，基本就是offset没传。

对大部分应用来说，解决这个坑的最好办法是不要自己实现多层自定义嵌套容器，尽量复用CoordinatorLayout。它内部对手势偏移的处理是经过千锤百炼的。

5.4 RecyclerView嵌套进NestedScrollView的卡顿

这可能是被问得最多的经典问题。RecyclerView放进NestedScrollView之后，列表明显掉帧，尤其是图片列表，一滑就卡成PPT。网上的解法林林总总，有让RecyclerView设置nestedScrollingEnabled=false的，有让RecyclerView高度wrap_content的。

先说结论：把RecyclerView的nestedScrollingEnabled设成false是标准解法。背后的原理是：当RecyclerView作为NestedScrollView的Child时，两者都有滚动能力。NestedScrollView会在onNestedPreScroll阶段把大部分滚动距离先消费掉，RecyclerView只能拿到少部分距离，于是它每次都只滚一点点，还没机会触发自身的回收复用机制。更糟的是两个滚动容器在Pre和Post两个阶段来回协商，每帧都要做多次回调，开销成倍增加。

关掉nestedScrollingEnabled后，RecyclerView变成了一个不参与嵌套协作的普通子View，所有滚动都由外层NestedScrollView接管。列表依然复用View，只是滚动计算简单了，性能自然上去。要注意这样设置之后，RecyclerView的fling动画不会自己触发，惯性完全由外层容器驱动。

如果你遇到的是"关掉之后惯性没了"的问题，那大概率是因为外层容器不是NestedScrollView，而是普通ScrollView。普通ScrollView不支持嵌套滚动协议，自然也没有fling联动，这种场景还是老老实实换NestedScrollView。

5.5 调试手段：日志、LayoutInspector、systrace

NestedScrolling的排查难在方法调用链太散，不知道哪一环出了问题。我常用的调试手段有三种，按成本从低到高排列。

第一是插日志。在onStartNestedScroll、onNestedPreScroll、onNestedScroll、onStopNestedScroll、onNestedPreFling里各打一条Log，带着dy和consumed的值，跑一遍页面就能看到完整的调用链。这一步能快速判断是Parent没接收到回调，还是收到了但消费距离不对。

第二是Layout Inspector。Android Studio自带的Layout Inspector能看到每个View的布局参数，配合动态修改头部高度，直观观察是头部高度没变化还是margin没跟上。

第三是systrace。如果怀疑性能问题，抓一段滚动过程的systrace，能看到每一帧里RecyclerView和NestedScrollView各占了多少时间。之前碰到一个"慢滑流畅、快滑掉帧"的问题，systrace里显示快速滑动时RecyclerView的onLayout占了20多毫秒，定位到是item布局里有大量重复计算，跟NestedScrolling本身没多少关系。

还有一个亲手写代码时很好用的技巧：重写容器的dispatchTouchEvent，在里头打印每个事件的坐标和action。有些诡异的触摸坐标问题，从这里能看到比scroll回调更原始的信息。

5.6 新旧接口差异：NestedScrollingChild2/3与ViewCompat

最后提醒一个版本兼容问题。NestedScrollingChild和NestedScrollingParent是API 21引入的，NestedScrollingChild2和NestedScrollingParent2在API 26加入，主要增加了type参数区分触摸滚动和非触摸滚动。NestedScrollingChild3在API 28加入，把dispatchNestedScroll方法的参数改成更完整的版本，新增对轴方向的独立判断。

好消息是大部分场景不需要直接操作这些新方法。RecyclerView内部已经实现了Child3接口，NestedScrollView实现了Parent2，你再往上加一层自己的Parent时，大部分回调签名还是老一套。但如果你的自定义Parent需要区分"当前这帧位移是手指拖的还是惯性动画产生的"，就需要重写带type参数的onNestedScroll并判断type == ViewCompat.TYPE_NON_TOUCH，这在做"惯性时头部阻尼不同"这种交互时特别有用。

当你写的是通用库代码，需要在低版本上也能跑时，推荐优先使用ViewCompat里的静态方法，比如ViewCompat.startNestedScroll(View, int)和ViewCompat.dispatchNestedPreScroll(View, int, int, int[], int[])，它内部会处理不同版本间的接口适配，不用自己写版本分支。

嵌套滚动这套机制写到这里，核心的调用链和实战示例都过了一遍。我在实际项目里的体会是：NestedScrolling真正让人豁然开朗的时刻，不是它帮你实现了某个炫酷交互，而是某天AppBarLayout联动出了诡异Bug，你知道该去查Behavior的onNestedPreScroll返回了什么，而不是在那里到处删布局代码碰运气。如果还想往下深入，建议自己再做一个横向嵌套滚动的例子，把双轴都过一遍，对这套机制的理解就能真正形成闭环。