您的位置:首页 > 移动开发 > Android开发

Android事件分发机制源码分析

2017-02-23 15:47 495 查看

Android事件分发机制源码分析

说到Android的事件机制,相信很多人都不陌生。详细了解事件在Android中传递的规则,使得我们能够更加清楚事件处理逻辑,更好的处理滑动冲突之类复杂的问题。本文主要分析事件在各个View层级中的分发规则,从Activity接收到事件到一个事件被成功消费的详细过程。

Activity的分发过程

当有触摸事件发生在一个Activity时,这个事件首先会被传递给Activity,即调用Activity的dispatchTouchEvent方法,然后开始事件的分发过程。现在我们可以知道,如果我们想要拦截所有的事件,那么可以通过重写Activity的dispatchTouchEvent方法实现。下面我们看一下Activity的dispatchTouchEvent方法:

public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}


首先,如果是ACTION_DOWN事件的话,会调用onUserInteraction方法,该方法在Activity中实现为一个空方法,可以通过覆盖该方法在一个事件序列到来时做一些事情。getWindow方法返回该Activity方法所关联的Window对象,Window是一个抽象类,而它的具体实现是PhoneWindow(在Activity类的attach方法中可以看到:mWindow = new PhoneWindow(this, window);)。因此,我们可以知道,Activity只是简单的将事件交给Window的superDispatchTouchEvent方法处理,如果Window未能成功处理该事件,则交给Activity自身的onTouchEvent方法处理。然后看一下Window的处理过程。

Window的分发过程

首先看一下PhoneWindow中superDispatchTouchEvent方法的实现:

@Override
public boolean superDispatchTouchEvent(KeyEvent event) {
return mDecor.superDispatchTouchEvent(event);
}


PhoneWindow的superDispatchTouchEvent方法很简单,就是直接将事件交给mDecor。而mDecor正是DecorView(实现为PhoneWindow中的内部类)的实例,即是Activity 中的顶级View,它是FrameLayout的子类,而它的superDispatchTouchEvent方法也直接调用了super.dispatchTouchEvent方法。而FrameLayout、LinearLayout、RelativeLayout等布局管理器的事件分发都继承自ViewGroup,因此,此时,事件交由ViewGroup处理。下面我们看一下ViewGroup如何分发事件。

ViewGroup的分发过程

ViewGroup中的dispatchTouchEvent方法比较长,有二百多行,因此这里将忽略逻辑不相关部分,按照事件分发逻辑逐步进行分析。

我们都知道,Android中以一个事件序列为单位进行处理,一个事件序列以ACTION_DOWN事件开始,以ACTION_UP事件结束,中间会有数个ACTION_MOVE事件。现在,我们看一下当一个事件到来时ViewGroup的处理逻辑:

if (actionMasked == MotionEvent.ACTION_DOWN) {
// Throw away all previous state when starting a new touch gesture.
// The framework may have dropped the up or cancel event for the previous gesture
// due to an app switch, ANR, or some other state change.
cancelAndClearTouchTargets(ev);
resetTouchState();
}


首先,如果到来的事件是ACTION_DOWN,也即当一个新的事件序列到来时,会执行初始化操作,清除上个事件序列的touchTarget及其状态等。如果不是一个新的事件序列(即到来的不是ACTION_DOWN事件),就跳过此操作,然后开始事件分发:

// Check for interception.
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
intercepted = onInterceptTouchEvent(ev);
ev.setAction(action); // restore action in case it was changed
} else {
intercepted = false;
}
} else {
// There are no touch targets and this action is not an initial down
// so this view group continues to intercept touches.
intercepted = true;
}


