我们知道点击事件的分发是由外向内的。下发过程为Activity=>Window=>View。
其中window对应则为activity的PhoneWindow，View则为PhoneWindow中的DecorView。
而DecorView将事件处理交由父类ViewGroup处理。
//------Activity#dispatchTouchEvent
public boolean dispatchTouchEvent(MotionEvent ev) {
......
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
//-----------PhoneWindow#superDispatchTouchEvent
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
//------------DecorView#superDispatchTouchEvent
public boolean superDispatchTouchEvent(MotionEvent event) {
return super.dispatchTouchEvent(event);
}
由源码可以看到最终走的是ViewGroup的dispatchTouchEvent流程去下发View的点击事件。该方法比较长，我们分段阅读。
if (actionMasked == MotionEvent.ACTION_DOWN) {
cancelAndClearTouchTargets(ev);//清空mFirstTouchTarget
resetTouchState();//重置标志位FLAG_DISALLOW_INTERCEPT
}
首先，如果事件为down事件则ViewGroup会将mFirstTouchTarge链表下发cancel事件及清空，并重置FLAG_DISALLOW_INTERCEPT标志位。这也是为什么子view不能影响ViewGroup对ACTION_DOWN事件处理的原因。
//mFirstTouchTarget在子view成功处理事件后不为null
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
//FLAG_DISALLOW_INTERCEPT为子View通过requestDisallowInterceptTouchEvent设置
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {//子view不拦截事件
intercepted = onInterceptTouchEvent(ev);//每次都询问是否拦截事件
ev.setAction(action); // restore action in case it was changed
} else {
intercepted = false;//子view拦截事件，自己不拦截
}
} else {
intercepted = true;//无处理对象，自己拦截
}
当actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null即处理事件子元素不为空或者事件为DOWN事件时，会判断时候拦截当前事件onInterceptTouchEvent(ev)
但子元素调用requestDisallowInterceptTouchEvent后则无法拦截DOWN事件以外的事件了（DOWN时会重置FLAG_DISALLOW_INTERCEPT标志位）
所以DOWN事件，ViewGroup总会询问是否需要拦截事件。
而当ViewGroup决定拦截事件后，后续点击事件都会由它处理并不再调用onInterceptTouchEvent()（因为对应的mFirstTouchTarget会清空）
接下来就是分析拦截和不拦截的处理过程了。
//不拦截，由子元素处理
final int childrenCount = mChildrenCount;
if (newTouchTarget == null && childrenCount != 0) {
......
final View[] children = mChildren;
//是倒序遍历的，即从最上层的子View开始往内层遍历
for (int i = childrenCount - 1; i >= 0; i--) {
.......
//点击事件坐标是否在child区域内
//child是否在播放动画
if (!canViewReceivePointerEvents(child)
|| !isTransformedTouchPointInView(x, y, child, null)) {
ev.setTargetAccessibilityFocus(false);
continue;
}
..........
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {//下发触摸事件
......
//将处理事件的view添加到mFirstTouchTarget链表中
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;//标记已经分发处理
break;
}
....
}
.....
}
这里毕竟清晰简单，不拦截由子元素处理时。遍历child，先判断点击区域是否在child区域范围内。在区域内则下发事件dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)，成功返回true后将child添加进mFirstTouchTarget链表中，并标识alreadyDispatchedToNewTouchTarget=true退出循环；下发返回false则继续遍历。
// 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);
} else {
// Dispatch to touch targets, excluding the new touch target if we already
// dispatched to it. Cancel touch targets if necessary.
TouchTarget predecessor = null;
TouchTarget target = mFirstTouchTarget;
while (target != null) {
final TouchTarget next = target.next;
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {//该target已经处理了该事件，跳过
handled = true;
} else {
//如果viewFlag被设置了PFLAG_CANCEL_NEXT_UP_EVENT ,那么就表示，下一步应该是Cancel事件
//或者如果当前的Action为取消，那么当前事件应该就是取消了
//拦截或resetCancelNextUpFlag，该child移出
final boolean cancelChild = resetCancelNextUpFlag(target.child)
|| intercepted;
//cancelChild == true，将会下发ACTION_CANCEL
//所以被拦截将直接下发ACTION_CANCEL
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;
}
}
拦截事件则mFirstTouchTarget == null，直接调用dispatchTransformedTouchEvent(ev, canceled, null, TouchTarget.ALL_POINTER_IDS)
mFirstTouchTarget != null则遍历mFirstTouchTarget，若event为cancel或者child被标记应该cancel或者intercepted == true这将会下发ACTION_CANCEL并将child移出。这样子的话，ViewGroup决定拦截某事件则后续都不会分配给子元素了，除非通过调用requestDisallowInterceptTouchEvent
上面下发事件和自己拦截都是通过dispatchTransformedTouchEvent方法的，其实这个方法逻辑也比较简单，伪代码大概如下：
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
if (child == null) {//ViewGroup拦截自己处理touch事件
handled = super.dispatchTouchEvent(event);
} else {
handled = child.dispatchTouchEvent(event);
}
return handled;
}
最终还是调起View#dispatchTouchEvent
public boolean dispatchTouchEvent(MotionEvent event) {
.......
boolean result = false;
.......
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;
}
}
........
return result;
}
View(不考虑ViewGroup)没有子元素只需要自己处理对应事件则可。
当View为enable状态且设置了OnTouchListener则优先调用OnTouchListener.onTouch。
当OnTouchListener.onTouch返回true则不再调用onTouchEvent(event)。所以OnTouchListener优先级高于onTouchEvent。
public boolean onTouchEvent(MotionEvent event) {
final float x = event.getX();
final float y = event.getY();
final int viewFlags = mViewFlags;
final int action = event.getAction();
final boolean clickable = ((viewFlags & CLICKABLE) == CLICKABLE
|| (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)
|| (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE;
//clickable的disable view仍会消耗触摸事件，它只是不响应它们。
if ((viewFlags & ENABLED_MASK) == DISABLED) {
if (action == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) {
setPressed(false);
}
mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN;
// A disabled view that is clickable still consumes the touch
// events, it just doesn't respond to them.
return clickable;
}
//View设置了代理则调用TouchDelegate.onTouchEvent，不展开。。。
if (mTouchDelegate != null) {
if (mTouchDelegate.onTouchEvent(event)) {
return true;
}
}
if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
switch (action) {
case MotionEvent.ACTION_UP:
........
boolean prepressed = (mPrivateFlags & PFLAG_PREPRESSED) != 0;
if ((mPrivateFlags & PFLAG_PRESSED) != 0 || prepressed) {
.......
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)) {
performClick();
}
}
}
.........
}
mIgnoreNextUpEvent = false;
break;
case MotionEvent.ACTION_DOWN:
//单击或者长按事件的判断,如果是长按则触发长按。
.......
break;
case MotionEvent.ACTION_CANCEL:
//复位操作
.......
break;
case MotionEvent.ACTION_MOVE:
//检测是否离开View区域，离开需要取消并复位
........
break;
}
return true;
}
return false;
}
从源码可以看到，View设置了Clickable后，就算为disable状态仍消费事件。
当MotionEvent.ACTION_UP时触发performClick()，如果View设置了OnClickListener则会调用内部onClick方法。
而longClick则再ACTION_DOWN时通过postDelayed方式判断通知。
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;
}
通过setOnClickListener、setOnLongClickListener会将CLICKABLE、LONG_CLICKABLE标志位置为1。
public void setOnClickListener(@Nullable OnClickListener l) {
if (!isClickable()) {
setClickable(true);
}
getListenerInfo().mOnClickListener = l;
}
public void setOnLongClickListener(@Nullable OnLongClickListener l) {
if (!isLongClickable()) {
setLongClickable(true);
}
getListenerInfo().mOnLongClickListener = l;
}
这样子，整套view的事件分发机制就此分析完成。
这时候看回《Android开发艺术探索》也就尤为清晰清楚了。
touch事件流（事件序列），由DOWN事件开始，由UP事件结束
-
正常情况，一个时间序列只能由一个View/ViewGroup处理拦截消耗。
- ViewGroup消耗了则
mFirstTouchTarget == null，intercepted == true，则拦截序列（不再询问onInterceptTouchEvent） - View拦截消耗了序列则跳出循环ViewGroup不再下发事件
- ViewGroup消耗了则
-
View/ViewGroup一旦决定拦截，则整个序列只能由它处理
-
requestDisallowInterceptTouchEvent，不再询问onInterceptTouchEvent，消耗事件则mFirstTouchTarget不为空，父元素不再处理 - ViewGroup#onInterceptTouchEvent确定拦截，将会清空
mFirstTouchTarget，由自己处理，不再询问onInterceptTouchEvent。
-
-
View/ViewGroup不消耗
ACTION_DOWN（onTouchEvent返回false）则后续不再交由它处理- 不消耗
ACTION_DOWN则mFirstTouchTarget == null，由父级处理。
- 不消耗
-
如果View消耗了
ACTION_DOWN而不消耗其他事件，则其父元素也不会消耗（不拦截），其他事件由Activity处理- 消耗了
ACTION_DOWN，mFirstTouchTarget != null，父元素不再处理
- 消耗了
ViewGroup默认不拦截任何事件，
onInterceptTouchEvent默认为falseView没有
onInterceptTouchEvent（无子元素），如果事件下发至它则OnTouchListener.onTouch(enable状态且有设置)/onTouchEvent一定会被调用。View#onTouchEvent默认都会消费事件（返回true），除非不可点击(clickable和longClickable同时为false)
View的enable属性不影响
onTouchEvent返回值，与clickable和longClickable有关。onClick发生前提为View可点击，且接收到
DOWN和UP事件子元素可以通过
requestDisallowInterceptTouchEvent干预父元素下发，但是DOWN事件除外。
参考：
《Android开发艺术探索》
