开局先一张“毒”，本文讲的是Android中的事件分发机制，根据Android事件分发机制前篇——事件如何传递到Activity中分析的，当我们触摸屏幕时，输入事件将会传入到Activity中。那么之后事件又是如何传递到具体的View当中去的呢？让我们结合源码再去进一步分析事件分发机制。
1. 点击事件的三个重要方法！
我们在研究事件分发机制，其实讨论的就是MotionEvent事件的分发过程，即当一个MotionEvent产生了以后，系统需要把这个事件传递给一个具体的View，这个传递的过程就是分发过程。点击事件的分发过程由下面三个很重要的方法来共同完成：
public boolean dispatchTouchEvent(MotionEvent ev)
用来进行事件的分发，如果事件能欧传递到当前View，那么此方法一定会调用，返回结果受当前View的onTouchEvent和下级View的dispatchTouchEvent方法的影响，当返回True时，表示当前View消耗事件，返回false，则传递到下一级View。
public boolean onInterceptTouchEvent(MotionEvent ev)
ViewGroup中的方法，用来判断是否拦截某个事件。返回true，表示当前ViewGroup拦截了事件，如果拦截，那么在同一个事件序列中（即一次ACTION_DOWN到ACTION_UP）此方法不会被再次调用。
public boolean onTouchEvent(MotionEvent ev)
在dispatchTouchEvent()方法中调用，用来处理点击事件，返回结果表示是否消耗事件。
2. 事件传递规则
展示我画工的时候到了！请看下图：
当Activity接受到点击事件后，会传递给Window再传递给DecorView，DecorView就是一个ViewGroup，他的dispatchTouchEvent就会被调用，如果这个ViewGroup的onInterceptTouchEvent方法返回true，就表示它要拦截事件，事件就会交给这个ViewGroup来处理；如果这个ViewGroup的onInterceptTouchEvent返回false，表示不拦截当前事件，这时，当前事件就会继续传递给它的子元素，子元素的dispatchTouchEvent方法就会被调用，如此反复直到事件被最终处理。（ViewGroup一般默认不拦截事件）
这里如果子元素是ViewGroup，那么和上面步骤一样，如果子元素是View或者是ViewGroup要自己处理事件。那么要看是否设置了onTouchListener，并且它的onTouch返回值是否为true，如果返回true那么onTouchEvent就不会被回调；如果onTouch返回值为false，那么onTouchEvent就会被调用。
而在onTouchEvent方法中，如果设置了onClickListener，那么它的onClick方法会被调用。
如果一个点击事件产生后，没有View消费这个事件，那么就会交给Activity的onTouchEvent()处理。
3. 分析源码
上面介绍了Android事件分发机制的三个重要的方法以及一些简单的传递规则，那么究竟这三个方法是如何共同工作的呢？我们从源码的角度进一步分析。
假设我们的页面如图，我们以一次最简单的点击View事件为例，当事件发生时，究竟会发生什么呢？
我们先从Activity的dispatchTouchEvent()开始分析
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
onUserInteraction()是一个空方法，它是让开发者自己去重写的，如果需要知道用户与设备正在进行交互，可以重写这个方法。我们再分析上面的代码，通过getWindow().superDispatchTouchEvent(ev)事件将会交给Activity所附属的Window进行分发，如果返回true，那么事件循环就结束了，返回false意味着没人处理，所有View的onTouchEvent都返回false，那么Activity的onTouchEvent就会被调用。
通过源码我们知道Window是个抽象类，Window的superDispatchTouchEvent()也是一个抽象方法啊，所以，我们必须找到Window的实现类，也就是PhoneWindow。PhoneWindow是Window的唯一实现。每个Activity都有一个自己的PhoneWindow，我们来看到它是如何处理点击事件的：
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
到这里，我们应该很清晰了，PhoneWindow将事件直接传递给了DecorView，DecorView是Activity的顶级View，我们在Activity中setContentView()方法设置的布局文件，就是加入到DecorView中的。DecorView继承自FrameLayout，FrameLayout继承自ViewGroup，所以我们知道事件已经传递到顶层的ViewGroup了。
那么DecorView是如何对事件进行分发的呢？我们看DecorView的superDispatchTouchEvent()方法：
public boolean superDispatchTouchEvent(MotionEvent event) {
return super.dispatchTouchEvent(event);
}
在这个方法中，DecorView直接调用了父类的dispatchTouchEvent(event)方法，也就是ViewGroup中的dispatchTouchEvent(event)方法。
所以我们来分析ViewGroup中，dispatchTouchEvent(event)是如何实现事件的分发的：
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
//一致性判断
if (mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onTouchEvent(ev, 1);
}
// If the event targets the accessibility focused view and this is it, start
// normal event dispatch. Maybe a descendant is what will handle the click.
if (ev.isTargetAccessibilityFocus() && isAccessibilityFocusedViewOrHost()) {
ev.setTargetAccessibilityFocus(false);
}
boolean handled = false;
//过滤掉不安全的触摸事件，其实是判断窗口被遮挡
if (onFilterTouchEventForSecurity(ev)) {
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
//....省略了一大段代码
}
//一致性判断
if (!handled && mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onUnhandledEvent(ev, 1);
}
return handled;
}
咦？怎么只有这么一点代码？嘿嘿，因为我省略了一大段代码。。我知道一下子贴出来这么多代码是没有人看滴！所以我先贴出来了外围的代码，虽然这些代码不是很重要。。。能注释的已经注释了，不能注释的我也无能为力了。
让我们进入那一大段被我省略的代码中去吧，当然，我会按顺序分成一小段一小段的来说
1.第一部分代码
// 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即为新的事件序列，因为ACTION_DOWN事件序列的开端），做重置状态的操作，其中cancelAndClearTouchTargets(ev)会将mFirstTouchTarget（下一部分源码将会讲到） 设置为null，resetTouchState()会将Touch状态标记清空。
2.第二部分代码
// Check for interception.
final boolean intercepted;
//当事件类型为ACTION_DOWN，或者mFirstTouchTarget不为null时
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
//判断是否设置FLAG_DISALLOW_INTERCEPT标记位，
//用来标记不允许拦截除了ACTION_DOWN以外的其他点击事件
//子View可以通过requestDisallowInterceptTouchEvent设置父View的该标记位
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
//当没有设置FLAG_DISALLOW_INTERCEPT标记位时，通过onInterceptTouchEvent()方法判断是否拦截
//这里体现了在dispatchTouchEvent()中调用了onInterceptTouchEvent()
intercepted = onInterceptTouchEvent(ev);
ev.setAction(action); // restore action in case it was changed
} else {
//不拦截，将intercepted设为false
intercepted = false;
}
} else {
// There are no touch targets and this action is not an initial down
// so this view group continues to intercept touches.
//设为true，表示拦截，将事件交给自己处理
intercepted = true;
}
上面的代码是检查是否拦截当前事件，使用变量intercepted记录是否拦截事件，我们可以看出，ViewGroup在事件类型为ACTION_DOWN或者mFirstTouchTarget！= null时，判断是否要拦截当前事件。ACTION_DOWN大家应该都知道是什么意思，那么mFirstTouchTarget到底是什么呢，在这里先给出结论，当一个点击动作发生时，ACTION_DOWN事件被ViewGroup的子元素成功处理时，mFirstTouchTarget将会被赋值，并指向这个子元素。这有什么用呢？用这个mFirstTouchTarget可以记录是否是子元素消费了一个点击动作当中的ACTION_DOWN事件，当ACTION_DOWN事件被ViewGroup拦截时，mFirstTouchTarget就为null，那么当这个点击动作事件序列的ACTION_MOVE和ACTION_UP事件到来时(actionMasked==MotionEvent.ACTION_DOWN || mFirstTouchTarget != null)这个条件就为false，这将使ViewGroup不用调用onInterceptTouchEvent()就直接将事件拦截交给自身处理。
判断了actionMasked == MotionEvent.ACTION_DOWN|| mFirstTouchTarget != null后，还得判断FLAG_DISALLOW_INTERCEPT这个标记位，这个标记位在requestDisallowInterceptTouchEvent()方法中设置，一般在子View中调用该方法，会使得ViewGroup无法拦截除了ACTION_DOWN以外的其他点击事件。为什么是除了ACTION_DOWN呢？因为在第一部分代码中，当ViewGroup分发事件时，如果事件类型是ACTION_DOWN，就会重置状态，resetTouchState()方法中，将会对FLAG_DISALLOW_INTERCEPT进行重置，并且mFirstTouchTarget 也会置空。
当设置了FLAG_DISALLOW_INTERCEPT标记位时，变量intercepted直接设为false，表示不拦截事件，当没有设置该标记位是，那么就要调用ViewGroup中的onInterceptTouchEvent(ev)，来看它的源码：
public boolean onInterceptTouchEvent(MotionEvent ev) {
//事件源是鼠标指向设备
if (ev.isFromSource(InputDevice.SOURCE_MOUSE)
//事件类型时ACTION_DOWN类型时
&& ev.getAction() == MotionEvent.ACTION_DOWN
//用户按下一个按钮时
&& ev.isButtonPressed(MotionEvent.BUTTON_PRIMARY)
//处于滚动条上时
&& isOnScrollbarThumb(ev.getX(), ev.getY())) {
return true;
}
return false;
}
可以看到一般情况下onInterceptTouchEvetn默认返回false，也就是不拦截事件，只有当代码中的注释都满足时，才会返回true。如果子View收到了ACTION_DOWN事件，而开发者又在这个方法中拦截了剩余的事件，那么子View将会收到ACTION_CANCEL事件。
总结一下上面的代码：
- 当ViewGroup决定拦截事件后，那么后续的点击事件将会默认的交给它处理，并且不再调用它的onInterceptTouchEvent()方法。
- 通过子View可以通过
requestDisallowInterceptTouchEvent()方法在子元素中干预父元素的事件分发过程，ACTION_DOWN事件除外。
让我们继续分析接下来的代码把
第三部分代码
// 检查事件是否取消
final boolean canceled = resetCancelNextUpFlag(this)
|| actionMasked == MotionEvent.ACTION_CANCEL;
// 判断事件是否分发给多个子元素，默认为true
final boolean split = (mGroupFlags & FLAG_SPLIT_MOTION_EVENTS) != 0;
TouchTarget newTouchTarget = null;
boolean alreadyDispatchedToNewTouchTarget = false;
if (!canceled && !intercepted) {
//事件不是ACTION_CANCEL并且ViewGroup的拦截标志位intercepted为false(不拦截)
View childWithAccessibilityFocus = ev.isTargetAccessibilityFocus()
? findChildWithAccessibilityFocus() : null;
//处理事件序列开端的事件
if (actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
final int actionIndex = ev.getActionIndex(); // always 0 for down
final int idBitsToAssign = split ? 1 << ev.getPointerId(actionIndex)
: TouchTarget.ALL_POINTER_IDS;
// Clean up earlier touch targets for this pointer id in case they
// have become out of sync.
removePointersFromTouchTargets(idBitsToAssign);
final int childrenCount = mChildrenCount;
if (newTouchTarget == null && childrenCount != 0) {
//这里获取触摸事件点的坐标
final float x = ev.getX(actionIndex);
final float y = ev.getY(actionIndex);
// 下面的这一段代码就是通过遍历寻找接受事件的子View
// 获得子View的集合
final ArrayList<View> preorderedList = buildTouchDispatchChildList();
final boolean customOrder = preorderedList == null
&& isChildrenDrawingOrderEnabled();
final View[] children = mChildren;
// 遍历子View判断哪个子View接受Touch事件
for (int i = childrenCount - 1; i >= 0; i--) {
final int childIndex = getAndVerifyPreorderedIndex(
childrenCount, i, customOrder);
final View child = getAndVerifyPreorderedView(
preorderedList, children, childIndex);
if (childWithAccessibilityFocus != null) {
if (childWithAccessibilityFocus != child) {
continue;
}
childWithAccessibilityFocus = null;
i = childrenCount - 1;
}
//判断子元素是否能接收到点击事件
if (!canViewReceivePointerEvents(child)
|| !isTransformedTouchPointInView(x, y, child, null)) {
ev.setTargetAccessibilityFocus(false);
continue;
}
//getTouchTarget去找到接收Touch事件的子View
//如果有则返回这个target，否则返回null
newTouchTarget = getTouchTarget(child);
if (newTouchTarget != null) {
//在这段代码的if判断通过说明找到了接收Touch事件的子View，即newTouchTarget，
//那么，既然已经找到了，所以执行break跳出for循环
newTouchTarget.pointerIdBits |= idBitsToAssign;
break;
}
resetCancelNextUpFlag(child);
//if括号中的方法其实是调用子View的dispatchTouchEvent()方法，
//如果返回true，则对mFirstTouchTarget赋值并跳出循环
//返回false，继续将事件分发给下一个子元素
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();
//子元素的dispatchTouchEvent()返回true，那么mFirstTouchTarget被赋值，同时break跳出循环。
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 (preorderedList != null) preorderedList.clear();
}
//表示经过前面的for循环没有找到子View接收Touch事件并且之前的mFirstTouchTarget不为空则为真，
//然后newTouchTarget指向了最初的TouchTarget。
if (newTouchTarget == null && mFirstTouchTarget != null) {
// Did not find a child to receive the event.
// Assign the pointer to the least recently added target.
newTouchTarget = mFirstTouchTarget;
while (newTouchTarget.next != null) {
newTouchTarget = newTouchTarget.next;
}
newTouchTarget.pointerIdBits |= idBitsToAssign;
}
}
}
啊！这一段代码可够长的啊，先总结一下，这一段代码做的主要是寻找在事件序列开端的类型时（ACTION_DOWN，ACTION_POINTER_DOWN这个为多点触摸动作，或者ACTION_HOVER_MOVE这个为鼠标进入View）对子View进行一个遍历寻找接收事件的目标View，并对mFirstTouchEvent赋值。我们再进行具体分析：
想要对子View进行遍历还要经过三次判断，重重考验！
首先通过
if (!canceled && !intercepted) {判断事件不为ACTION_CANCEL并且ViewGroup的拦截标志位intercepted为false(不拦截)就会进入其中。然后通过下面的事件类型判断事件为事件序列的开端，则再进入下一步，只有事件序列的开端会寻找目标View，其他事件如ACTION_MOVE，ACTION_UP将会直接交给目标View来处理。
if (actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
- 最后通过
if (newTouchTarget == null && childrenCount != 0) {判断是否已经找到了目标View，和是否有子元素。很容易理解，找到了目标了就不用进行遍历寻找了，没有子元素，也不用进行寻找。
经过三重判断之后，总算深入敌军内部了！
final float x = ev.getX(actionIndex);
final float y = ev.getY(actionIndex);
// 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;
for (int i = childrenCount - 1; i >= 0; i--) {
可以看到，这里先获得触摸事件的坐标，再获得子View的list集合preorderedList，再进行一个倒序遍历。为什么是倒序遍历呢？这是因为preorderedList中的顺序是按照addView或者XML布局文件中的顺序来的，后addView添加的子View，会因为Android的UI绘制机制显示在上层；假如点击的地方有两个子View都包含的点击的坐标，那么后被添加到布局中的那个子view会先响应事件，所以，这样的顺序是顺理成章的。
接下来就是在循环中获得子View，并通if(!canViewReceivePointerEvents(child)||!isTransformedTouchPointInView(x, y, child, null))判断子元素是否能接受到点击事件，能否接收到点击事件主要由两点衡量：1. 子元素是否在播动画2. 点击事件是否落在子元素的区域内。前者判断第一点，后者判断第二点。如果满足，则继续，，如果都不满足，那这位选手只能被淘汰了，下一位选手继续。
成功过关的选手，就要判断它是否是我们要找的那个目标View了，请看下面代码：
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;
}
getTouchTarget(child)是用来获得指定View的TouchTarget对象的，如果存在指定View的TouchTarget对象，就返回该对象，否则返回null。判断newTouchTarget是否为空，表明是否已经找到了目标View。当newTouchTarget不为null时，表示已经找到，break跳出循环。
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
...
//子元素的dispatchTouchEvent()返回true，
//那么mFirstTouchTarget被赋值，同时break跳出循环。
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
break;
}
dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)方法，将事件传递给了子元素，其实调用的就是子元素的dispatchTouchEvent()方法。
！！！事件就是这样传递给子View的
如果子元素为ViewGroup，那么就继续递归；如果子元素为View，那么调用的就是View中的dispatchTouchEvent()方法。
如果这里返回true，说明已经找到目标View，即子View消耗了事件，那么将会做下面的操作：
给newTouchTarget和mFirstTouchTarget赋值，mFirstTouchTarget的赋值过程在addTouchTarget()方法中
给alreadyDispatchedToNewTouchTarget赋值为true（看这个名字应该知道他的意思，已经）
执行break跳出循环。
如果这里返回false（如果循环中这一步都是false），就说明子View没有消耗事件，就会导致mFirstTouchTarget为null，那么该View就默认拦截下来同一事件序列中的所有点击事件。（原因在第二部分代码中）
到这里第四部分就差不多结束了，我们来总结一下把。这段代码做的操作就是在一个点击动作的开端事件中，通过遍历子View的dispatchTouchEvent()方法，找到接收事件的目标View，并记录在mFirstTouchTarget中，如果没有找到，mFirstTouchTarget就为null，那么同一事件序列下的所有点击事件就都会被该ViewGroup拦截。
那么到底是否找到了目标View呢？我们一起看第五部分代码把：
第五部分代码
// 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) {
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;
}
}
这一部分代码其实是对事件的分发了，当事件类型不为ACTION_DOWN时，就不用经历上面的磨难，直接来到这一步。我们先看如果mFirstTouchTarget == null的情况，这里直接调用了dispatchTransformedTouchEvent(ev,canceled,null,TouchTarget.ALL_POINTER_IDS)，前面已经讲过，这个方法是用来调用子View的dispatchTouchEvent()方法的，但是请注意这里的第三个参数child传的是null，之前已经贴过源码，这里就不贴了，当child为null时，它会调用super.dispatchTouchEvent()。很显然，这里转到了View的dispatchTouchEvent()方法。好吧，我们之后再分析View中的dispatchTouchEvent()方法，现在我们先继续分析。
当mFirstTouchTarget不为null时，让我们的目光来到这里
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {
handled = true;
}
仔细看了第四部分代码的兄弟们应该发现alreadyDispatchedToNewTouchTarget 和 newTouchTarget 都是在第四部分代码中被赋值的，也就是说当点击事件类型为ACTION_DOWN等事件序列开端事件时，并且事件被子View处理时，alreadyDispatchedToNewTouchTarget 为true，并且newTouchTarget==target（mFirstTouchTarget），此时，直接设置handled为true，handled为方法返回值，表示事件已经被处理。
如果事件不满足上面的条件，也就是说，事件为ACTION_MOVE或者ACTION_UP等这些类型时执行下面的代码：
else {
final boolean cancelChild = resetCancelNextUpFlag(target.child)|| intercepted;
if (dispatchTransformedTouchEvent(ev, cancelChild,
target.child, target.pointerIdBits)) {
handled = true;
}
...
}
同样是调用dispatchTransformedTouchEvent方法，但是这里第三个参数child传入了子View，所以在这里直接调用了子View的dispatchTouchEvent()方法，将事件交给子View处理。
最后一部分代码
/**
* 处理ACTION_UP和ACTION_CANCEL
* Update list of touch targets for pointer up or cancel, if needed.
* 在此主要的操作是还原状态
*/
if (canceled|| actionMasked == MotionEvent.ACTION_UP
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
resetTouchState();
} else if (split && actionMasked == MotionEvent.ACTION_POINTER_UP) {
final int actionIndex = ev.getActionIndex();
final int idBitsToRemove = 1 << ev.getPointerId(actionIndex);
removePointersFromTouchTargets(idBitsToRemove);
}
View的dispatchTouchEvent方法
ViewGroup中的dispatchTouchEvent()方法就到此结束了，我们再来看View中的dispatchTouchEvent()方法。
public boolean dispatchTouchEvent(MotionEvent event) {
...
boolean result = false;
...
//过滤掉不安全的事件，当View被遮挡时，就是不安全的
if (onFilterTouchEventForSecurity(event)) {
//如果view是enable的，并且是否滚动条已经处理事件
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是一个单独的元素，它没有子元素因此无法向下传递事件，所以只能自己处理事件。我们直接看关键的代码部分，View首先会判断有没有设置onTouchListener，如果onTouchListener中的onTouch方法返回true，那么onTouchEvent就不会被调用。可见，onTouchListener的优先级高于onTouchEvent，这样的好处是方便在外界处理点击事件。
onTouchEvent
我们再来看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();
//通过clickable来记录是否可以点击或者长点击，或者是鼠标右键
final boolean clickable = ((viewFlags & CLICKABLE) == CLICKABLE
|| (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)
|| (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE;
//可以看出即便是disabled的状态，也会消耗事件，但是不处理，只是返回true
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过小，不容易点击，通过扩大点击区域实现更好的交互
if (mTouchDelegate != null) {
if (mTouchDelegate.onTouchEvent(event)) {
return true;
}
}
//当可以点击或者会显示工具提示的时候
if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
switch (action) {
case MotionEvent.ACTION_UP:
mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN;
if ((viewFlags & TOOLTIP) == TOOLTIP) {
handleTooltipUp();
}
if (!clickable) {
removeTapCallback();
removeLongPressCallback();
mInContextButtonPress = false;
mHasPerformedLongPress = false;
mIgnoreNextUpEvent = false;
break;
}
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;
// 记录点击位置，并执行是否为LongPress的检测
case MotionEvent.ACTION_DOWN:
...
break;
// 将所有的状态设置为最初始
case MotionEvent.ACTION_CANCEL:
...
break;
//仅仅做了将具体的坐标传递给背景以及判断点击区域是否还在view中
case MotionEvent.ACTION_MOVE:
...
break;
}
return true;
}
return false;
}
首先是判断并记录clickable状态，由三个标记位决定，具体请看注释。然后处理disenable状态下的view，可以看出，view照样会消耗点击事件。
接着，如果View有设置代理，那么交给代理执行。我们直接看onTouchEvent中对点击事件的具体处理。
可以看出，分为几种情况:
- ACTION_DOWN: 记录点击位置，并执行是否为LongPress的检测
- ACTION_CANCEL: 将所有的状态设置为最初始
- ACTION_MOVE:将具体的坐标传递给背景以及判断点击区域是否还在view中
- ACTION_UP:当这个事件发生时，会触发performClick方法，如果View设置了onClickListener，那么performClick方法内部会调用它的onClick方法。
ok，到这里，对于事件分发的源码就差不多分析完毕了。
感谢
《Android开发艺术探索》
dispatchTouchEvent源码解析
