一 事件的产生与起始
我们在点击手机的时候，屏幕下的电容传感器就会把坐标通过模数转换成具体的数字，然后通过android的linux层里面的JNI进行封装，最终把这么具体的坐标值和动作封装到PhoneWindowService里的一个队列，然后依次在这个队列取出event，分发给Activity的dispathTounchEvent这个方法。我们做android开发的只需要了解事件分发从Actiivty开始就行了，前面的比较底层就不深入研究了。
二 事件调用的方法
我们都知道，事件分发的难点其实就是搞懂事件在View树下是如何传递的。
我们对屏幕的点击，滑动，抬起等一系的动作都是由一个一个MotionEvent对象组成的。根据不同动作，主要有以下三种事件类型：
- ACTION_DOWN：手指刚接触屏幕，按下去的那一瞬间产生该事件
- ACTION_MOVE：手指在屏幕上移动时候产生该事件
- ACTION_UP：手指从屏幕上松开的瞬间产生该事件
从ACTION_DOWN开始到ACTION_UP结束我们称为一个事件序列
正常情况下，无论你手指在屏幕上有多么骚的操作，最终呈现在MotionEvent上来讲无外乎下面两种:
1.点击后抬起，也就是单击操作：ACTION_DOWN -> ACTION_UP
2.点击后再风骚的滑动一段距离，再抬起：ACTION_DOWN -> ACTION_MOVE -> … -> ACTION_MOVE -> ACTION_UP
而处理事件传递的方法有三个，分别是：
- dispatchTouchEvent：这个负责事件分发，分发到子View
- onInterceptTouchEvent：这个负责拦截，决定是否分发到子View
- onTouchEvent：这个是负责消费，就是处理事件逻辑
我们就从ACTION_DOWN这个事件的传递来跟着源码解析一下，事件是如何在View树上进行传递的
三 ACTION_DOWN在View树上的传递
前面已经说过了，当我们点击屏幕的时候，首先会调用Actiivty的dispatchTounchEvent这个方法，我们来看一下这个方法：
Activity：dispatchTouchEvent
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
//1
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
通过上面的代码我们可以发现，事件会给Activity附属的Window进行分发。如果返回true，那么事件被消费。如果返回false表示事件发下去却没有View可以进行处理，则最后return Activity自己的onTouchEvent方法。
重点看注释1，这里调用了getWindow其实就是PhoneWindow，我们继续跟踪
PhoneWindow：superDispatchTouchEvent
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
ok,到这里就很清楚了，最终调用了DecorView的superDispatchTouchEvent方法，我们知道DecorView是继承树是：DecorView–> FrameLayout–>ViewGroup,所以跟踪代码，最终会调用ViewGrunp的dispatchTouchEvent这个方法。
ViewGrunp的dispatchTouchEvent的代码太长，这里先来一个伪代码得出结论，然后我们在根据结论来去看源码，这样就不会眼花了。
ViewGrunp的dispatchTouchEvent的伪代码
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean consume = false;//事件是否被消费
if (onInterceptTouchEvent(ev)){//调用onInterceptTouchEvent判断是否拦截事件
consume = onTouchEvent(ev);//如果拦截则调用自身的onTouchEvent方法
}else{
consume = child.dispatchTouchEvent(ev);//不拦截调用子View的dispatchTouchEvent方法
}
return consume;//返回值表示事件是否被消费，true事件终止，false调用父View的onTouchEvent方法
}
Ok，我们根据上面的伪代码，再来对比一下ViewGrounp里的dispatchTouchEvent源码，这样就能清晰的理解源码里的作用，不至于这么乱！
class ViewGroup:
public boolean dispatchTouchEvent(MotionEvent ev) {
...
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// Handle an initial down.
if (actionMasked == MotionEvent.ACTION_DOWN) {
// Throw away all previous state when starting a new touch gesture.
// The framework may have dropped the up or cancel event for the previous gesture
// due to an app switch, ANR, or some other state change.
cancelAndClearTouchTargets(ev);
//清除FLAG_DISALLOW_INTERCEPT设置并且mFirstTouchTarget 设置为null
resetTouchState();
}
// Check for interception.
final boolean intercepted;//是否拦截事件
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
//FLAG_DISALLOW_INTERCEPT是子View通过
//requestDisallowInterceptTouchEvent方法进行设置的
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
//调用onInterceptTouchEvent方法判断是否需要拦截
intercepted = onInterceptTouchEvent(ev);
ev.setAction(action); // restore action in case it was changed
} else {
intercepted = false;
}
} else {
// There are no touch targets and this action is not an initial down
// so this view group continues to intercept touches.
intercepted = true;
}
...
}
我们在处理滑动事件冲突的时候，在子View里通常会调用requestDisallowInterceptTouchEvent这个方法来控制父View对事件的分发，从而解决冲突，这个方法设置的其实就是源码里的FLAG_DISALLOW_INTERCEPT这个标志位，从源码里我们也可以看出来，不是所有事件都可以通过这种方法进行控制的，在ACTION_DOWN事件下，会调用resetTouchState()这个方法重置标志位，所以在处理滑动冲突的时候大家要特别注意！！
mFirstTouchTarget 这个变量我们现在暂时理解为：如果事件由子View去处理时mFirstTouchTarget 会被赋值并指向子View
源码解析：
所以当事件为ACTION_DOWN或者 mFirstTouchTarget ！=null（即事件由子View处理）时会进行拦截判断。具体规则是如果子View设置了FLAG_DISALLOW_INTERCEPT标志位，那么intercepted =false。否则调用onInterceptTouchEvent方法。
如果事件不为ACTION_DOWN 且事件为ViewGroup本身处理（即mFirstTouchTarget ==null）那么intercepted =true，很显然事件已经交给自己处理根本没必要再调用onInterceptTouchEvent去判断是否拦截。
Ok，我们继续来看下一段代码，假设ViewGrounp不拦截事件，那么事件自然会传递到它的子View里去，那么ViewGrounp怎么在众多子View中精确找到我们点击的子View的呢？继续往下看：
class ViewGroup:
public boolean dispatchTouchEvent(MotionEvent ev) {
final View[] children = mChildren;
//对子View进行遍历
for (int i = childrenCount - 1; i >= 0; i--) {
final int childIndex = getAndVerifyPreorderedIndex(
childrenCount, i, customOrder);
final View child = getAndVerifyPreorderedView(
preorderedList, children, childIndex);
// If there is a view that has accessibility focus we want it
// to get the event first and if not handled we will perform a
// normal dispatch. We may do a double iteration but this is
// safer given the timeframe.
if (childWithAccessibilityFocus != null) {
if (childWithAccessibilityFocus != child) {
continue;
}
childWithAccessibilityFocus = null;
i = childrenCount - 1;
}
//判断1，View可见并且没有播放动画。2，点击事件的坐标落在View的范围内
//如果上述两个条件有一项不满足则continue继续循环下一个View
if (!canViewReceivePointerEvents(child)
|| !isTransformedTouchPointInView(x, y, child, null)) {
ev.setTargetAccessibilityFocus(false);
continue;
}
newTouchTarget = getTouchTarget(child);
//如果有子View处理即newTouchTarget 不为null则跳出循环。
if (newTouchTarget != null) {
// Child is already receiving touch within its bounds.
// Give it the new pointer in addition to the ones it is handling.
newTouchTarget.pointerIdBits |= idBitsToAssign;
break;
}
resetCancelNextUpFlag(child);
//dispatchTransformedTouchEvent第三个参数child这里不为null
//实际调用的是child的dispatchTouchEvent方法
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
// Child wants to receive touch within its bounds.
mLastTouchDownTime = ev.getDownTime();
if (preorderedList != null) {
// childIndex points into presorted list, find original index
for (int j = 0; j < childrenCount; j++) {
if (children[childIndex] == mChildren[j]) {
mLastTouchDownIndex = j;
break;
}
}
} else {
mLastTouchDownIndex = childIndex;
}
mLastTouchDownX = ev.getX();
mLastTouchDownY = ev.getY();
//当child处理了点击事件，那么会设置mFirstTouchTarget 在addTouchTarget被赋值
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
//子View处理了事件，然后就跳出了for循环
break;
}
}
}
很显然，依然是通过for循环遍历每一个子View，通过条件判断，找到要响应的子View之后，执行响应的方法之后跳出for循环。
我们先来看看找到响应子View的这两个条件：
1.如果View可见并且没有播放动画canViewReceivePointerEvents方法判断
/**
* Returns true if a child view can receive pointer events.
* @hide
*/
private static boolean canViewReceivePointerEvents(@NonNull View child) {
return (child.mViewFlags & VISIBILITY_MASK) == VISIBLE
|| child.getAnimation() != null;
}
注意判断条件加了！，所以判断逻辑要反过来
2.点击事件的坐标落在View的范围内isTransformedTouchPointInView方法判断
/**
* Returns true if a child view contains the specified point when transformed
* into its coordinate space.
* Child must not be null.
* @hide
*/
protected boolean isTransformedTouchPointInView(float x, float y, View child,
PointF outLocalPoint) {
final float[] point = getTempPoint();
point[0] = x;
point[1] = y;
transformPointToViewLocal(point, child);
//调用View的pointInView方法进行判断坐标点是否在View内
final boolean isInView = child.pointInView(point[0], point[1]);
if (isInView && outLocalPoint != null) {
outLocalPoint.set(point[0], point[1]);
}
return isInView;
}
如果满足这两个条件，就会调用这段代码newTouchTarget = getTouchTarget(child);
/**
* Gets the touch target for specified child view.
* Returns null if not found.
*/
private TouchTarget getTouchTarget(@NonNull View child) {
for (TouchTarget target = mFirstTouchTarget; target != null; target = target.next) {
if (target.child == child) {
return target;
}
}
return null;
}
可以看到，当mFirstTouchTarget不等于null的时候，就会判断当前的child和target里的child是否是同一个view，如果是就直接将mFirstTouchTarget赋值给newTouchTarget ，很显然，当我们第一次点击
View的时候，代码走到这里的时候，mFirstTouchTarget还没有被赋值，此时自然还是等于null，当我们把事件分发给子View 的时候，mFirstTouchTarget就会指向当前child，此时显然还没开始分发，我们继续往下看关键代码
dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)方法。为方便我们将代码再一次贴到后面来:
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
// Child wants to receive touch within its bounds.
mLastTouchDownTime = ev.getDownTime();
if (preorderedList != null) {
// childIndex points into presorted list, find original index
for (int j = 0; j < childrenCount; j++) {
if (children[childIndex] == mChildren[j]) {
mLastTouchDownIndex = j;
break;
}
}
} else {
mLastTouchDownIndex = childIndex;
}
mLastTouchDownX = ev.getX();
mLastTouchDownY = ev.getY();
//当child处理了点击事件，那么会设置mFirstTouchTarget 在addTouchTarget被赋值
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
//子View处理了事件，然后就跳出了for循环
break;
}
可以看到它被最后一个if包围，如果它返回为true，那么就break跳出循环，如果返回为false则继续遍历下一个子View。我们具体来看一下这个方法的关键代码：
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
if (child == null) {
handled = super.dispatchTouchEvent(event);
} else {
handled = child.dispatchTouchEvent(event);
}
}
}
这个代码很简单，很显然child是不等于null的，此时会调用子view的dispatchTouchEvent()方法，如果没有子View（满足上面提到的两个条件的VIew），此时ViewGrounp就会调用父类的dispatchTouchEvent，其实就是VIew 的dispatchTouchEvent()方法。
再回头看dispatchTransformedTouchEvent则为true进入最后一个if语句，有这么一句
newTouchTarget = addTouchTarget(child, idBitsToAssign);
/**
* Adds a touch target for specified child to the beginning of the list.
* Assumes the target child is not already present.
*/
private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) {
final TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
target.next = mFirstTouchTarget;
mFirstTouchTarget = target;
return target;
}
没错，mFirstTouchTarget 就是在addTouchTarget中被赋值！到此子View遍历结束
如果在遍历完子View以后ViewGroup仍然没有找到事件处理者即ViewGroup并没有子View或者子View处理了事件，但是子View的dispatchTouchEvent返回了false（一般是子View的onTouchEvent方法返回false）那么ViewGroup会去处理这个事件。
从代码上看就是我们遍历的dispatchTransformedTouchEvent方法返回了false。那么mFirstTouchTarget 必然为null；
在ViewGroup的dispatchTouchEvent遍历完子View后有下面的处理。
// Dispatch to touch targets.
if (mFirstTouchTarget == null) {
// No touch targets so treat this as an ordinary view.
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
}
上面的dispatchTransformedTouchEvent方法第三个child参数传null
我们刚看了这个方法。当child为null时，handled = super.dispatchTouchEvent(event);所以此时将调用View的dispatchTouchEvent方法，点击事件给了View。到此事件分发过程全部结束！
结论：
-
ViewGroup会遍历所有子View去寻找能够处理点击事件的子View（可见，没有播放动画，点击事件坐标落在子View内部）最终调用子View的dispatchTouchEvent方法处理事件
-
当子View处理了事件则mFirstTouchTarget 被赋值，并终止子View的遍历。
3、如果ViewGroup并没有子View或者子View处理了事件，但是子View的dispatchTouchEvent返回了false（一般是子View的onTouchEvent方法返回false）那么ViewGroup会去处理这个事件（本质调用View的dispatchTouchEvent去处理）
四 View最终如何处理事件？
class View:
public boolean dispatchTouchEvent(MotionEvent ev) {
// If the event should be handled by accessibility focus first.
if (event.isTargetAccessibilityFocus()) {
// We don't have focus or no virtual descendant has it, do not handle the event.
if (!isAccessibilityFocusedViewOrHost()) {
return false;
}
// We have focus and got the event, then use normal event dispatch.
event.setTargetAccessibilityFocus(false);
}
boolean result = false;
if (mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onTouchEvent(event, 0);
}
final int actionMasked = event.getActionMasked();
if (actionMasked == MotionEvent.ACTION_DOWN) {
// Defensive cleanup for new gesture
stopNestedScroll();
}
if (onFilterTouchEventForSecurity(event)) {
if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
result = true;
}
//noinspection SimplifiableIfStatement
ListenerInfo li = mListenerInfo;
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
result = true;
}
if (!result && onTouchEvent(event)) {
result = true;
}
}
if (!result && mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onUnhandledEvent(event, 0);
}
// Clean up after nested scrolls if this is the end of a gesture;
// also cancel it if we tried an ACTION_DOWN but we didn't want the rest
// of the gesture.
if (actionMasked == MotionEvent.ACTION_UP ||
actionMasked == MotionEvent.ACTION_CANCEL ||
(actionMasked == MotionEvent.ACTION_DOWN && !result)) {
stopNestedScroll();
}
return result;
}
相比ViewGrounp的方法代码量。View的相对较少，因为它没有子View需要遍历分发，我们来看一下核心的代码：
//如果窗口没有被遮盖
if (onFilterTouchEventForSecurity(event)) {
if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
result = true;
}
//noinspection SimplifiableIfStatement
//当前监听事件
ListenerInfo li = mListenerInfo;
//需要特别注意这个判断当中的li.mOnTouchListener.onTouch(this, event)条件
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
result = true;
}
//result为false调用自己的onTouchEvent方法处理
if (!result && onTouchEvent(event)) {
result = true;
}
}
相信很多人在面试或者应用的时候都遇到过这个问题，ontounch的监听先执行，还是onClick的监听先执行？这里就可以得到答案了。当mOnTouchListener.onTouch()返回ture时，会执行完onTounch方法后事件就此消费，不会再执行onTouchEvent()方法，而onClick方法是在onTouchEvent内部调用的，所以onClick也不会被调用；当没有设置OnTouchListener或者设置了OnTouchListener但是onTouch方法返回false则会调用View自己的onTouchEvent方法。
接下来看onTouchEvent方法：
class View:
public boolean onTouchEvent(MotionEvent event) {
final float x = event.getX();
final float y = event.getY();
final int viewFlags = mViewFlags;
final int action = event.getAction();
//1.如果View是设置成不可用的（DISABLED）仍然会消费点击事件
if ((viewFlags & ENABLED_MASK) == DISABLED) {
if (action == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) {
setPressed(false);
}
// A disabled view that is clickable still consumes the touch
// events, it just doesn't respond to them.
return (((viewFlags & CLICKABLE) == CLICKABLE
|| (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)
|| (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE);
}
...
//2.CLICKABLE 和LONG_CLICKABLE只要有一个为true就消费这个事件
if (((viewFlags & CLICKABLE) == CLICKABLE ||
(viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE) ||
(viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE) {
switch (action) {
case MotionEvent.ACTION_UP:
boolean prepressed = (mPrivateFlags & PFLAG_PREPRESSED) != 0;
if ((mPrivateFlags & PFLAG_PRESSED) != 0 || prepressed) {
// take focus if we don't have it already and we should in
// touch mode.
boolean focusTaken = false;
if (isFocusable() && isFocusableInTouchMode() && !isFocused()) {
focusTaken = requestFocus();
}
if (prepressed) {
// The button is being released before we actually
// showed it as pressed. Make it show the pressed
// state now (before scheduling the click) to ensure
// the user sees it.
setPressed(true, x, y);
}
if (!mHasPerformedLongPress && !mIgnoreNextUpEvent) {
// This is a tap, so remove the longpress check
removeLongPressCallback();
// Only perform take click actions if we were in the pressed state
if (!focusTaken) {
// Use a Runnable and post this rather than calling
// performClick directly. This lets other visual state
// of the view update before click actions start.
if (mPerformClick == null) {
mPerformClick = new PerformClick();
}
if (!post(mPerformClick)) {
//3.在ACTION_UP方法发生时会触发performClick()方法
performClick();
}
}
}
...
break;
}
...
return true;
}
return false;
}
从注释1处我们知道，尽管View是DISABLED的状态，依然可以消费事件，只是我们点击看起来没什么反应罢了，其次，只要CLICKABLE和LONG_CLICKABLE有一个为true，就一定会消费这个事件，就是onTouchEvent返回true。这点也说明了如果没有重写onTouchEvent的方法的话，事件传递到最底层的View都会把事件消费掉。View的longClickable默认为false，clickable需要区分情况，如Button的clickable默认为true，而TextView的clickable默认为false。
五 附图
这里需要注意，当onTouchEvent()返回false的时候，其实此时当前View的diapatchTouchEvent返回false，并不是像箭头一样直接调用了父View的onTounchEvent，而是通过返回值直接回到父View的dispatchTounchEvent，此时父View dispatchTounchEvent返回了false，根据上述ViewGrounp的代码，此时mFirstTouchTarget必然是等于null的，此时会调用ViewGrounp的super.dispatchTouchEvent(event)；最终才会调用ViewGrounp的onTounchEvent()方法。
六 事件流列举
ViewGroup 和View的这些方法的默认实现就是会让整个事件安装U型完整走完，所以 return super.xxxxxx() 就会让事件依照U型的方向的完整走完整个事件流动路径），中间不做任何改动，不回溯、不终止，每个环节都走到。
所以如果看到方法return super.xxxxx() 那么事件的下一个流向就是走U型下一个目标，稍微记住上面这张图，你就能很快判断出下一个走向是哪个控件的哪个函数。
onInterceptTouchEvent 的作用
Intercept 的意思就拦截，每个ViewGroup每次在做分发的时候，问一问拦截器要不要拦截（也就是问问自己这个事件要不要自己来处理）如果要自己处理那就在onInterceptTouchEvent方法中 return true就会交给自己的onTouchEvent的处理，如果不拦截就是继续往子控件往下传。默认是不会去拦截的，因为子View也需要这个事件，所以onInterceptTouchEvent拦截器return super.onInterceptTouchEvent()和return false是一样的，是不会拦截的，事件会继续往子View的dispatchTouchEvent传递
ViewGroup 和View 的dispatchTouchEvent方法返回super.dispatchTouchEvent()的时候事件流走向
首先看下ViewGroup 的dispatchTouchEvent，之前说的return true是终结传递。return false 是回溯到父View的onTouchEvent，然后ViewGroup怎样通过dispatchTouchEvent方法能把事件分发到自己的onTouchEvent处理呢，return true和false 都不行，那么只能通过Interceptor把事件拦截下来给自己的onTouchEvent，所以ViewGroup dispatchTouchEvent方法的super默认实现就是去调用onInterceptTouchEvent，记住这一点。
那么对于View的dispatchTouchEvent return super.dispatchTouchEvent()的时候呢事件会传到哪里呢，很遗憾View没有拦截器。但是同样的道理return true是终结。return false 是回溯会父类的onTouchEvent，怎样把事件分发给自己的onTouchEvent 处理呢，那只能return super.dispatchTouchEvent,View类的dispatchTouchEvent（）方法默认实现就是能帮你调用View自己的onTouchEvent方法的。
说了这么多，不知道有说清楚没有，我这边最后总结一下：
对于 dispatchTouchEvent，onTouchEvent，return true是终结事件传递。return false 是回溯到父View的onTouchEvent方法。
ViewGroup 想把自己分发给自己的onTouchEvent，需要拦截器onInterceptTouchEvent方法return true 把事件拦截下来。
ViewGroup 的拦截器onInterceptTouchEvent 默认是不拦截的，所以return super.onInterceptTouchEvent()=return false；
View 没有拦截器，为了让View可以把事件分发给自己的onTouchEvent，View的dispatchTouchEvent默认实现（super）就是把事件分发给自己的onTouchEvent。
ViewGroup和View 的dispatchTouchEvent 是做事件分发，那么这个事件可能分发出去的四个目标
注：------> 后面代表事件目标需要怎么做。
1、 自己消费，终结传递。------->return true ；
2、 给自己的onTouchEvent处理-------> 调用super.dispatchTouchEvent()系统默认会去调用 onInterceptTouchEvent，在onInterceptTouchEvent return true就会去把事件分给自己的onTouchEvent处理。
3、 传给子View------>调用super.dispatchTouchEvent()默认实现会去调用 onInterceptTouchEvent 在onInterceptTouchEvent return false，就会把事件传给子类。
4、 不传给子View，事件终止往下传递，事件开始回溯，从父View的onTouchEvent开始事件从下到上回归执行每个控件的onTouchEvent------->return false；
注：由于View没有子View所以不需要onInterceptTouchEvent 来控件是否把事件传递给子View还是拦截，所以View的事件分发调用super.dispatchTouchEvent()的时候默认把事件传给自己的onTouchEvent处理（相当于拦截），对比ViewGroup的dispatchTouchEvent 事件分发，View的事件分发没有上面提到的4个目标的第3点。
ViewGroup和View的onTouchEvent方法是做事件处理的，那么这个事件只能有两个处理方式：
1、自己消费掉，事件终结，不再传给谁----->return true;
2、继续从下往上传，不消费事件，让父View也能收到到这个事件----->return false;View的默认实现是不消费的。所以super==false。
ViewGroup的onInterceptTouchEvent方法对于事件有两种情况：
1、拦截下来，给自己的onTouchEvent处理—>return true;
2、不拦截，把事件往下传给子View---->return false,ViewGroup默认是不拦截的，所以super==false；
6.2 关于ACTION_MOVE 和 ACTION_UP
上面讲解的都是针对ACTION_DOWN的事件传递，ACTION_MOVE和ACTION_UP在传递的过程中并不是和ACTION_DOWN 一样，你在执行ACTION_DOWN的时候返回了false，后面一系列其它的action就不会再得到执行了。简单的说，就是当dispatchTouchEvent在进行事件分发的时候，只有前一个事件（如ACTION_DOWN）返回true，才会收到ACTION_MOVE和ACTION_UP的事件。具体这句话很多博客都说了，但是具体含义是什么呢？我们来看一下下面的具体分析。
上面提到过了，事件如果不被打断的话是会不断往下传到叶子层（View），然后又不断回传到Activity，dispatchTouchEvent 和 onTouchEvent 可以通过return true 消费事件，终结事件传递，而onInterceptTouchEvent 并不能消费事件，它相当于是一个分叉口起到分流导流的作用，ACTION_MOVE和ACTION_UP 会在哪些函数被调用，之前说了并不是哪个函数收到了ACTION_DOWN，就会收到 ACTION_MOVE 等后续的事件的。
下面通过几张图看看不同场景下，ACTION_MOVE事件和ACTION_UP事件的具体走向并总结一下规律。
6.2.1
6.2.2
在这种场景下ACTION_MOVE和ACTION_UP 将如何呢，看下面的打出来的日志
Activity|dispatchTouchEvent–>ACTION_MOVE ViewGroup1|dispatchTouchEvent–>ACTION_MOVE----TouchEventActivity|dispatchTouchEvent–>ACTION_UP ViewGroup1|dispatchTouchEvent–>ACTION_UP----
红色的箭头代表ACTION_DOWN 事件的流向
蓝色的箭头代表ACTION_MOVE 和 ACTION_UP 事件的流向
6.2.3 我们在ViewGroup2 的dispatchTouchEvent 返回true消费这次事件
Activity|dispatchTouchEvent–>ACTION_DOWN ViewGroup1|dispatchTouchEvent–>ACTION_DOWNViewGroup1|onInterceptTouchEvent–>ACTION_DOWNViewGroup2|dispatchTouchEvent–>ACTION_DOWN---->消费Activity|dispatchTouchEvent–>ACTION_MOVE ViewGroup1|dispatchTouchEvent–>ACTION_MOVEViewGroup1|onInterceptTouchEvent–>ACTION_MOVEViewGroup2|dispatchTouchEvent–>ACTION_MOVE----TouchEventActivity|dispatchTouchEvent–>ACTION_UP ViewGroup1|dispatchTouchEvent–>ACTION_UPViewGroup1|onInterceptTouchEvent–>ACTION_UPViewGroup2|dispatchTouchEvent–>ACTION_UP----
红色的箭头代表ACTION_DOWN 事件的流向
蓝色的箭头代表ACTION_MOVE 和 ACTION_UP 事件的流向
6.2.4 我们在View 的dispatchTouchEvent 返回true消费这次事件
这个我不就画图了，效果和在ViewGroup2 的dispatchTouchEvent return true的差不多，同样的收到ACTION_DOWN 的dispatchTouchEvent函数都能收到 ACTION_MOVE和ACTION_UP。
所以我们就基本可以得出结论如果在某个控件的dispatchTouchEvent 返回true消费终结事件，那么收到ACTION_DOWN 的函数也能收到 ACTION_MOVE和ACTION_UP。
6.2.5 我们在View 的onTouchEvent 返回true消费这次事件
红色的箭头代表ACTION_DOWN 事件的流向
蓝色的箭头代表ACTION_MOVE 和 ACTION_UP 事件的流向
6.2.6 我们在ViewGroup 2 的onTouchEvent 返回true消费这次事件
红色的箭头代表ACTION_DOWN 事件的流向
蓝色的箭头代表ACTION_MOVE 和 ACTION_UP 事件的流向
6、我们在ViewGroup 1 的onTouchEvent 返回true消费这次事件
6.2.7 我们在ViewGroup 1 的onTouchEvent 返回true消费这次事件
6.2.8 我们在Activity 的onTouchEvent 返回true消费这次事件
一下子画了好多图，还有好几种情况就不再画了，相信你也看出规律了，对于在onTouchEvent消费事件的情况：在哪个View的onTouchEvent 返回true，那么ACTION_MOVE和ACTION_UP的事件从上往下传到这个View后就不再往下传递了，而直接传给自己的onTouchEvent 并结束本次事件传递过程。
对于ACTION_MOVE、ACTION_UP总结：ACTION_DOWN事件在哪个控件消费了（return true）， 那么ACTION_MOVE和ACTION_UP就会从上往下（通过dispatchTouchEvent）做事件分发往下传，就只会传到这个控件，不会继续往下传，如果ACTION_DOWN事件是在dispatchTouchEvent消费，那么事件到此为止停止传递，如果ACTION_DOWN事件是在onTouchEvent消费的，那么会把ACTION_MOVE或ACTION_UP事件传给该控件的onTouchEvent处理并结束传递。
七 面试问点
为什么消费掉 Down 事件后,后续的事件都会传递给它？
ViewGrounp DispatcherTounchEvent这个方法主要分成三个部分，第一是判断是否需要拦截事件，第二就是通过for循环找到被点击的子View，第三就是判断mFirstTouchTarget 是否为null
在第二部分，找到被点击的子View之后，分发前会判断mFirstTouchTarget是否为null，此时一定是null的，此时就会把当前的子View赋值给mFirstTouchTarget，同时子VIew开始消费事件跳出循环，当第二个事件分发下来，会走第三部分，此时mFirstTouchTarget指向的是前面消费down事件的子View，那么就会直接分发给子View去消费
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
