Android事件分发——View篇
接上文，我们谈到事件传递到ViewGroup后，如果有子 View，并且子View可以接受事件，那么就回调用子View（可能是一个View，也可能是一个ViewGroup）的dispatchTouchEvent()方法。而如果没有子 View，或者子View不能接受事件，那么就会调用ViewGroup的父类，也就是View的dispatchTouchEvent()方法中。
那么我们看一看View里面的dispatchTouchEvent()的代码：
/** * Pass the touch screen motion event down to the target view, or this * view if it is the target. * * @param event The motion event to be dispatched. * @return True if the event was handled by the view, false otherwise. */
public boolean dispatchTouchEvent(MotionEvent event) {
// If the event should be handled by accessibility focus first.
if (event.isTargetAccessibilityFocus()) {
// We don't have focus or no virtual descendant has it, do not handle the event.
if (!isAccessibilityFocusedViewOrHost()) {
return false;
}
// We have focus and got the event, then use normal event dispatch.
event.setTargetAccessibilityFocus(false);
}
boolean result = false;
if (mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onTouchEvent(event, 0);
}
final int actionMasked = event.getActionMasked();
if (actionMasked == MotionEvent.ACTION_DOWN) {
// Defensive cleanup for new gesture
stopNestedScroll();
}
if (onFilterTouchEventForSecurity(event)) {
//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;
}
}
if (!result && mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onUnhandledEvent(event, 0);
}
// Clean up after nested scrolls if this is the end of a gesture;
// also cancel it if we tried an ACTION_DOWN but we didn't want the rest
// of the gesture.
if (actionMasked == MotionEvent.ACTION_UP ||
actionMasked == MotionEvent.ACTION_CANCEL ||
(actionMasked == MotionEvent.ACTION_DOWN && !result)) {
stopNestedScroll();
}
return result;
}第26行判断是否为ACTION_DOWN，如果是，则停止滚动。
第31行通过onFilterTouchEventForSecurity()方法判断当前View是否被覆盖。
第34行开始有一个判断语句：if (li != null && li.mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED && li.mOnTouchListener.onTouch(this, event))。
这个判断语句比较重要，下面逐个分析：
- li 对象肯定不为空。因为li对象由mListenerInfo赋值，而关于mListenerInfo有下面的代码存在：
ListenerInfo getListenerInfo() {
if (mListenerInfo != null) {
return mListenerInfo;
}
mListenerInfo = new ListenerInfo();
return mListenerInfo;
}- li.mOnTouchListener 是否为空呢？这个就要看我们是否为View设置了OnTouchListener了，如果设置了，就不为空；没设置就为空。
(mViewFlags & ENABLED_MASK) == ENABLED这个判断当前的View是否为ENABLE，默认都是enable。li.mOnTouchListener.onTouch(this, event))这个就是判断OnTouchLinstener的返回了。
如果上面4点都为true，则34行的判断语句也为true。这时候View中的dispatchTouchEvent()返回值也为true。
到这里我们就能推导出一些结论性的东西了：View的dispatchTouchEvent()方法触发后，如果该View为ENABLE，并设置了OnTouchLisener且返回为true。那么该View的dispatchTouchEvent()返回true。
如果该View没有设置OnTouchListener()或者OnTouchListener()返回false。那么就会执行到第40行做一个判断onTouchEvent(event)。那么onTouchEvent()什么时候返回true？什么时候返回false呢？我们可以看一下该方法的源码：
public boolean onTouchEvent(MotionEvent event) {
final float x = event.getX();
final float y = event.getY();
final int viewFlags = mViewFlags;
final int action = event.getAction();
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);
}
if (mTouchDelegate != null) {
if (mTouchDelegate.onTouchEvent(event)) {
return true;
}
}
if (((viewFlags & CLICKABLE) == CLICKABLE ||
(viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE) ||
(viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE) {
switch (action) {
case MotionEvent.ACTION_UP:
boolean prepressed = (mPrivateFlags & PFLAG_PREPRESSED) != 0;
if ((mPrivateFlags & PFLAG_PRESSED) != 0 || prepressed) {
// take focus if we don't have it already and we should in
// touch mode.
boolean focusTaken = false;
if (isFocusable() && isFocusableInTouchMode() && !isFocused()) {
focusTaken = requestFocus();
}
if (prepressed) {
// The button is being released before we actually
// showed it as pressed. Make it show the pressed
// state now (before scheduling the click) to ensure
// the user sees it.
setPressed(true, x, y);
}
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();
}
}
}
if (mUnsetPressedState == null) {
mUnsetPressedState = new UnsetPressedState();
}
if (prepressed) {
postDelayed(mUnsetPressedState,
ViewConfiguration.getPressedStateDuration());
} else if (!post(mUnsetPressedState)) {
// If the post failed, unpress right now
mUnsetPressedState.run();
}
removeTapCallback();
}
mIgnoreNextUpEvent = false;
break;
case MotionEvent.ACTION_DOWN:
mHasPerformedLongPress = false;
if (performButtonActionOnTouchDown(event)) {
break;
}
// Walk up the hierarchy to determine if we're inside a scrolling container.
boolean isInScrollingContainer = isInScrollingContainer();
// For views inside a scrolling container, delay the pressed feedback for
// a short period in case this is a scroll.
if (isInScrollingContainer) {
mPrivateFlags |= PFLAG_PREPRESSED;
if (mPendingCheckForTap == null) {
mPendingCheckForTap = new CheckForTap();
}
mPendingCheckForTap.x = event.getX();
mPendingCheckForTap.y = event.getY();
postDelayed(mPendingCheckForTap, ViewConfiguration.getTapTimeout());
} else {
// Not inside a scrolling container, so show the feedback right away
setPressed(true, x, y);
checkForLongClick(0);
}
break;
case MotionEvent.ACTION_CANCEL:
setPressed(false);
removeTapCallback();
removeLongPressCallback();
mInContextButtonPress = false;
mHasPerformedLongPress = false;
mIgnoreNextUpEvent = false;
break;
case MotionEvent.ACTION_MOVE:
drawableHotspotChanged(x, y);
// Be lenient about moving outside of buttons
if (!pointInView(x, y, mTouchSlop)) {
// Outside button
removeTapCallback();
if ((mPrivateFlags & PFLAG_PRESSED) != 0) {
// Remove any future long press/tap checks
removeLongPressCallback();
setPressed(false);
}
}
break;
}
return true;
}
return false;
}这个方法的代码和ViewGroup的dispatchTouchEvent()源码的长度有得一拼了。
第7行有一个判断，如果该View为DISABLE，返回值就由13行的判断决定：如果CLICKABLE、LONG_CLICKABLE或CONTEXT_CLICKABLE有一个为true，则返回true。（默认情况下，LONG_CLICKABLE为false）
其实我们可以发现，只要进了第7行判断的代码，该onTouchEvent()方法就返回true，否则就返回false。这一点很重要。
如果View是ENABLE的，那么就会进入第24行的判断。在ACTION_UP事件里面，有一个方法performClick()我们看一下它的源码：
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;
}
sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED);
return result;
}在第4行有一个判断。之前已经知道了li不为空了。那么li.mOnClickListener呢？我们看一下li.mOnClickListener赋值的地方：
public void setOnClickListener(@Nullable OnClickListener l) {
if (!isClickable()) {
setClickable(true);
}
getListenerInfo().mOnClickListener = l;
}setOnClickLisnter()！！！多么熟悉的方法！！！也就是说，如果我们为View重写了setOnClickLinstener()方法的话，performClick()就返回true，否则返回false。
好了，结合上面的分析，我们可以得出关于View事件分发的一些结论：
- 如果设置了
OnTouchListener()且返回true。View的事件流程就完成了，不会执行到OnClickLinstener()方法。 - 如果没有设置
OnTouchLinstener()或者设置了OnTouchListener()且返回false。则View会执行OnClickLinster()方法。
如果View中的dispatchTouchEvent()返回了false，结合我们之前对于Activity的相关分析，就会调用到Activity的onTouchEvent()方法。
终于结束了一个事件的轮回，不容易啊。
让我喝口茉莉花茶，再聊聊剩下的。
小结
结合之前对Activity和ViewGroup的相关分析，我们可以得出事件分发的大致流程：
- 事件分发是从
Activity开始，传递到Window，再传递给视图的顶级View（一般是View的子类ViewGroup）。然后顶级View再派发事件。 - 事件传递到ViewGroup之后，会首先调用
dispatchTouchEvent()方法，然后执行onInterceptTouchEvent()方法。由于ViewGroup中的该方法默认返回false，所以ViewGroup默认不拦截事件。如果我们重写了onInterceptTouchEvent()方法并返回了true，那么该事件就被消耗掉了，不会往下派发了。否则传递到子View(如果有），或者调用View的onInterceptTouchEvent()方法。 - 当事件传递到View之后（这里的View包含ViewGroup），会首先调用
dispatchTouchEvent()方法。在该方法内会调用OnTouchListener()，如果设置了OnTouchListener()且返回true。View的事件流程就完成了，不会执行到OnClickLinstener()方法。如果没有设置OnTouchLinstener()或者设置了OnTouchListener()且返回false。则View会执行OnClickLinster()方法。至此，一个事件派发结束。 - 如果事件在ViewGroup中就被拦截了（onInterceptTouchEvent()方法被重写并返回了true），或者事件在View中的
dispatchTouchEvent()方法返回了false。（有好多种可能的情况使得该方法返回false，详见上面的分析），就会调用到Activity中的onTouchEvent()方法。
也就是说，在整个流程中会涉及到以下三个方法：
- dispatchTouchEvent() 用来分发事件。如果事件传递到了某个view，则该view的
dispatchTouchEvent()方法肯定会调用到。而其返回值受到下面两个方法的影响。 - inInterceptTouchEvent() 只有ViewGroup中存在该方法，用来决定是否拦截某个事件。
- onTouchEvent() 在dispatchTouchEvent()方法中会调用到这个方法。用来处理点击事件。
当然，在分析的过程中我们也得出了一些比较有意思的结论，比如：
- View的
ENABLE属性是否为true并不会对onTouchEvent()的默认返回值有影响。只要clickable、longclickable或者contextclickable有一个为true，那么onTouchEvent()就返回true。 - 我们可以通过
requestDisallowInterceptTouchEvent()方法在子View中控制父View的事件是否传递，但是对ACTION_DOWN事件除外。 - View没有
onInterceptTouchEvent()方法，而ViewGroup中有该方法。这是二者的区别之一。
大概就是这些了，欢迎交流。