在分发的过程中,首先ViewGroup会判断是否拦截该事件(拦截则不再向下层View分发)。ViewGroup的onInterceptTouchEvent默认返回false,因此当actionMasked == MotionEvent.ACTION_DOWN或者mFirstTouchTarget != null时,ViewGroup不拦截该事件,否则intercepted = true。更进一步,也即如果一个新的事件序列到来,或者该事件序列已经被子View处理(也即mFirstTouchTarget != null)时,ViewGroup就不拦截该事件,将该事件向下层分发,否则拦截该事件(因为没有子View处理该事件序列,因此无需继续分发),交由ViewGroup来处理。然后看一下当ViewGroup不拦截事件时的处理逻辑:

final View[] children = mChildren;
for (int i = childrenCount - 1; i >= 0; i--) {
final int childIndex = getAndVerifyPreorderedIndex(
childrenCount, i, customOrder);
final View child = getAndVerifyPreorderedView(
preorderedList, children, childIndex);

// If there is a view that has accessibility focus we want it
// to get the event first and if not handled we will perform a
// normal dispatch. We may do a double iteration but this is
// safer given the timeframe.
if (childWithAccessibilityFocus != null) {
if (childWithAccessibilityFocus != child) {
continue;
}
childWithAccessibilityFocus = null;
i = childrenCount - 1;
}

if (!canViewReceivePointerEvents(child)
|| !isTransformedTouchPointInView(x, y, child, null)) {
ev.setTargetAccessibilityFocus(false);
continue;
}

newTouchTarget = getTouchTarget(child);
if (newTouchTarget != null) {
// Child is already receiving touch within its bounds.
// Give it the new pointer in addition to the ones it is handling.
newTouchTarget.pointerIdBits |= idBitsToAssign;
break;
}

resetCancelNextUpFlag(child);
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
// Child wants to receive touch within its bounds.
mLastTouchDownTime = ev.getDownTime();
if (preorderedList != null) {
// childIndex points into presorted list, find original index
for (int j = 0; j < childrenCount; j++) {
if (children[childIndex] == mChildren[j]) {
mLastTouchDownIndex = j;
break;
}
}
} else {
mLastTouchDownIndex = childIndex;
}
mLastTouchDownX = ev.getX();
mLastTouchDownY = ev.getY();
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
break;
}

// The accessibility focus didn't handle the event, so clear
// the flag and do a normal dispatch to all children.
ev.setTargetAccessibilityFocus(false);
}


上面的代码虽然看起来比较长,但是逻辑还是比较清晰的,需要注意的是,在此循环外有一个if判断:

