上篇文章事件分发之View事件处理讲述了事件分发处理中最基础的一环,那么本篇文章就继续来分析ViewGroup的事件分发以及处理。java
ViewGroup事件分发以及处理极其的复杂,体如今如下几个方面post
ACTION_DOWN
,ACTION_MOVE
, ACTION_UP
,甚至还有ACTION_CANCEL
事件,有不一样的处理状况。鉴于代码的复杂性,本篇文章会对不一样的状况分段讲解,并在讲解完毕用一副图来表示代码的处理过程。动画
因为篇幅的缘由,本文并不打算把多点触控的代码拿出来说解,由于多点触控也是比较难以讲解的一块。若是后续有时间,并且若是感受有必要,我会用另一篇文章来说解ViewGroup对多手指事件的处理。ui
当ViewGroup检测到ACTION_DOWN
事件后,它作的第一件事是检测是否截断ACTION_DOWN
事件。this
public boolean dispatchTouchEvent(MotionEvent ev) {
if (onFilterTouchEventForSecurity(ev)) {
// 作一些重置动做,包括清除FLAG_DISALLOW_INTERCEPT
if (actionMasked == MotionEvent.ACTION_DOWN) {
cancelAndClearTouchTargets(ev);
resetTouchState();
}
// 1. 检测是否截断事件
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
// 因为以前清除过FLAG_DISALLOW_INTERCEPT,所以这里的值为false
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
// 判断本身是否截断
intercepted = onInterceptTouchEvent(ev);
ev.setAction(action); // restore action in case it was changed
} else {
}
} else {
}
}
复制代码
对于ACTION_DOWN
事件,ViewGroup只经过onInterceptTouchEvent()
方法来判断是否截断。spa
咱们首先来分析下ViewGroup.onInterceptTouchEvent()
返回false
的状况,也就是不截断ACTION_DOWN
的状况,以后再来分析截断的状况。3d
若是ViewGroup不截断ACTION_DOWN
事件,那么intercepted
值为false
。这意思就是说ViewGroup不截断处理这个事件了,那就得找个子View来处理事件rest
public boolean dispatchTouchEvent(MotionEvent ev) {
if (onFilterTouchEventForSecurity(ev)) {
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// 1. 检测是否截断事件
// ...
TouchTarget newTouchTarget = null;
boolean alreadyDispatchedToNewTouchTarget = false;
// 不截断
if (!canceled && !intercepted) {
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;
final int childrenCount = mChildrenCount;
if (newTouchTarget == null && childrenCount != 0) {
final float x = ev.getX(actionIndex);
final float y = ev.getY(actionIndex);
// 获取有序的子View集合
final ArrayList<View> preorderedList = buildTouchDispatchChildList();
final boolean customOrder = preorderedList == null
&& isChildrenDrawingOrderEnabled();
final View[] children = mChildren;
for (int i = childrenCount - 1; i >= 0; i--) {
// 2.经过循环来寻找一个能处理ACTION_DOWN事件的子View
// 2.1 获取一个子View
final int childIndex = getAndVerifyPreorderedIndex(
childrenCount, i, customOrder);
final View child = getAndVerifyPreorderedView(
preorderedList, children, childIndex);
// 2.2 判断子View是否可以处理事件
if (!canViewReceivePointerEvents(child)
|| !isTransformedTouchPointInView(x, y, child, null)) {
ev.setTargetAccessibilityFocus(false);
// 若是不能处理,就进行下一轮循环继续寻找子View
continue;
}
// 3. 把事件分发给子View
// ...
}
}
}
}
}
return handled;
}
复制代码
首先2.1步,获取一个子View。至于以怎么样一个方式获取一个子View,咱们这里不须要深究,若是你们之后遇到绘制顺序,以及子View接收事件的顺序问题时,能够再回头分析这里获取子View的顺序。code
获取到一个子View后,2.2步,判断这个子View是否知足处理事件的标准,标准有两个orm
canViewReceivePointerEvents()
判断子View是否可以接收事件。它的原理很是简单,只要View可见,或者View有动画,那么View就能够接收事件。isTransformedTouchPointInView()
判断事件的坐标是否在子View内。它的原理能够简单描述下,首先要把事件坐标转换为View空间的坐标,而后判断转换后的坐标是否在View内。这个提及来简单,可是若是要解释,须要你们了解View滚动以及Matrix相关知识,所以我这里不打算详细解释。2.2步呢,若是找到的子View没有这个能力处理事件,那么就会直接进行下一轮循环,去找下一个可以处理事件的子View。这一步基本上都是能找到子View的,由于若是咱们想使用某个控件,手指确定要在上面按下吧。
有了能处理事件的子View,如今就把ACTION_DOWN
事件分发给它处理,而且经过结果看看它是否处理了ACTION_DOWN
事件,咱们来看下代码
public boolean dispatchTouchEvent(MotionEvent ev) {
if (onFilterTouchEventForSecurity(ev)) {
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// 1. 检测是否截断事件
// ...
// 不取消,不截断
if (!canceled && !intercepted) {
if (actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
if (newTouchTarget == null && childrenCount != 0) {
// 遍历寻找一个能处理事件的View
for (int i = childrenCount - 1; i >= 0; i--) {
// 2. 找一个能处理事件的子View
// ...
// 3. 把事件分发给子View
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
// 3.1 子View处理了事件,获取一个TouchTarget对象
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
break;
}
}
}
}
}
if (mFirstTouchTarget == null) {
} else {
TouchTarget predecessor = null;
TouchTarget target = mFirstTouchTarget;
while (target != null) {
final TouchTarget next = target.next;
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {
// 3.2 找到了处理ACTION_DOWN事件的子View,设置结果
handled = true;
} else {
}
}
}
}
// 3.3 返回结果
return handled;
}
复制代码
第3步,经过dispatchTransformedTouchEvent()
方法把事件发给这个子View,并经过返回值肯定子View的处理结果
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel, View child, int desiredPointerIdBits) {
final boolean handled;
final int oldPointerIdBits = event.getPointerIdBits();
final int newPointerIdBits = oldPointerIdBits & desiredPointerIdBits;
final MotionEvent transformedEvent;
// 手指数没有变
if (newPointerIdBits == oldPointerIdBits) {
// 1. child有单位矩阵状况
if (child == null || child.hasIdentityMatrix()) {
if (child == null) {
} else {
// 先把事件坐标转换为child坐标空间的坐标
final float offsetX = mScrollX - child.mLeft;
final float offsetY = mScrollY - child.mTop;
event.offsetLocation(offsetX, offsetY);
// 把事件发给child处理
handled = child.dispatchTouchEvent(event);
event.offsetLocation(-offsetX, -offsetY);
}
// 返回处理结果
return handled;
}
transformedEvent = MotionEvent.obtain(event);
} else {
transformedEvent = event.split(newPointerIdBits);
}
if (child == null) {
} else {
// 2. 处理child没有单位矩阵的状况
// 先把事件坐标转换为child坐标空间的坐标
final float offsetX = mScrollX - child.mLeft;
final float offsetY = mScrollY - child.mTop;
transformedEvent.offsetLocation(offsetX, offsetY);
// 再根据转换矩阵,把转换后的坐标通过逆矩阵再次转换
if (! child.hasIdentityMatrix()) {
transformedEvent.transform(child.getInverseMatrix());
}
// 最后交给child处理转换坐标后的事件
handled = child.dispatchTouchEvent(transformedEvent);
}
// 返回处理结果
return handled;
}
复制代码
虽然根据子View是否有单位矩阵的状况,这里的处理流程分为了两步,可是这里的处理方式大体都是相同的,都是首先把事件坐标作转换,而后交给子View的dispatchTouchEvent()
处理。
从dispatchTransformedTouchEvent()
实现能够看出,它的返回结果是由子View的dispatchTouchEvent()
决定的。假如返回了true
, 就表明子View处理了ACTION_DOWN
,那么就走到了3.1步,经过addTouchTarget()
获取一个TouchTarget
对象
private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) {
// 从对象池中获取一个TouchTarget
final TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
// 插入到链单表的头部
target.next = mFirstTouchTarget;
// mFirstTouchTarget指向单链表的开头
mFirstTouchTarget = target;
return target;
}
复制代码
这里是一个对象池配合链表的常规操做,这里要注意一点就是,mFirstTarget
指向单链表的头部,mFirstTouchTarget.child
就是指向了处理了ACTION_DOWN
事件的子View。
走到这里就表明找到并处理了ACTION_DOWN
事件的子View,以后就走到3.2和3.3直接返回结果true
。
咱们用一幅图来表示下ACTION_DOWN
事件不被截断的处理过程
其实ViewGroup是能够本身处理ACTION_DOWN
事件的,有两种状况会让这成为可能
ACTION_DOWN
事件ACTION_DOWN
事件的子View因为这两种状况的代码处理方式是同样的,因此我把这两种状况放到一块儿讲,代码以下
public boolean dispatchTouchEvent(MotionEvent ev) {
if (onFilterTouchEventForSecurity(ev)) {
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// 检测是否截断事件
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
// ACTION_DOWN时,disallowIntercept值永远为false
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
// 返回true,截断事件
intercepted = onInterceptTouchEvent(ev);
} else {
}
} else {
}
// 1. 若是ViewGroup截断事件,直接走第3步
if (!canceled && !intercepted) {
if (actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
if (newTouchTarget == null && childrenCount != 0) {
// 2. 若是全部的子View都不处理ACTION_DOWN事件,直接走第3步
for (int i = childrenCount - 1; i >= 0; i--) {
// 找一个能处理事件的子View
// ...
// View处理事件
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
}
}
}
}
}
if (mFirstTouchTarget == null) {
// 3. ViewGroup本身处理ACTION_DOWN事件
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
} else {
}
}
// 4. 返回处理结果
return handled;
}
复制代码
从代码中能够看到,若是ViewGroup截断ACTION_DOWN
事件或者找不到一个能处理ACTION_DOWN
事件的子View,最终都会走到第3步,经过dispatchTransformedTouchEvent()
方法把ACTION_DOWN
事件交给本身处理,注意传入的第三个参数为null
,表示没有处理事件的子View
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel, View child, int desiredPointerIdBits) {
final int oldPointerIdBits = event.getPointerIdBits();
final int newPointerIdBits = oldPointerIdBits & desiredPointerIdBits;
// 手指数不变
if (newPointerIdBits == oldPointerIdBits) {
if (child == null || child.hasIdentityMatrix()) {
if (child == null) {
// 调用View.dispatchTouchEvent()
handled = super.dispatchTouchEvent(event);
} else {
}
// 返回处理的结果
return handled;
}
} else {
}
return handled;
}
复制代码
很简单,调用父类View的diaptchTouchEvent()
方法,由事件分发之View事件处理可知,会交给onTouchEvent()
方法。
View事件处理其实还有
OnTouchListener
一环,可是通常不会给ViewGroup
设置这个监听器,所以这里忽略了。
从整个分析过程能够看出,若是ViewGroup本身处理ACTION_DOWN
事件,那么ViewGroup.dispatchTouchEvent()
的返回值是与ViewGroup.onTouchEvent()
返回值相同的。
咱们如今也用一幅图来表示ViewGroup本身处理ACTION_DOWN
事件的状况,其中包括两套处理流程,我这里仍是再强调一遍ViewGroup本身处理ACTION_DOWN
事件的状况
ACTION_DOWN
事件ACTION_DOWN
事件的子ViewViewGroup对ACTION_DOWN
的处理很关键,咱们永远要记住一点,它是为了找到mFirstTouchTarget
,由于mFirstTouchTarget.child
指向处理了ACTION_DOWN
事件的子View。
为什么mFirstTouchTarget
如此关键,由于后续全部事件都是围绕mFirstTouchTarget
来处理的,例如把后续事件交给mFirstTouchTarget.child
来处理。
对于ACTION_MOVE
事件,ViewGroup也会去判断是否进行截断,代码片断以下
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean handled = false;
if (onFilterTouchEventForSecurity(ev)) {
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// 1. 检测是否截断
final boolean intercepted;
// 1.2 若是有处理ACTION_DOWN事件的子View
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
// 判断子View是否请求不容许父View截断事件
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) { // 子View容许截断事件
// 判断本身是否截断
intercepted = onInterceptTouchEvent(ev);
ev.setAction(action); // restore action in case it was changed
} else { // 子View不容许截断事件
intercepted = false;
}
} else {
// 1.3 没有处理ACTION_DOWN的子View,就截断ACTION_MOVE事件
intercepted = true;
}
}
}
复制代码
从代码中能够看到,mFirstTouchTarget
成为了是否截断ACTION_MOVE
事件的判断条件。如今知道ACTION_DOWN
事件处理有多重要了吧,它直接影响了ACTION_MOVE
事件的处理,固然还有ACTION_UP
和ACTION_CANCEL
事件的处理。
1.3步的意思是,既然没有处理了ACTION_DOWN
事件的子View,也就是mFirstTouchTarget == null
,那么只能由老夫ViewGroup截断,而后本身处理了。
1.2步呢,若是有处理了ACTION_DOWN
事件的子View,也就是mFirstTouchTarget != null
,在把事件分发给mFirstTouchTarget.child
以前呢,ViewGroup要看看本身是否要截断,这就要分两种状况了
onInterceptTouchEvent()
来判断ViewGroup本身是否截断如今,有两种状况会致使ViewGroup不截断ACTION_MOVE
事件
mFirstTouchTarget != null
,子View容许父ViewGroup截断事件,而且ViewGroup的onInterceptTouchEvent()
返回false
mFirstTouchTarget != null
,子View不容许父ViewGroup截断事件那么接下来,咱们仍是先分析ViewGroup不截断ACTION_MOVE
事件的状况
若是ViewGroup不截断事件,其实也说明mFirstTouchTarget
不为null
,那么ACTION_MOVE
事件会分发给mFirstTouchTarget.child
,咱们来看下代码
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean handled = false;
if (onFilterTouchEventForSecurity(ev)) {
// 1. 检测是否截断ACTION_MOVE
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
// 1.1 儿子容许截断,老子本身决定也不截断
intercepted = onInterceptTouchEvent(ev);
} else {
// 1.2 儿子不容许截断,老子就不截断
intercepted = false;
}
} else {
}
if (!canceled && !intercepted) {
if (actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
}
}
if (mFirstTouchTarget == null) {
// 截断事件的状况
} else {
while (target != null) {
final TouchTarget next = target.next;
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {
} else {
// 不截断事件,cancelChild为false
final boolean cancelChild = resetCancelNextUpFlag(target.child)
|| intercepted;
// 3. 把事件交给mFirstTouchTarget指向的子View处理
if (dispatchTransformedTouchEvent(ev, cancelChild,
target.child, target.pointerIdBits)) {
handled = true;
}
// ...
}
// ...
}
}
}
return handled;
}
复制代码
ViewGroup不截断ACTION_MOVE
事件时,就调用dispatchTransformedTouchEvent()
把事件交给mFirstTouchTarget.chid
处理
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel, View child, int desiredPointerIdBits) {
final boolean handled;
final int oldPointerIdBits = event.getPointerIdBits();
final int newPointerIdBits = oldPointerIdBits & desiredPointerIdBits;
final MotionEvent transformedEvent;
// 1. child有单位矩阵的状况
if (newPointerIdBits == oldPointerIdBits) { // 手指数没有变
if (child == null || child.hasIdentityMatrix()) {
if (child == null) {
} else {
// 事件坐标进行转换
final float offsetX = mScrollX - child.mLeft;
final float offsetY = mScrollY - child.mTop;
event.offsetLocation(offsetX, offsetY);
// 把事件传递给child
handled = child.dispatchTouchEvent(event);
event.offsetLocation(-offsetX, -offsetY);
}
return handled;
}
transformedEvent = MotionEvent.obtain(event);
} else {
transformedEvent = event.split(newPointerIdBits);
}
if (child == null) {
}
// 2. child没单位矩阵的状况
else {
// 事件坐标进行转换
final float offsetX = mScrollX - child.mLeft;
final float offsetY = mScrollY - child.mTop;
transformedEvent.offsetLocation(offsetX, offsetY);
if (! child.hasIdentityMatrix()) {
transformedEvent.transform(child.getInverseMatrix());
}
// 把事件传递给child
handled = child.dispatchTouchEvent(transformedEvent);
}
return handled;
}
复制代码
咱们能够看到不管是哪一种状况,最终都会调用child.dispatchTouchEvent()
方法把ACTION_MOVE
事件传递给child
。 也就是说处理了ACTION_DOWN
事件的子View最终会收到ACTION_MOVE
事件。
咱们用一张图来总结下ViewGroup不截断ACTION_MOVE
事件的处理流程
从前面的分析的可知,若是ViewGroup截断ACTION_MOVE
事件,是有两种状况
mFirstTouchTarget == null
,那么ViewGroup就要截断事件本身来处理。mFirstTouchTarget != null
,而且子View容许截断事件,ViewGroup的onInterceptTouchEvent()
返回true。然而这两种状况的代码处理流程是不一样的,这无疑又给代码分析增长了难度,咱们先来看第一种状况,没有mFirstTouchTarget
的状况
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean handled = false;
if (onFilterTouchEventForSecurity(ev)) {
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
} else {
// 1. mFirstTouchTarget为null, 截断事件
intercepted = true;
}
if (!canceled && !intercepted) {
if (actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
}
}
if (mFirstTouchTarget == null) {
// 2. 截断了,把事件交给ViewGroup本身处理
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
} else {
// ...
}
}
return handled;
}
复制代码
从代码能够看到,当mFirstTouchTarget == null
的时候,ViewGroup截断事件,就调用dispatchTransformedTouchEvent()
方法交给本身处理,这个方法以前分析过,不过注意这里的第三个参数为null,表明没有处理这个事件的子View
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel, View child, int desiredPointerIdBits) {
final boolean handled;
// 手指数没变
if (newPointerIdBits == oldPointerIdBits) {
if (child == null || child.hasIdentityMatrix()) {
if (child == null) {
// 调用父类View的dispatchTouchEvent()方法
handled = super.dispatchTouchEvent(event);
} else {
}
return handled;
}
}
复制代码
很简单,就是调用父类View的dispatchTouchEvent()
方法,也就是调用了ViewGroup.onTouchEvent()
方法,而且ViewGroup.dispatchTouchEvent()
的返回值与ViewGroup.onTouchEvent()
相同。
如今来看看第二种截断的状况,也就是mFirstTouchTarget != null
,而且ViewGroup.onInterceptTouchEvent()
返回true
。
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean handled = false;
if (onFilterTouchEventForSecurity(ev)) {
// 检测是否截断
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
// 1. 子View容许截断,而且ViewGroup也截断了,intercepted为true
intercepted = onInterceptTouchEvent(ev);
} else {
intercepted = false;
}
} else {
}
if (!canceled && !intercepted) {
// ...
}
if (mFirstTouchTarget == null) {
// ...
} else {
TouchTarget predecessor = null;
TouchTarget target = mFirstTouchTarget;
while (target != null) {
final TouchTarget next = target.next;
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {
// ...
} else {
// intercepted为true, cancelChild为true,表明取消child处理事件
final boolean cancelChild = resetCancelNextUpFlag(target.child)
|| intercepted;
// 2. 向child发送ACTION_CANCEL事件
if (dispatchTransformedTouchEvent(ev, cancelChild,
target.child, target.pointerIdBits)) {
handled = true;
}
// 取消child处理事件
if (cancelChild) {
if (predecessor == null) {
// 3. 把mFirstTouchTarget值设为null
mFirstTouchTarget = next;
} else {
predecessor.next = next;
}
target.recycle();
target = next;
continue;
}
}
predecessor = target;
target = next;
}
}
}
return handled;
}
复制代码
第1步,当mFirstTouchTarget != null
,子View容许父ViewGroup截断ACTION_MOVE
事件,而且ViewGroup.onInterceptTouchEvent()
返回true
,也就是父ViewGroup截断事件。
第2步,ViewGroup仍然会调用dispatchTransformedTouchEvent()
方法把事件发送给mFirstTouchTarget
,只是此次mFisrtTouchTarget
接收到的是ACTION_CANCEL
事件,而不是ACTION_MOVE
事件。注意,第二个参数cancelChild
的值为true
,咱们来看下具体的方法实现
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel, View child, int desiredPointerIdBits) {
final boolean handled;
final int oldAction = event.getAction();
// cancel值为true
if (cancel || oldAction == MotionEvent.ACTION_CANCEL) {
// 设置事件的类型为ACTION_CANCEL
event.setAction(MotionEvent.ACTION_CANCEL);
if (child == null) {
handled = super.dispatchTouchEvent(event);
} else {
// 把ACTION_CANCEL的事件发送给child
handled = child.dispatchTouchEvent(event);
}
event.setAction(oldAction);
// 返回child处理结果
return handled;
}
}
复制代码
咱们能够惊讶的发现,当ViewGroup截断了ACTION_MOVE
事件,mFirstTouchTarget.child
竟然收到的是ACTION_CANCEL
事件。如今你们知道了一个View在怎样的状况下收到ACTION_CANCEL
事件吧!!!
把ACTION_CANCEL
事件发送给mFirstTouchTarget
后还没完,还进行了第3步,把mFirstTouchTarget
设置为null
。 这就很过度了,ViewGroup截断了原本属于mFirstTouchTarget
的ACTION_MOVE
事件,把ACTION_MOVE
变为ACTION_CANCEL
事件发送了mFirstTouchTarget
,最后还要取消mFirstTouchTarget.child
接收后续事件的资格。
因为滑动的时候,会产生大量的ACTION_MOVE
事件,既然ViewGroup截断ACTION_MOVE
以后,后续的ACTION_MOVE
事件怎么处理呢?固然是按照mFirstTouchTarget == null
的状况,调用ViewGroup.onTouchEvent()
处理。
如今,咱们再用一幅图来表示ViewGroup截断ACTION_MOVE
事件的过程
这幅图没有列出发送ACTION_CANCEL结果,彷佛平时也没有在乎ACTION_CANCEL的处理结果。
View/ViewGroup每一次都是处理一个事件序列,一个事件序列由ACTON_DOWN
开始,由ACTION_UP
/ACTION_CANCEL
结束,中间有零个或者多个ACTION_MOVE
事件。
ACTION_UP
和ACTION_CANCEL
理论上讲只能取其一。
ViewGroup处理ACTION_UP
和ACTION_CANCEL
事件与处理ACTION_MOVE
事件的流程是同样的,你们能够从源代码中自行再分析一遍。
前面咱们一直在提子View可以请求父View不容许截断事件,那么子View如何作到呢
final ViewParent parent = getParent();
if (parent != null) {
parent.requestDisallowInterceptTouchEvent(true);
}
复制代码
获取父View,并调用其requestDisallowInterceptTouchEvent(true)
方法,从而不容许父View截断事件。
父View通常为ViewGroup,咱们就来看看ViewGroup.requestDisallowInterceptTouchEvent()
方法的实现吧
// ViewGroup.java
public void requestDisallowInterceptTouchEvent(boolean disallowIntercept) {
// 已经设置FLAG_DISALLOW_INTERCEPT标记,就直接返回
if (disallowIntercept == ((mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0)) {
// We're already in this state, assume our ancestors are too
return;
}
// 根据参数值来决定是否设置FLAG_DISALLOW_INTERCEPT标记
if (disallowIntercept) {
mGroupFlags |= FLAG_DISALLOW_INTERCEPT;
} else {
mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;
}
// 把这个请求继续往上传给父View
if (mParent != null) {
mParent.requestDisallowInterceptTouchEvent(disallowIntercept);
}
}
复制代码
requestDisallowInterceptTouchEvent(boolean disallowIntercept)
会根据参数disallowIntercept
的值来决定是否设置FLAG_DISALLOW_INTERCEPT
标记,再去请求父View作相同的事情。
如今,咱们能够想象一个事情,假如某个子View调用了getParent.requestDisallowInterceptTouchEvent(true)
,那么这个子View的上层的全部父View都会设置一个FLAG_DISALLOW_INTERCEPT
标记。这个标记一旦设置,那么全部的父View再也不截断后续任何事件。这个方法实在是霸道,要慎用,不然可能影响某个父View的功能。
然而requestDisallowInterceptTouchEvent()
方法的调用并非在任什么时候候都有效的,请看以下代码
private void resetTouchState() {
// 清除FLAG_DISALLOW_INTERCEPT标记
mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;
}
public boolean dispatchTouchEvent(MotionEvent ev) {
if (onFilterTouchEventForSecurity(ev)) {
// ACTION_DOWN清除FLAG_DISALLOW_INTERCEPT标记
if (actionMasked == MotionEvent.ACTION_DOWN) {
resetTouchState();
}
final boolean canceled = resetCancelNextUpFlag(this)
|| actionMasked == MotionEvent.ACTION_CANCEL;
// 省略处理ACTION_DOWM, ACTION_MOVE, ACTIOON_UP的代码
// ACTION_CANCEL或者ACTION_UP也会清除FLAG_DISALLOW_INTERCEPT标记
if (canceled
|| actionMasked == MotionEvent.ACTION_UP
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
resetTouchState();
} else if (split && actionMasked == MotionEvent.ACTION_POINTER_UP) {
}
}
return handled;
}
复制代码
咱们能够发现,在处理ACTION_DOWN
事件的时候,会首先清除这个FLAG_DISALLOW_INTERCEPT
标记,那意思就是说,子View若是在父View处理ACTION_DOWN
以前调用了getParent().requestDisallowInterceptTouchEvent(true)
方法,实际上是无效的。
ACTION_UP
或ACTION_CANCEL
事件,都表示事件序列的终止,咱们能够看到,在处理完ACTION_UP
或ACTION_CANCEL
事件,都会取消FLAG_DISALLOW_INTERCEPT
标记。很显然这是能够理解的,由于一个事件序列完了,就要恢复状态,等待处理下一个事件序列。
如今,咱们如今能够得出一个推论,getParent().requestDisallowInterceptTouchEvent(true)
是要在接收ACTION_DOWN
以后,并在接收ACTION_UP
或ACTION_CANCEL
事件以前调用才有效。很明显这个方法只是在针对ACTION_MOVE
事件。
那么,什么状况下子View会去请求不容许父View截断ACTION_MOVE
事件呢?我用ViewPager
举例让你们体会下。
第一种状况就是ViewPager
在onInterceptTouchEvent()
接收到ACTION_MOVE
事件,准备截断ACTION_MOVE
事件,在执行滑动代码以前,调用getParent().requestDisallowInterceptTouchEvent(true)
, 请求父View不容许截断后续ACTION_MOVE
事件。为什么要向父View作这个请求?由于既然ViewPager
已经利用ACTION_MOVE
开始滑动了,父View再截断ViewPager
的ACTION_MOVE
就说不过去了吧。
第二种状况就是ViewPager
在手指快速滑动并抬起后,ViewPager
仍然还处于滑动状态,此时若是手指再按下,ViewPager
认为这是一个终止当前滑动,并从新进行滑动的动做,所以ViewPager
会向父View请求不容许截断ACTION_MOVE
事件,由于它要立刻利用ACTION_MOVE
开始再进行滑动。
若是你们能看懂这先后两篇文章,分析
ViewPager
没有太大的问题的。
从这两种状况能够得出一个结论,那就是若是当前控件即将利用ACTION_MOVE
来执行某种持续的动做前,例如滑动,那么它能够请求父View不容许截断后续的ACTION_MOVE
事件。
文章很是长,可是已经把每一个过程都分析清楚了。然而在实战中,不管是自定义View事件处理,仍是事件冲突解决,咱们每每会感受畏首畏尾,有点摸不着头脑。如今我对本文的关键点进行总结,但愿你们在实际应用中牢记这些关键点
ViewGroup.dispatchTouchEvent()
什么时候返回true
,什么时候返回false
。由于处理了事件才返回true
,由于没有处理事件才返回false
。ACTION_DOWN
时,出现一个关键变量,就是mFirstTouchTarget
,必定要记住,只有在消费了ACTION_DOWN
事件才有值。ACTION_MOVE
正常的状况下会传给mFirstTouchTarget.child
,而若是被ViewGroup截断,就会把接收到ACTION_MOVE
变为ACTION_CANCEL
事件发送给mFirstTouchTarget.child
,而且把mFirstTouchTarget
置空,后续的ACTION_MOVE
事件就会传给ViewGroup的onTouchEvent()
。ACTION_UP
, ACTION_CANCEL
事件处理流程与ACTION_MOVE
同样。