第七章 View的滑动冲突
1. 概述
在进行Android开发的时候，都可能会碰到滑动冲突。有时候，下载了一个Demo运行的好好的，但是出现滑动冲突，这样导致Demo运行崩溃。然后，整个人都炸了。下面来分析下滑动冲突是如何产生的呢？其实在界面中只要内外两侧同时可以滑动。这时候我们就会产生滑动冲突。如何解决滑动冲突呢？这就是我们这章需要分析的。
2. 常见的滑动冲突场景
常见的滑动冲突场景可以简单分为三种：
| 场景 | 描述 |
|---|---|
| 场景一 | 外部滑动方向和内部滑动方向不一致 |
| 场景二 | 外部滑动方向和内部滑动方向一致 |
| 场景三 | 上面两种情况的嵌套 |
滑动冲突的场景
场景一，主要是将ViewPager和Fragment配合使用的页面滑动效果。目前很多市场上的App几乎都是使用这个效果。在这种效果中，可以通过左右滑动来切换页面。而每个页面内部往往又是一个ListView,本来这种情况是冲突的，但是ViewPager内部处理了这种滑动冲突，所以采用Viewpger时，我们无需关注这个问题，但是如果我们采用的不是ViewPager而是ScrollView等，那就必须手动处理滑动冲突。造成的后果就是内外两层就只有一层能够滑动，除了这种情况，还存在其他情况，还有外部上下滑动，内部左右滑动等，它们都属于同一类的滑动。
场景二，这种情况稍微复杂一些，当内外两层都在同一个方向可以滑动的时候，显然存在逻辑问题，当手指按住屏幕的时候，系统无法知道用户想滑动那一层，所以当手指滑动的时候就会出现问题，要么只有一层能滑动，要么就是两层能够都滑动的很卡顿。实际开发中，这种场景主要是值内外两层同时能上下滑动或者内外两层同时左右滑动。
场景三是场景二和一的嵌套。具体来说，实际开发中外部有一个SlideMenu效果，然后内部一个ViewPager页面，ViewPager中的每一个页面又是一个ListView，这种场景滑动冲突更加复杂，处理起来其实也不复杂，只要处理好内层和中层，中层和外层之间的滑动冲突。
3. 滑动冲突的处理规则
不管滑动冲突有多么复杂，它都有既定的规则。根据规则我们可以选择合适的方法处理。
场景一的处理规则，当用户左右滑动的时候，需要让外部的View拦截点击事件，当用户上下滑动的时候，需要让内部的View拦截点击事件。这时候我们需要根据他们的特征来解决滑动冲突。具体就是来说：根据滑动方式是水平滑动还是数值滑动来判断到底是由内部的View还是外部的View来拦截事件。如图所示根据滑动过程中的两个点之间的坐标来判断是水平滑动还是垂直滑动。
滑动过程示意
如何根据坐标得到滑动的方向呢？这个很简单，可以根据滑动路径和水平方向所形成的夹角，也可以根据水平方向和竖直方向上的距离差，来判断，比如数值方向滑动的距离大就判断为竖直方向，否则判断为水平滑动，根据这个方法就可以进行下一步的解决方法指定了。
场景二的处理规则，因为场景二是内外view的滑动方向一致，所以无法根据角度，距离差以及速度差来做判断，但是这个时候一般能在业务上找到突破点，根据状态的不同来判断是外部View拦截还是内部View拦截。比如需求是：当处于某种状态的时候，外部View去响应用户的滑动，而当处于另一种状态的时候需要内部View来响应用户的滑动。
场景三和场景二一样，只能根据业务的需求来寻找突破点。
4. 滑动冲突的解决方式
场景一的滑动冲突，很简单的，我们只需要根据滑动的距离差来距离判断，这个距离差就是所谓的滑动规则。如果用ViewPager去实现场景1中的效果，就不需要手动处理滑动冲突，因为ViewPager内部已经帮我们解决了。但是如果没有使用ViewPager的时候，我们需要怎样将点击事件交给合适的View去处理。这里将两种方法去解决滑动冲突：外部拦截法和内部拦截法。
4.1 外部拦截法
外部拦截法是将点击事件都先经过父容器的拦截处理，如果父容器需要此事件就拦截，不需要就不拦截，这样就可以解决滑动冲突的问题了。这里就需要用到点击事件的分发机制，重写父容器的的onInterceptTouchEvent(MotionEvent event)方法，然后对于event的动作进行处理。常见的动作有MotionEvent.ACTION_DOWN,MotionEvent.ACTION_MOVE, MotionEvent.ACTION_UP。事件分发机制在上一章就讲解了，不了解的话，可以看看上一章Android 开发中的View和事件分发机制了解事件分发。
public boolean onInterceptHoverEvent(MotionEvent event) {
boolean intercepted = false;
int x = (int) event.getX();
int y = (int) event.getY();
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
//必须为false
//NOTE:如果在ACTION_DOWN返回true，那么后续的ACTION_MOVE和ACTION_UP
//事件都会直接交给父容器处理，这个时候就没法再传递给子元素了
intercepted = false;
break;
case MotionEvent.ACTION_MOVE:
if (isParentNeed()) { //父容器需要当前点击事件
intercepted = true;
} else {
intercepted = false;
}
break;
case MotionEvent.ACTION_UP:
//必须返回false，因为ACTION_UP本身没有太多意义
intercepted = false;
break;
default:
break;
}
mLastXIntercept = x;
mLastYIntercept = y;
return intercepted;
}
在onInterceotTouchEvent方法中，首先点击屏幕，父容器拦截ACTION_DOWN事件。必须返回false，即不拦截ACTION_DOWN事件，这样才能将事件传递给ViewGroup。甚至是View；其次是ACTION_MOVE事件，根据需求决定；最后是ACTION_UP,这里就必须返回false,因为是ACTION_UP事件本身没有太多意义。
4.2 内部拦截法
内部拦截法是指父容器不拦截任何事件，所有的事件都传递给了子元素。如果此事件需要就直接消耗掉，否则就交给父容器进行处理，这和Android 中的事件分发机制不一样，需要配合requestDisallowInterceptTouchEvent方法才能正常工作。我们重写子元素的dispatchTouchEvent()方法。
public boolean dispatchTouchEvent(MotionEvent event) {
int x = (int) event.getX();
int y = (int) event.getY();
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
getParent().requestDisallowInterceptTouchEvent(true);
break;
case MotionEvent.ACTION_MOVE:
int deltaX = x - mLastX;
int deltaY = y - mLastY;
if (isParentNeed()) { //父容器需要此点击事件
getParent().requestDisallowInterceptTouchEvent(false);
}
break;
case MotionEvent.ACTION_UP:
break;
default:
}
mLastX = x;
mLastY = y;
return super.dispatchTouchEvent(event);
}
上述代码实内部拦截法的典型代码，当面对不同的滑动策略时只需要修改里面的条件即可，其他不需要做改动而且也不能有改动。除了子元素需要处理以外，父元素也需要默认拦截除了ACTION_DOWN以外的其他事件，这样当子元素调用parent.requestDisallowInterceptTouchEvent(false)方法时父元素才能继续拦截所需要的事件。
还要重写外部View的onInterceptTouchEvent，当监听事件为ACTION_DOWN时，父元素不拦截。
public boolean onInterceptHoverEvent(MotionEvent event) {
if (event.getAction() == MotionEvent.ACTION_DOWN) {
return false;
} else {
return true;
}
}
下面是一个小demo。
github地址：https://github.com/wangxin3119/StylesViewDemo
