每日一问:Android 滑动冲突,你们都是怎样处理的 (2)

至于为什么不去拦截 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 哟。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpjpzg.html