View是Android开发中所有控件的基类，虽然它不属于四大组件，但是它在android开发中的地位丝毫不亚于四大组件，甚至于毫不夸张的说，它的重要性和使用场景是超出BroadcastReceiver和ContentProvider。在日常的开发中跟view打交道的时候太多了，可以说，android开发中最终的页面呈现全靠view。而我们在开发中也碰到使用view给我们带来的问题和困扰。其中一个很典型和突出的问题（view滑动冲突）就是由于view的事件分发处理不当导致的，所以深刻理解android开发中view的分发机制对于解决这一系列的问题很有必要。
触摸事件（MotionEvent）的传递规则
所谓的触摸事件的分发，其实就是对用户操作view，android系统做出反应——产生MotionEvent事件，系统对这个事件从顶级view一层一层的进行分发，直到一个具体的view接收和消化并最终响应了该事件。（当然这里说的view可能不太准确，因为这个事件可能分发到最后，整个事件链中的所有view都没有接收或者消化并响应该事件，它最终会被所在的activit所消化。ps：整个原理我们会在后面做具体的解释说明）
在整个事件链分发过程中，我们主要关注三个方法：
public boolean dispatchTouchEvent(MotionEvent ev);
public boolean onInterceptTouchEvent(MotionEvent ev);
public boolean onTouchEvent(MotionEvent ev);
-
dispatchTouchEvent()方法主要处理整个事件序列的分发,返回值标识当前view是否消耗当前传递事件。返回值主要受当前view的touchEvent()和下级view的dispatchTouchEvent()影响（ps:原理稍后进行说明）
-
onInterceptTouchEvent()方法主要用来标识（告知）系统，拦截整个事件序列的view是当前view，该方法在整个事件序列中只会有一次为true的返回值，并且如果当前view返回了true，那么在该次事件序列传递过程中，其子view的这个方法都不会再被调用。
-
onTouchEvent()方法用来处理触摸事件，也就是该次事件序列中最终消费事件的方法。当然他它可能会是整个事件序列传递中的任意一个view消费该次事件，当然这个事件只能被唯一一个view（或者window，或者activity）所消费
上面说的一大串可能很多人就会懵了，没关系，我们来看一段从源码里剥离出来的伪代码就可以把这三个方法的关系和调用捋清楚：
public boolean dispatchTouchEvent(MotionEvent ev){
boolean consume = false;
if (onInterceptTouchEvent(ev)) {
consume = onTouchEvent();
}else{
consume = child.dispatchTouchEvent(ev);
}
return consume;
}
通过以上的讲述，我想大家可能会对触摸事件的传递规则有了一定的认识。接下来我们稍微总结一下。
对于一个View或者一个ViewGroup而言，如果事件传递到它，这时它的dispatchTouchEvent()方法会被调用，在dispatchTouchEvent()方法会首先调用自己的onInterceptTouchEvent()判断是否拦截这次事件
-
如果onInterceptTouchEvent()返回true则表示拦截该事件，并且它的onTouchEvent()方法会被调用意味着事件自己交给自己处理（ps:如果onTouchEvent()也同样返回false，那么结果会如何呢？）
-
反之，如果onInterceptTouchEvent()返回false，那么这个事件就传递给它的子View（当然传递给子View的前提是它得拥有子View，那么如果当前View没有子View，那么结果又会怎么样呢？）
-
以之上两条规则作为传递规则，直至事件被最终处理掉
触摸事件在Activity的传递规则
当用户触摸了页面时，系统会产生一个MotionEvent事件，该事件系统的一系列处理，在页面展示层面而言，它会被首先传递到用户操作的Activity（当然也有可能是Service）。之后这个事件的传递顺序如下：
- Activity -> Window -> 顶级View（ViewGroup）从顶级View以下就按照前文所说的事件分发机制去分发处理。
如果传递的过程中所有的View和window都不事件进行响应，那么最终事件会一级一级的往上送，如果所有的View和Window的onTouchEvent()都返回false，那么这个事件会被送回Activity进行处理（Activity的onTouchEvent()方法会被调用）。这个用现实中的例子来描述的话，我给它称之为“搞不定找老大”。
到这里为止，我们可以得出这样一个结论：
一次事件必然需要一个处理者，实在没有处理者和消耗者，那么它会被回传给大Boss（Activity）。如果一个View的onTouchEvent()方法被执行了，那么意味着这个事件序列在正常情况下是不会再往下传递的了，如果当前view的onTouchEvent()返回了false，那么这个事件就会被扔给上级进行处理。
这个结论可以解决上文所提的两个问题。
onTouchEvent()、onTouch()、OnClick()的区别与联系
在这边我就直接给出我测试的结论了，基于这一块的源码，感兴趣的朋友可以自行查阅、了解。
当一个View被设置了OnTouchListener时，那么如果事件传递到了这个View，OnTouchListener的onTouch()方法会被首先调用，如果事件在onTouch()方法中被消耗掉了（返回值为true）。那就没有onTouchEvent()方法什么事了。只有onTouch()方法返回false时，onTouchEvent()方法才会被执行，在onTouchEvent()方法中，如果
设置了OnClickListener，这个时候会去回调OnClick()方法。也就是说，我们平时常用的OnClickListener优先级最低，
处于事件传递的末端。
我事件我做主
在前文我们所讲述事件传递规则有一条主线是不变的，事件的传递过程是由外向内的，也就是从父元素往子元素一级级传递。这样的话子元素如果跟父元素都能处理事件时，按照正常事件分发流程，子元素是别想了。但是这样不行啊，子元素处理的必要性如果很强，那么这个事件我们就应该从父元素抢占过来。那么通过requestDisallowInterceptTouchEvent() 方法可以实现对父元素的事件分发过程进行干预，从而实现子元素必要时可以抢占事件的处理和消耗权。
网友评论