一、引言
View的事件分发一直都是块难啃的骨头，每次都是在遇到问题时才在网上找一下事件分发的流程，而每次看的时候当时都以为懂了，但是过了一段时间却又忘了。如此反复，对View的事件分发一直没有搞懂，所以这次决定结合源码来分析View的事件分发机制。
二、源码分析
在进行源码分析前，我们先来看一下View的事件分发的流程图。
看一下这个事件分发流程图，是不是觉得View的事件分发也没有那么复杂吧。
下面我们开始通过源码来验证上面流程的正确性，Let‘s go~
2.1 Activity对事件进行分发
当一个点击事件发生时，事件最先传递到当前View所在的Activity中，由Activity的dispatchTouchEvent进行分发。
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
首先调用了getWindow(). superDispatchTouchEvent方法，返回true表示事件被消耗掉了；返回false表示事件交给Activity的onTouchEvent方法处理。
getWindow()返回的是Window类。在Android中，只有PhoneWindow是Window的唯一实现类，所以执行的正是PhoneWindow里的方法。
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
在PhoneWindow中，也没有复杂的处理逻辑，转而调用了变量mDecor的superDispatchTouchEvent方法。
这里的mDecor是DecorView类型。DecorView我们挺熟悉了，它是Activity的顶级View。在Activity中，我们通过setContentView方法设置了自定义View，而DecorView就是我们自定义View的父容器。
public boolean superDispatchTouchEvent(MotionEvent event) {
return super.dispatchTouchEvent(event);
}
DecorView对于superDispatchTouchEvent方法的实现逻辑就更奇葩了，直接调用父类的dispatchTouchEvent方法，而DecorView的父类是ViewGroup。
注意了，事件这里已经传递到了第一个顶级ViewGroup的dispatchTouchEvent方法了。
2.2 ViewGroup对事件进行分发
ViewGroup中的dispatchTouchEvent方法的处理逻辑比较复杂，那我们就化整为零，一段一段的看。
public boolean dispatchTouchEvent(MotionEvent ev) {
...省略
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
//由于事件为ACTION_DOWN时，重置了mGroupFlags，所以一定会调用onInterceptTouchEvent方法。
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 {
//当事件不为ACTION_DOWN，而且mFirstTouchTarget == null时，intercepted置为true。
intercepted = true;
}
...省略
}
actionMasked == MotionEvent.ACTION_DOWN，我们比较好理解，表示按下事件。
但是mFirstTouchTarget != null，是什么意思呢？
其实看完下面的代码就会知道，当点击事件被ViewGroup中的子View消费后，那么mFirstTouchTarget != null。反过来说，当点击事件被当前ViewGroup消费了，那么mFirstTouchTarget == null。
我们知道，事件的最开始一定是ACTION_DOWN事件，然后伴随着一系列的ACTION_MOVE事件，最后是ACTION_UP事件。
当事件为ACTION_DOWN时，mGroupFlags总是被重置了。
// 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);
resetTouchState();
}
private void resetTouchState() {
clearTouchTargets();
resetCancelNextUpFlag(this);
mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;
mNestedScrollAxes = SCROLL_AXIS_NONE;
}
当事件为ACTION_DOWN时，由于mGroupFlags的重置，所以disallowIntercept的值为false，也就是说onInterceptTouchEvent方法一定会执行。
注意了，事件这里已经传递到了第一个顶级ViewGroup的onInterceptTouchEvent方法了。
onInterceptTouchEvent方法的返回值决定着事件分发的走向，分为如下两个分支：
1、当返回为true时，表示当前ViewGroup拦截了该事件。
2、当返回为false时，表示当前ViewGroup不拦截该事件。该事件转而传递到该ViewGroup的子View。
2.2.1 onInterceptTouchEvent返回true
这里先看第一个分支，当返回为true时，intercepted的赋值为true。
if (!canceled && !intercepted) {
//事件传递到子View才会走下面的逻辑
...省略
}
if (mFirstTouchTarget == null) {
// No touch targets so treat this as an ordinary view.
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
} else {
...省略
}
intercepted的赋值为true，说明事件被当前ViewGroup拦截了，mFirstTouchTarget == null条件判断成立，所以调用了dispatchTransformedTouchEvent方法。注意，这里的第三个参数为null。
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
final boolean handled;
...省略
// Perform any necessary transformations and dispatch.
if (child == null) {
handled = super.dispatchTouchEvent(transformedEvent);
} else {
final float offsetX = mScrollX - child.mLeft;
final float offsetY = mScrollY - child.mTop;
transformedEvent.offsetLocation(offsetX, offsetY);
if (! child.hasIdentityMatrix()) {
transformedEvent.transform(child.getInverseMatrix());
}
handled = child.dispatchTouchEvent(transformedEvent);
}
transformedEvent.recycle();
return handled;
}
上面提到的第三个参数为null，也就是说child == null 成立，所以这里执行了super. dispatchTouchEvent方法。ViewGroup的父类是View，所以这里执行的是View的dispatchTouchEvent方法。
public boolean dispatchTouchEvent(MotionEvent event) {
...省略
boolean result = false;
...省略
if (onFilterTouchEventForSecurity(event)) {
...省略
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;
}
}
...省略
return result;
}
这里判断了当前View（也就是上面的ViewGroup）的状态是否是Enable的，并且当前View是否通过setOnTouchListener方法设置了OnTouchListener接口方法并在onTouch方法中是否返回true。
当上面提到的条件都返回true时，result的赋值为true。当result的赋值为true时，onTouchEvent方法并不会执行。
这里得出一个结论：
当View设置了OnTouchListener接口，并在接口方法onTouch中返回true时，View的onTouchEvent方法不会执行，也就是说事件不会传递到View的onTouchEvent方法中。
这里讨论一般的情况，当result为false时，onTouchEvent方法就被执行了。
注意了，事件这里已经传递到了第一个顶级ViewGroup的onTouchEvent方法了。
当onTouchEvent返回true时，表示该事件被当前View消耗了，后续的一系列事件默认都会传递给当前View。
平时我们经常给View设置的OnClickListener是在onTouchEvent中触发的（源码中调用了performClick方法）。结合上面得出的结论，我们可以得到另外一个结论：
OnTouch比onTouchEvent先执行，onTouchEvent比onClick先执行。我们平时给View设置的点击事件是处于最末端执行的。
当onTouchEvent返回false时，表示当前View不处理该事件，我们回溯上面的方法，这就相当于最开始的dispatchTouchEvent方法返回false，继续回溯到Activity的dispatchTouchEvent方法。
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
也就是说，(getWindow().superDispatchTouchEvent(ev)返回false，Activity的onTouchEvent方法会被执行。
2.2.2 onInterceptTouchEvent返回false
我们再来看第二个分支，当ViewGroup的onInterceptTouchEvent方法返回false时，则执行如下逻辑。
if (!canceled && !intercepted) {
if (actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
...省略
final int childrenCount = mChildrenCount;
if (newTouchTarget == null && childrenCount != 0) {
...省略
final View[] children = mChildren;
//遍历当前ViewGroup的每一个子View，将该事件分发下去
for (int i = childrenCount - 1; i >= 0; i--) {
final int childIndex = getAndVerifyPreorderedIndex(
childrenCount, i, customOrder);
final View child = getAndVerifyPreorderedView(
preorderedList, children, childIndex);
...省略
resetCancelNextUpFlag(child);
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
// Child wants to receive touch within its bounds.
mLastTouchDownTime = ev.getDownTime();
if (preorderedList != null) {
for (int j = 0; j < childrenCount; j++) {
if (children[childIndex] == mChildren[j]) {
mLastTouchDownIndex = j;
break;
}
}
} else {
mLastTouchDownIndex = childIndex;
}
mLastTouchDownX = ev.getX();
mLastTouchDownY = ev.getY();
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
break;
}
ev.setTargetAccessibilityFocus(false);
}
if (preorderedList != null) preorderedList.clear();
}
...省略
}
}
遍历了当前ViewGroup的每一个子View，将事件分发下去。对于ViewGroup的子View，调用了dispatchTransformedTouchEvent方法。
还有没有印象？前面ViewGroup拦截事件时也调用了该方法，只不过当时的第三个参数为null。
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
final boolean handled;
...省略
// Perform any necessary transformations and dispatch.
if (child == null) {
handled = super.dispatchTouchEvent(transformedEvent);
} else {
final float offsetX = mScrollX - child.mLeft;
final float offsetY = mScrollY - child.mTop;
transformedEvent.offsetLocation(offsetX, offsetY);
if (! child.hasIdentityMatrix()) {
transformedEvent.transform(child.getInverseMatrix());
}
handled = child.dispatchTouchEvent(transformedEvent);
}
transformedEvent.recycle();
return handled;
}
可以看到，当child不为null时，调用了child的dispatchTouchEvent方法。
如果child是一个ViewGroup的话，那么事件分发的逻辑就和上面分析ViewGroup一样了。所以，回去对照上面的事件分发流程图。事件分发到子ViewGroup时，逻辑和其父容器的一毛一样的！！！
当dispatchTransformedTouchEvent方法返回true时，表示事件由该子View消耗了，所以addTouchTarget方法就会被执行。
private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) {
final TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
target.next = mFirstTouchTarget;
mFirstTouchTarget = target;
return target;
}
而mFirstTouchTarget就是在这里赋值的。这也验证了上面那个结论：
当mFirstTouchTarget != null 时，表示事件由当前ViewGroup的子View消耗了。
ViewGroup对于事件分发的逻辑验证就告一段落了。假设ViewGroup的子View不是一个容器，而是一个纯粹的View，那么事件分发逻辑又是怎样的呢？
2.3 View对事件进行分发
接着上面的逻辑，事件继续传递，在dispatchTransformedTouchEvent方法中，如果child是一个View，那么调用的就是View的dispatchTouchEvent方法。
public boolean dispatchTouchEvent(MotionEvent event) {
...省略
boolean result = false;
...省略
if (onFilterTouchEventForSecurity(event)) {
...省略
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;
}
}
...省略
return result;
}
我们上面也分析了View的dispatchTouchEvent方法。这里就只说一下结论：
dispatchTouchEvent方法调用了onTouchEvent方法，方法的返回值表示事件是否被消耗了。当事件没有被消耗，那么mFirstTouchTarget 没有被赋值，即mFirstTouchTarget == null。
此时事件回传到了子View的父容器。如果父容器不处理该事件，事件会继续往上传，直到事件被消耗。
当事件被消耗了，后面一系列事件都会传递到该View。当然在传递的过程中，ACTION_MOVE和ACTION_UP事件默认会经过父容器的onInterceptTouchEvent方法，父容器可以拦截在该方法中拦截事件。
如果所有View都不消耗该事件，那么该事件会回传到Activity。Activity如果也不消耗该事件，那么该事件就消失了。
三、总结
本文从源码的角度分析了View的事件分发流程。事件从Activity开始传递，中间经过ViewGroup的分发、拦截、消耗或者是View的分发、消耗等一系列方法的处理，事件或被ViewGroup、View消耗，或继续往上传递给Activity处理，而这就是一个完整的事件分发流程。