Android动态响应怎么关闭,Android 事件分发中你可能忽略掉的点！

原标题：Android 事件分发中你可能忽略掉的点！

本文作者

作者： fishforest

链接：

https://www.jianshu.com/p/0a8ec531d5fb

前言

对于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

publicboolean dispatchTouchEvent(MotionEvent ev) {

boolean handled = false;

if(onFilterTouchEventForSecurity(ev)) {

finalint action = ev.getAction;

finalint actionMasked = action & MotionEvent.ACTION_MASK;

// Handle an initial down.

if(actionMasked == MotionEvent.ACTION_DOWN) {

//首次Down事件处理------------>(1)

cancelAndClearTouchTargets(ev);

resetTouchState;

}

//ViewGroup是否拦截事件

...

//是否发送取消事件

finalboolean 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) {

//遍历消费链

finalTouchTarget next = target.next;

if(alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {

//已经消费过，直接返回

handled = true;

} else{

//判断是否需要发送取消事件------------>(2)

finalboolean 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;

}

}

...

}

...

returnhandled;

}

上面列出了三个重点，将一一分析：

(1)

主要是 cancelAndClearTouchTargets(xx)方法：

#ViewGroup.java

privatevoidcancelAndClearTouchTargets( 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

privatestaticboolean resetCancelNextUpFlag( @NonNull View view){

if((view.mPrivateFlags & PFLAG_CANCEL_NEXT_UP_EVENT) != 0) {

//之前设置过取消标记，此处重置

view.mPrivateFlags &= ~PFLAG_CANCEL_NEXT_UP_EVENT;

//返回true

returntrue;

}

returnfalse;

}

PFLAG_CANCEL_NEXT_UP_EVENT标记的作用是记录View是否被临时移出Window。比如View.performButtonActionOnTouchDown(xx)处理鼠标相关的问题，这个值平时也很少用到。

既要判断resetCancelNextUpFlag(xx)返回值，也要判断intercepted值：ViewGroup是否拦截并消费了事件。

若是两者之一有一者满足，则认为需要发送 cancel事件。

(3)

(2)点仅仅是判断是否需要发送 cancel事件，真正发送事件的方法是dispatchTransformedTouchEvent(xx)：

#ViewGroup.java

privateboolean dispatchTransformedTouchEvent( MotionEvent event, boolean cancel,

View child, intdesiredPointerIdBits ) {

final boolean handled;

final intoldAction = 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);

returnhandled;

}

//正常事件流程

}

结合上述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

privatevoidremoveViewInternal( intindex, View view){

...

view.clearAccessibilityFocus;

//发送cancel 事件

cancelTouchTarget(view);

cancelHoverTarget(view);

if(view.getAnimation != null||

(mTransitioningViews != null&& mTransitioningViews.contains(view))) {

addDisappearingView(view);

} elseif(view.mAttachInfo != null) {

//调用detached

view.dispatchDetachedFromWindow;

}

...

}

可以看出，当View 从ViewGroup 移除后，若是它已经消费了事件，那么将会收到cancel事件。

使用如下代码测试：

viewGroup.postDelayed( newRunnable {

@Override

publicvoidrun{

viewGroup.removeAllViews;

}

}, 3000);

手指按在View 上，3s后将View 从ViewGroup里移除。

Window 移除View

当调用WindowManager.removew(view)方法时，最终会调用到ViewGroup.dispatchDetachedFromWindow(xx)方法：

##ViewGroup.java

voiddispatchDetachedFromWindow{

//发送 cancel 事件

cancelAndClearTouchTargets( null);

...

}

使用如下代码测试：

viewGroup.postDelayed( newRunnable {

@Override

publicvoidrun{

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.java

publicboolean onTouchEvent( MotionEvent event){

//点击的坐标

final floatx = event.getX;

final floaty = event.getY;

...

if(clickable || (viewFlags & TOOLTIP) == TOOLTIP) {

switch(action) {

caseMotionEvent.ACTION_UP:

...

boolean prepressed = (mPrivateFlags & PFLAG_PREPRESSED) != 0;

if((mPrivateFlags & PFLAG_PRESSED) != 0|| prepressed) {

//处在按下状态

...

//没有发生长按动作

if(!mHasPerformedLongPress && !mIgnoreNextUpEvent) {

//移除长按动作

removeLongPressCallback;

if(!focusTaken) {

if(mPerformClick == null) {

mPerformClick = newPerformClick;

}

//响应点击动作

if(!post(mPerformClick)) {

performClickInternal;

}

}

}

...

}

mIgnoreNextUpEvent = false;

break;

caseMotionEvent.ACTION_DOWN:

...

break;

caseMotionEvent.ACTION_CANCEL:

if(clickable) {

//重置按下状态

setPressed( false);

}

//移除延时单击动作

removeTapCallback;

//移除长按动作

removeLongPressCallback;

...

break;

caseMotionEvent.ACTION_MOVE:

...

if(!pointInView(x, y, touchSlop)) {

//移除延时单击动作

removeTapCallback;

//移除长按动作

removeLongPressCallback;

if((mPrivateFlags & PFLAG_PRESSED) != 0) {

重置按下状态

setPressed( false);

}

mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN;

}

...

break;

}

returntrue;

}

returnfalse;

}

A、正常响应点击/长按动作

对于正常情况来说，比如上面的对ACTION_UP事件的处理。

先说单击动作：

1、首先需要当前View 处在按下状态。

B、移动时处理点击/长按动作

1、一直在监测当前的事件点坐标是否还在目标View里，若不在，则进行第2步处理。

C、总结

1、一旦View消费了Down事件，那么后续的Move、Up、Cancel等事件都会交给它处理。(ViewGroup没有拦截消费的前提下)

2、即使滑动超出了当前View的范围，它依然能够收到上述事件。3

手指离开屏幕时事件处理

当手指滑动离开屏幕时，如下图：

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

本文基于Android 10。

各种事件Demo请移步： 相关代码演示

https://github.com/fishforest/AndroidDemo

最后推荐一下我做的网站，玩Android: wanandroid.com，包含详尽的知识体系、好用的工具，还有本公众号文章合集，欢迎体验和收藏！

开启B站少女心，探究APP换肤

不需要权限的悬浮窗方案了解一下~

引入Jetpack架构后，你的App会发生哪些变化？

如果你想要跟大家分享你的文章，欢迎投稿~

┏(＾0＾)┛明天见！返回搜狐，查看更多

责任编辑：