可能你遇到过这样的情形，从github上down下来一个开源项目的demo跑到好好的，可是一用到自己项目中就出现各种问题，例如滑动冲突问题，可是不知道从何下手解决？了解View的分发机制也许可以帮助你。在自定义有交互View中，事件分发处于一个比较重的地位，也是面试的常客。

在开始之前呢先啰嗦一点题外话，我们在平时学习工作中经常会遇到一些问题，特别是作为开发人员，通常的做法是google、baidu一些资料，看看别人有没有遇到过类似的问题，借鉴他们的处理方案。这的确是一个有效的方法，可是我们都坚信一点，那就是不管在生活上还是在工作上，总有的时候没有人可以给你参考，你需要独立思考并作出选择，所以养成独立思考的习惯也很重要。

通常来说要去探究一件事，总要有一些线索才行，你比如说警察破案，他要勘察案发现场，搜集一些证据，然后沿着线索一步步侦破案件。那我们现在要分析View的事件分发机制，如何去找这个所谓的线索，事实上程序的“作案”过程会被完整地记录了，那就是方法栈。你是不是联想到了平时程序异常时打出来的异常栈，就是它，现在就案情重演一次，看看它的“作案”过程：

btn.setOnTouchListener(new View.OnTouchListener() {
    @Override
    public boolean onTouch(View v, MotionEvent event) {
        //throw new RuntimeException("Touch");
        Thread.dumpStack();
        return false;
    }
});

这里选择给一个Button设置OnTouchListener，然后在onTouch方法中通过Thread.dumpStack()打印出方法的调用栈，当然你也可以抛出一个异常，或者进入debug模式来查看。点一下这个Button打印出了下面这一段内容：

事件传递的方法调用栈

这一段内容记虽然比较长，但是不复杂。它展示了点击事件在整个Android系统中的传递过程，从ZygoteInit.main方法到OnTouchListener.onTouch方法。从严格意义上来讲，这不算是完整的过程，为啥？通常点击事件是从点击屏幕开始，当点击手机屏幕后，驱动程序是如何处理并把这个事件交给Android系统这个过程是没有体现的。

这次我并不打算分析完整个过程，因为其实在应用层，事件的输入通常是在应用的界面上，而我们编写界面基本是开始于Activity，所以从Activity开始分析往下分析，就是下面这一段：

start_from_activity.png

是不是看起来内容少了很多，心理负担一下子就轻了不少。可以看到事件的传递过程是Activity->PhoneWindow->DecorView->ViewGroup->View。下面就沿着这条线索摸索摸索，首先是Activity的dispatchTouchEvent方法：

public boolean dispatchTouchEvent(MotionEvent ev) {
    if (ev.getAction() == MotionEvent.ACTION_DOWN) {
        //这个方法是空的实现，用法可以看看它的注释
        onUserInteraction();
    }
    //将事件传递到Window中
    if (getWindow().superDispatchTouchEvent(ev)) {
        return true;
    }
    
    //如果子View都不消耗该事件，那Activity的onTouchEvent()方法就会被调用
    return onTouchEvent(ev);
}

可以看到，Activity将事件传递给了Window，如果Window的superDispatchTouchEvent()方法返回true，那Activity的onTouchEvent就不会被调用了。

接着就到Window了，这个Window是个抽象类，我们要找的是它的实现类，通过前面的方法调用栈知道它是PhoneWindow，看看它的superDispatchTouchEvent方法：

@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
    return mDecor.superDispatchTouchEvent(event);
}

Window又将事件传递给了DecorView，可见这个Window充当了Activity和DecorView之间的连接纽带。

//DecorView#superDispatchTouchEvent
public boolean superDispatchTouchEvent(MotionEvent event) {
    return super.dispatchTouchEvent(event);
}

DecorView的superDispatchTouchEvent方法调用了父类的dispatchTouchEvent，而DecorView的直接父类是FrameLayout，而FrameLayout的dispatchTouchEvent方法是从ViewGroup继承下来的，所以事件就传递到了ViewGroup中，这点从方法栈也可以看出来。

ViewGroup的dispatchTouchEvent方法代码是比较多的，也是View事件分发的核心，搞清楚它基本也就搞清楚了View的事件分发过程，下面分段来看看这个方法的实现：

// 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();
}

从这段代码实现可以看到在DOWN事件的时候会重置一些状态信息。

