处理自定义 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 的时候结合实际场景也就可以得心应手了。