每日一问：Android 滑动冲突，你们都是怎样处理的

坚持原创日更，短平快的 Android 进阶系列，敬请直接在微信公众号搜索：nanchen，直接关注并设为星标，精彩不容错过。

在 Android 开发中，滑动冲突总是我们一个无法避免的话题。而对于解决方案却是众说纷纭。比如 RecyclerView 嵌套 RecyclerView，直接通过相关方法禁掉内部 RecyclerView 的滑动；ScrollView 嵌套 RecyclerView 直接把 ScrollView 替换为 NestedScrollView 等等。但我们今天要说的是在自定义 View 中遇到滑动冲突时，我们又应该如何处理呢？

当然，今天的话题需要 View 的事件分发机制做理论前提，还不了解 View 的事件分发机制的小伙伴可以移步我之前面试系列的一篇文章：面试系列：讲讲 Android 的事件分发机制。

简单介绍 View 的时间分发机制

当然，这里也可以简单地提一下，基本的流程就是下面的伪代码。

public boolean dispatchTouchEvent(MotionEvent ev) {
    boolean consume = false;
    if (onInterceptTouchEvent(ev)) {
        consume = onTouchEvent(ev);
    }else{
        consume = child.dispatchTouchEvent(ev);
    }
    return consume;
}

当一个 ViewGroup 接收到一个事件的时候，首先会调用 dispatchTouchEvent() 方法进行事件分发，如果 onInterceptTouchEvent() 返回 true，则代表当前 View 会拦截事件，则直接回调 onTouchEvent() 方法进行事件处理。如果不拦截，则直接回调子 View 的 dispatchTouchEvent() 方法，如此反复，一直到最里面的子 View。

当一个点击事件产生后，它的传递过程遵循以下顺序：Activity => Window => View，即事件总是先传递给 Activity，Activity 再传递给 Window，最后 Window 再传递给顶层 DocorView，然后遵循上面的方式一直在最里层 View。

而处理事件则从最里层 View 不断回传给自己的外层 View，如果一直没有 View 进行处理，则直接会回传到 Activity 中。

既然都提了这么一点，也就突然想给出一些结论，参考自 Android 开发艺术探索：

一不小心发现还是挺多的，当然这些都是结论，具体可以跟着面试系列：讲讲 Android 的事件分发机制进行源码流程探讨，你会发现上面的结论很容易得到。

处理自定义 View 中的滑动冲突

对于大多数 Android 开发来说，处理滑动冲突好像很难，但实战一下又发现，好像也挺简单，因为这个实际上是有套路可循的。基本就两种方案：外部拦截法 && 内部拦截法。

外部拦截法

所谓外部拦截法，顾名思义，就是直接在父容器中直接拦截掉我们的滑动事件，让其不能进入到子元素中，这似乎和我们 RecyclerView 嵌套 RecyclerView 时禁用内部 RecyclerView 滑动有那么一丝相似之处，就是内部不处理就完事儿了。但细细品来又完全不一样，这里的外部拦截法会让内部元素根本就收不到滑动事件。

这种方法明显非常适合我们上面讲的事件分发机制。我们在接收 ACTION_MOVE 事件的时候，直接通过使 onInterceptTouchEvent() 方法返回 true 来直接拦截掉事件就可以了，伪代码想必大家也知道了：

override fun onInterceptTouchEvent(ev: MotionEvent?): Boolean {
    ev?.run {
        if (action == MotionEvent.ACTION_MOVE && 父容器需要点击事件){
            return true
        }
    }
    return super.onInterceptTouchEvent(ev)
}

代码很简单，我们仅仅需要在事件 ACTION_MOVE 时去处理我们的逻辑就好了，当满足我们的逻辑的时候，就拦截掉 ACTION_MOVE 事件给自己处理。

至于为什么不去拦截 ACTION_DOWN 和 ACTION_UP，想必大家也清楚了。上面说了，如果拦截了 ACTION_DOWN 事件，那后续的 ACTION_MOVE、ACTION_UP 等其它事件均不会在调用 onInterceptTouchEvent() 方法，会直接交给当前容器处理。而如果我们拦截掉 ACTION_UP 的话，肯定会导致子元素的点击事件无法被处理，因为大家肯定都知道一个点击事件从 ACTION_DOWN 开始，从 ACTION_UP 结束，二者缺一不可。

内部拦截法

内部拦截法相对外部拦截法会复杂一些，所以我们通常来说，都更加推荐用外部拦截法进行处理。不过，内部拦截法依然有着它非常重要的地位，具体情况有可能会遇到。

内部拦截法的话，需要 requestDisallowInterceptTouchEvent() 方法的支持，这个方法是干什么的呢？顾名思义，请求是否不允许拦截事件，其接收一个 boolean 参数，表示是否不允许拦截。

我们直接重写子元素的 dispatchTouchEvent() 方法，得到伪代码如下：

override fun dispatchTouchEvent(ev: MotionEvent?): Boolean {
    ev?.run {
        when(action){
            MotionEvent.ACTION_DOWN -> parent.requestDisallowInterceptTouchEvent(true)
            MotionEvent.ACTION_MOVE ->{
                if(满足需要让外部容器拦截事件){
                    parent.requestDisallowInterceptTouchEvent(false)
                }
            }
        }
    }
    return super.dispatchTouchEvent(ev)
}

想必代码也是非常简单易懂的，我们给父容器的 requestDisallowInterceptTouchEvent() 传递的参数代表是否不允许其拦截事件，当参数为 true 的时候代表不允许拦截，为 false 的时候代表拦截。所以看起来和外部拦截法也就如出一辙了。

不过仅仅有这点修改还不够，我们通过前面的理论基础知道，当我们的父容器拦截掉 ACTION_DOWN 事件的时候，所有的事件都无法再传递到子元素中，自然也就不会调用上面我们写的 dispatchTouchEvent() 方法了。所以我们在内部拦截法的时候还需要重写父容器的 onInterceptTouchEvent() 方法。

override fun onInterceptTouchEvent(ev: MotionEvent?): Boolean {
    ev?.run {
        if (action == MotionEvent.ACTION_DOWN){
            return false
        }
    }
    return super.onInterceptTouchEvent(ev)
}

至此，基本介绍了两种处理滑动冲突的解决方案，在自定义 View 的时候结合实际场景也就可以得心应手了。

除了滑动冲突，滑动处理也是一项非常有意思的工作，感兴趣的可以可以参考 NestedScrollingParent2 和 NestedScrollingChild2 哟。

南尘