View 的杂症之滑动冲突

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

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

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

结合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)通知父控件自己解决该事件。

写在后面

滑动冲突，的确是一个比较令人头秃但又村头不见村尾见的问题。但是只需我们抓住处理冲突的要领：外部阻拦法和内部阻拦法，应该都可以处理大部分的冲突问题，假如依旧是处理不了的，你可以怀疑怀疑你的产经了。??