先来现象:
现象相关的文章,网上实在是太多太多,这里不做累述,仅仅陈述一下结论。
涉及到事件分发过程的方法一共有3个,其中2个是View类的方法:
这个方法是整个事件分发的开始,负责消费事件和分发事件(仅ViewGroup类有此作用),网上一般说返回true会消耗事件,使事件不向下分发(其实返回true的话事件确实不会向上传递了,也就是事件被消耗掉了,但是事件依旧会向下传递到最底部),实质上,这里的返回值是不应该由开发者来指定的,至于原因,留个心,下面会说到,如果开发者进行指定的话,无论返回什么,都不会向下分发。
这个方法是事件的处理方法,也是大部分时候重写的地方。这里返回true的话,事件会在这一层就结束,不会向上传递。不同于上面的dispatchTouchEvent,这个方法是View的,ViewGroup并没有重写这个方法。
最后一个,是ViewGroup独有的:
3、public boolean onInterceptTouchEvent(MotionEvent ev)这个方法最简单,运行在dispatchTouchEvent之后, 当返回true时,事件在这一层ViewGroup被拦截住了,不会向下传递了(这个才是阻止事件向下分发的地方)。
dispatchTouchEvent -> onInterceptTouchEvent(ViewGroup) -> OnTouchListener.onTouch
-> onTouchEvent
好了对现象的描述到此为止,现在开始对本质的探索。
为了方便理解,我先将整个流程梗概写出来,请带着梗概一起阅读,括号后面为该方法所属的类,V=View,VG=ViewGroup。
好了,一切准备就绪了,可以开始草源码了。
首先从第一个方法开始,事件分发的入口是最外层的ViewGroup的dispatchTouchEvent方法,该方法很复杂,这里我只清点分发逻辑相关的代码进行讲解。
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;
...
if (!canceled && !intercepted) {...}//这里就是向下分发事件的代码
上面的代码是不是有些眼熟,没错,这里就是调用onInterceptTouchEvent的地方,如果onInterceptTouchEvent返回值为true时,就不会调用分发事件的代码,于是,事件就不会向下分发。
进入代码片后:
<span style="font-size:24px;">View childWithAccessibilityFocus = ev.isTargetAccessibilityFocus()
? findChildWithAccessibilityFocus() : null;
if (actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
final int actionIndex = ev.getActionIndex(); // always 0 for down
final int idBitsToAssign = split ? 1 << ev.getPointerId(actionIndex)
: TouchTarget.ALL_POINTER_IDS;
// Clean up earlier touch targets for this pointer id in case they
// have become out of sync.
removePointersFromTouchTargets(idBitsToAssign);
final int childrenCount = mChildrenCount;
if (newTouchTarget == null && childrenCount != 0) {
final float x = ev.getX(actionIndex);
final float y = ev.getY(actionIndex);
// Find a child that can receive the event.
// Scan children from front to back.
final ArrayList<View> preorderedList = buildOrderedChildList();
final boolean customOrder = preorderedList == null
&& isChildrenDrawingOrderEnabled();
final View[] children = mChildren;
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;
}
... //for循环的代码块还没有结束哦</span>
<span style="font-size:24px;">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;
}</span>
<span style="font-size:24px;">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;</span>
这段代码里面的重点则是dispatchTransformedTouchEvent方法和alreadyDispatchedToNewTouchTarget 这个布尔值。dispatchTransformedTouchEvent返回值为true时,alreadyDispatchedToNewTouchTarget 的值也变为true。
现在进入dispatchTransformedTouchEvent方法:
<span style="font-size:24px;">if (child == null) {
handled = super.dispatchTouchEvent(event);
} else {
handled = child.dispatchTouchEvent(event);
}</span>
这个方法主要就是上面这几句代码,如果child为空则证明需要调用的是自身的dispatchTouchEvent,反之,则需要调用焦点子View的dispatchTouchEvent,这里也是事件分发中向下分发的地方,本质上来说,事件分发的向下传递实质就是一个递归的过程,由父类不断的向下调用获得焦点子Viewd的dispatchTouchEvent,如果子View也是一个ViewGroup则会继续调用ViewGroup重写后的dispatchTouchEvent,然后再次进入这段代码,直到底部为View或者底部为ViewGroup但焦点子View为空的时候。然后递归开始往回执行,如下图:
好了,到这里for循环终于是结束了。
接下来,就是ViewGroup的dispatchTouchEvent方法最后的部分了:
<span style="font-size:24px;">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;
}
}
...
return handled;</span>
好了,到这里ViewGroup的dispatchTouchEvent方法就结束了,其实从这个方法基本上就能看到整个事件分发机制的雏形了,还记得之前提到的为什么重写的时候不要手动给dispatchTouchEvent返回值么,因为事件分发的代码就是在super.dispatchTouchEvent里面啊。
那么,疑问来了,既然无法指定dispatchTouchEvent的返回值,那么要怎么去控制事件被消耗呢,根据之前的梗概流程,让我们看一下View类的dispatchTouchEvent:
<span style="font-size:24px;">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;
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;</span>
想必各位看官也看到了,dispatchTouchEvent返回值true or false的关键,就在于我们一直没有讲到的最后一个,也是大家用的最多的一个方法onTouchEvent,还有大家最最熟悉的OnTouchListener,_(:з」∠)_,让我先从OnTouchListener说起。
OnTouchListener这个接口想必搞Android开发的大家都是用过的,里面的onTouch方法不是有返回值么,这里也看到了,如果返回为true,result就会为true,事件在这一层被消耗,并且连带这层的onTouchEvent方法就不会调用了(所以实现了OnTouchListener并且返回为true的情况下,onTouchEvent方法就完全失效了)。
反之如果返回false,情况就比较复杂了,那么不仅会执行这一层的onTouch方法,连带上一层的(如果实现了的话)也会执行,同时也会执行onTouchEvent方法,但是要注意,运行了onTouchEvent方法后,如果View为Button类的话,当事件为Up和Down的时候;scorll类并且内部有内容的情况下手势为Up、Down、Move的时候;其他的View的话,就只有手势为Down的时候。这些时候,才会触发dispatchTouchEvent方法。
而那些事件冲突的问题,就是发生在onTouchEvent这个方法里。
鉴于onTouchEvent里,涉及到大量的位运算,以及各种View的各种手势的事件,这里暂时先放一放,等我研究透了之后会在写一篇博文补上。