教你用两招就完美解决 Android 滑动冲突！

冲突状况

在 Android 开发中，滑动冲突老是咱们一个没法避免的话题。而对于解决方案倒是众说纷纭。好比 RecyclerView 嵌套 RecyclerView，直接经过相关方法禁掉内部 RecyclerView 的滑动；ScrollView 嵌套 RecyclerView 直接把 ScrollView 替换为 NestedScrollView 等等。

但咱们今天要说的是在自定义 View 中遇到滑动冲突时，咱们又应该如何处理呢？固然，今天的话题须要 View 的事件分发机制作理论前提。

1. 简单介绍 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 再传递给顶层 DecorView，而后遵循上面的方式一直在最里层 View。

而处理事件则从最里层 View 不断回传给本身的外层 View，若是一直没有 View 进行处理，则直接会回传到 Activity 中。

onTouchEvent() 返回 true 表明本身要处理。

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

1.同一个事件序列是指从手指接触屏幕（ACTION_DOWN）的那一刻起，到手指离开屏幕（ACTION_UP）的那一刻结束，中间含不定数量的 ACTION_MOVE 事件。
2.某个 View 一旦决定拦截事件，那么这一个事件序列都只能由它处理，而且它的 onInterceptTouchEvent() 方法也不会再调用。换句话说，好比一个 ViewGroup 里面有数个子 View，一旦 ACTION_DOWN 事件从 Activity 传到这个 ViewGroup 被其拦截，则后续的 MOVE 和 UP 等事件也不会传递到里面的子 View 中。
3.若是一个 View 一旦开始处理事件，若是它不消耗 ACTION_DOWN 事件，即 onTouchEvent()返回为 false，那么同一事件序列中的其余事件也不会再交给它处理，直接会调用其父 View 的 onTouchEvent()。
4.若是 View 不消耗除 ACTION_DOWN 之外的其余事件，那么这个点击事件会消失，此时父元素的 onTouchEvent() 并不会被调用，而且固然 View 能够持续收到后续的事件，最终这些消失的点击事件会传递给 Activity 处理。
5.ViewGroup 默认不拦截事件，View 没有 onInterceptTouchEvent() 方法，一旦有事件传递给它，则直接会调用 onTouchEvent()，而且起默认都会消耗掉事件。除非它是不可点击的（即 clickable 和 longClickable 均为 false）。View 的 longClickable 默认都为 false，而 clickable 分状况，好比 Button 默认为 true，TextView 默认为 false。
6.View 的 enable 属性不会影响 onTouchEvent() 的默认返回值，哪怕一个 View 是 disable 状态的，只要它的 clickable 或者 longClickable 有一个为 true，那么它的 onTouchEvent() 就会返回 true。
7.requestDisallowInterceptTouchEvent() 能够在子元素中干预父元素的事件分发过程，可是没法干预 ACTION_DOWN 事件。
8.事件优先顺序：
setOnTouchListener() => onTouchEvent() => onClickListener()

一不当心发现仍是挺多的，固然这些都是结论。

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

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

2.1 外部拦截法

所谓外部拦截法，顾名思义，就是直接在父容器中直接拦截掉咱们的滑动事件，让其不能进入到子元素中，这彷佛和咱们 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 结束，两者缺一不可。

2.2 内部拦截法

内部拦截法相对外部拦截法会复杂一些，因此咱们一般来讲，都更加推荐用外部拦截法进行处理。不过，内部拦截法依然有着它很是重要的地位，具体状况有可能会遇到。

内部拦截法的话，须要 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 的时候结合实际场景也就能够驾轻就熟了。

文章提到的问题你遇到过吗？是怎么解决的？

---

最后对于程序员来讲，要学习的知识内容、技术有太多太多，要想不被环境淘汰就只有不断提高本身，历来都是咱们去适应环境，而不是环境来适应咱们！

这里附上上述的技术体系图相关的几十套腾讯、头条、阿里、美团等公司19年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了很多精力），包含知识脉络 + 诸多细节，因为篇幅有限，这里以图片的形式给你们展现一部分。

相信它会给你们带来不少收获：

上述【高清技术脑图】以及【配套的架构技术PDF】能够 加我wx：X1524478394 免费获取

当程序员容易，当一个优秀的程序员是须要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每一个阶段都须要掌握不一样的能力。早早肯定本身的职业方向，才能在工做和能力提高中甩开同龄人。