在Android开发过程中，事件分发机制是核心知识点，掌握好事件分发机制能帮助我们分析滑动失效或者滑动冲突问题。
MotionEvent对象
View的事件分发其实就在处理一系列的MotionEvent，即点击事件。在事件分发过程中，主要涉及到以下4种事件：
MotionEvent.ACTION_DOWN：手指刚触摸屏幕时触发；
MotionEvent.ACTION_MOVE： 手指在屏幕上移动时触发，可能多次；
MotionEvent.ACTION_UP：手指从屏幕松开的一瞬间触发；
MotionEvent.ACTION_CANCEL： 当事件被上层拦截或外界取消时触发；
事件分发过程的方法
事件分发过程是由dispatchTouchEvent(),onInterceptTouchEvent(),onTouchEvent()三个方法共同完成的，伪代码的描述如下：
public void dispatchTouchEvent(MotionEvent ev){
boolean consume = false;
if(onInterceptTouchEvent(ev)){
consume = onTouchEvent(ev);
}else {
consume = child.dispatchTouchEvent(ev);
}
return consume;
}
当事件产生后，会首先调用ViewGroup的dispatchTouchEvent方法，如果ViewGroup的onInterceptTouchEvent返回了true表示需要拦截当前事件，那么事件就会交给ViewGroup处理，onTouchEvent方法就会被调用；如果onInterceptTouchEvent返回了false表示不需要拦截当前事件，这时候这个事件就会传递给子View处理，子View的dispatchTouchEvent就会被调用，如此反复直到事件最终被处理为止。
事实上当一个事件产生后，它是遵从Activity->Window->View传递顺序，也就是说当事件产生后，首先会传递给Activity，再从Activity传递给Window，最后从Window传递给View，这是事件分发机制的一个过程，下面从源码的看下事件分发机制
Activity和Window的分发过程
当一个事件产生时，会先传递给Activity，调用Activity的dispatchTouchEvent方法进行分发
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
//当事件是ACTION_DOWN时可以重写onUserInteraction执行操作
onUserInteraction();
}
//将事件传递给Window处理
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
//如果没有任何一个View就交给Activity的onTouchEvent处理
return onTouchEvent(ev);
}
从上面的代码可以知道Activity会把事件交给附属的Window处理，如果返回true，则事件分发就结束了，如果返回false，则交给Activity的onTouchEvent处理。
接下来看Window是如何将事件传递给ViewGroup的？在Android中Window是抽象类，从源码的注释中也可以得到PhoneWindow是Window的唯一实现类，那么跟踪到PhoneWindow中的superDispatchTouchEvent方法
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
到这里，可以发现PhoneWindow中直接将事件传递给了DecorView，而DecorView是FrameLayout的子类，setContentView设置的View就是DecorView的子View，这样就将事件传递给了子View，这个子View也就是根View，一般都是ViewGroup，所以事件就传递到了ViewGroup，接下来我们就可以看ViewGroup中的dispatchTouchEvent了
ViewGroup的事件分发
当点击事件达到顶级View时，一般都是ViewGroup，这时候就会调用ViewGroup的dispatchTouchEvent方法，首先截取事件拦截部分来看
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
//不允许拦截事件，子View可以requestDisallowInterceptTouchEvent设置，也是事件冲突内部拦截法的处理的关键点
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
intercepted = onInterceptTouchEvent(ev);
ev.setAction(action); // restore action in case it was changed
} else {
intercepted = false;
}
} else {
// 如果不是down事件，并且上一次事件被拦截，则这个事件序列一直被拦截，不会传递下去了
intercepted = true;
}
如果是ACTION_DOWN事件，或者是mFirstTouchTarget != null成立，那么ViewGroup就会判断是否要拦截事件。ACTION_DOWN事件比较好理解，那么mFirstTouchTarget != null是什么意思呢？其实是如果ViewGroup的子View处理了事件，那么mFirstTouchTarget就会指向该子View，反之如果事件被ViewGroup拦截，那么mFirstTouchTarget =null；所以说如果某个ViewGroup拦截了事件，那么这一个事件序列(move和up事件)都交给它自己处理，并且onInterceptTouchEvent不会再被调用了，因为这时候既不是down事件，mFirstTouchTarget !=null也不成立，intercepted = true则拦截事件，不再继续分发给子View事件了。
这里可以发现一个标记位FLAG_DISALLOW_INTERCEPT，这个标记位是子View通过requestDisallowInterceptTouchEvent设置的，这个标记位一旦设置后，那么intercepted = false，ViewGroup就不能拦截除了ACTION_DOWN以外的事件了。为什么是除ACTION_DOWN以外的事件呢？因为在事件分发开始的时候，如果是ACTION_DOWN事件，那么会清除FLAG_DISALLOW_INTERCEPT的标记位。
if (actionMasked == MotionEvent.ACTION_DOWN) {
cancelAndClearTouchTargets(ev);
resetTouchState();
}
private void resetTouchState() {
clearTouchTargets();
resetCancelNextUpFlag(this);
mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;
mNestedScrollAxes = SCROLL_AXIS_NONE
}
如果不拦截事件，那么就开始向子View分发事件了，在分发事件之前先按照子View的层级来排序buildTouchDispatchChildList->buildOrderedChildList
ArrayList<View> buildOrderedChildList() {
final int childrenCount = mChildrenCount;
if (childrenCount <= 1 || !hasChildWithZ()) return null;
if (mPreSortedChildren == null) {
mPreSortedChildren = new ArrayList<>(childrenCount);
} else {
// callers should clear, so clear shouldn't be necessary, but for safety...
mPreSortedChildren.clear();
mPreSortedChildren.ensureCapacity(childrenCount);
}
final boolean customOrder = isChildrenDrawingOrderEnabled();
for (int i = 0; i < childrenCount; i++) {
// add next child (in child order) to end of list
final int childIndex = getAndVerifyPreorderedIndex(childrenCount, i, customOrder);
final View nextChild = mChildren[childIndex];
final float currentZ = nextChild.getZ();
// insert ahead of any Views with greater Z
int insertIndex = i;
while (insertIndex > 0 && mPreSortedChildren.get(insertIndex - 1).getZ() > currentZ) {
insertIndex--;
}
mPreSortedChildren.add(insertIndex, nextChild);
}
return mPreSortedChildren;
}
遍历子View，并且分发事件，代码片段如下：
for (int i = childrenCount - 1; i >= 0; i--) {
final int childIndex = getAndVerifyPreorderedIndex(
childrenCount, i, customOrder);
final View child = getAndVerifyPreorderedView(
preorderedList, children, childIndex);
//...省略代码
//判断子View是否可以处理事件
if (!child.canReceivePointerEvents()
|| !isTransformedTouchPointInView(x, y, child, null)) {
ev.setTargetAccessibilityFocus(false);
continue;
}
//down事件的时候还是null
newTouchTarget = getTouchTarget(child);
if (newTouchTarget != null) {
newTouchTarget.pointerIdBits |= idBitsToAssign;
break ;
}
resetCancelNextUpFlag(child);
//dispatchTransformedTouchEvent事件分发给子view
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
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();
// 把当前处理事件的子View指向mFirstTouchTarget
newTouchTarget = addTouchTarget(child, idBitsToAssign);
//已经将事件给当前子View处理
alreadyDispatchedToNewTouchTarget = true;
break;
}
ev.setTargetAccessibilityFocus(false);
}
通过上面代码，循环遍历子View的时候先判断当前子View可见并且当前不在播放动画并且当前点击坐标内在View内，否则遍历下一个View。再判断是否是已经处理事件的子View，在down事件的时候newTouchTarget还是null，则执行到了dispatchTransformedTouchEvent方法中。如果将事件分发到了子View，那么将子View指向mFirstTouchTarget，并且newTouchTarget!=null，设置alreadyDispatchedToNewTouchTarget为true。
那么看看dispatchTransformedTouchEvent中是如何分发事件的：
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
final boolean handled;
//如果cancel为true，则将事件置为ACTION_CANCEL，这也就是为什么之前说的MotionEvent.ACTION_CANCEL是被拦截后的事件
final int oldAction = event.getAction();
if (cancel || oldAction == MotionEvent.ACTION_CANCEL) {
//设置事件为ACTION_CANCEL
event.setAction(MotionEvent.ACTION_CANCEL);
if (child == null) {
//如果子View为空，则把事件给当前View处理
handled = super.dispatchTouchEvent(event);
} else {
//如果不为空，则事件传递给子View处理
handled = child.dispatchTouchEvent(event);
}
event.setAction(oldAction);
return handled;
}
final MotionEvent transformedEvent;
if (newPointerIdBits == oldPointerIdBits) {
if (child == null || child.hasIdentityMatrix()) {
if (child == null) {
handled = super.dispatchTouchEvent(event);
} else {
final float offsetX = mScrollX - child.mLeft;
final float offsetY = mScrollY - child.mTop;
event.offsetLocation(offsetX, offsetY);
handled = child.dispatchTouchEvent(event);
event.offsetLocation(-offsetX, -offsetY);
}
return handled;
}
transformedEvent = MotionEvent.obtain(event);
} else {
transformedEvent = event.split(newPointerIdBits);
}
// 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;
}
在这个方法中，如果cancel为true，则将当前事件设置为ACTION_CANCEL。如果子View不为空，则将事件传递给子View处理，如果为空，则交给当前View来处理。
if (mFirstTouchTarget == null) {
//注释一
//child== null，说明没有处理事件的子View，则自己处理
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
} else {
TouchTarget predecessor = null;
TouchTarget target = mFirstTouchTarget;
while (target != null) {
final TouchTarget next = target.next;
//注释二
//如果事件已经被处理了alreadyDispatchedToNewTouchTarget为true，直接返回事件已经被处理
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {
handled = true;
} else {
final boolean cancelChild = resetCancelNextUpFlag(target.child)
|| intercepted;
//注释三
//一大串的move事件进来，如果事件被拦截intercepted为true，而子View不为空，但是这时候并不是给子View传递事件，在dispatchTransformedTouchEvent给子View设置了ACTION_CANCEL事件，mFirstTouchTarget=null
//下一次的move的事件进来后执行mFirstTouchTarget == null，dispatchTransformedTouchEvent(ev, canceled, null,TouchTarget.ALL_POINTER_IDS)方法了，这样就把事件从子View切换回了ViewGroup
if (dispatchTransformedTouchEvent(ev, cancelChild,target.child, target.pointerIdBits)) {
handled = true;
}
if (cancelChild) {
if (predecessor == null) {
mFirstTouchTarget = next;
} else {
predecessor.next = next;
}
target.recycle();
target = next;
continue;
}
}
predecessor = target;
target = next;
}
}
如果已经将事件分发给子View处理，那么mFirstTouchTarget!=null，并且alreadyDispatchedToNewTouchTarget=true，所以当前事件已经传递给子View，这也就是注释二的逻辑。
那么什么情况下会进入到注释三呢？在使用内部拦截法来处理事件冲突的时候，一般在子View的dispatchTouchEvent的move事件调用parent.requestDisallowInterceptTouchEvent(false)，按照一开始分析的事件分发是否拦截的逻辑，会执行到ViewGroup的onInterceptTouchEvent，如果onInterceptTouchEvent返回了true，这时候就会执行到注释三的逻辑中，因为这时候alreadyDispatchedToNewTouchTarget为false。因为intercepted =true，所以cancelChild为true，这时候的target.child还不为空，调用
dispatchTransformedTouchEvent(ev, cancelChild,target.child, target.pointerIdBits)，跟踪到dispatchTransformedTouchEvent方法中，可以发现如果cancel为true的时候，会给子View分发一个ACTION_CANCLE事件。接下来给mFirstTouchTarget赋值为next，而next为null，那么mFirstTouchTarget也为null了。而move事件一般都是多个的，所以再次调用dispatchTouchEvent的时候，还是需要拦截事件，所以不会分发给子View事件，那么mFirstTouchTarget还是为null，则执行注释一的逻辑，这时候child为null，则事件给自己处理，从而也完成了一次事件的切换，解决了事件冲突。
View的事件分发
当ViewGroup的事件没有拦截，并且传递到子View的时候，就会调用子View的dispatchTouchEvent，那么接下来看下dispatchTouchEvent的关键逻辑部分
if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
result = true;
}
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;
}
通过上面的逻辑，可以知道如果给View设置了OnTouchListener，并且处理onTouch返回true，那么就不会执行View的onTouchEvent方法了，说明onTouch的优先级比onTouchEvent高。否则执行View的onTouchEvent方法
//只要有CLICKABLE或者LONG_CLICKABLE就可以，无关view的是否是disable的
final boolean clickable = ((viewFlags & CLICKABLE) == CLICKABLE
|| (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)
|| (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE;
//如果设置了mTouchDelegate代理，则执行mTouchDelegate.onTouchEvent
if (mTouchDelegate != null) {
if (mTouchDelegate.onTouchEvent(event)) {
return true;
}
}
if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
switch (action) {
case MotionEvent.ACTION_UP:
//...省略代码
if ((mPrivateFlags & PFLAG_PRESSED) != 0 || prepressed) {
boolean focusTaken = false;
if (isFocusable() && isFocusableInTouchMode() && !isFocused()) {
focusTaken = requestFocus();
}
if (prepressed) {
setPressed(true, x, y);
}
if (!mHasPerformedLongPress && !mIgnoreNextUpEvent) {
removeLongPressCallback();
if (!focusTaken) {
if (mPerformClick == null) {
mPerformClick = new PerformClick();
}
if (!post(mPerformClick)) {
//执行点击事件
performClickInternal();
}
}
}
View的onTouchEvent默认会返回true的，就是消费事件，除非View是不可点击的，即clickable和longClickable同时为false。这里也说View的enable属性不影响onTouchEvent的默认返回值，只要有clickable或者longClickable。从这里也可以知道View的onClick事件发生的前提是View是可点击的，并且接收到一次完整的down和up事件。performClick()执行了onClick事件：
public boolean performClick() {
//...省略代码
final boolean result;
final ListenerInfo li = mListenerInfo;
if (li != null && li.mOnClickListener != null) {
playSoundEffect(SoundEffectConstants.CLICK);
li.mOnClickListener.onClick(this);
result = true;
} else {
result = false;
}
//...省略代码
return result;
}
通过performClick函数可以发现如果给View设置了OnClickListener，那么在完成一次完整的down和up事件后就可以回调onClick方法。
事件冲突处理
事件冲突产生的原因主要有三种：
1、外部滑动和内部滑动方向一致；
2、外部滑动和内部滑动方向不一致；
3、上面两种混合的情况；
发生事件冲突的解决方法主要有两种，一种是外部拦截法，一种是内部拦截法，但是核心思想都是从事件分发机制着手。
外部拦截法：
事件分发的时候都要通过父容器拦截处理，那么在父容器需要事件的时候拦截，在不需要事件的不拦截，这样就能解决事件冲突。可以通过重写onInterceptTouchEvent来处理是否拦截，但是需要注意的是ACTION_DOWN事件一定不能拦截，否则后续的ACTION_MOVE和ACTION_UP都接收不到事件了。
内部拦截法：
父容器不拦截任何事件，如果子View需要事件则消费，否则就交给父容器处理。可以在子View的dispatchTouchEvent中处理，配合requestDisallowInterceptTouchEvent来使用。但是需要注意的是ACTION_DOWN事件是不会受FLAG_DISALLOW_INTERCEPT标记位影响的，因为每次ACTION_DOWN都会清除FLAG_DISALLOW_INTERCEPT标记位的。
