Android MotionEvent 之ACTION_CANCEL

Android MotionEvent 之ACTION_CANCEL前言 对于Android MotionEvent,我们平时大多关注的是ACTION_DOWN、ACTION_UP、ACTION_MOVE,本篇将重点分析ACTION_CANCEL 产生的原因及其滑动事

前言

对于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)里。

image.png

先看看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、手指离开屏幕时事件处理

当手指滑动离开屏幕时,如下图:

image

其处理逻辑与手指离开当前View时事件处理是一致的。

本文基于Android 10。 各种事件Demo请移步:相关代码演示

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

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

今天的文章Android MotionEvent 之ACTION_CANCEL分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/14889.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注