前言
对于Android MotionEvent，我们平时大多关注的是ACTION_DOWN、ACTION_UP、ACTION_MOVE，本篇将重点分析ACTION_CANCEL 产生的原因及其滑动事件的处理。
通过本篇文章，你将了解到：
1、ACTION_CANCEL 产生的原因
2、手指离开当前View时事件处理
3、手指离开屏幕时事件处理
1、ACTION_CANCEL 产生的原因
从ViewGroup 入手分析
事件分发是从ViewGroup-->View，因此想要知道View是否收到ACTION_CANCEL，需要从ViewGroup入手，而ViewGroup 分发的重点即在dispatchTouchEvent(xx)里。
先看看dispatchTouchEvent(xx) 代码，之前的文章有详细分析过，此次重点关注
ACTION_CANCEL的处理逻辑：
#ViewGroup.java
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean handled = false;
if (onFilterTouchEventForSecurity(ev)) {
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// Handle an initial down.
if (actionMasked == MotionEvent.ACTION_DOWN) {
//首次Down事件处理------------>(1)
cancelAndClearTouchTargets(ev);
resetTouchState();
}
//ViewGroup是否拦截事件
...
//是否发送取消事件
final boolean canceled = resetCancelNextUpFlag(this)
|| actionMasked == MotionEvent.ACTION_CANCEL;
//寻找接收了Down事件的子View(子布局)
...
if (mFirstTouchTarget == null) {
//没有子View(子布局)消费事件，于是事件流转到ViewGroup onTouchEvent
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
} else {
//有子View(子布局)消费事件
TouchTarget predecessor = null;
TouchTarget target = mFirstTouchTarget;
while (target != null) {
//遍历消费链
final TouchTarget next = target.next;
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {
//已经消费过，直接返回
handled = true;
} else {
//判断是否需要发送取消事件------------>(2)
final boolean cancelChild = resetCancelNextUpFlag(target.child)
|| intercepted;
//分发事件------------>(3)
if (dispatchTransformedTouchEvent(ev, cancelChild,
target.child, target.pointerIdBits)) {
handled = true;
}
if (cancelChild) {
//如果是取消事件，则子View(子布局)没必要消费了，因此从消费链里摘除
if (predecessor == null) {
mFirstTouchTarget = next;
} else {
predecessor.next = next;
}
target.recycle();
target = next;
continue;
}
}
predecessor = target;
target = next;
}
}
...
}
...
return handled;
}
上面列出了三个重点，将一一分析：
(1)
主要是cancelAndClearTouchTargets(xx)方法：
#ViewGroup.java
private void cancelAndClearTouchTargets(MotionEvent event) {
//子View(子布局) 消费了Down事件
if (mFirstTouchTarget != null) {
boolean syntheticEvent = false;
...
for (TouchTarget target = mFirstTouchTarget; target != null; target = target.next) {
resetCancelNextUpFlag(target.child);
//分发cancel 事件
dispatchTransformedTouchEvent(event, true, target.child, target.pointerIdBits);
}
...
}
}
可以看出，最终调用了dispatchTransformedTouchEvent(xx)发送cancel事件。
按照正常流程来说，因为收到Down事件时，mFirstTouchTarget==null，因此此处通常不会执行发送cancel事件。
(2)
resetCancelNextUpFlag(xx)方法，顾名思义：重置取消标记。
#ViewGroup.java
private static boolean resetCancelNextUpFlag(@NonNull View view) {
if ((view.mPrivateFlags & PFLAG_CANCEL_NEXT_UP_EVENT) != 0) {
//之前设置过取消标记，此处重置
view.mPrivateFlags &= ~PFLAG_CANCEL_NEXT_UP_EVENT;
//返回true
return true;
}
return false;
}
PFLAG_CANCEL_NEXT_UP_EVENT 标记的作用是记录View是否被临时移出Window。比如View.performButtonActionOnTouchDown(xx)处理鼠标相关的问题，这个值平时也很少用到。
既要判断resetCancelNextUpFlag(xx)返回值，也要判断intercepted值：ViewGroup是否拦截并消费了事件。
若是两者之一有一者满足，则认为需要发送cancel事件。
(3)
(2)点仅仅是判断是否需要发送cancel事件，真正发送事件的方法是dispatchTransformedTouchEvent(xx)：
#ViewGroup.java
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) {
//将event 事件设置为cancel
event.setAction(MotionEvent.ACTION_CANCEL);
if (child == null) {
//ViewGroup自己消费
handled = super.dispatchTouchEvent(event);
} else {
//子View(子布局) 消费
handled = child.dispatchTouchEvent(event);
}
//处理后，将action重置
event.setAction(oldAction);
return handled;
}
//正常事件流程
}
结合上述3点可知，在ViewGroup.dispatchTouchEvent(xx)里发送cancel事件，常用的判断即是：
1、ViewGroup是否拦截消费了事件，若是则给子View(子布局)发送cancel事件。
2、发送给子View cancel事件后，后续的事件将不会发给子View。
那么除了ViewGroup 拦截消费事件，还有哪些地方触发发送cancel 事件呢？
ViewGroup 移除View
想象一种场景：
手指在View 上滑动，在此过程中，View 被移出ViewGroup。
来看ViewGroup.remove(xx)的实现：
removeView(view)-->removeViewInternal(view)-->removeViewInternal(index, view)
核心功能在removeViewInternal(index, view) 实现：
#ViewGroup.java
private void removeViewInternal(int index, View view) {
...
view.clearAccessibilityFocus();
//发送cancel 事件
cancelTouchTarget(view);
cancelHoverTarget(view);
if (view.getAnimation() != null ||
(mTransitioningViews != null && mTransitioningViews.contains(view))) {
addDisappearingView(view);
} else if (view.mAttachInfo != null) {
//调用detached
view.dispatchDetachedFromWindow();
}
...
}
可以看出，当View 从ViewGroup 移除后，若是它已经消费了事件，那么将会收到cancel 事件。
使用如下代码测试：
viewGroup.postDelayed(new Runnable() {
@Override
public void run() {
viewGroup.removeAllViews();
}
}, 3000);
手指按在View 上，3s后将View 从ViewGroup里移除。
Window 移除View
当调用WindowManager.removew(view)方法时，最终会调用到ViewGroup.dispatchDetachedFromWindow(xx)方法：
##ViewGroup.java
void dispatchDetachedFromWindow() {
//发送 cancel 事件
cancelAndClearTouchTargets(null);
...
}
使用如下代码测试：
viewGroup.postDelayed(new Runnable() {
@Override
public void run() {
getWindowManager().removeView(getWindow().getDecorView());
}
}, 3000);
手指按在View 上，3s后将View 从Window里移除。
可以看出，触发发送cancel 事件常见的有三种场景：
2、手指离开当前View时事件处理
如上图，手指在View 上按下，View消费了Down事件，此时手指滑出View，并在ViewGroup上滑动，那么整个事件分发是怎么样的呢？
通常来说，单指滑动的时候事件分为三个过程：
1、按下事件--->Down 事件。
2、滑动事件--->Move 事件。
3、抬起事件--->Up 事件。
从事件分发流程可知，当手指按下的时候：
1、若View 消费了Down事件，那么之后的Move、Up事件都会传递给View(不考虑ViewGroup拦截情况)。
2、手指在滑动的过程中，滑出了View，在ViewGroup上滑动，此时Move、Up事件依然会传递给View。
而View 本身是支持响应长按与点击动作的，若是当前手指还在View 上，那么很好理解，若是当前手指已经滑动到ViewGroup上，长按与点击动作如何响应呢？
从直觉上来说，应该不响应的。
如何做到不响应的？理论上来说：因为可以知道每个MotionEvent的触摸坐标，通过该坐标就可以得知当前MotionEvent是否落在目标View 上，若坐标不在目标View(消费Down事件的View)，那么就不响应长按与点击动作。
来看看源码里是如何处理的：
#View.java
public boolean onTouchEvent(MotionEvent event) {
//点击的坐标
final float x = event.getX();
final float y = event.getY();
...
if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
switch (action) {
case MotionEvent.ACTION_UP:
...
boolean prepressed = (mPrivateFlags & PFLAG_PREPRESSED) != 0;
if ((mPrivateFlags & PFLAG_PRESSED) != 0 || prepressed) {
//处在按下状态
...
//没有发生长按动作
if (!mHasPerformedLongPress && !mIgnoreNextUpEvent) {
//移除长按动作
removeLongPressCallback();
if (!focusTaken) {
if (mPerformClick == null) {
mPerformClick = new PerformClick();
}
//响应点击动作
if (!post(mPerformClick)) {
performClickInternal();
}
}
}
...
}
mIgnoreNextUpEvent = false;
break;
case MotionEvent.ACTION_DOWN:
...
break;
case MotionEvent.ACTION_CANCEL:
if (clickable) {
//重置按下状态
setPressed(false);
}
//移除延时单击动作
removeTapCallback();
//移除长按动作
removeLongPressCallback();
...
break;
case MotionEvent.ACTION_MOVE:
...
if (!pointInView(x, y, touchSlop)) {
//移除延时单击动作
removeTapCallback();
//移除长按动作
removeLongPressCallback();
if ((mPrivateFlags & PFLAG_PRESSED) != 0) {
////重置按下状态
setPressed(false);
}
mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN;
}
...
break;
}
return true;
}
return false;
}
A、正常响应点击/长按动作
对于正常情况来说，比如上面的对ACTION_UP 事件的处理。
先说单击动作：
1、首先需要当前View 处在按下状态。
2、其次长按动作没有发生。
再说长按动作：
长按动作是个延时执行任务，若是没被取消，则终将会被执行。
B、移动时处理点击/长按动作
由A点可知，若是手指没有滑出当前View，那么点击与长按按照正常流程走。若是滑动出了View，在ACTION_MOVE事件处理逻辑如下：
1、一直在监测当前的事件点坐标是否还在目标View里，若不在，则进行第2步处理。
2、发现事件点坐标已经不在目标View里，于是移除延时单击动作、移除长按动作、重置按下状态。
3、当目标View收到ACTION_UP事件后，发现按下状态为false，于是不响应单击动作，而延时长按动作已经被取消了，也不会响应长按动作。
C、总结
1、一旦View消费了Down事件，那么后续的Move、Up、Cancel等事件都会交给它处理(ViewGroup没有拦截消费的前提下)
2、即使滑动超出了当前View的范围，它依然能够收到上述事件。
3、若是最终的Up事件不是发生在当前View之上，那么该View不响应单击与长按动作。
4、若是收到Cancel事件，那么View就不会再响应单击与长按动作，并且后续的事件将不会再收到。
3、手指离开屏幕时事件处理
当手指滑动离开屏幕时，如下图：
其处理逻辑与手指离开当前View时事件处理是一致的。
本文基于Android 10。
各种事件Demo请移步：相关代码演示
