最近公司需要组织一次分享，也算是重新学习了下，记下笔记，方便以后查询。
通过看《Android开发艺术探索》对View有了更深层次的理解，下面是具体内容。
一、什么是View
View是Android中所有控件的基类，不管是简单Button还是复杂的RelativeLayout，它们的共同基类都是View。所以说，View是一种界面层控件的一种抽象，它代表了一个控件。除了View，还有ViewGroup，它可以被翻译为控件组，意思就是ViewGroup内部包含了许多个控件，即一组View。在Android设计中，ViewGroup也继承了View，这就意味着View本身就可以是单个控件也可以由多个控件组成的一组控件。
二、点击事件的传递规则
1、点击事件传递的对象
首先我们要知道事件传递的对象是什么，其实就是MotionEvent，即点击事件。
在手指接触屏幕后所产生的一系列事件中，典型的事件类型有如下几种：
- ACTION_DOWN——手指刚接触屏幕；
- ACITON_MOVE——手指在屏幕上移动；
- ACTION_UP——手指从屏幕上松开的一瞬间。
正常情况下，一次手指接触屏幕的行为会触发一系列点击事件，有如下几种情况：
- 点击屏幕后立即松开，事件序列为DOWN->UP;
- 点击屏幕滑动一会再松开，事件序列为DOWN->MOVE->…->MOVE->UP。
上述情况就是典型的事件序列。
2、点击事件的事件分发
所谓的点击事件的事件分发，其实就是对MotionEvent事件的分发过程，即当一个MotionEvent产生了以后，系统需要把这个事件传递给一个具体的View，而这个传递的过程就是分发过程。
点击事件的分发过程由三个很重要的方法来共同完成：
- dispatchTouchEvent
public boolean dispatchTouchEvent(MotionEvent event)该方法用来进行事件的分发。如果事件能够传递给当前View，那么此方法一定会被调用，返回结果会受当前View的onTouchEvent和下级View的dispatchTouchEvent方法的影响，同时，该返回结果表示是否消耗当前事件。
- onInterceptTouchEvent
public boolean onInterceptTouchEvent(MotionEvent event)该方法在dispatchTouchEvent内部调用，用来判断是否拦截某个事件，如果当前View拦截了某个事件，那么在同一个事件序列当中，此方法不会被再次调用，返回结果表示是否拦截当前事件。
- onTouchEvent
public boolean onTouchEvent(MotionEvent event)该方法在dispatchTouchEvent方法中调用，用来处理点击事件，返回结果表示是否消耗当前事件，如果不消耗，则在同一个事件序列中，当前View无法再次接收到事件。
那么它们之间什么关系呢，可以用下面的伪代码表示：
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean consume = false;
if (onInterceptTouchEvent(ev) ) { //拦截
consume = onTouchEvent(ev); //处理点击事件
} else { //不拦截
consume = child.dispatchTouchEvent(ev); //传给子View处理
}
return consume;
}上述伪代码已经将三者的关系表现的淋漓尽致。通过上面的伪代码，我们可以大致了解点击事件的传递规则：
1、对于一个根ViewGroup来说，点击事件产生后，首先会传递给根ViewGroup，这时根ViewGroup的dispatchTouchEvent就会被调用，如果这个ViewGroup的onInterceptTouchEvent方法返回true，就表示它要拦截当前事件，接着事件就会交给这个ViewGroup处理，即它的onTouchEvent方法就会被调用；如果这个ViewGroup的onInterceptTouchEvent方法返回false，就表示它不拦截当前事件，这时当前事件就会继续传递给它的子元素，接着子元素的dispatchTouchEvent方法就会被调用，如此反复直到事件被最终处理。
2、当一个View处理点击事件时，如果该view设置了OnTouchListener，那么OnTouchListener中的onTouch方法会被回调。这时事件如何处理还要看onTouch的返回值，如果返回false，则当前view的onTouchEvent方法会被调用；如果返回true，那么onTouchEvent方法将不会被调用。由此可见，给View设置OnTouchListener，其优先级比onTouchEvent要高。在onTouchEvent方法中，如果当前设置的有OnClickListener，那么它的onClick方法会被调用。可以看出，OnClickListener的优先级最低，处于事件传递的尾端。
当一个点击事件产生后，它的传递过程遵循如下顺序：Activity->Window->View，即事件总是先传递给Activity，Activity再传递给Window，最后Window再传递给顶级View。顶级View接收到事件后，就会按照事件分发机制去分发事件。
考虑一下，如果一个View的onTouchEvent返回false，那么它的父容器的onTouchEvent将会被调用，以此类推。如果所有的元素都不处理这个事件，那么这个事件将会最终传递给Activity处理，即Activity的onTouchEvent方法会被调用。这里有个例子很贴切。把点击事件比喻为一个艰巨的任务，这个任务被顶头上峰层层分派，最后分给了一个程序员去处理（事件分发过程），结果这个程序员搞不定（onTouchEvent返回false），只能交给能力更高的上峰去处理（上级的onTouchEvent被调用），如果这个上峰还是搞不定，只能一层层向上汇报。这是不和事件的分发过程很相似。希望能帮助我们加深理解。
关于事件传递的机制，这里给出一些结论，如下：
（1）同一个事件序列是指从手指接触屏幕的那一刻起，到手指离开屏幕的那一刻结束，在这个过程中所产生的一系列事件，这个事件序列以down事件开始，中间含有数量不定的move事件，最终以up事件结束。
（2）正常情况下，一个事件序列只能被一个View拦截且消耗。这一条的原因可以参考（3），因为一旦一个元素拦截了某次事件，那么同一个事件序列内的所有事件都会直接交给它处理，因此同一个事件序列中事件不能分别由两个View处理，但是通过特殊手段可以做到，比如一个View将本该自己处理的事件通过onTouchEvent强行传递给其他View处理。
（3）某个View一旦决定拦截，那么这一个事件序列都只能由它来处理（如果事件序列能够传递给它的话），并且它的onInterceptTouchEvent不会再被调用。一旦决定拦截后，那么onInterceptTouchEvent就不会再去询问是否要拦截，并且将同一个事件序列内的其他方法都直接交给这个View处理。
（4）某个View一旦开始处理事件，如果它不消耗ACTION_DOWN事件（onTouchEvent返回false），那么同一事件序列中的其他事件都不会再交给它来处理，并且事件将重新交给它的父元素去处理，即父元素的onTouchEvent会被调用。就好比上峰分给你一个任务，你没搞定，上峰短期内就不敢在把其他的任务分给你。二者道理相似。
（5）如果View不消耗除ACTION_DOWN以外的其他事件，那么这个点击事件会消失，此时父元素的onTouchEvent并不会被调用，并且当前View可以持续收到后续的事件，最终这些消失的点击事件会传递给Activity处理。
（6）ViewGroup默认不拦截任何事件。Android源码中ViewGroup的onInterceptTouchEvent方法默认返回false；
（7）View没有onInterceptTouchEvent方法，一旦有点击时间传递给它，那么它的onTouchEvent方法就会被调用。
（8）View的onTouchEvent默认都会消耗事件（返回true），除非它是不可点击的（clickable和longClickable同时为false）。View的longClickable属性默认都为false，clickable属性要分情况，比如Button的clickable属性默认为true，而TextView的clickable属性默认为false。
（9）View的enable属性不影响onTouchEvent的默认返回值。哪怕一个View是disable状态的，只要它的clickable或者longClickable有一个为true，那么它的onTouchEvent就返回true。
（10）onClick会发生的前提是当前View是可点击的，并且它收到了DOWN和UP的事件。
（11）事件传递过程是由外向内的，即事件总是先传递给父元素，然后再由父元素分发给子View，通过requestDisallowInterceptTouchEvent方法可以再子元素中干预父元素的事件分发过程，但是ACTION_DOWN事件除外。
三、事件分发的源码分析
1、Activity对点击事件的分发过程
点击事件用MotionEvent来表示，当一个点击操作发生时，事件最先传递给当前Activity，由Activity的dispatchTouchEvent来进行事件派发，具体的工作是由Activity内部的Window来完成。
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}现在分析上面代码。首先事件开始交给Activity所附属的Window进行分发，如果返回true，整个事件循环就结束了；如果返回false意味着事件没有人处理。所以当View的onTouchEvent都返回了false时，Activity的onTouchEvent将会被调用。
2、Window对点击事件的分发过程
Window会将事件传递给decor view，decor view一般就是当前界面的底层容器（setContentView所设置的View的父容器），通过Activity.getWindow().getDecorView()可以获得。现在来看Window是如何将事件传递给ViewGroup的。通过源码知道，Window是个抽象类，而Window的superDispatchTouchEvent方法也是个抽象方法，所以必须找到Window的实现类才行。
/**
* Abstract base class for a top-level window look and behavior policy. An
* instance of this class should be used as the top-level view added to the
* window manager. It provides standard UI policies such as a background, title
* area, default key processing, etc.
*
* <p>The only existing implementation of this abstract class is
* com.android.internal.policy.PhoneWindow, which you should instantiate when needing a
* Window.
*/
public abstract class Window {
//...
/**
* Used by custom windows, such as Dialog, to pass the touch screen event
* further down the view hierarchy. Application developers should
* not need to implement or call this.
*
*/
public abstract boolean superDispatchTouchEvent(MotionEvent event);
//...
}那么Window的实现类是什么呢，从注释中可以看出是com.android.internal.policy.PhoneWindow。上面的注释的大意是：Window类可以控制顶级View的外观和行为策略，它的唯一实现位于com.android.internal.policy.PhoneWindow中。
现在看下PhoneWindow中源码，看是如何处理点击事件的。如下所示：
public class PhoneWindow extends Window implements MenuBuilder.Callback {
//...
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
//...
}到这里就很清楚了，PhoneWindow将事件直接传递给了DecorView，现在看下这个DecorView是个什么东西？
public class PhoneWindow extends Window implements MenuBuilder.Callback {
// This is the top-level view of the window, containing the window decor.
private DecorView mDecor;
@Override
public final View getDecorView() {
if (mDecor == null) {
installDecor();
}
return mDecor;
}
//...
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
//...
private final class DecorView extends FrameLayout implements RootViewSurfaceTaker {
//...
public boolean superDispatchTouchEvent(MotionEvent event) {
return super.dispatchTouchEvent(event);
}
}
}public class FrameLayout extends ViewGroup {
//...
}到这里，可以理解为事件已经传递到顶级View了。我们知道，
((ViewGroup) getWindow().getDecorView().findViewById(android.R.id.content)).getChildat(0);通过上面的代码可以获取到Activity所设置的View，这个mDecor显然就是getWindow().getDecorView()返回的View，而我们通过setContentView设置的View是它的一个子View。现在事件传递到DecorView这里，由于DecorView继承自FrameLayout 且是父View，FrameLayout 又继承自ViewGroup，所以最终事件会传递给View。从这里开始，事件已经传递到顶级View了，顶级View也叫根View，顶级View一般来说都是ViewGroup。
3、顶级View对点击事件的分发过程
首先回顾下上面提到过的顶级View对点击事件的分发过程：当点击事件到达顶级View时，会调用ViewGroup的DispatchTouchEvent方法，逻辑如下：
如果顶级ViewGroup拦截事件即onInterTouchEvent返回true，则事件由ViewGroup处理：
（1）这时如果ViewGroup的OnTouchListener被设置，则onTouch会被调用，否则onTouchEvent会被调用。也就是说，如果都提供的话，onTouch会屏蔽掉onTouchEvent。
（2）在onTouchEvent中，如果设置了OnClickListener，则onClick会被回调。如果顶级ViewGroup拦截事件即onInterTouchEvent返回false，则不拦截此次事件，事件会传递给它所在的点击事件链上的子View，这时子View的dispatchTouchEvent回调调用。如此循环，完成整个事件的分发。
下面看ViewGroup源码：
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
//...
//当为ACTION_DOWN事件时重置FLAG_DISALLOW_INTERCEPT标记位
//(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();
}
//...
//(2) 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;
}
//...
}从源码（2）可以看出，判断是否拦截当前事件的条件：
（1）actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null
actionMasked == MotionEvent.ACTION_DOWN好理解，那么mFirstTouchTarget != null是啥意思？
这个从后面的代码逻辑中可以看出，当ViewGroup不拦截事件且由ViewGroup的子元素成功处理时，mFirstTouchTarget会被赋值并指向子元素。也就是说，一旦ViewGroup拦截当前事件，mFirstTouchTarget==null，mFirstTouchTarget!=null不成立，即为false。
那么mFirstTouchTarget的作用是啥，就是为了在同一个事件序列中，当DOWN事件消耗后，那些ACTION_MOVE事件和ACTION_UP事件怎么判断是否去执行拦截函数onInterceptTouchEvent，就是根据mFirstTouchTarget是否为空来判断。当mFirstTouchTarget为空，mFirstTouchTarget!=null不成立时，就表示ViewGroup拦截了当前事件，也就不用再去执行onInterceptTouchEvent拦截函数了，同时，那些ACTION_MOVE事件和ACTION_UP事件都会默认交给当前的ViewGroup来处理。
这正好验证了上面的第3条结论：当ViewGroup决定拦截事件后，那么后续的点击事件将会默认交给它处理并且不再调用它的onInterceptTouchEvent方法。
（2）FLAG_DISALLOW_INTERCEPT
这个标记位是通过子View的requestDisallowInterceptTouchEvent方法来设置的。FLAG_DISALLOW_INTERCEPT一旦设置后，ViewGroup将无法拦截除了ACTION_DOWN以外的其他点击事件。因为ViewGroup在分发事件时，一旦是ACTION_DOWN事件就会重置FLAG_DISALLOW_INTERCEPT这个标记位。当面对ACTION_DOWN事件时，ViewGroup总是会调用自己的onInterceptTouchEvent方法来询问自己是否要拦截该事件。这一点从上面的源码可以看出来。
从源码（1）可以看出，ViewGroup会在ACTION_DOWN事件到来时在resetTouchState()方法中对FLAG_DISALLOW_INTERCEPT进行重置。结论就是，子View调用requestDisallowInterceptTouchEvent方法并不能影响ViewGroup对ACTION_DOWN事件的处理。
这正好验证了上面的第11条结论：FLAG_DISALLOW_INTERCEPT这个标志位的作用是让ViewGroup不再拦截事件，当然前提是ViewGroup不拦截ACTION_DOWN事件。
总结两点：
（1）onInterceptTouchEvent不是每次事件都会被调用，如果我们想提前处理所有的点击事件，要选择dispatchTouchEvent方法，只有这个方法能确保每次都会调用，当然前提是事件能传递到当前的ViewGroup；
（2）FLAG_DISALLOW_INTERCEPT 标记位的作用给我们提供了一个思路，当面对滑动冲突的时候，是不是可以考虑用这种方法去解决？
现在在看当ViewGroup不拦截事件的时候，事件会向下分发交由它的子View进行处理：
//...
final View[] children = mChildren;
//（1）遍历所有子元素
for (int i = childrenCount - 1; i >= 0; i--) {
final int childIndex = customOrder
? getChildDrawingOrder(childrenCount, i) : i;
final View child = (preorderedList == null)
? children[childIndex] : preorderedList.get(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;
}
//（2）一子元素是否在播放动画；二点击事件的坐标是否落在子元素的区域内
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);
//(3)
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();
//（4）如果子元素的dispatchTouchEvent返回true，那么mFirstTouchTarget 就会被赋值同时跳出for循环
//下面这几行代码完成了mFirstTouchTarget 的赋值并终止了对子元素的遍历。如果子元素的dispatchTouchEvent
//返回false，ViewGroup将会把事件分发给下一个子元素
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);
}
//...
// (5)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 {
//...
}
//...
上面的代码逻辑还算清晰：首先代码(1)遍历ViewGroup的所有子元素，然后判断子元素是否能够接收到点击事件。主要由2点来判断，即代码（2）：
一子元素是否在播放动画；二点击事件的坐标是否落在子元素的区域内。满足条件就把事件传递给这个子元素来处理。还可以看到，代码（3）dispatchTransformedTouchEvent实际上就是调用代码（7）处的子元素的dispatchTouchEvent方法，在dispatchTransformedTouchEvent内部有如下一段代码：
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
final boolean handled;
// Canceling motions is a special case. We don't need to perform any transformations
// or filtering. The important part is the action, not the contents.
final int oldAction = event.getAction();
if (cancel || oldAction == MotionEvent.ACTION_CANCEL) {
event.setAction(MotionEvent.ACTION_CANCEL);
if (child == null) {
//(6)
handled = super.dispatchTouchEvent(event);
} else {
//(7)由于Child不为空，所以调用子元素的dispatchTouchEvent
handled = child.dispatchTouchEvent(event);
}
event.setAction(oldAction);
return handled;
}
// Calculate the number of pointers to deliver.
final int oldPointerIdBits = event.getPointerIdBits();
final int newPointerIdBits = oldPointerIdBits & desiredPointerIdBits;
// If for some reason we ended up in an inconsistent state where it looks like we
// might produce a motion event with no pointers in it, then drop the event.
if (newPointerIdBits == 0) {
return false;
}
// If the number of pointers is the same and we don't need to perform any fancy
// irreversible transformations, then we can reuse the motion event for this
// dispatch as long as we are careful to revert any changes we make.
// Otherwise we need to make a copy.
final MotionEvent transformedEvent;
if (newPointerIdBits == oldPointerIdBits) {
if (child == null || child.hasIdentityMatrix()) {
if (child == null) {
handled = super.dispatchTouchEvent(event);
} else {
final float offsetX = mScrollX - child.mLeft;
final float offsetY = mScrollY - child.mTop;
event.offsetLocation(offsetX, offsetY);
handled = child.dispatchTouchEvent(event);
event.offsetLocation(-offsetX, -offsetY);
}
return handled;
}
transformedEvent = MotionEvent.obtain(event);
} else {
transformedEvent = event.split(newPointerIdBits);
}
// Perform any necessary transformations and dispatch.
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);
}
// Done.
transformedEvent.recycle();
return handled;
}
如果子元素的dispatchTouchEvent返回true，那么mFirstTouchTarget就会被赋值同时跳出for循环，即代码（4），如下代码：
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
break; /**
* Adds a touch target for specified child to the beginning of the list.
* Assumes the target child is not already present.
*/
private TouchTarget addTouchTarget(View child, int pointerIdBits) {
TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
target.next = mFirstTouchTarget;
mFirstTouchTarget = target;
return target;
}在addTouchTarget方法内完成了mFirstTouchTarget的赋值，mFirstTouchTarget 是否被赋值，将直接影响到ViewGroup对事件的拦截策略，如果mFirstTouchTarget 为null，那么ViewGroup就默认拦截接下来统一序列中所有的点击事件。
如果遍历所有的子元素后事件都没有被合适地处理，这包含两种情况：第一种是ViewGroup没有子元素；第二种是子元素处理了点击事件，但是在dispatchTouchEvent中返回了false，这一般是因为子元素在onTouchEvent中返回了false。在这两种情况下，ViewGroup就会自己处理点击事件。
这就证实了第4条结论：某个View一旦开始处理事件，如果它不消耗ACTION_DOWN事件（onTouchEvent返回false），那么同一事件序列中的其他事件都不会再交给它来处理，并且事件将重新交给它的父元素去处理，即父元素的onTouchEvent会被调用。如代码（5）。
注意代码（5）这里的代码：
handled = dispatchTransformedTouchEvent(ev, canceled, null,TouchTarget.ALL_POINTER_IDS);
第三个参数child为null，从代码（6）可以知道，会调用super.dispatchTouchEvent(event)，即交给父元素去处理。
4、View对点击事件的处理过程
View对点击事件的处理过程稍微简单一些，注意以下提到的View不包含ViewGroup。
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;
//(1)
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
result = true;
}
//(2)
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;
}View对点击事件的处理过程，首先会判断有没有设置OnTouchListener，如代码（1）处；如果OnTouchListener中的onTouch方法返回true，那么onTouchEvent就不会被调用，如代码（2）处。可见，OnTouchListener就优先级高于onTouchEvent，这样做的好处是方便在外界处理点击事件。
接着分析onTouchEvent的实现。先看当View处于不可用状态下点击事件的处理过程，如下所示，不可用状态下的View照样会消耗点击事件，尽管它看起来不可用，如代码（3）。
public boolean onTouchEvent(MotionEvent event) {
final float x = event.getX();
final float y = event.getY();
final int viewFlags = mViewFlags;
final int action = event.getAction();
//(3)View不可用状态下点击事件的消耗
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);
}
//(4)View设置有代理
if (mTouchDelegate != null) {
if (mTouchDelegate.onTouchEvent(event)) {
return true;
}
}
//(5)点击事件的处理
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;
}如果View设置有代理，那么还会执行TouchDelegate的onTouchEvent的方法，如代码（4），这个onTouchEvent的工作机制和OnTouchListener类似。
再看下代码（5），是对点击事件的具体处理，可以看出，只要View的CLICKABLE和LONG_CLICKABLE有一个为true，那么它就会消耗这个事件，即onTouchEvent返回true，不管它是不是DISABLE状态，这就证实了上面的8、9、10的结论。
再看ACTION_UP事件发生时，会触发performClick方法，如果View设置了OnClickListener，那么performClick方法内部会调用它的onClick方法，如下代码所示：
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;
}View的LONG_CLICKABLE属性默认为false，而CLICKABLE属性是否为false和具体的View有关，确切的说是可点击的View其CLICKABLE为true，不可点击的View其CLICKABLE为false，比如Button是可点击的，TextView是不可点击的。
通过setClickable和setLongClickable可以分别改变View的CLICKABLE和LONG_CLICKABLE属性。
另外，setOnClickListener会自动将View的CLICKABLE设为true，setOnLongClickListener则会自动将View的LONG_CLICKABLE设为true。可看下面源码：
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;
}到这里，点击事件的分发机制的源码实现已经分析完了。
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