if ( actionMasked == MotionEvent.ACTION_DOWN
|| (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
|| actionMasked == MotionEvent.ACTION_HOVER_MOVE )


不考虑鼠标和多指事件,那么只有ACTION_DOWN事件到来时才会进入上述循环进行分发,那么也就是说,因为进入循环的一定是ACTION_DOWN事件,此时已经清除了touchTargets,所以进入上述循环时getTouchTarget方法一定返回null,那么分发过程如下:

遍历该ViewGroup的所有子View,然后判断该子View是否能接收该事件(通过判断该View是否可见或者正在播放动画和该事件是否落在该View所在区域两个条件来决定),不满足条件则执行continue继续该循环。然后调用dispatchTransformedTouchEvent方法将事件依次分发给子View,寻找新的touchTarget。如果有子View处理了该事件,则通过addTouchTarget将新的target加到touchTargets链中,并赋值mFirstTouchTarget,然后结束循环。

if (mFirstTouchTarget == null) {
// No touch targets so treat this as an ordinary view.
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
}


现在看一下mFirstTouchTarget == null时的处理。此时有两种情况,第一种:ViewGroup拦截了该事件,也即该事件不是ACTION_DOWN,并且mFirstTouchTarget == null,也就是说该事件序列的ACTION_DOWN事件没有被子View处理。第二种:该事件是ACTION_DOWN事件,并且该事件没有成功分发给子View,那么mFirstTouchTarget也会等于null。此时,调用dispatchTransformedTouchEvent方法将事件交由自己来处理(注意:此时第三个参数为null表示自己处理)。

dispatchTransformedTouchEvent方法的一部分如下:

if (child == null) {
handled = super.dispatchTouchEvent(event);
} else {
final float offsetX = mScrollX - child.mLeft;
final float offsetY = mScrollY - child.mTop;
event.offsetLocation(offsetX, offsetY);

handled = child.dispatchTouchEvent(event);

event.offsetLocation(-offsetX, -offsetY);
}
return handled;


上面这部分代码展示了dispatchTransformedTouchEvent方法的主要逻辑,也即如果child(该方法的第三个参数)为null,则调用父类(也即View类)的dispatchTouchEvent方法, 否则调用child的dispatchTouchEvent方法,将事件向下传递。如果child是一个ViewGroup,则将再次进行上述分发过程,而如果child只是一个View(此处的View不包含Viewgroup),则交给View类的dispatchTouchEvent处理。

如果到来的不是ACTION_DOWN事件,而且没有被拦截,那么此时一定有子View处理了该事件,那么就直接将事件分发给该子View,该子View保存在以mFirstTouchTarget为首的TouchTarget链表中:

TouchTarget predecessor = null;
TouchTarget target = mFirstTouchTarget;
while (target != null) {
final TouchTarget next = target.next;
if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {
handled = true;
} else {
final boolean cancelChild = resetCancelNextUpFlag(target.child)
|| intercepted;
if (dispatchTransformedTouchEvent(ev, cancelChild,
target.child, target.pointerIdBits)) {
handled = true;
}
if (cancelChild) {
if (predecessor == null) {
mFirstTouchTarget = next;
} else {
predecessor.next = next;
}
target.recycle();
target = next;
continue;
}
}
predecessor = target;
target = next;
}


至此,ViewGroup对事件的分发过程就结束了,如果子View仍然是ViewGroup,那么就由子View重复上述过程,如果子View不是ViewGroup,那么就进入View(此处的View不包括ViewGroup)对事件的处理过程。

View的分发过程

由于View不包含子View,所以不用继续分发,收到事件时自己处理就好了。因此View中也没有事件拦截逻辑,也不包含onInterceptTouchEvent方法,当有事件分发给View时,该View就要处理该事件(但不一定成功处理)。View类的dispatchTouchEvent方法的处理逻辑如下:

ListenerInfo li = mListenerInfo;
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
result = true;
}

if (!result && onTouchEvent(event)) {
result = true;
}


首先,View检查是否设置了OnTouchListener,如果设置了OnTouchListener则执行它的onTouch方法,如果OnTouchListener返回了true,则处理结束。否则执行View的onTouchEvent方法。由上可见,OnTouchListener的优先级比onTouchEvent高,并且如果OnTouchListener返回了true,则不会再执行onTouchEvent方法。

View类的onTouchEvent方法里会根据不同的事件进行相应的处理,比如在接收到ACTION_UP事件时通过performClick来完成OnClickListener(如果设置的有的话)的onClick等。需要注意的是,如果一个View被setEnable(false),那么该View的OnTouchListener、onTouchEvent都不会被调用。但是,只要该View的clickable==true或者longClickable==true,那么该View都会消耗该事件,从onTouchEvent方法中位于头部的以下代码可以看出:

if ((viewFlags & ENABLED_MASK) == DISABLED) {
if (action == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) {
setPressed(false);
}
// A disabled view that is clickable still consumes the touch
// events, it just doesn't respond to them.
return (((viewFlags & CLICKABLE) == CLICKABLE
|| (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)
|| (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE);
}


规律总结

通过上面的分析,我们能总结以下规律:

ViewGroup一旦拦截事件,那么整个事件序列(如果还能传递给它)都将被拦截;

如果一个View没有处理ACTION_DOWN事件,那么该事件序列的后续事件都不会交给它处理;

如果一个View处理了ACTION_DOWN事件,但没有处理后续事件,那么该事件序列的后续事件将会最终交由Activity处理;

View的onTouchEvent默认都会消耗事件,除非它的clickable和longClickable同时为false。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息