Android好奇宝宝_08_乱侃触摸事件传递
讲解触摸事件传递原理的网上有一大把,有从源码角度讲的,有从实际例子角度讲的。我这里呢只是记录下自己的理解,讲的可能没其他大牛透彻,有错误的跪求评论指正。
直接上图,对照图解和文字来分析触摸事件的传递。
(1)乱七八糟图解版:
(2)看图说话:
(2.1)上图并不包含Activity,Activity没有onInterceptTouchEvent方法,默认实现都是直接往下传递。
(2.2)讲解3个触摸事件控制方法的含义及其返回值的意义:
<1>onInterceptTouchEvent
onInterceptTouchEvent是ViewGroup特有的方法,Activity和View并没有此方法,它的作用是用于拦截触摸事件不再传递给子View(Activity和View并没有子View,所以没有此方法很符合逻辑),默认实现不拦截。如果拦截的话子View将完全接受不到触摸事件,子View的任何相关触摸事件的方法都不会被调用。(注:有例外情况我会在后面再说)(有特殊情况)
返回true:
表示拦截触摸事件,不继续调用子View的dispatchTouchEvent方法,直接调用自己的onTouchEvent方法。(有特殊情况)
返回false:
表示不拦截事件,继续去调用子View的dispatchTouchEvent。
<2>dispatchTouchEvent
用于分派触摸事件,注意是分派事件,而不是处理事件,这个方法应该做的是决定事件的传递方向,而不是处理消费掉触摸事件。
返回true:
表示自己要消费这个事件,但并不是马上消费,而是如果其子View没人消费的话,则自己消费。事件还是会继续往下传递的,只是在往上传递过程中如果还能到达自己的话,那么就会去消费这个事件。
返回false:
表示自己不消费这个事件,如果同时onTouchEvent也返回false表示不消费这个事件的话,就会继续往上传递给parent的onTouchEvent。
<3>onTouchEvent
用于处理事件,如果你想处理触摸事件并做出相应的动作,那么应该在这个方法中进行。
返回true:
表示自己想消费这个事件,并且马上生效,即刻消费,事件传递停止。
返回false:
表示自己不想消费这个事件,同时检查dispatchTouchEvent之前若是返回了true,就会发现:哎呀,我之前说子View没人处理的话,那么就我来处理。好吧,我要遵守诺言,就交给我处理吧,不要再传递了。
注意dispatchTouchEvent和onTouchEvent返回true的区别:
dispatchTouchEvent是没人消费的话就交给我消费,你们都没人要啊,那就给我吧,各位大爷真是好人啊。
onTouchEvent是我现在就要消费,其它人都没份了,都干嘛干嘛去,就是这么霸气,就是这么任性。
(2.3)传递过程中那些可能发生的事
触摸事件的第一个接收者总是Activity,Activity一般不会去消费触摸事件,而是直接传递给处于该触摸事件范围的View树集合。在View树中等级位置对应在触摸事件中的位置,即越外层的View,就位于越顶层,而其child则位于底层。即Activity在最顶层,然后接下来是容器控件,最后的View在最底层。
在一般情况下:
事件先从上往下,经过每一个dispatchTouchEvent。到达最后一个View时,调用其onTouchEvent,开始从下往上的传递过程,经过每一个onTouchEvent,这是没任何View想要消费触摸事件的情况。
可能发生的几个转折点:
<1>在从上往下的过程中,如果某个View的onInterceptTouchEvent返回了true,表示拦截事件,事件不会继续往下传递,而是直接调用这个View的onTouchEvent,注意这并不意味着这个View消费了这个事件,只是拦截了这个事件继续往下传递,剥夺了子View的消费权,提前开始从下往上的过程而已,是否由它消费还要看其onTouchEvent的返回值是否为true。(有特殊情况)
<2>在从下往上的过程中,如果某个View的onTouchEvent返回了true,表示自己想要消费这个事件,事件不会继续往上传递,事件传递结束。
<3>还是在从下往上的过程中,如果某个View在之前的dispatchTouchEvent方法返回了true,表示在之前这个View表明如果所有子View都不消费这个事件的话,那么就让我来消费,事件不会继续往上传递,事件传递结束。
(所有子View都不消费这个事件意味着所有子View的dispatchTouchEvent和onTouchEvent都返回了false,不然事件早被消费且传递结束了,根本不会再到达自己。)
<4>这个比较少用,某个子View调用了parent的requestDisallowInterceptTouchEvent方法,表示请求parent不要拦截事件,这种情况下parent的onInterceptTouchEvent返回了true也拦截不了事件,即让onInterceptTouchEvent方法失效,这就是上面3个标记了(有特殊情况)所说的特殊情况。
(2.4)记忆功能
记忆功能是指,如果某个View消费了Down事件,那么接下来的Move和Up等事件还是会从Activity顶层向下传递,但是传递到这个View时,即使这个View并没有用onInterceptTouchEvent方法来拦截事件,事件还是会被拦截,直接由该View处理。即如果一个View消费了Down事件,则接下来的Move和Up事件也会交给它消费。
这么做的原因是:一般情况下单一的触摸事件并不能形成有效的动作。比如一个拖动动作需要Down事件和连续的Move事件,点击动作至少需要一个Down事件和Up事件。把单一的触摸事件分派给不同的View,往往形成不了有意义的动作,所以加入了这个记忆功能来减少事件的传递。
(3)随便说点
理解触摸事件的传递一般是为了解决触摸事件发生冲突的情况,处理触摸事件冲突时要注意一点:
我们要处理的是由谁来处理触摸事件,而不是去修改消费这个事件的View应该去怎么处理。
有点拗口是吧,再说白一点就是我们应该控制谁来处理,而不是控制怎么去处理,每个View都有自己的处理逻辑,我们不应该去修改它。
举个栗子:
手指左右拖动不了ViewPager时,我们想得应该是怎么在手指左右拖动的情况下让ViewPager能获得触摸事件的消费权,而不要管接受到触摸事件后怎么让ViewPager随着手指滚动,这个功能ViewPager自己已经实现了,你把触摸事件给它,它就能滚。
好了,本篇完结,建议对触摸事件传递机制不熟悉的自己写个例子打印些Log日志验证一下,再百度谷歌下一下常见的触摸冲突及其解决办法。
求赞求评论求指点啊!!!
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。