要解决滑动冲突，首先必须理解 Android 的事件分发机制。该机制由三个核心方法构成，它们共同决定了 MotionEvent（触摸事件）的传递路径和最终归属。
public boolean dispatchTouchEvent(MotionEvent ev)
true 表示事件已被消费，事件流就此终结；返回 false 表示事件未被处理，将回传给父 View 的 onTouchEvent 方法进行处理。如果调用了 super.dispatchTouchEvent(ev)，则继续向下或向上传递。public boolean onInterceptTouchEvent(MotionEvent ev)
ViewGroup 中。此方法用于判断是否要拦截当前事件流。它是解决滑动冲突的核心所在。true 表示 ViewGroup 决定拦截事件，后续的 ACTION_MOVE、ACTION_UP 等事件将直接由该 ViewGroup 的 onTouchEvent 处理，不再传递给子 View。返回 false 表示不拦截，事件将继续传递给子 View。public boolean onTouchEvent(MotionEvent ev)
onInterceptTouchEvent 拦截成功，或子 View 未消费事件），事件会交由该方法处理。true 表示事件已被成功消费，事件传递终止。返回 false 表示不消费此事件，事件会“冒泡”回传给父 View 的 onTouchEvent 方法。通常情况下，如果一个 View 要消费一系列事件，就必须在 ACTION_DOWN 事件中返回 true。滑动冲突的根本原因在于，父 ViewGroup 在不恰当的时机（例如，子 View 正在滚动时）通过 onInterceptTouchEvent 拦截了本应由子 View 处理的事件。
在传统的 View 体系中，主要有两种解决滑动冲突的思路：外部拦截法和内部拦截法。
核心思想：由父容器（ViewGroup）根据业务需求，在 onInterceptTouchEvent 方法中做出最终裁决，决定何时拦截事件。
实现方式：重写父容器的 onInterceptTouchEvent 方法。
// 伪代码示例
public class ParentViewGroup extends FrameLayout {
private int mLastX;
private int mLastY;
@Override
public boolean onInterceptTouchEvent(MotionEvent event) {
boolean intercepted = false;
int x = (int) event.getX();
int y = (int) event.getY();
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
// ACTION_DOWN 事件必须返回 false。
// 如果在此处返回 true，会直接拦截事件流，
// 导致子 View 永远无法接收到任何事件。
intercepted = false;
break;
case MotionEvent.ACTION_MOVE:
int deltaX = x - mLastX;
int deltaY = y - mLastY;
// 根据业务逻辑判断是否拦截
// 例如：当横向滑动距离大于纵向滑动距离时，由父容器处理
if (Math.abs(deltaX) > Math.abs(deltaY)) {
intercepted = true;
} else {
intercepted = false;
}
break;
case MotionEvent.ACTION_UP:
intercepted = false;
break;
}
mLastX = x;
mLastY = y;
return intercepted;
}
}
优点：实现简单，符合事件分发流程。
缺点：所有滑动冲突的判断逻辑都封装在父容器中，与子 View 的具体实现耦合度高，不易扩展和维护。
核心思想：父容器默认不拦截任何事件，将判断权交给子 View。子 View 根据自身情况，通过 requestDisallowInterceptTouchEvent() 方法主动控制父容器是否需要拦截事件。
实现方式：
dispatchTouchEvent 方法，在其中根据滑动情况调用 getParent().requestDisallowInterceptTouchEvent(boolean)。onInterceptTouchEvent，并尊重子 View 的请求。代码要点：
子 View 实现:
// 伪代码示例
public class ChildView extends View {
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
// 请求父容器不要拦截事件，确保子 View 能接收到后续事件
getParent().requestDisallowInterceptTouchEvent(true);
break;
case MotionEvent.ACTION_MOVE:
// 判断是否需要父容器处理
if (/* 条件：例如滑动到边界 */) {
// 将控制权交还给父容器
getParent().requestDisallowInterceptTouchEvent(false);
}
break;
case MotionEvent.ACTION_UP:
break;
}
return super.dispatchTouchEvent(event);
}
}
父容器配合:
// 父容器需要简单重写 onInterceptTouchEvent
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
// 在 ACTION_DOWN 时不拦截，确保事件能传递到子 View
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
return false;
}
// 后续事件默认拦截，但会根据 requestDisallowInterceptTouchEvent 的状态决定
return true;
}
优点：将控制权下放给子 View，符合“高内聚、低耦合”的设计原则，逻辑更清晰，易于维护。
缺点：实现稍微复杂一些。
Jetpack Compose 引入了一套全新的嵌套滚动模型，从“拦截式”转变为“协作式”，使得处理滑动冲突变得更加优雅和直观。
核心 API：Modifier.nestedScroll(connection: NestedScrollConnection)
模型：在 Compose 中，父子组件不再通过拦截来抢夺事件控制权，而是通过 NestedScrollConnection 接口进行协商。滚动事件发生时，父子组件都有机会在不同的阶段消费滚动增量（delta）。
NestedScrollConnection 关键回调:
onPreScroll(available: Offset, source: NestedScrollSource): Offset
available。返回值是父组件已经消费的 Offset。CollapsingToolbar）优先响应的效果。onPostScroll(consumed: Offset, available: Offset, source: NestedScrollSource): Offset
available，父组件可以在此阶段消费。onPreFling(available: Velocity): Velocity 和 onPostFling(consumed: Velocity, available: Velocity): Velocity
Scroll 类似，但处理的是 Fling（快速滑动）事件，允许父子组件协作处理惯性滚动。定位：Modifier.nestedScroll 是 Jetpack Compose 中处理所有嵌套滚动场景的标准且唯一的解决方案，其协作式模型从根本上避免了传统 View 体系中的滑动冲突问题。