这是一个系列文章，如果没有责任链设计模式的基础知识，请移步Android事件分发流程（一）责任链设计模式
接着上文说，员工提交一次请假申请的处理流程，随着请假天数的增多请假流程涉及的到相关角色就会越来越多，请假申请的处理流程也就变得复杂了许多；而责任链设计模式，将每个角色的职责进行抽象，使得各个角色职责分明；因此，编码层面上讲，处理流程是清晰明确的。这就是责任链设计模式解决此类问题的优势所在。因此使用责任链设计模式实现Android系统事件分发机制是再合适不过的。
事件分发机制概述
View的事件分发机制是责任链的复杂场景，原因是上面介绍的请假申请处理流程是单一请求事件的分发处理，而Android的事件分发机制则是分发处理一次从按下到抬起的同一事件序列。
同一事件序列：是指从手指接触屏幕的那一刻起，到手指离开屏幕的那一刻结束，在这个过程中所产生的一系列的事件。这个事件序列以ACTION_DOWN事件开始，中间含有数量不定的ACTION_MOVE事件，最后以ACTION_UP事件结束。
一般来讲，同一事件序列只能被一个View对象拦截并消耗。因为一个视图对象一旦拦截了某次事件，那么同一事件序列的所有事件都会交给它来处理，因此同一事件序列不能分别由两个View同时处理。但是，特殊的手段可以做到这一点，比如一个视图对象将本该自己处理的事件通过onTouchEvent方法强行传递给其他View对象处理。
View对象一旦决定拦截事件，那么同一事件序列的其他事件都只能由它来处理（如果事件序列能传递给它的话），它的onInterceptTouchEvent不会再次被调用。原因是因为父容器会记录处理该事件序列的视图对象，从而优化事件分发流程。这一点稍后能在源码中看到。
如果视图对象一旦开始处理事件，但是不消耗ACTION_DOWN事件（onTouchEvent方法返回false），那么同一事件序列中的其它事件都不会交给他处理，而是将事件重新交给他的父元素处理（即调用onTouchEvent事件）。但是如果该视图对象只消耗了ACTION_DOWN事件，而不消耗其他事件的话，当前View可以持续受到后续的事件，最终这些消失的事件会被Activity处理。
ViewGroup默认不拦截任何事件。View没有onInterceptTouchEvent方法，一旦有点击事件传递给它，那么它的onTouchEvent方法就会被调用。View的onTouchEvent方法是默认会消耗事件（返回true），除非它是不可点击的（即clickable和longClickable同时为false），View的longClickable属性默认都为false；clickable属性不同的子类有不同的实现，如Button的clickable默认为true，而TextView的clickable属性默认为false。
View的enable属性不影响onTouchEvent的默认返回值，哪怕一个View 是disable状态，只要它的clickable、longClickable有一个为true，onTouchEvent就返回true。
点击事件onClick方法会被调用的前提是当前View可点击，并且收到了ACTION_DOWN和ACTION_UP事件。
事件传递过程是由外向内的，也就是说事件先传递给父容器，然后再由父元素分发给子View；子View可以通过requestDisallowInterceptTouchEvent方法可以在子元素中干预父容器的事件分发过程，但是ACTION_DOWN事件除外。
View的事件分发机制在安卓开发中一大难点同时也是核心知识点。了解了事件分发机制的处理机制是解决滑动冲突和实现高级View定制的前置知识。
以下结合源码分析android对事件分发机制的设计细节。
事件序列传递过程
事件传递过程传递顺序如下；
Activity->Window->View
事件总是先传递给Activity，Activity再传递给Window，然后Window在传递给顶级View处理。顶级View接收到时间后就会安卓事件分发机制去分发事件（着重关注这部分）。
- Activity对点击事件的分发过程
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
//如果Window消耗该事件，Activity的onTouchEvent就不会被调用
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
//如果Window元素没有处理该事件，Activity去处理
return onTouchEvent(ev);
}
- PhoneWindow对象的superDispatchTouchEvent方法会调用mDector对象进行处理。
我们都知道可以通过((ViewGroup)getWindow().getDecorView().findViewById(android.R.id.content)).getChildAt(0)可以获取Activity所设置的contentView视图，因此可以相信，Window对象直接交给顶级View去处理。
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
- 顶级View对点击事件的分发过程。
事件分发给顶级View（一般是ViewGroup）以后会调用ViewGroup的dispatchTouchEvent方法。事件分发机制的奥秘就在这个方法中。后续的介绍都是这部分内容。
事件分发流程中的三个核心方法
-
dispatchTouchEvent(MotionEvent event)
用来进行事件分发。如果事件能够传递给当前的View，那么该方法一定会被调用，该方法的返回值取决于当前View的onTouchEvent和下级View的dispatchTouchEvent方法的影响，表示是否消耗当前事件。 -
onInterceptTouchEvent(MotionEvent event)
在上述方法内部调用，用于判断是否拦截这个事件，如果当前View拦截某个事件，那么在同一个事件序列中，不会再次调用该方法，返回值表示是否拦截当前事件。 -
onTouchEvent(MotionEvent event)
处理当前事件的方法，返回值表示是否消耗当前事件，如果不消耗，在同一事件序列中，当前View无法再次接受到事件。
下面的伪代码，可以将三者的关系表达清楚；
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean consume=false;
if(onInterceptTouchEvent(ev)){//判断是否拦截该事件
consume=onTouchEvent(ev);//拦截该事件的话，调用自己处理事件的方法
} else {
consume=child.dispatchTouchEvent(ev);//不拦截事件，交给子View进行事件分发处理
}
return consume;//返回是否消耗该事件
}
顶级View的分发过程
dispatchTouchEvent源码分析
ViewGroup中的dispatchTouchEvent方法是了解事件分发过程的非常重要的方法，它是View事件分发流程的入口方法。研究一个方法我们关注的有如下几点，方法的入参，返回值和实现逻辑。
- 入参
方法的入参是一个MotionEvent对象，即点击事件。该对象常用的有三种状态分别是ACTION_DOWN、ACTION_MOVE、ACTION_UP。以这三种状态为切入点进行解读，能够更清晰的理解实现逻辑。
- 返回值
布尔类型的返回值，表示是否消耗这个事件。
- 实现逻辑
参数表示方法的输入，返回值表示方法的输出，而最重要的实现细节，是读懂源码的关键。下面由点带面的进行解读。
当方法收到一个点击事件，会做那些工作？
- 点击事件标记为ACTION_DOWN时执行按下事件初始化操作。
主要做的工作，是重置FLAG_DISALLOW_INTERCEPT标志位、取消和清除处理触摸事件的目标对象；
// 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();
}
- 判断是否拦截当前事件
可以看出下面这段逻辑不只是会在ACTION_DOWN事件产生时才会进入，当mFirstTouchTarget != null时也会进入。mFirstTouchTarget对象是何时被赋值的呢？答案是当事件有ViewGroup的子元素成功处理时该对象会被赋值并指向子元素，这一点稍后会具体分析。由此得知，当前点击事件标记不是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的所有子元素，然后判断子元素是否能够接收到点击事件。能否接收点击事件的判断依据是：子元素可见（VISIBLE状态或正在播动画导致的非VISIBLE状态）和点击事件的坐标落在子元素的区域内。如果某个子元素同时满足这两个条件，那么事件就会传递给它来处理。
//注：该方法片段位于ViewGroup的dispatchTouchEvent方法中
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;
}
//判断child元素能否处理该事件用到的两个方法；分割线下附有方法详情介绍
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;
}
}
----------------------------------------分割线--------------------------------------
//判断child元素能否处理该事件用到的两个方法，两则必须都满足才能交给该child元素处理
/**
* Returns true if a child view can receive pointer events.
* 判断视图能否处理事件的第一个方法：可见或正在播动画导致的不可见。
* @hide
*/
private static boolean canViewReceivePointerEvents(@NonNull View child) {
return (child.mViewFlags & VISIBILITY_MASK) == VISIBLE
|| child.getAnimation() != null;
}
/**
* Returns true if a child view contains the specified point when transformed
* into its coordinate space.
* Child must not be null.
* 子判断视图能否处理事件的第一个方法：点击事件的坐标是否落在子元素的区域内
* @hide
*/
protected boolean isTransformedTouchPointInView(float x, float y, View child,
PointF outLocalPoint) {
final float[] point = getTempPoint();
point[0] = x;
point[1] = y;
transformPointToViewLocal(point, child);
final boolean isInView = child.pointInView(point[0], point[1]);
if (isInView && outLocalPoint != null) {
outLocalPoint.set(point[0], point[1]);
}
return isInView;
}
dispatchTransformedTouchEvent方法实际上就是调用子元素的dispatchTouchEvent方法。其中有一段代码值得细看。当传递的child元素为空时，直接调用当前对象的父类（也就是View类）的事件分发方法进行处理。如下。
//注：改代码片段位于ViewGroup的dispatchTransformedTouchEvent方法中，可能有所删减
// Perform any necessary transformations and dispatch.
if (child == null) {
//这几乎容易被忽略，ViewGroup的父类是View所以会调用View类的分发记住进行分发。
//View类的分发机制会在后面进行分析。
//聪明的你一定会发现，如果不加super的话会导致死循环(持续的递归)。
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);
}
// Done.
ViewGroup将事件交给child元素处理，如果该事件被child元素成功处理了，就会通过addTouchTarget完成mFirstTouchTarget的赋值。其实mFirstTouchTarget是单链表结构的实例。经过之前的分析我们知道，mFirstTouchTarget是否为null直接影响了ViewGroup对事件的拦截策略，这是前面已经提到过的。addTouchTarget方法源码如下。
/**
* Adds a touch target for specified child to the beginning of the list.
* Assumes the target child is not already present.
*/
private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) {
final TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
target.next = mFirstTouchTarget;
mFirstTouchTarget = target;
return target;
}
经过对子元素的遍历之后，如果mFirstTouchTarget依然为null，证明事件没有被子元素合适地处理。有两种情况导致这一结果：
- ViewGroup没有子元素可以处理事件。
- 子元素处理了点击事件，但是没有消耗事件
这个时候，ViewGroup会自己处理点击事件。这块逻辑的代码表示如下。
// 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);
}
View类事件的处理过程
经过对子元素的遍历之后，事件没有被子元素合适地处理，就像上面说到的ViewGroup会自己处理该事件。这时，ViewGroup会调用它的父类（基类）的dispatchTouchEvent方法进行处理，也就是将要分析的这段内容。
View类对点击事件的处理过程对比ViewGroup的处理简单些，原因是View类型的元素是一个单独的元素而非视图容器，因此无需进行向下传递只能自己处理。
//注：该方法位于View类中，方法体内代码有所删减
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处理事件的优先级
根据上面的代码看出，如果View的mOnTouchListener != null 时会被优先调用，如果事件被mOnTouchListener消耗，此时onTouchEvent方法会被屏蔽；如果mOnTouchListener未被设置或者已设置但是当前事件没有被消耗掉，这时才会调用onTouchEvent方法处理当前事件。由此可见，onTouchListener的优先级高于onTouchEvent。
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);
}
通过上面的代码能很明显的看出，处于DISABLED状态的View依然可以消耗点击事件。
接着往下看，如果View元素设置了TouchDelegrate类型的代理，这时会执行代理类中的onTouchEvent方法，该类的工作机制和OnTouchListener类似，这里不深入分析。源码如下。
if (mTouchDelegate != null) {
if (mTouchDelegate.onTouchEvent(event)) {
return true;
}
}
View类的onTouchEvent方法的具体处理逻辑代码，如下所示。
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;
}
if (isInScrollingContainer) {
```省略部分代码
} else {
// Not inside a scrolling container, so show the feedback right away
setPressed(true, x, y);
checkForLongClick(0, x, y);
}
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;
}
上面的代码是略长的，主要的分析关注的点是点击事件和长按事件的处理过程，涉及到以上的四种类别的事件的处理，相信分析起来并不困难。
值得提出的一点是，在onTouchEvent方法中如果当前设置了OnClickListener,那么在MotionEvent.ACTION_UP事件处理时它的onClick方法才会在performClick方法的内部调用。因此OnClickListener，优先级最低，处于事件传递的尾端。
ViewGroup 默认的是否拦截事件的判断
ViewGroup默认拦截事件的的方法分析，当点击事件的点击点，坐落在ScrollbarThumb上的时候进行拦截，否则是默认不拦截事件的。
public boolean onInterceptTouchEvent(MotionEvent ev) {
if (ev.isFromSource(InputDevice.SOURCE_MOUSE)
&& ev.getAction() == MotionEvent.ACTION_DOWN
&& ev.isButtonPressed(MotionEvent.BUTTON_PRIMARY)
&& isOnScrollbarThumb(ev.getX(), ev.getY())) {
return true;
}
return false;
}
到此，从Android源码层面分析事件传递过程已经分析完了。
后续文章会做滑动冲突类型的实例分析。敬期。
