Android事件分发机制源码分析
说到Android的事件机制，相信很多人都不陌生。详细了解事件在Android中传递的规则，使得我们能够更加清楚事件处理逻辑，更好的处理滑动冲突之类复杂的问题。本文主要分析事件在各个View层级中的分发规则，从Activity接收到事件到一个事件被成功消费的详细过程。
Activity的分发过程
当有触摸事件发生在一个Activity时，这个事件首先会被传递给Activity，即调用Activity的dispatchTouchEvent方法，然后开始事件的分发过程。现在我们可以知道，如果我们想要拦截所有的事件，那么可以通过重写Activity的dispatchTouchEvent方法实现。下面我们看一下Activity的dispatchTouchEvent方法：
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}首先，如果是ACTION_DOWN事件的话，会调用onUserInteraction方法，该方法在Activity中实现为一个空方法，可以通过覆盖该方法在一个事件序列到来时做一些事情。getWindow方法返回该Activity方法所关联的Window对象，Window是一个抽象类，而它的具体实现是PhoneWindow（在Activity类的attach方法中可以看到：mWindow = new PhoneWindow(this, window);）。因此，我们可以知道，Activity只是简单的将事件交给Window的superDispatchTouchEvent方法处理，如果Window未能成功处理该事件，则交给Activity自身的onTouchEvent方法处理。然后看一下Window的处理过程。
Window的分发过程
首先看一下PhoneWindow中superDispatchTouchEvent方法的实现：
@Override
public boolean superDispatchTouchEvent(KeyEvent event) {
return mDecor.superDispatchTouchEvent(event);
}PhoneWindow的superDispatchTouchEvent方法很简单，就是直接将事件交给mDecor。而mDecor正是DecorView（实现为PhoneWindow中的内部类）的实例，即是Activity 中的顶级View，它是FrameLayout的子类，而它的superDispatchTouchEvent方法也直接调用了super.dispatchTouchEvent方法。而FrameLayout、LinearLayout、RelativeLayout等布局管理器的事件分发都继承自ViewGroup，因此，此时，事件交由ViewGroup处理。下面我们看一下ViewGroup如何分发事件。
ViewGroup的分发过程
ViewGroup中的dispatchTouchEvent方法比较长，有二百多行，因此这里将忽略逻辑不相关部分，按照事件分发逻辑逐步进行分析。
我们都知道，Android中以一个事件序列为单位进行处理，一个事件序列以ACTION_DOWN事件开始，以ACTION_UP事件结束，中间会有数个ACTION_MOVE事件。现在，我们看一下当一个事件到来时ViewGroup的处理逻辑：
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();
}首先，如果到来的事件是ACTION_DOWN，也即当一个新的事件序列到来时，会执行初始化操作，清除上个事件序列的touchTarget及其状态等。如果不是一个新的事件序列（即到来的不是ACTION_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 {
// There are no touch targets and this action is not an initial down
// so this view group continues to intercept touches.
intercepted = true;
}在分发的过程中，首先ViewGroup会判断是否拦截该事件（拦截则不再向下层View分发）。ViewGroup的onInterceptTouchEvent默认返回false，因此当actionMasked == MotionEvent.ACTION_DOWN或者mFirstTouchTarget != null时，ViewGroup不拦截该事件，否则intercepted = true。更进一步，也即如果一个新的事件序列到来，或者该事件序列已经被子View处理（也即mFirstTouchTarget != null）时，ViewGroup就不拦截该事件，将该事件向下层分发，否则拦截该事件（因为没有子View处理该事件序列，因此无需继续分发），交由ViewGroup来处理。然后看一下当ViewGroup不拦截事件时的处理逻辑：
final View[] children = mChildren;
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;
}
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);
}上面的代码虽然看起来比较长，但是逻辑还是比较清晰的，需要注意的是，在此循环外有一个if判断：
if ( actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE )不考虑鼠标和多指事件，那么只有ACTION_DOWN事件到来时才会进入上述循环进行分发，那么也就是说，因为进入循环的一定是ACTION_DOWN事件，此时已经清除了touchTargets，所以进入上述循环时getTouchTarget方法一定返回null，那么分发过程如下：
遍历该ViewGroup的所有子View，然后判断该子View是否能接收该事件（通过判断该View是否可见或者正在播放动画和该事件是否落在该View所在区域两个条件来决定），不满足条件则执行continue继续该循环。然后调用dispatchTransformedTouchEvent方法将事件依次分发给子View，寻找新的touchTarget。如果有子View处理了该事件，则通过addTouchTarget将新的target加到touchTargets链中，并赋值mFirstTouchTarget，然后结束循环。
if (mFirstTouchTarget == null) {
// No touch targets so treat this as an ordinary view.
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
}现在看一下mFirstTouchTarget == null时的处理。此时有两种情况，第一种：ViewGroup拦截了该事件，也即该事件不是ACTION_DOWN，并且mFirstTouchTarget == null，也就是说该事件序列的ACTION_DOWN事件没有被子View处理。第二种：该事件是ACTION_DOWN事件，并且该事件没有成功分发给子View，那么mFirstTouchTarget也会等于null。此时，调用dispatchTransformedTouchEvent方法将事件交由自己来处理（注意：此时第三个参数为null表示自己处理）。
dispatchTransformedTouchEvent方法的一部分如下：
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;上面这部分代码展示了dispatchTransformedTouchEvent方法的主要逻辑，也即如果child（该方法的第三个参数）为null，则调用父类（也即View类）的dispatchTouchEvent方法， 否则调用child的dispatchTouchEvent方法，将事件向下传递。如果child是一个ViewGroup，则将再次进行上述分发过程，而如果child只是一个View（此处的View不包含Viewgroup），则交给View类的dispatchTouchEvent处理。
如果到来的不是ACTION_DOWN事件，而且没有被拦截，那么此时一定有子View处理了该事件，那么就直接将事件分发给该子View，该子View保存在以mFirstTouchTarget为首的TouchTarget链表中：
TouchTarget predecessor = null;
TouchTarget target = mFirstTouchTarget;
while (target != null) {
final TouchTarget next = target.next;
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {
handled = true;
} else {
final boolean cancelChild = resetCancelNextUpFlag(target.child)
|| intercepted;
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;
}至此，ViewGroup对事件的分发过程就结束了，如果子View仍然是ViewGroup，那么就由子View重复上述过程，如果子View不是ViewGroup，那么就进入View（此处的View不包括ViewGroup）对事件的处理过程。
View的分发过程
由于View不包含子View，所以不用继续分发，收到事件时自己处理就好了。因此View中也没有事件拦截逻辑，也不包含onInterceptTouchEvent方法，当有事件分发给View时，该View就要处理该事件（但不一定成功处理）。View类的dispatchTouchEvent方法的处理逻辑如下：
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，如果设置了OnTouchListener则执行它的onTouch方法，如果OnTouchListener返回了true，则处理结束。否则执行View的onTouchEvent方法。由上可见，OnTouchListener的优先级比onTouchEvent高，并且如果OnTouchListener返回了true，则不会再执行onTouchEvent方法。
View类的onTouchEvent方法里会根据不同的事件进行相应的处理，比如在接收到ACTION_UP事件时通过performClick来完成OnClickListener（如果设置的有的话）的onClick等。需要注意的是，如果一个View被setEnable(false)，那么该View的OnTouchListener、onTouchEvent都不会被调用。但是，只要该View的clickable==true或者longClickable==true，那么该View都会消耗该事件，从onTouchEvent方法中位于头部的以下代码可以看出：
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);
}规律总结
通过上面的分析，我们能总结以下规律：
- ViewGroup一旦拦截事件，那么整个事件序列（如果还能传递给它）都将被拦截；
- 如果一个View没有处理ACTION_DOWN事件，那么该事件序列的后续事件都不会交给它处理；
- 如果一个View处理了ACTION_DOWN事件，但没有处理后续事件，那么该事件序列的后续事件将会最终交由Activity处理；
- View的onTouchEvent默认都会消耗事件，除非它的clickable和longClickable同时为false。
扫一扫
328
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