// Check for interception.
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
        || mFirstTouchTarget != null) {
    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 {
    //从这个else条件可以看出，只要不是DOWN事件或者mFirstTouchTarget为null, intercepted直接赋值为true，也就是默认拦截。这个DOWN很好理解，但是这个mFirstTouchTarget是什么现在还不知道
    
    // There are no touch targets and this action is not an initial down
    // so this view group continues to intercept touches.
    intercepted = true;
}

从这一段代码可以看到在DOWN事件的时候，会调用onInterceptTouchEvent()方法来询问是否要拦截该事件，并通过intercepted来标记，后面的代码会根据这个标记来选择不同的处理方式，首先看看intercepted为false，即事件会向下传递给子View:

// Find a child that can receive the event.
// Scan children from front to back.
final ArrayList<View> preorderedList = buildTouchDispatchChildList();
final boolean customOrder = preorderedList == null
        && isChildrenDrawingOrderEnabled();
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;
    }
    
    //判断子View是否可以接收点击事件，点击事件的x,y坐标是否在子View内部
    if (!canViewReceivePointerEvents(child)
            || !isTransformedTouchPointInView(x, y, child, null)) {
        ev.setTargetAccessibilityFocus(false);
        continue;
    }
    
    newTouchTarget = getTouchTarget(child);
    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);
    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();
        newTouchTarget = addTouchTarget(child, idBitsToAssign);
        alreadyDispatchedToNewTouchTarget = true;
        break;
    }

    // The accessibility focus didn't handle the event, so clear
    // the flag and do a normal dispatch to all children.
    ev.setTargetAccessibilityFocus(false);
}

这段代码也比较简单，遍历所有的子View，首先判断子View是否能接收点击事件（View的可见性为VISIBLE或者view.getAnimation() != null），接着判断事件的x,y坐标是否在View的内部。如果能满足这两个条件，那事件就可以传给该子View处理了。其中dispatchTransformedTouchEvent()方法实际上是调用了子View的dispatchTouchEvent()方法，如下：

View#dispatchTouchEvent

// 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());
    }
    //这里传入的child不是null，所以走这个分支
    handled = child.dispatchTouchEvent(transformedEvent);
}

这里调用dispatchTransformedTouchEvent()传入的child不是null，所以走的是else分支。注意，如果子View的dispatchTouchEvent()方法返回true, 那么 mFirstTouchTarget 就会被赋值并跳出遍历子View的循环，如下：

//addTouchTarget内部会对 mFirstTouchTarget进行赋值操作
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
break;

addTouchTarget()内部会为mFirstTouchTarget赋值

private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) {
    final TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
    target.next = mFirstTouchTarget;
    mFirstTouchTarget = target;
    return target;
}

还记的前面关于拦截是的条件吗？

if (actionMasked == MotionEvent.ACTION_DOWN|| mFirstTouchTarget != null)

这里就解答了前面的疑问，ViewGroup不拦截DOWN事件，且子View的dispatchTouchEvent()方法返回true时mFirstTouchTarget被赋值。前面我们也提到DOWN事件时会重置一些状态信息，这个mFirstTouchTarget会被置为null。也就是说一旦子View的dispatchTouchEvent()方法返回true，那同一个事件序列中，mFirstTouchTarget != null这个条件就都成立。

如果遍历完所有子View，mFirstTouchTarget为null（有两种情况，子View的dispatchTouchEvent()方法都返回false；或者事件被拦截了，即intercepted为true），则会走下面的逻辑：

// 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。

// Perform any necessary transformations and dispatch.
if (child == null) {
    //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);
}

可以看到当child为null是调用的super.dispatchTouchEvent()方法，这个super就是View。看到这你可能会问，前面为什么不直接往下分析View的dispatchTouchEvent()方法的实现？当然可以，只是这样方法栈就会变深，而我们记忆是有限的，一味地深入会让自己无法自拔，这点在阅读源码的时候要注意。现在大局观已经明确，再去分析它的实现就比较清晰了。

public boolean dispatchTouchEvent(MotionEvent event) {
    ...
    boolean result = false;
    ...
    if (onFilterTouchEventForSecurity(event)) {
        //点击ScrollBar
        if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
            result = true;
        }
        //noinspection SimplifiableIfStatement
        ListenerInfo li = mListenerInfo; 
        
        //li.mOnTouchListener就是通过setOnTouchListener设置的OnTouchListener
        if (li != null && li.mOnTouchListener != null
                && (mViewFlags & ENABLED_MASK) == ENABLED
                && li.mOnTouchListener.onTouch(this, event)) {
            result = true;
        }
        //如果 mOnTouchListener.onTouch()返回true，onTouchEvent()就不会再被调用了
        if (!result && onTouchEvent(event)) {
            result = true;
        }
    }
    ...
    return result;
}

从View的dispatchTouchEvent()的实现可以看到，如果有调用setOnTouchListener()设置了OnTouchListener的话，就会先调用OnTouchListener的onTouch()方法，若onTouch()返回false，再调用View的onTouchEvent()方法；若返回true，则直接返回了，这将导致View的onTouchEvent()不会被调用。另外在onTouchEvent()内部会调用OnClickListener.onClick()方法：

public boolean onTouchEvent(MotionEvent event) {
    ...
    if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
        switch (action) {
            case MotionEvent.ACTION_UP:
                ...
                if (!post(mPerformClick)) {
                    //这个方法的实现会调用OnClickListener.onClick()方法
                    performClick();
                }
                ...
        }
    }
}

在UP事件时调用performClick()内部会调用OnClickListener.onClick()，所以父View不能拦截UP事件，否则点击事件就不会被调用。

