Android ViewGroup事件分发和处理源码分析
作者:大胃粥
正文
上篇文章事件分发之View事件处理讲述了事件分发处理中最基础的一环,那么本篇文章就继续来分析ViewGroup的事件分发以及处理。
ViewGroup事件分发以及处理极其的复杂,体现在以下几个方面
- ViewGroup不仅要分发事件,而且也可能截断并处理事件。
- 对于
ACTION_DOWN
,ACTION_MOVE
,ACTION_UP
,甚至还有ACTION_CANCEL
事件,有不同的处理情况。 - ViewGroup的代码中还杂合了对多手指的处理情况。
鉴于代码的复杂性,本篇文章会对不同的情况分段讲解,并在讲解完毕用一副图来表示代码的处理过程。
由于篇幅的原因,本文并不打算把多点触控的代码拿出来讲解,因为多点触控也是比较难以讲解的一块。如果后续有时间,而且如果感觉有必要,我会用另外一篇文章来讲解ViewGroup对多手指事件的处理。
处理ACTION_DOWN事件
检测是否截断事件
当ViewGroup检测到ACTION_DOWN
事件后,它做的第一件事是检测是否截断ACTION_DOWN
事件。
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()
方法来判断是否截断。
我们首先来分析下ViewGroup.onInterceptTouchEvent()
返回false
的情况,也就是不截断ACTION_DOWN
的情况,之后再来分析截断的情况。
不截断ACTION_DOWN事件
寻找处理事件的子View
如果ViewGroup不截断ACTION_DOWN
事件,那么intercepted
值为false
。这意思就是说ViewGroup不截断处理这个事件了,那就得找个子View来处理事件
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的顺序。
获取到一个子View后,2.2步,判断这个子View是否满足处理事件的标准,标准有两个
- 通过
canViewReceivePointerEvents()
判断子View是否能够接收事件。它的原理非常简单,只要View可见,或者View有动画,那么View就可以接收事件。 - 通过
isTransformedTouchPointInView()
判断事件的坐标是否在子View内。它的原理可以简单描述下,首先要把事件坐标转换为View空间的坐标,然后判断转换后的坐标是否在View内。这个说起来简单,但是如果要解释,需要大家了解View滚动以及Matrix相关知识,因此我这里不打算详细解释。
2.2步呢,如果找到的子View没有这个能力处理事件,那么就会直接进行下一轮循环,去找下一个能够处理事件的子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事件
其实ViewGroup是可以自己处理ACTION_DOWN
事件的,有两种情况会让这成为可能
- ViewGroup自己截断
ACTION_DOWN
事件 - ViewGroup找不到能处理
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
事件的情况
- ViewGroup截断
ACTION_DOWN
事件 - ViewGroup找不到能处理
ACTION_DOWN
事件的子View
处理ACTION_DOWN总结
ViewGroup对ACTION_DOWN
的处理很关键,我们永远要记住一点,它是为了找到mFirstTouchTarget
,因为mFirstTouchTarget.child
指向处理了ACTION_DOWN
事件的子View。
为何mFirstTouchTarget
如此关键,因为后续所有事件都是围绕mFirstTouchTarget
来处理的,例如把后续事件交给mFirstTouchTarget.child
来处理。
处理ACTION_MOVE事件
检测是否截断ACTION_MOVE事件
对于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要看看自己是否要截断,这就要分两种情况了
- 如果子View允许父View截断事件,那么就通过
onInterceptTouchEvent()
来判断ViewGroup自己是否截断 - 如果子View不允许父View截断事件,那么ViewGroup肯定就不截断了。
现在,有两种情况会导致ViewGroup不截断ACTION_MOVE
事件
mFirstTouchTarget != null
,子View允许父ViewGroup截断事件,并且ViewGroup的onInterceptTouchEvent()
返回false
mFirstTouchTarget != null
,子View不允许父ViewGroup截断事件
那么接下来,我们还是先分析ViewGroup不截断ACTION_MOVE
事件的情况
不截断ACTION_MOVE
事件分发给mFirstTouchTarget.child
如果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
事件的处理流程
截断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的处理结果。
处理 ACTION_UP 和 ACTION_CANCEL 事件
View/ViewGroup每一次都是处理一个事件序列,一个事件序列由ACTON_DOWN
开始,由ACTION_UP
/ACTION_CANCEL
结束,中间有零个或者多个ACTION_MOVE
事件。
ACTION_UP
和ACTION_CANCEL
理论上讲只能取其一。
ViewGroup处理ACTION_UP
和ACTION_CANCEL
事件与处理ACTION_MOVE
事件的流程是一样的,大家可以从源代码中自行再分析一遍。
正确地使用requestDisallowInterceptTouchEvent()
前面我们一直在提子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
一样。- 注意子View请求不允许父View截断的调用时机。
以上就是Android ViewGroup事件分发和处理源码分析的详细内容,更多关于Android ViewGroup事件分发处理的资料请关注脚本之家其它相关文章!