Android View事件处理

事件的处理对象们

Android中View的事件处理用的是设计模式中的职责链模式。整个职责链中的处理对象是这样的：Activity->ViewGroup->View。

事件处理的三个重要阶段

这三类事件处理对象对事件的处理主要有三个阶段，对应三个重要的方法：

1. 事件分发：boolean dispatchTouchEvent(MotionEvent ev)
   让当前处理对象决定是由自己来消费事件，还是将事件交给子View来处理。Activity、ViewGroup、View都有这个方法。
2. 事件拦截：boolean onInterceptTouchEvent(MotionEvent ev)
   让处理对象决定要不要继续把时间传递给子View，还是自己消费掉算了 。只有ViewGroup有这个方法。
3. 事件消费：boolean onTouchEvent(MotionEvent ev)
   决定是否消费掉事件，如何消费。Activity、ViewGroup、View都有这个方法。

这三个方法不同的返回值会影响事件的传递，其实还是挺复杂的。今天趁着劳动节，我来做做体力劳动，自定义一个ViewGroup和一个View，通过日志打印出这三个方法在不同的返回值下的调用。

onTouchEvent

all onTouchEvent false

viewGroup 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

• onTouchEvent返回true时，表示当前View想要消费掉事件。连续的所有的事件都会逐层被分发到当前View后，调用onTouchEvent方法

onInterceptTouchEvent

ViewGroup onInterceptTouchEvent=true, onTouchEvent=true

ViewGroup 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处理接下来的事件。

ViewGroup onInterceptTouchEvent=false

• 当onInterceptTouchEvent返回false或者super.onInterceptTouchEvent时，表示当前ViewGroup不拦截事件，事件分发到子View
• 当还没有确定事件讲会被哪个View处理时，事件在分发阶段都会调用onInterceptTouchEvent，但是一旦事件的处理对象明确后，onInterceptTouchEvent讲不会再被调用。这就是为什么，当最底层的ViewonTouchEvent返回true消费掉事件后，接下来的事件不知道到底会被谁处理，因此被下发到底层View的过程中还是会调用ViewGroup的onInterceptTouchEvent。而当事件被中途拦截，或者会被上层的某个父View处理后，ViewGroup的onInterceptTouchEvent都不会被调用。

dispatchTouchEvent

Paste_Image.png

• 返回'true'，事件无疾而终，接下来的连续的事件也无疾而终无人处理。

Paste_Image.png

• 返回false，事件也不会继续往下传递，但是会被逐级向上传递给父view的onTouchEvent去处理。
• 返回super.dispatchTouchEvent时，事件才会正常的往下传递给子View。一开始学习的时候，我有一个误区，认为这三个方法要么返回true，要么返回false，返回true的时候是自己处理事件，返回false的时候是让子view去处理事件。其实不是这样的，返回true的时候确实是让自己来处理事件，但是必须要调用super.dispatchTouchEvent才会把事件传递给子View进行处理。
• 参考其它朋友写的文章：

ViewGroup的dispatchTouchEvent是真正在执行“分发”工作，而View的dispatchTouchEvent方法，并不执行分发工作，或者说它分发的对象就是自己。一般情况下，我们不该在普通View内重写dispatchTouchEvent方法，因为它并不执行分发逻辑。当Touch事件到达View时，我们该做的就是是否在onTouchEvent事件中处理它。