一 概述
Android View 虽然不是四大组件,但其并不比四大组件的地位低。而 View 的核心知识点:事件分发机制则是不少刚入门同学的拦路虎。
ScrollView 嵌套 RecyclerView (或者 ListView) 的滑动冲突,这种老大难的问题的理论基础就是事件分发机制。
事件分发机制面试也会经常被提及,如果你能掌握其原理,并跟面试官深入的灵魂交流一下,那么一定会让面试官对你印象深刻,抛出爱的橄榄枝,想想都有点小激动。
接下来,就让我们一起从浅入深,由表及里的去研究下 View 的事件分发机制,进而全方位,立体式,去弄懂这个神秘的机制吧。
二 MotionEvent 事件
我们对屏幕的点击,滑动,抬起等一系的动作都是由一个一个 MotionEvent 对象组成的。根据不同动作,主要有以下三种事件类型:
- ACTION_DOWN:手指刚接触屏幕,按下去的那一瞬间产生该事件
- ACTION_MOVE:手指在屏幕上移动时候产生该事件
- ACTION_UP:手指从屏幕上松开的瞬间产生该事件
从 ACTION_DOWN 开始到 ACTION_UP 结束我们称之为一个事件序列
正常情况下,无论你手指在屏幕上有多么骚的操作,最终呈现在 MotionEvent 上来讲无外乎下面两种:
- 点击后抬起,也就是单击操作:ACTION_DOWN -> ACTION_UP
- 点击后再风骚的滑动一段距离,再抬起:ACTION_DOWN -> ACTION_MOVE -> … -> ACTION_MOVE -> ACTION_UP
public class MotionEventActivity extends BaseActivity {
private Button mButton;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_motion_event);
mButton = (Button) findViewById(R.id.button);
mButton.setOnTouchListener(new View.OnTouchListener() {
@Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
e("MotionEvent: ACTION_DOWN");
break;
case MotionEvent.ACTION_MOVE:
e("MotionEvent: ACTION_MOVE");
break;
case MotionEvent.ACTION_UP:
e("MotionEvent: ACTION_UP");
break;
}
return false;
}
});
}
public void click(View v) {
e("点击了按钮");
}
}
当我们单击按钮:
当我们在按钮上滑动:
细心的同学一定发现了我们常用的按钮的 onclick 事件都是在 ACTION_UP 以后才被调用的。这和 View 的事件分发机制是不是有某种不可告人的关系呢?!
上面代码我们给 button 设置了 OnTouchListener 并重写了 onTouch 方法,方法返回值默认为 false。如果这里我们返回 true,那么你会发现 onclick 方法不执行了!!!What?
这些随着我们的深入探讨,结论就会浮出水面!针对 MotionEvent,我们先说这么多。
三 MotionEvent 事件分发
当一个 MotionEvent 产生了以后,就是你的手指在屏幕上做一系列动作的时候,系统需要把这一系列的 MotionEvent 分发给一个具体的 View。我们重点需要了解这个分发的过程,那么系统是如何去判断这个事件要给哪个 View,也就是说是如何进行分发的呢?
事件分发需要 View 的三个重要方法来共同完成:
- public boolean dispatchTouchEvent(MotionEvent event)
事件分发的重要方法。那么很明显,如果一个 MotionEvent 传递给了 View,那么 dispatchTouchEvent 方法一定会被调用!
返回值:表示是否消费了当前事件。可能是 View 本身的 onTouchEvent 方法消费,也可能是子 View 的 dispatchTouchEvent 方法中消费。返回 true 表示事件被消费,本次的事件终止。返回 false 表示 View 以及子 View 均没有消费事件,将调用父 View 的 onTouchEvent 方法 - public boolean onInterceptTouchEvent(MotionEvent ev)
事件拦截,当一个 ViewGroup 在接到 MotionEvent 事件序列时候,首先会调用此方法判断是否需要拦截。特别注意,这是 ViewGroup 特有的方法,View 并没有拦截方法
返回值:是否拦截事件传递,返回 true 表示拦截了事件,那么事件将不再向下分发,而是调用 View 本身的 onTouchEvent 方法。返回 false 表示不做拦截,事件将向下分发到子 View 的 dispatchTouchEvent 方法 - public boolean onTouchEvent(MotionEvent ev)
真正对 MotionEvent 进行处理或者说消费的方法。在 dispatchTouchEvent 进行调用。
返回值:返回 true 表示事件被消费,本次的事件终止。返回 false 表示事件没有被消费,将调用父 View 的 onTouchEvent 方法
上面的三个方法可以用以下的伪代码来表示其之间的关系。
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean consume = false; // 事件是否被消费
if (onInterceptTouchEvent(ev)) { // 调用 onInterceptTouchEvent 判断是否拦截事件
consume = onTouchEvent(ev);// 如果拦截则调用自身的 onTouchEvent 方法
} else {
// 不拦截调用子 View 的 dispatchTouchEvent 方法
consume = child.dispatchTouchEvent(ev);
}
// 返回值表示事件是否被消费,true 事件终止,false 调用父 View 的 onTouchEvent 方法
return consume;
}
通过上面的介绍,相信我们已经初步了解了 View 的事件分发的机制。
接下来我们来看一下 View 和 ViewGroup 在事件分发的时候有什么不一样的地方:
ViewGroup 是 View 的子类,也就是说 ViewGroup 本身就是一个 View,但是它可以包含子 View(当然子 View 也可能是一个 ViewGroup),所以不难理解,上面所展示的伪代码表示的是 ViewGroup 处理事件分发的流程。而 View 本身是不存在分发,所以也没有拦截方法(onInterceptTouchEvent),它只能在 onTouchEvent 方法中进行处理消费或者不消费。
上面结论先简单的理解一下,通过下面的流程图,会更加清晰的帮助我们梳理事件分发机制
可以看出事件的传递过程都是从父 View 到子 View。
但是这里有三点需要特别强调一下
- 子 View 可以通过 requestDisallowInterceptTouchEvent 方法干预父 View 的事件分发过程(ACTION_DOWN 事件除外),而这就是我们处理滑动冲突常用的关键方法。关于滑动冲突的处理,我们在 Android View滑动冲突处理 中有专门分析,这里就不做过多解释
- 对于 View 而言,如果设置了onTouchListener,那么 OnTouchListener 方法中的 onTouch 方法会被回调。onTouch 方法返回 true,则 onTouchEvent 方法不会被调用(onClick 事件是在 onTouchEvent 中调用的)所以三者优先级是 onTouch -> onTouchEvent -> onClick
- View 的 onTouchEvent 方法默认都会消费掉事件(返回 true),除非它是不可点击的(clickable 和 longClickable 同时为 false),View 的 longClickable 默认为 false,clickable 需要区分情况,如 Button 的 clickable 默认为 true,而 TextView 的 clickable 默认为 false
四 View 事件分发源码
作为程序猿,最不想看的但是也不得不去看的就是源码!所谓知其然也要知其所以然,神秘的大佬曾经说过提高的方法就是READ THE FUCKING CODE!那么我们就带大家来看一下 Android 对事件分发的处理方式,看是否与我们上面说的结论一致!(为方便阅读,以下都只给出了关键代码并额外添加上一些简单注释,全部代码请自行阅读源码)
点击事件产生后,最先传递到当前的 Activity,由 Acivity 的 dispatchTouchEvent 方法来对事件进行分发。那么很明显我们先看 Activity 的 dispatchTouchEvent 方法:
4.1 Activity.dispatchTouchEvent
Activity.java
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) { // 事件分发并返回结果
return true; // 事件被消费
}
return onTouchEvent(ev); // 没有 View 可以处理,调用 Activity onTouchEvent 方法
}
通过上面的代码我们可以发现,事件会给 Activity 附属的 Window 进行分发。如果返回 true,那么事件被消费。如果返回 false 表示事件发下去却没有 View 可以进行处理,则最后 return Activity 自己的 onTouchEvent 方法。
跟进 getWindow().superDispatchTouchEvent(ev) 方法发现是 Window 类当中的一个抽象方法
Window.java
/**
* Abstract base class for a top-level window look and behavior policy. An
* instance of this class should be used as the top-level view added to the
* window manager. It provides standard UI policies such as a background, title
* area, default key processing, etc.
*
* <p>The only existing implementation of this abstract class is
* android.view.PhoneWindow, which you should instantiate when needing a
* Window.
*/
Class Window:
// 抽象方法,需要看 PhoneWindow 的实现
public abstract boolean superDispatchTouchEvent(MotionEvent event);
我们知道,Window 的唯一实现类是 PhoneWindow。那么去看 PhoneWindow 对应的代码。
class PhoneWindow
// This is the top-level view of the window, containing the window decor.
private DecorView mDecor;
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
PhoneWindow 又调用了 DecorView 的 superDispatchTouchEvent 方法。而这个 DecorView 就是 Window 的顶级 View,我们通过 setContentView 设置的 View 是它的子 View(Activity 的 setContentView,最终是调用 PhoneWindow 的 setContentView,有兴趣同学可以去阅读,这块不是我们讨论的重点)
到这里事件已经被传递到我们的顶级 View 中,一般是 ViewGroup。
那么接下来重点将放到 ViewGroup 的 dispatchTouchEvent 方法中。我们之前说过,事件到达 View 会调用 dispatchTouchEvent 方法,如果 View 是 ViewGroup 那么会先判断是否拦截该事件。
4.2 ViewGroup.dispatchTouchEvent
ViewGroup.java
public boolean dispatchTouchEvent(MotionEvent ev) {
......
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// Handle an initial down.
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);
// 清除 FLAG_DISALLOW_INTERCEPT 设置,并且 mFirstTouchTarget 设置为 null
resetTouchState();
}
// Check for interception.
final boolean intercepted; // 是否拦截事件
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
// FLAG_DISALLOW_INTERCEPT 是子 View 通过
// requestDisallowInterceptTouchEvent 方法进行设置的
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
// 调用 onInterceptTouchEvent 方法判断是否需要拦截
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;
}
......
}
我们前面说过子 View 可以通过 requestDisallowInterceptTouchEvent 方法干预父 View 的事件分发过程(ACTION_DOWN 事件除外)
为什么 ACTION_DOWN 除外?通过上述代码我们不难发现。如果事件是 ACTION_DOWN,那么 ViewGroup 会重置 FLAG_DISALLOW_INTERCEPT 标志位,并且将 mFirstTouchTarget 设置为 null。对于 mFirstTouchTarget 我们可以先这么理解,如果事件由子 View 去处理时,mFirstTouchTarget 会被赋值并指向子 View。
所以当事件为 ACTION_DOWN 或者 mFirstTouchTarget != null(即事件由子 View 处理)时会进行拦截判断。具体规则是如果子 View 设置了 FLAG_DISALLOW_INTERCEPT 标志位,那么 intercepted =false。否则调用 onInterceptTouchEvent 方法。
如果事件不为 ACTION_DOWN 且事件为 ViewGroup 本身处理(即 mFirstTouchTarget ==null )那么 intercepted = true,很显然事件已经交给自己处理根本没必要再调用 onInterceptTouchEvent 去判断是否拦截。
结论:
当 ViewGroup 决定拦截事件后,后续事件将默认交给它处理并且不会再调用 onInterceptTouchEvent 方法来判断是否拦截。子 View 可以通过设置 FLAG_DISALLOW_INTERCEPT 标志位来不让 ViewGroup 拦截除 ACTION_DOWN 以外的事件。
我们知道 onInterceptTouchEvent 并非每次都会被调用。如果要处理所有的点击事件那么需要选择 dispatchTouchEvent 方法,而 FLAG_DISALLOW_INTERCEPT 标志位可以帮助我们去有效的处理滑动冲突。
如果 ViewGroup 不拦截事件,那么事件将下发给子 View 进行处理。
ViewGroup.java
public boolean dispatchTouchEvent(MotionEvent ev) {
final View[] children = mChildren;
// 对子 View 进行遍历
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;
}
// 判断1,View 可见并且没有播放动画。2,点击事件的坐标落在 View 的范围内
// 如果上述两个条件有一项不满足则 continue 继续循环下一个 View
if (!canViewReceivePointerEvents(child)
|| !isTransformedTouchPointInView(x, y, child, null)) {
ev.setTargetAccessibilityFocus(false);
continue;
}
newTouchTarget = getTouchTarget(child);
// 如果有子 View 处理即 newTouchTarget 不为 null 则跳出循环。
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);
// dispatchTransformedTouchEvent 第三个参数 child 这里不为 null
// 实际调用的是 child 的 dispatchTouchEvent 方法
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();
// 当 child 处理了点击事件,那么会设置 mFirstTouchTarget,并在 addTouchTarget 中被赋值
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
// 子 View 处理了事件,然后就跳出了 for 循环
break;
}
}
}
上面代码是将事件分发给子 View 的关键代码,需要关注的地方都加了注释。分发过程首先需要遍历 ViewGroup 的所有子 View,可以接收点击事件的 View 需要满足下面条件:
- 如果 View 可见并且没有播放动画 canViewReceivePointerEvents 方法判断
/**
* Returns true if a child view can receive pointer events.
* @hide
*/
private static boolean canViewReceivePointerEvents(@NonNull View child) {
return (child.mViewFlags & VISIBILITY_MASK) == VISIBLE
|| child.getAnimation() != null;
}
- 点击事件的坐标落在 View 的范围内 isTransformedTouchPointInView 方法判断
/**
* Returns true if a child view contains the specified point when transformed
* into its coordinate space.
* Child must not be null.
* @hide
*/
protected boolean isTransformedTouchPointInView(float x, float y, View child,
PointF outLocalPoint) {
final float[] point = getTempPoint();
point[0] = x;
point[1] = y;
transformPointToViewLocal(point, child);
// 调用 View 的 pointInView 方法进行判断坐标点是否在 View 内
final boolean isInView = child.pointInView(point[0], point[1]);
if (isInView && outLocalPoint != null) {
outLocalPoint.set(point[0], point[1]);
}
return isInView;
}
如果满足上面两个条件,接着我们看后面的代码 newTouchTarget = getTouchTarget(child);
/**
* Gets the touch target for specified child view.
* Returns null if not found.
*/
private TouchTarget getTouchTarget(@NonNull View child) {
for (TouchTarget target = mFirstTouchTarget; target != null; target = target.next) {
if (target.child == child) {
return target;
}
}
return null;
}
可以看到当 mFirstTouchTarget 不为 null 的时候并且 target.child 就为我们当前遍历的 child 的时候,那么返回的 newTouchTarget 就不为 null,则跳出循环。
我们前面说过,当子 View 处理了点击事件那么 mFirstTouchTarget 就不为 nulll。事实上此时我们还没有将事件分发给子 View,所以正常情况下我们的 newTouchTarget 此时为 null
接下来关键来了:
4.3 ViewGroup.dispatchTransformedTouchEvent
dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign) 方法。为方便,我们将代码再一次贴到后面来
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();
// 当 child 处理了点击事件,那么会设置 mFirstTouchTarget 在 addTouchTarget 被赋值
newTouchTarget = addTouchTarget(child, idBitsToAssign);
alreadyDispatchedToNewTouchTarget = true;
// 子 View 处理了事件,然后就跳出了 for 循环
break;
}
可以看到它被最后一个 if 包围,如果它返回为 true,那么就 break 跳出循环,如果返回为 false 则继续遍历下一个子 View。
我们跟进 dispatchTransformedTouchEvent 方法可以看到这样的关键逻辑:
if (child == null) {
handled = super.dispatchTouchEvent(event);
} else {
handled = child.dispatchTouchEvent(event);
}
这里 child 是我们遍历传入的子 View 此时不为 null,则调用了 child.dispatchTouchEvent(event);
我们子 View 的 dispatchTouchEvent 方法返回 true,表示子 View 处理了事件,那么我们一直提到的,mFirstTouchTarget 会被赋值,是在哪里完成的呢?
再回头看 dispatchTransformedTouchEvent 则为 true 进入最后一个 if 语句,有这么一句 newTouchTarget = addTouchTarget(child, idBitsToAssign);
/**
* Adds a touch target for specified child to the beginning of the list.
* Assumes the target child is not already present.
*/
private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) {
final TouchTarget target = TouchTarget.obtain(child, pointerIdBits);
target.next = mFirstTouchTarget;
mFirstTouchTarget = target;
return target;
}
没错,mFirstTouchTarget 就是在 addTouchTarget 中被赋值!到此子 View 遍历结束。
如果在遍历完子 View 以后,ViewGroup 仍然没有找到事件处理者即 ViewGroup 并没有子 View 或者子 View 处理了事件,但是子 View 的 dispatchTouchEvent 返回了 false(一般是子 View 的 onTouchEvent 方法返回 false)那么 ViewGroup 会去处理这个事件。
从代码上看,就是我们遍历的 dispatchTransformedTouchEvent 方法返回了 false。那么 mFirstTouchTarget 必然为 null;
在 ViewGroup 的 dispatchTouchEvent 遍历完子 View 后,有下面的处理。
// Dispatch to touch targets.
if (mFirstTouchTarget == null) {
// No touch targets so treat this as an ordinary view.
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
}
上面的 dispatchTransformedTouchEvent 方法第三个 child 参数传 null。
我们刚看了这个方法。当 child 为 null 时,handled = super.dispatchTouchEvent(event); 所以此时将调用 父View 的 dispatchTouchEvent 方法,点击事件给了 父View。到此事件分发过程全部结束!
结论:
-
ViewGroup 会遍历所有子 View 去寻找能够处理点击事件的子 View(可见,没有播放动画,点击事件坐标落在子 View 内部),最终调用子 View 的 dispatchTouchEvent 方法处理事件
-
当子 View 处理了事件,则 mFirstTouchTarget 被赋值,并终止子 View 的遍历
-
如果 ViewGroup 并没有子 View 或者子 View 处理了事件,但是子 View 的 dispatchTouchEvent 返回了 false(一般是子 View 的 onTouchEvent 方法返回 false)那么 ViewGroup 会去处理这个事件(本质调用 View 的 dispatchTouchEvent 去处理)
通过 ViewGroup 对事件的分发,我们知道事件最终是调用 View 的 dispatchTouchEvent 来处理。
View 最终是怎么去处理事件的
4.4 View.dispatchTouchEvent
View.java
public boolean dispatchTouchEvent(MotionEvent ev) {
// If the event should be handled by accessibility focus first.
if (event.isTargetAccessibilityFocus()) {
// We don't have focus or no virtual descendant has it, do not handle the event.
if (!isAccessibilityFocusedViewOrHost()) {
return false;
}
// We have focus and got the event, then use normal event dispatch.
event.setTargetAccessibilityFocus(false);
}
boolean result = false;
if (mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onTouchEvent(event, 0);
}
final int actionMasked = event.getActionMasked();
if (actionMasked == MotionEvent.ACTION_DOWN) {
// Defensive cleanup for new gesture
stopNestedScroll();
}
if (onFilterTouchEventForSecurity(event)) {
if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
result = true;
}
// noinspection SimplifiableIfStatement
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;
}
}
if (!result && mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onUnhandledEvent(event, 0);
}
// Clean up after nested scrolls if this is the end of a gesture;
// also cancel it if we tried an ACTION_DOWN but we didn't want the rest
// of the gesture.
if (actionMasked == MotionEvent.ACTION_UP ||
actionMasked == MotionEvent.ACTION_CANCEL ||
(actionMasked == MotionEvent.ACTION_DOWN && !result)) {
stopNestedScroll();
}
return result;
}
上面是 View 的 dispatchTouchEvent 方法的全部代码。相比 ViewGroup 我们需要好几段去拆开看的长篇大论而言,它就简洁多了。很明显 View 是单独的一个元素,它没有子 View,所以也没有分发的代码。我们需要关注的,也只是上面当中的一部分代码。
// 如果窗口没有被遮盖
if (onFilterTouchEventForSecurity(event)) {
if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
result = true;
}
// noinspection SimplifiableIfStatement
// 当前监听事件
ListenerInfo li = mListenerInfo;
// 需要特别注意这个判断当中的 li.mOnTouchListener.onTouch(this, event) 条件
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
result = true;
}
// result 为 false 调用自己的 onTouchEvent 方法处理
if (!result && onTouchEvent(event)) {
result = true;
}
}
通过上面代码我们可以看到 View 会先判断是否设置了 OnTouchListener,如果设置了 OnTouchListener 并且 onTouch 方法返回了 true,那么 onTouchEvent 不会被调用。
当没有设置 OnTouchListener 或者设置了 OnTouchListener 但是 onTouch 方法返回 false,则会调用 View 自己的 onTouchEvent方 法。
接下来看 onTouchEvent 方法:
4.5 View.onTouchEvent
View.java
public boolean onTouchEvent(MotionEvent event) {
final float x = event.getX();
final float y = event.getY();
final int viewFlags = mViewFlags;
final int action = event.getAction();
// 1.如果 View 是设置成不可用的(DISABLED)仍然会消费点击事件
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);
}
...
// 2.CLICKABLE 和 LONG_CLICKABLE 只要有一个为 true 就消费这个事件
if (((viewFlags & CLICKABLE) == CLICKABLE ||
(viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE) ||
(viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE) {
switch (action) {
case MotionEvent.ACTION_UP:
boolean prepressed = (mPrivateFlags & PFLAG_PREPRESSED) != 0;
if ((mPrivateFlags & PFLAG_PRESSED) != 0 || prepressed) {
// take focus if we don't have it already and we should in
// touch mode.
boolean focusTaken = false;
if (isFocusable() && isFocusableInTouchMode() && !isFocused()) {
focusTaken = requestFocus();
}
if (prepressed) {
setPressed(true, x, y);
}
if (!mHasPerformedLongPress && !mIgnoreNextUpEvent) {
// This is a tap, so remove the longpress check
removeLongPressCallback();
// Only perform take click actions if we were in the pressed state
if (!focusTaken) {
if (mPerformClick == null) {
mPerformClick = new PerformClick();
}
if (!post(mPerformClick)) {
// 3.在 ACTION_UP 方法发生时会触发 performClick() 方法
performClick();
}
}
}
...
break;
}
...
return true;
}
return false;
}
上述代码有三个关键点分别在注释处标出。
- 可以看出即便 View 是 disabled 状态,依然不会影响事件的消费,只是它看起来不可用
- 只要 CLICKABLE 和 LONG_CLICKABLE 有一个为 true,就一定会消费这个事件,就是 onTouchEvent 返回 true,这点也印证了我们前面说的 View 的 onTouchEvent 方法默认都会消费掉事件(返回 true),除非它是不可点击的(clickable 和 longClickable 同时为 false),View 的 longClickable 默认为 false,clickable 需要区分情况,如 Button 的 clickable 默认为 true,而 TextView 的 clickable 默认为 false
ACTION_UP 方法中有 performClick();接下来看一下它:
View.java
public boolean performClick() {
final boolean result;
final ListenerInfo li = mListenerInfo;
if (li != null && li.mOnClickListener != null) {
playSoundEffect(SoundEffectConstants.CLICK);
li.mOnClickListener.onClick(this);
result = true;
} else {
result = false;
}
sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED);
return result;
}
很明显,如果 View 设置了 OnClickListener,那么会回调 onClick 方法。
到这里相信大家对一开始的例子已经没有什么疑惑了吧。
最后再强调一点,我们刚说过 View 的 longClickable 默认为 false,clickable 需要区分情况,如 Button 的 clickable 默认为 true,而 TextView 的 clickable 默认为 false。
这是默认情况,我们可以单独给 View 设置 clickable 属性,但有时候会发现 View 的 setClickable 方法失效了。假如我们想让 View 默认不可点击,将 View 的 clickable 设置成 false,在合适的时候需要可点击所以我们又给 View 设置了 OnClickListener,那么你会发现 View 默认依然可以点击,也就是说 setClickable 失效了。
View.java
public void setOnClickListener(@Nullable OnClickListener l) {
if (!isClickable()) {
setClickable(true);
}
getListenerInfo().mOnClickListener = l;
}
public void setOnLongClickListener(@Nullable OnLongClickListener l) {
if (!isLongClickable()) {
setLongClickable(true);
}
getListenerInfo().mOnLongClickListener = l;
}
View 的 setOnClickListener 会默认将 View 的 clickable 设置成 true。
View 的 setOnLongClickListener 同样会将 View 的 longClickable 设置成 true。
五 核心要点
- 事件分发原理:责任链模式,事件层层传递,直到被消费
- View 的 dispatchTouchEvent 主要用于调度自身的监听器和 onTouchEvent
- View 的事件的调度顺序是 onTouchListener > onTouchEvent > onLongClickListener > onClickListener
- 不论 View 自身是否注册点击事件,只要 View 是可点击的就会消费事件
- 事件是否被消费由返回值决定,true 表示消费,false 表示不消费,与是否使用了事件无关
- ViewGroup 中可能有多个 ChildView 时,将事件分配给包含点击位置的 ChildView
- ViewGroup 和 ChildView 同时注册了事件监听器(onClick等),由 ChildView 消费
- 一次触摸流程中产生事件应被同一 View 消费,全部接收或者全部拒绝
- 只要接受 ACTION_DOWN 就意味着接受所有的事件,拒绝 ACTION_DOWN 则不会收到后续内容
- 如果当前正在处理的事件被上层 View 拦截,会收到一个 ACTION_CANCEL,后续事件不会再传递过来
至此,MotionEvent 事件分发机制与源码的分析已经全部完毕,欢迎大家留言交流。