前言

对于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请移步：相关代码演示

您若喜欢，请点赞、关注，您的鼓励是我前进的动力

持续更新中，和我一起步步为营系统、深入学习Android/Java