public boolean performClick() {
    final boolean result;
    final ListenerInfo li = mListenerInfo;
    if (li != null && li.mOnClickListener != null) {
        playSoundEffect(SoundEffectConstants.CLICK);
        //onClick()被调用
        li.mOnClickListener.onClick(this);
        result = true;
    } else {
        result = false;
    }
    sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED);
    notifyEnterOrExitForAutoFillIfNeeded(true);
    return result;
}

从前面的分析可以看到我们平时常用的onClick()方法的优先级是最低的，调用顺序为：OnTouchListener.onTouch()->onTouchEvent()->OnClickListener.onClick()，而且onTouch()返回true会中断后续的调用。

前面的分析过程中发现，主要的逻辑是下面三个方法：

public boolean dispatchTouchEvent(MotionEvent ev)

用来进行事件分发，当事件传递到当前面View，dispatchTouchEvent()方法会被调用，它的返回值受onTouchEvent()方法的返回值和子View的dispatchTouchEvent()返回值的影响，表示是否消耗事件。

public boolean onInterceptTouchEvent(MotionEvent ev)

这个方法的返回值表示是否拦截事件，如果返回true，同一个事件序列中不会再被调用，同一个事件序列指的是down->move...move->up。

public boolean onTouchEvent(MotionEvent event)

在dispatchTouchEvent()内部调用，用于处理事件，返回值表示是否消耗该事件。如果返回false，同一事件序列中，当前View（不包括ViewGroup）将无法再次接收到。

这三个方法的关系大致可以理解为下面的伪代码：

public boolean dispatchTouchEvent(MotionEvent ev) {
    boolean consume;
    if (onInterceptTouchEvent(ev)) {
        consume = onTouchEvent(ev);
    } else {
        consume = child.dispatchTouchEvent(ev);
    }
    return consume;
}

大致的意思是当事件传递给ViewGroup时，ViewGroup的dispatchTouchEvent()方法会被调用，接着调用它的onInterceptTouchEvent()方法询问是否拦截该事件，如拦截则该事件交给这个ViewGroup处理，即它的onTouchEvent()方法被调用；如不拦截，则传递给子View，如此反复直到事件被处理掉。下面给出一些前面分析得到的结论：

（1）当一个View决定拦截某个事件，即onInterceptTouchEvent()返回true，那么同一个事件序列的所有事件都直接交给它处理而不会再调用onInterceptTouchEvent()来询问是否拦截；换句话说就是一个事件序列只能被一个View拦截并消耗。
（2）某个View一旦开始处理事件，如果它不消耗调DOWN事件，即onTouchEvent()返回false，那同一个事件序列的其他事件就不会再交给它处理，事件将重新交由它的父View处理，即父View的onTouchEvent()会被调用。
（3）如果不消耗DOWN以外的事件，同一个事件序列还是会传给当前View，没有消耗的事件会交给Activity的onTouchEvent()来处理。
（4）View的onTouchEvent()默认都消耗事件，即返回true，除非它是不可点击的，即下面的clickable为false。

final boolean clickable = ((viewFlags & CLICKABLE) == CLICKABLE
                || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)
                || (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE;

可以看到只要是CLICKABLE、LONG_CLICKABLE、CONTEXT_CLICKABLE这三个有一个为true它就是可点击的，而与ennable无关，换句话说就是如果View的enable为true也是会消耗事件的。

（5）事件总是先传给父View，然后在传给子View，在子View中可以通过调用父View的requestDisallowInterceptTouchEvent()来干预事件的拦截过程，在处理滑动冲突可以利用这一点。

@Override
public void requestDisallowInterceptTouchEvent(boolean disallowIntercept) {

    if (disallowIntercept == ((mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0)) {
        // We're already in this state, assume our ancestors are too
        return;
    }

    if (disallowIntercept) {
        mGroupFlags |= FLAG_DISALLOW_INTERCEPT;
    } else {
        mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;
    }

    // Pass it up to our parent
    if (mParent != null) {
        mParent.requestDisallowInterceptTouchEvent(disallowIntercept);
    }
}

在这个方法内部修改了mGroupFlags的值，现在再回头看看ViewGroup拦截事件的逻辑：

ViewGroup#dispatchTouchEvent

if (actionMasked == MotionEvent.ACTION_DOWN
        || mFirstTouchTarget != null) {
    //这个值会受到干预，进而影响是intercepted的值，也就是干预拦截   
    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 {
    intercepted = true;
}

可以看到如果disallowIntercept为true，intercepted直接置为false。另外DOWN事件是不能干预的，因为在DONW事件时调用会resetTouchState()来重置状态信息，mGroupFlags会被重置。

private void resetTouchState() {
    clearTouchTargets();
    resetCancelNextUpFlag(this);
    mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;
    mNestedScrollAxes = SCROLL_AXIS_NONE;
}

这些结论看似轻描淡写，要真正理解就必须要仔细看看源码才行，如果你能为这些结论说出有力的论据，那说明你掌握的也差不多了。后面我会运用这些论据来自定义一个具体的ViewGroup，让这些结论变得有用。