View是安卓中极为重要的一个部件，除去四大组件以外，平时我们与View接触的最多，它负责着显示的一切，已处理着用户的操作，协调着用户与APP之间的IO。对于个人而言，view的使用频率甚至比某些四大组件还要高，但我们却很少去在意它到底是怎么处理交互的。
认真学习view的事件分发处理机制，对我们自定义View和处理滑动冲突是很有帮助的。
Part.1 View与ViewGroup
View是Android中所有控件的基类，在Android中我们调用的每个控件，包括Linerlayout、Button甚至是ListView等等都不过是View的派生类。
显然，Linerlayout与Button仍然是存在区别的，一个LinerLayout可以在它的内部放下其他的View，而Button顶多在内部写点文字。这是因为LinerLayout继承了ViewGroup类，该类是View的一个子类，它的作用从名字就可以看出，是为了给其他View提供容器。
我们的xml文件里面常常是以一个XXXLayout包裹着大量的Button、TextView甚至是LinerLayout，这说明ViewGroup中是允许存在ViewGroup嵌套的，层层叠叠控件嵌套就形成了一棵View控件树。
Part.2 浅析View的事件分发机制
当我们在屏幕上发生点击事件时，系统的WindowManagerService检测到了这次点击之后想AMS一样通过IPC通知到具体的一个Activity中，这时我们的APP就获得了这次点击事件。
2.1 MotionEvent
java讲究万物皆为对象，在事件分发这个过程中，我们重要的事件就被封装成了一个MotionEvent的对象，这个对象包含了我们的操作信息，例如：
ActionMask：
- ACTION_DOWN————手指戳到屏幕
- ACTION_MOVE————手指在屏幕上移动
- ACTION_UP————手指松开屏幕的瞬间
上述三种是我们最常见到的事件，也是我们需要专注处理的事件。一般而言，用户的操作都是一系列事件，所以会有这样一些序列：
- 点击一下屏幕： DOWN->UP
- 滑动屏幕： DOWN->MOVE->….->MOVE->UP
由此可见，这三个事件是最基本的事件，基本上只要对屏幕进行操作必然会产生这三种事件。
同时MotionEvent对象还为我们提供了点击事件发生的x,y坐标，我们分别用以下方法获取：
getX()/getY()
该方法用于获取点击事件相对于当前View左上角发生的X/Y值。getRawX()/getRawY()
该方法用于获取点击事件相对于屏幕左上角的X/Y值。
灵活利用上面的方法与MotionMask便能使我们方便的实现需求。
2.2 事件的传递规则
与事件传递有关的方法实际上就只有三个，它们以及它们的变形方法均出现在了Activity、View、以及ViewGroup类里面。一个事件只要依靠这三个方法便能完成在整个APP中的传递。
public boolean dispatchTouchEvent(MotionEvent event);该方法负责事件的传递，它是每一级传递的源头。当一个事件能够传递到一个View的时候，该View的dispatchTouchEvent方法一定会触发。它的返回结果收到onTouchEvent与下一级dispatchTouchEvent方法的结果影响。
public boolean onInterceptTouchEvent(MotionEvent event);该方法负责判断当前View是否要对当前事件进行拦截，经过判断后该方法会将true/false返回给intercept属性，该属性影响着事件接下来的传递方案，当它为true的时候，该事件将不会往下继续传递。
public boolean onTouchEvent(MotionEvent event);当一个View确定要拦截当前的事件的时候就会调用该方法，在该方法内部是对事件的处理逻辑。如果成功处理事件，该方法会返回true，否则返回false。
用一段伪码对这个过程进行描述即是:
public boolean dispatchTouchEvent(MotionEvent ev){
boolean consume = false;
if( onInterceptTouchEvent(ev) ){
consume = onTouchEvent(ev);
} else {
consume = child.dispatchTouchEvent(ev);
}
return consume;
}当一个事件发生后，它会从Activity出发，经过Windows层最后到达View层，此时的View也就是我们布局的最底层View，它是一个ViewGroup。从这里开始，事件就遵循上述的代码。
dispatchTouchEvent被调用后首先判断当前View是否需要拦截这个事件。如果是，该事件就会进入onTouchEvent之中被处理，若成功处理则返回true，否则返回false。如果不是，它将直接进入子View的dispatchTouchEvent之中再次执行上述操作，直到在某一层中onTouchEvent成功的处理了事件，此时会返回true。
这个过程有点像一棵树的遍历，通过不断地递归找到能处理事件的View。
另外，当一个View设置了onTouchListener和onClickListener的时候，那么onTouchListener的onTouch方法会被最先调用，若onTouch方法返回false，onTouchEvent方法才会被调用。而onClick方法的调用发生在onTouchEvent的内部。因而我们可以得到这样一个优先级：onTouchListener>onTouchEvent>onClickListerner，上述过程中有一个环节返回true，则代表事件得以处理，接下来的处理方法都无法再得到该事件。
当然，在上述的所有方法都被调用过，且无法发现任何可以处理事件的子View的时候，该事件会一级一级回溯，查看父View中是否能处理。在最后的最后，事件会回到Activity中并让Activity中的onTouchEvent试图处理。
Part.3 深入View事件分发的源代码
在上一Part中我们已经较为具体的描述了事件的分发与处理，接下来我们一起深入到代码中去看看这一过程的细节。
上面提到，所有的事件的传递都是Activity中开始发生的：
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction(); //忽略
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}Activity中dispatchTouchEvent方法的处理十分简洁，第一个判断中的方法是一个空方法，估计是提供给开发者覆写以监听某种状态。而第二个判断就是进行事件分发了，通过调用getWindow方法，事件就进入了Windows层进行分发。
Window类是个抽象类，其具体实现类是PhoneWindow类，在该类中事件会被直接传递到DecorView。文档告诉我们，DecorView是顶级View，我们通过setContentView方法设置的是该View的一个子View。实际上这些都不重要，我们只需要知道从现在开始，事件的分发就已经进入到了View层。
一般而言，顶级View都是ViewGroup————不然怎么装的下我们定义的布局呢，所以dispatchTouchEvent方法就传递到了ViewGroup中，由于ViewGroup中的该方法过长，包含着许多除了传递以外的处理，故不全部粘出来。
在看代码之前让我们首先记住几个关键的变量：
intercepted
该属性控制着dispatchTouchEvent方法的执行，也表明了当前View是否要拦截事件。disallowIntercept
该属性同样控制着dispatchTouchEvent方法的执行，但不同的是这个值是受子View控制而不是本身，子View可以通过requestDisallowIntercept（）方法影响FLAG_DISALLOW_INTERCEPT标志位从而影响该属性，一旦该属性为true，当前View就无法拦截ACTION_DOWN以外的事件。mFirstTouchTarget
该属性指向一个子View，当有一个子View成功的处理了当前事件的时候，该属性会指向它，以方便它来对接下下来的事件进行处理。
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();
}刚进入dispatchTouchEvent方法的时候，View便进行一次判别。若当前是ACTION_DOWN,说明这是一个全新的事件序列的开始，于是乎它便会通过调用resetTouchState()重置FLAG_DIALLOW_INTERCEPT标志位，避免上次事件序列的运行结果影响该次事件。
// 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;
}紧接着，我们的intercepted属性就迎来了它全新的人生，注意intercepted属性是被final修饰的局部变量，因而在每次事件到来的时候它都会被重新定义且无法更改。
当事件第一次（ACTION_DOWN）传递到该View时必定会进入该判定中,由于子View此时无法调用requestDisallowIntercept（）方法，故disallowIntercept属性必然为false，因而onInterceptTouchEvent（）得以执行。
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;
}该方法个人感觉最大的作用就是提供给开发者重写以解决所需要的业务逻辑。此时，intercepted属性的值便被确定了。
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;
}
}上面的代码或许有点长，但从for循环的地方开始相信就能明白这是在做什么了。ViewGroup首先遍历了自己的所有子View，然后依次判定该子View是否能够接收到点击事件。判定的依据是：子元素是否在播放动画和点击事件的坐标是否落在子元素区域内。
如果确认子元素能够接受到该事件，就会调用dispatchTransformedTouchEvent()方法
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
...
if (child == null) {
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);
}
...
}由于传进来的child不为空，因而该方法直接调用了子View的dispatchTouchEvent方法，此时，如果子View是个ViewGroup那么将会在子ViewGroup层再次重复上述的操作。若子View是个View，那么此时就会进入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中的dispatchTouchEvent方法要相对短很多，这是因为View一般就是接受事件传递和处理的最小单位了，并不会再传递给其他View。在该方法中首先去寻找当前View是否设置了onTouchListener，若存在则先回调监听器的onTouch方法，如果onTouch方法不返回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) {
...
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) {
if (mPerformClick == null) {
mPerformClick = new PerformClick();
}
if (!post(mPerformClick)) {
performClick();
}
}
}
}
...
break;
...
}
}当一个View只要满足clickable/long_clickable/context_clickable三种属性中的一种，该View就会消耗掉该事件，如果当前View设置了onClickListener，那么在此时就会被回调。这就是为什么上面曾经听到过的一个点击事件的执行顺序是onTouch->onTouchEvent->onClick的原因，且由于onTouch本身是一个if语句的条件，当我们设置返回值为true的时候，View.dispatchTouchEvent中的result属性就会被置为true，那么接下来onTouchEvent与onClick当然就无法触发了。
假设三个方法处理完毕后均返回false，这代表着当前View尽管获得了该事件的处理权，但是由于自身能力无法处理该事件，因而导致result返回false。此时就会回归到ViewGroup.dispatchTouchEvent中继续寻找下一个子View，若所有的子View都无法处理该事件，那么ViewGroup就会再次调用dispatchTransformedTouchEvent，但此时传入的child为null，因而它会调用super.dispatchTouchEvent(event)。
一开始我们说过，ViewGroup也是View，因而此时它会试图自己消化掉这个事件，其过程与子View消化的过程是一样的，此处不再赘述。若此时还是无法成功处理这个事件，那么该事件就返回到了ViewGroup的上一层。
说了这么一堆，都不过是一个事件的处理。但在真实情况中一般事件都是一个序列来进行的，接下来举两个例子。
如果一个down事件被ViewGroup直接拦截下来，即intercepted = true。紧接着他就会被自己处理。假设成功处理了该事件，当同一个事件序列的MOVE和UP序列再度来临的时候，由于mFirstTouchTarget为空，intercepted = true，所以接下来的所有事件都会被这个ViewGroup处理，别人再也无法得到这个事件序列。
假设一个新的down事件来临，重置事件被触发，标志位重新归零，ViewGroup不拦截。此时子View获得处理的机会，子View成功处理使得mFirstTouchTarget = child，并调用requestDisallowIntercept方法让父View不再拦截，当后续MOVE和UP序列来临时intercepted = false，后续事件继续交由子View处理，父View也无法得到这个事件。
当子View处理完DOWN事件后，MOVE事件仍旧会先到达父View，但此时不需要再循环遍历出所需子View，因为它已经被记录在mFirstTouchView中，此时alreadyDispatchedToNewTouchTarget为false，并直接进入下述代码：
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;
}然后通过else后的dispatchTransformedTouchEvent方法继续向子View分发接下来的事件。
Part.3 总结
事件分发与处理机制十分复杂，需要反复去读源码甚至是用纸币一步一步写下来才能搞明白，本人不善文采，故上面的描述可能比较乱，望海涵。接下来我们做一个总的归纳。
同一个事件序列是从手指接触屏幕的那一刻起，到手指离开屏幕的那一刻结束。在这个过程中产生的一系列序列，这个序列以down事件为开始，中间含有数个move，最后以UP结束。
正常情况下，一个事件序列只能被一个View拦截且消耗。因为一旦一个元素拦截了down事件，那么后续事件默认都会交给它处理。但通过特殊手段确实可以转移，例如在子View中的onTouchEvent方法中将事件传递给其他View。
某个View一旦决定拦截，那么这一个事件序列只能交给它处理（如果事件序列能够被传递给它的话），并且它的onInterceptedTouchEvent不会再被调用。（这里要注意，ViewGroup没有覆写onTouchEvent，而View中没有onIntercepted方法，当然一个View显然也不需要重复intercepted，反正交给ViewGroup判定就好了）
某个View一旦开始处理事件，如果它不消耗ACTION_DOWN事件（onTouchEvent返回false），那么同一时间序列中的其他事件都不会交给它处理，并将事件重新提交给它的父元素去处理（找下一个child）。
如果View不消耗除ACTION_DOWN以外的其他事件，那么这个点击事件会消失，此时父元素的onTouchEvent并不会被调用，并且当前View可以持续受到后续事件，最终这些消失的事件会被Activity处理。（第二次传递时间时，alreadyDispatchedToNewTouchTarget = false，dispatchTransformedTouchEvent返回false，最后ViewGroup.dispatchTouchEvent也返回false…无限循环）
ViewGroup默认不拦截任何事件。源码onInterceptTouchEvent默认返回false。
View没有onInterceptTouchEvent方法，一旦有事件传递给它，那么它的onTouchEvent方法就会被调用
View的onTouchEvent默认都会消耗事件（返回true），除非他是不可点击的（clickable和longClickable同时为false）。View的longClickable属性默认都为false，clickable分情况，但当一个View设置了onClickListener，那clickable会自动设置为true。
View的enable属性不影响onTouchEvent的默认返回值。哪怕一个View是Disable状态的，只要他的clickable或者longClickable有一个为true，那么他的onTouchEvent就返回true。
onClickable会发生的前提是View可以点击，并且受到了down和up。
事件传递是由外向内的，事件处理是由里到外的，子View可以通过requestDiallowInterceptTouchEvent方法干预父元素的事件分发，但ACTION_DOWN除外。
136
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
