事件的处理对象们
Android中View的事件处理用的是设计模式中的职责链模式。整个职责链中的处理对象是这样的:Activity->ViewGroup->View。
事件处理的三个重要阶段
这三类事件处理对象对事件的处理主要有三个阶段,对应三个重要的方法:
- 事件分发:
boolean dispatchTouchEvent(MotionEvent ev)
让当前处理对象决定是由自己来消费事件,还是将事件交给子View来处理。Activity、ViewGroup、View都有这个方法。 - 事件拦截:
boolean onInterceptTouchEvent(MotionEvent ev)
让处理对象决定要不要继续把时间传递给子View,还是自己消费掉算了 。只有ViewGroup有这个方法。 - 事件消费:
boolean onTouchEvent(MotionEvent ev)
决定是否消费掉事件,如何消费。Activity、ViewGroup、View都有这个方法。
这三个方法不同的返回值会影响事件的传递,其实还是挺复杂的。今天趁着劳动节,我来做做体力劳动,自定义一个ViewGroup和一个View,通过日志打印出这三个方法在不同的返回值下的调用。
onTouchEvent
all onTouchEvent falseviewGroup onTouchEvent true, view onTouchEvent false
- 返回
false
或者是super.onTouchEvent
时,表示当前View不想消费事件。则会逐级调用其父控件的onTouchEvent
方法,直到调用的父控件的onTouchEvent
返回true为止,即直到有父控件消费掉事件为止,或者是最终被Activity消费掉事件。这就是典型的职责链模式 - 当某个事件在最终被某个对象的
onTouchEvent
消费掉后,这个事件之后连续的事件都会在分发到那个对象后,直接被它的onTouchEvent
消费掉,而不会继续传递给子View了。从日志当中可以看出,View和ViewGroup的onTouchEvent
都返回false
,不消费事件,ACTION_DOWN事件最终被Activity消费掉。这此后ACTION_UP在被dispatch到Activity之后,就直接调用Activity的onTouchEvent
,不会继续往下传递给子View了。同样的,当ViewGroup消费ACTION_DOWN事件后,接下来的ACTION_MOVE, ACTION_UP都会在dispatch到ViewGroup后,调用ViewGroup的onTouchEvent
。
-
onTouchEvent
返回true
时,表示当前View想要消费掉事件。连续的所有的事件都会逐层被分发到当前View后,调用onTouchEvent
方法
onInterceptTouchEvent
ViewGroup onInterceptTouchEvent=true, onTouchEvent=trueViewGroup onInterceptTouchEvent=true, onTouchEvent=false
-
onInterceptTouchEvent
返回true
时,表示当前ViewGroup想拦截事件。此时会调用ViewGroup的onTouchEvent
方法,它的子View会收到ACTION_CANCEL事件。如果ViewGroup的onTouchEvent
返回true
,则接下来的事件都会直接交给ViewGroup的onTouchEvent
去处理,不会再调用onInterceptTouchEvent
了。也就是ViewGroup从某个点拦截住事件,并且消费掉事件后,就可以直接处理接下来的事件而不需要再次拦截了。如果ViewGroup的onTouchEvent
返回false
,那么事件会被逐级向上传给它的父View的onTouchEvent
去处理,并且此后连续的事件都不会传递给当前的ViewGroup了,也就是说当前ViewGroup再也没有机会收到接下来的事件了。因此,一般在自定义ViewGroup时,onInterceptTouchEvent
返回true
开始拦截事件时,都要让onTouchEvent
返回true
,并在onTouchEvent
处理接下来的事件。
- 当
onInterceptTouchEvent
返回false
或者super.onInterceptTouchEvent
时,表示当前ViewGroup不拦截事件,事件分发到子View - 当还没有确定事件讲会被哪个View处理时,事件在分发阶段都会调用
onInterceptTouchEvent
,但是一旦事件的处理对象明确后,onInterceptTouchEvent
讲不会再被调用。这就是为什么,当最底层的ViewonTouchEvent
返回true
消费掉事件后,接下来的事件不知道到底会被谁处理,因此被下发到底层View的过程中还是会调用ViewGroup的onInterceptTouchEvent
。而当事件被中途拦截,或者会被上层的某个父View处理后,ViewGroup的onInterceptTouchEvent
都不会被调用。
dispatchTouchEvent
Paste_Image.png- 返回'true',事件无疾而终,接下来的连续的事件也无疾而终无人处理。
- 返回
false
,事件也不会继续往下传递,但是会被逐级向上传递给父view的onTouchEvent
去处理。 - 返回
super.dispatchTouchEvent
时,事件才会正常的往下传递给子View。一开始学习的时候,我有一个误区,认为这三个方法要么返回true,要么返回false,返回true的时候是自己处理事件,返回false的时候是让子view去处理事件。其实不是这样的,返回true的时候确实是让自己来处理事件,但是必须要调用super.dispatchTouchEvent
才会把事件传递给子View进行处理。 - 参考简书其它朋友写的文章:
ViewGroup的dispatchTouchEvent是真正在执行“分发”工作,而View的dispatchTouchEvent方法,并不执行分发工作,或者说它分发的对象就是自己。一般情况下,我们不该在普通View内重写dispatchTouchEvent方法,因为它并不执行分发逻辑。当Touch事件到达View时,我们该做的就是是否在onTouchEvent事件中处理它。
网友评论