View的事件传递机制

先说两个重要的概念：
1.同一事件序列事件序列：即手指触摸屏幕产生ACTION_DOWN开始，其中包含不定数量的ACTION_MOVE等，以ACTION_UP结束，即手指离开屏幕那一刻。这就是一个事件序列。
2.事件的传递顺序：当一个点击操作产生之后，事件最先传递给当前的Activity，由Activity的dispatchTouchEvent来进行事件的分发，具体的工作是由Activity内部的Window（PhoneWindow）来完成的。Window会将时间传递给Activity的顶级View DecorView，即setContentView所设置的View的父容器，通过Activity.getWindow.getDecorView()可以获得。Activity的dispatchTouchEvent完整源码如下：
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
这段代码比较简单，也很好理解。其中onUserInteraction是一个空实现。按照上面的逻辑，其实在一个事件到来时，通过重写Activity的dispatchTouchEvent方法可以做很多事情。当所有的View的onTouchEvent都返回了false，那么Activity将调用自己的onTouchEvent来处理事件。

View的点击事件分发过程由三个很重要的方法来完成：dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent。

public boolean dispatchTouchEvent(MotionEvent e):用来进行事件的分发，如果当前事件能够传递给当前View，那么此方法一定会被调用，返回结果受当前View的onTouchEvent和下级View的dispatchTouchEvent方法的影响，表示是否消耗当前事件。

public boolean onInterceptTouchEvent(MotionEvent e):在上面方法的内部调用，注意，此方法只有ViewGroup才有，用来判断ViewGroup是否拦截某个事件，如果拦截某个事件，那么在同一个事件序列当中，此方法不会被再次调用，返回结果表示是否拦截当前事件。

public boolean onTouchEvent(MotionEvent e):在dispatchTouchEvent方法中调用，用来处理点击事件，返回结果表示是否消耗当前事件。

上述三个方法的关系可以大概用下面的伪代码表示：
public boolean dispatchTouchEvent（MotionEvent ev）{
boolean consume = false;
if(onInterceptTouchEvent(ev)){
consume = onTouchEvent(ev);
}else{
consume = child.dispatchTouchEvent(ev); 
if(consume==false && ev.getAction == MotionEvent.ACTION_DOWN){
onTouchEvent(ev);
}
}
return consume;
}

通过上诉代码可以大致看到点击事件的传递规则：对于一个根ViewGroup来说，点击事件产生以后，首先会传递给它，这时它的dispatchTouchEvent方法会被调用，如果这个ViewGroup的onInterceptTouchEvent方法返回true，就代表它要拦截事件，接着事件就会交给它处理，即调用ViewGroup的onTouchEvent方法；如果这个ViewGroup的onInterceptTouchEvent返回了false，就表示它不拦截当前事件，这时，这时当前事件就会继续传递给它的子元素，接着子元素的dispatchTouchEvent方法就会被调用，如此反复。如果子元素没有处理事件，且事件是ACTION_DOWN的话，那么ViewGroup会自己处理，如果此时它也不处理的这个ACTION_DOWN的话（返回了false），那么会继续交给它的上级ViewGroup来处理，如此反复。最后都没有处理的话，会重新传递到Activity中。

根据事件传递的机制，可以得出以下结论：

1）同一个事件序列是指从手指接触屏幕的那一刻起，到手指离开屏幕的那一刻结束，在这个过程中所产生的一系列事件，这个事件序列以MotionEvent.ACTION_DOWN事件开始，中间含有数量不定的MotionEvent.ACTION_MOVE事件，最终以MotionEvent.ACTION_UP事件结束。

2）正常情况下，一个事件序列只能被一个View拦截且消耗。这一条的原因可以参考（3），因为一旦一个元素拦截了某次事件，那么同一个事件序列内的所有事件都会直接交给它处理，因此同一个事件序列中的事件不能分别由两个View同时处理，但是通过特殊的手段可以做到，比如一个View将本身该自己处理的事件通过onTouchEvent强行传递给其他View处理。

3）某个View一旦决定拦截，那么这一个事件序列都只能由它来处理（如果事件序列能够传递给它的话），并且它的onInterceptTouchEvent不会再被调用。这条也很好理解，就是说当一个View决定拦截一个事件后，那么系统会把同一个事件序列内的其他方法都直接交给它来处理，因此 就不用再调用 这个View的onInterceptTouchEvent去询问它是否要拦截了。

4）某个View一旦开始处理事件，如果它不消耗ACTION_DOWN事件 （onTouchEvent返回了false），那么同一事件序列中的其他事件都不会再交给它来处理，并且事件将重新交由它的父元素去处理，即父元素的onTouchEvent会被调用。意思就是事件（ACTION_DOWN）一旦交给一个View处理，那么它就必须消耗掉，否则同一事件序列中剩下的事件就不再交给它来处理了。对于非ACTION_DOWN事件参看第5条。

5）如果View不消耗除ACTION_DOWN以外的其他事件，那么这个点击事件会消失，此时父元素的onTouchEvent并不会被调用，并且当前View可以持续收到后续的事件，最终这些消失的点击事件会传递给Activity处理。

6）ViewGroup默认不拦截任何事件。Android源码中VIewGroup的onInterceptTouchEvent方法 默认返回false。

7）View没有onInterceptTouchEvent方法，一旦有点击事件传递给它，那么它的onTouchEvent方法就会被调用。

8）View的onTouchEvent默认都会消耗事件（返回true），除非它是不可点击的(clickable 和 longClickable 同时为false)。View的longClickable属性默认都为false，clickable属性要分情况，比如Button的clickable属性默认为true，而TextView的clickable属性默认为false。通过setClickable和setLongClickable可以分别改变View的clickable和longClickable属性。setOnClickListener会自动将View的clickable属性设为true，setOnLongClickListener同理。

9）View的enable属性不影响onTouchEvent的默认返回值。哪怕一个View是disable状态的，只要它的clickable 或者 lonClickable有一个为true，那么它的onTouchEvent（默认不重写的情况下）就返回true。

10) onClick会发生的前提是当前View是可点击的，并且它收到了ACTION_DOWN 和ACTION_UP事件。

11）事件传递的过程是由外向内的，即事件总是先传递给父元素，然后再由父元素分发给子View，通过调用父元素的requestDisallowInterceptTouchEvent方法可以在子元素中干预父元素的的事件颁发过程，但是ACTION_DOWN事件除外，因为当ACTION_DOWN这个事件到来的时候，会重置这个标记位。