当我们的页面层级相对简单的时候，一般都不会有滑动冲突的问题产生，但是随着业务的扩展，我们的项目日益壮大，页面也越来越复杂，当多个可滑动的控件嵌套在一起的时候，这时候就会产生令人摸不着头发的杂症-滑动冲突。

大致总结了一下，滑动冲突主要有以下几种表现形式：

• 同一个滑动方向的滑动冲突
• 不同滑动方向的滑动冲突
• 乱来随便搞的方向的滑动冲突

结合View的事件分发机制，针对滑动冲突，我们一般有两种方法：外部拦截法和内部拦截法。

外部拦截法

顾名思义，通过外部拦截而达到解决滑动冲突的办法，那这个外部拦截是在哪里拦截呢？外部，指的就是父控件，拦截，那指的就是 onInterceptTouchEvent 这个方法，通过事件分发机制，我们知道，当onInterceptTouchEvent这个方法返回 true 的时候，事件就不再向下传递给子View 了，而是回调该控件的 onTouchEvent 方法。利用这个特性，我们可以自己处理当前的事件需要交由谁来处理，如果是父控件，则直接在onInterceptTouchEvent返回 true 进行拦截就可以了。

内部拦截法

仍然顾名思义，外部不对事件进行拦截，而是交由子控件进行处理，如果子控件需要，则直接消耗该事件，否则交由父控件处理。这种方式往往还需要结合requestDisallowInterceptTouchEvent方法一起使用，这个方法在View的事件分发机制有提到过，它可以干扰父控件的拦截事件。这种方法相对复杂，它还需要父控件拦截除了ACTION_DOWN以外的事件，这样，当子控件不需要处理的时候，才能交还由父控件处理。

下面谈谈针对上面提到的三种常见冲突我们需要如何处理。

同一个方向的滑动冲突

这种冲突常见的就是ScrollView 嵌套了 RecyclerView 这种形式。个人认为，同一方向的冲突用内部拦截法可能会相对好一些，假设当前触摸的子控件，则直接由子控件处理，如果非子控件，那全权由父控件处理，当然，这其中还需考量相应的实际业务进行编写。当然了，如果仅仅是ScrollView 嵌套了 RecyclerView的冲突的话，其实可以用 Android 的原生控件 CoordinatorLayout，该控件已经很好的解决了这两类控件嵌套一起的冲突。

不同方向的滑动冲突

这种冲突常见的应该就是页面可上下滑动，可左右切换的形式。对于这样的冲突，外部拦截法用起来相对更合适一些。假设当前的页面是父控件是上下滚动，子控件的左右滑动，其实我们只需要在父控件的onInterceptTouchEvent方法中进行相应的业务逻辑判断就可以了，当判断为手势为上下的时候，则父控件拦截事件进行处理，如果不是则放行。

乱来随便搞的方向的滑动冲突

这种冲突都相对复杂了，往往都是页面层级很深。说难也难，说简单也简单，难就难在多控件嵌套，处理逻辑比较麻烦，说简单其实也不难，拆分开来，一层一层的解决也还好。

就说一下我当下遇到的一个问题吧。业务需求：顶层需监听左右滑动做翻页操作，次层需要可以上下滚动显示，底层又有一个控件需要左右滑动。我 %￥￥@￥%&&…………%#@￥

好，现在对问题做一个拆分，我们可以把外层的左右和中间层的上下做一个分区，把中间层的上下和底层的左右做一个分区。那么，我们只要分别处理这两个地方的冲突就可以了。出于各种乱七八糟的考虑，我外层用的是外部拦截法，内层用的是内部拦截法。对于外层而言，我重写了外层的onInterceptTouchEvent方法，根据回调，拿到MotionEvent,进行业务判断，如果是左右则交由当前控件处理，如果不是就放行。对于内层，因为不想处理这个中间件，所以采用了内部拦截法，在底层需要左右滑动的控件中重写了其 dispatchOnTouchEvent方法，当判断手势是左右滑动的时候，则调用parent.requestDisallowInterceptTouchEvent(true)通知父控件我需要处理该事件，如果非左右滑动，则调用parent.requestDisallowInterceptTouchEvent(false)通知父控件自己处理该事件。

写在后面

滑动冲突，确实是一个比较令人头秃但又村头不见村尾见的问题。但是只要我们抓住解决冲突的要领：外部拦截法和内部拦截法，应该都可以解决大部分的冲突问题，如果仍旧是解决不了的，你可以怀疑怀疑你的产经了。🌜