本文适合看了众多事件分发文章还一头雾水的同学，源码来自android-23
根据情景分析源码
- View的mOnTouchListener.onTouch返回true，则OnClick失效。
//View的dispatchTouchEvent方法
public boolean dispatchTouchEvent(MotionEvent event) {
boolean result = false;//这个变量用来记录view是否消费掉事件
if (onFilterTouchEventForSecurity(event)) {
ListenerInfo li = mListenerInfo;
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
//事件被外面的mOnTouchListener.onTouch消费掉
result = true;
}
if (!result && onTouchEvent(event)) {
//事件被自己的onTouchEvent消费掉,而且注意前面有个!result判断,说明如果已经被
// mOnTouchListener.onTouch消费掉了,则不会走onTouchEvent(),也走不会有onClick事件了,因为
// OnClick是写在由onTouchEvent()里的performClick执行的.
result = true;
}
}
return result;
}
以上说明了2种事件的消费形式，一种是mOnTouchListener.onTouch，另一种是onTouchEvent，而且mOnTouchListener.onTouch优先于onTouchEvent。这两者的区别就是mOnTouchListener.onTouch倾向于从控件外部监听，而onTouchEvent倾向于自定义控件，即从内部监听。
- View的onTouchEvent()中如果DOWN返回false，则接收不到后续的事件。
//ViewGroup的dispatchTouchEvent方法
public boolean dispatchTouchEvent(MotionEvent ev) {
...
一丶初始化
//当事件为ACTION_DOWN的时候,初始化所有变量，包括TouchTarget链
if (actionMasked == MotionEvent.ACTION_DOWN) {
cancelAndClearTouchTargets(ev);
}
二丶记录需要分发的view并添加到TouchTarget链中
//如果没有cancel且没有被拦截,那么就开始准备分发
if (!canceled && !intercepted) {
//只是在ACTION_DOWN的情况下才会去遍历子view,所以之后就不给机会了
if (actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
//执行子View的dispatchTouchEvent是从外到内的
for (int i = childrenCount - 1; i >= 0; i--) {
//从TouchTarget链中查找是否已经有了这个child
newTouchTarget = getTouchTarget(child);
if (newTouchTarget != null) {
//如果child已经添加进了TouchTarget链中,那么中断循环,说明一个事件只能被一个view消费
break;
}
//dispatchTransformedTouchEvent方法会调用child的dispatchTouchEvent,即给子view分发事件,
// 如果按照疑问1那样使用2种情况里任意一种情况消费掉了该事件,则返回true
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
//向TouchTarget链中加入child,只有这里会添加,而下面又是break,所以我觉得TouchTarget链里始终
// 只有一个元素,那谷歌为什么要这么设计呢?不明白...
newTouchTarget = addTouchTarget(child, idBitsToAssign);
//用这个变量来标记是否已经分发事件了,这里由于上面已经分发了,所以标记true,
// 这个变量下面会有使用到
alreadyDispatchedToNewTouchTarget = true;
break;
}
}
}
}
三丶开始分发, 分发给自己或者分发给孩子
//这个mFirstTouchTarget可以理解为添加进TouchTarget链中的第一个元素,即是链表头
if (mFirstTouchTarget == null) {
//因为mFirstTouchTarget为null,所以表示没有子view消费这个事件,所以只能自己消费了
// 这里还是跟上面一样调用的dispatchTransformedTouchEvent方法,但是参数传的为null,那么根据源码会
// 调用super.dispatchTouchEvent,而ViewGroup是没有重写dispatchTouchEvent方法的,所以就是调用的
// view的dispatchTouchEvent方法,此时他已经把自己当成了一个原始的view(没有孩子的那种)
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
} else {
TouchTarget target = mFirstTouchTarget;
//从mFirstTouchTarget开始,不断地通过target.next来遍历每一个view,并向这些view分发消息
while (target != null) {
final TouchTarget next = target.next;
//alreadyDispatchedToNewTouchTarget这个变量上面提到过了,那么上面变为true了,这里就不会分发了
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {
handled = true;
} else {
//没有分发过事件的就继续分发
if (dispatchTransformedTouchEvent(ev, cancelChild,
target.child, target.pointerIdBits)) {
handled = true;
}
}
target = next;
}
}
return handled;
}
上面代码有些多，不过注释比较详细，先说下alreadyDispatchedToNewTouchTarget()这个方法会调用dispatchTouchEvent()方法，然后TouchTarget链其实最多只有一个元素，就是需要消费掉该事件的child，在第二步记录需要分发的view并添加到TouchTarget链中，其实这个操作一定是down事件才会执行的，之后的move和up是不会走这里的，因为在遍历子view之前会判断是否是down，之后就不给机会了，所以如果down事件子view没有表示对这个事件感兴趣，没有加入到TouchTarget中，那么后续的分发也是不会有的。
- 可以利用requestDisallowInterceptTouchEvent（boolean）来强制viewparent不拦截事件。但是为什么要写在子View的dispatchTouchEvent或onTouchEvent中，为什么不能写在findView之后。
//ViewGroup的dispatchTouchEvent方法
public boolean dispatchTouchEvent(MotionEvent ev) {
...
if (actionMasked == MotionEvent.ACTION_DOWN) {
cancelAndClearTouchTargets(ev);
resetTouchState();//这里会初始化disallowIntercept的值
}
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 {
intercepted = true;
}
...
}
上面disallowIntercept可以由requestDisallowInterceptTouchEvent变为true,如果为true，就不会拦截了，但是为什么设置在findView之后不行，因为我们发现在方法resetTouchState()中会初始化disallowIntercept，因为requestDisallowInterceptTouchEvent代表着你只对某一次从DOWN事件开始的行为感兴趣，而且会递归地被父布局一层一层调用。(补充一下：如果父布局从DOWN时间开始就拦截了，那么子布局再怎么getParent.requestDisallowInterceptTouchEvent都没用,因为只有down的时候才会去遍历子view并加入到TouchTarget，所以这也是导致getParent.requestDisallowInterceptTouchEvent失效的原因之一)
- 当有事件穿透时，为什么加个android:clickable="true"或者setOnClickListener就行了。
//View的onTouchEvent方法
public boolean onTouchEvent(MotionEvent event) {
...
//如果view是可点击的,那么不管是什么类型的action都会默认返回true
if (((viewFlags & CLICKABLE) == CLICKABLE ||
(viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE) ||
(viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE){
switch (action) {
...
}
return true;
}
return false;
}
由上可知改变CLICKABLE的值为true就可以让控件执行switch内部的代码，也会返回true表示消费掉该事件，在父布局没有拦截的情况下，事件因为被子布局消费就不会传给父布局，也就不会穿透了，而android:clickable="true"或者setOnClickListener都可以改变这个值。(在第二个案例里我们可以看到父布局检测孩子是否消费该事件是由外到内的，检测不到后再给自己消费)
梳理一下
一个完整的事件是以DOWN开始的，由ViewGroup流向View，ViewGroup需要通过requestDisallowInterceptTouchEvent和onInterceptTouchEvent一起来判断是否拦截事件，且requestDisallowInterceptTouchEvent优先级更大，如果拦截的话，便会dispatch给自己的onTouchEvent或mOnTouchListener.onTouch来消费，如果不拦截的话，会遍历子View，由外到内，找到愿意消费的第一个子View，并且break，所以永远只有一个布局真正意义上的消费该事件(当然你可以通过自定义改写)。
总结
有时候带着某个实际场景的问题来看源码会比较好，不然你是没有动力来看密密麻麻的源码的，不过源码的注释和命名还是很讲究的。
参考链接：
可能是讲解Android事件分发最好的文章
Android事件分发机制完全解析，带你从源码的角度彻底理解(上)
Android事件分发机制完全解析，带你从源码的角度彻底理解(下)
从Android源码的角度理解应用开发（1）-Touch机制