先看一下 View 的事件分发逻辑
View的事件分发入口在View基类源码的dispatchTouchEvent(MotionEvent event);方法里。
分发的逻辑集中在dispatchTouchEvent()方法里的以下重要的代码段：
boolean result = false; //---------------------- 1、定义变量
......
//noinspection SimplifiableIfStatement
ListenerInfo li = mListenerInfo;
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) { // 2、onTouch返还结果
result = true;
}
if (!result && onTouchEvent(event)) { // 3、onTouchEvent(event)执行位置
result = true;
}
*（1）变量result 的初始值为false，从上面代码的注释2和注释3的执行顺序来看，OnTouchListener的ouTouch方法的执行优先级大于onTouchEvent方法。
*（2）当代码2处的onTouch方法返回true时，result被重新赋值:result = true;然后走到代码上面3的条件判断，! result 等于false，所以该条件判断“&&”后面的onTouchEvent(event)就得不到执行。所以，只有在OnTouchListener事件监听onTouch方法返回false时，我们自定义View时所重写的onTouchEvent(event)才会被调用。
*（3）点击事件OnClickListener是在上面代码3的onTouchEvent(event)方法里被调用的。 调用路径 : onTouchEvent() -> performClickInternal() -> performClick() -> li.mOnClickListener.onClick(this); 所以，当上面代码3处的onTouchEvent(event)得不到执行，那OnClickListener点击事件也得不到执行，所以点击事件的执行优先级最低。
*（4）举个例子
我们在开发过程中给一个控件设置OnTouchListener事件，如下：
textView.setOnTouchListener(new View.OnTouchListener() {
@Override
public boolean onTouch(View v, MotionEvent event) {
return true; //---- 4 将onTouch方法的返回值改为true
}
});
如上所示，给一个TextView设置OnTouchListener事件监听，并将onTouch方法返回值改为true， 根据上面的源码分析，得到的结果是TextView的onTouchEvent(event)方法将不会被调用，并且点击事件OnClickListener 将不会被触发，除非将上面代码4处返回值改为false。
*（5）再举个例子
我们在自定义View当中重写onTouchEvent方法，用于交互，如下:
@Override
public boolean onTouchEvent(MotionEvent event) {
// return super.onTouchEvent(event); //-- 5 注释掉
return true; // ---------- 6 改为返回true
}
开发过程中为了拦截完整的一个系列的事件，将上面onTouchEvent的返回值改为true，不再调用父类super.onTouchEvent(event)方法。
从上面源码分析第*(3)点来看，点击事件是在基类View的onTouchEvent方法里被调用，现在自定义View重写了onTouchEvent方法并且不再调用父类super.onTouchEvent(event)，所以该自定义View的点击事件将不会被触发。以上两点在开发过程当中应注意。
再看一下 ViewGroup事件分发大概逻辑
在 ViewGroup 源码的 dispatchTouchEvent 方法里有这样一段代码 ：
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; // 注释 1
}
} else {
// There are no touch targets and this action is not an initial down
// so this view group continues to intercept touches.
intercepted = true; // 注释 11
}
也就是在 ACTION_DOWN 事件触发时，无论如何都会走进 if 条件判断里。且默认情况下 会走到注释1处： intercepted = false;
继续往下看下面一段代码：
...
if (!canceled && !intercepted) { // 注释 2
...
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) { // 注释 3
// Child wants to receive touch within its bounds.
...
newTouchTarget = addTouchTarget(child, idBitsToAssign); // 注释 4
}
}
/*****************************************************************************/
private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) {
final TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
...
mFirstTouchTarget = target; // 注释 5
...
}
...
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
...
final boolean handled;
...
handled = child.dispatchTouchEvent(event); // 注释 6
...
return handled;
}
可以看到， ACTION_DOWN 时即可以走进注释 2处的调价判断。然后走到注释 3 处调用子 View的 dispatchTouchEvent方法（最终调用处在注释 6）。如果ACTION_DOWN 事件触发后，子View 的onTouchEvent方法返回 false，那么上面代码注释 3 处的条件判断将走不进，即注释 4处将得不到执行，那全局变量 mFirstTouchTarget 将得不到赋值（最终赋值在 注释 5处），mFirstTouchTarget 为 null。
mFirstTouchTarget 为 null了，那么当 后续一系列move事件来时。再看前面注释 1处的条件判断就走不进，而走进了注释 11处执行了 intercepted = true; 代码。intercepted 为 true时，注释 2处的条件判断就走不进了。就这样后续的一系列move事件，都不会走到注释 3 处，事件也就传递不到子 View。
网友评论