前言
在Android View 事件分发机制源码详解(ViewGroup篇)一文中，主要对ViewGroup#dispatchTouchEvent的源码做了相应的解析，其中说到在ViewGroup把事件传递给子View的时候，会调用子View的dispatchTouchEvent，这时分两种情况，如果子View也是一个ViewGroup那么再执行同样的流程继续把事件分发下去，即调用ViewGroup#dispatchTouchEvent；如果子View只是单纯的一个View，那么调用的是View#dispatchTouchEvent。因此，本文将分析View(非ViewGroup)的事件分发、处理机制。
View#dispatchTouchEvent
事件来到View的时候，会调用该方法，前提是你的自定义View没有重写该方法。我们先看看它的源码：
public boolean dispatchTouchEvent(MotionEvent event) {
...
boolean result = false;
...
if (onFilterTouchEventForSecurity(event)) {
//noinspection SimplifiableIfStatement
ListenerInfo li = mListenerInfo;
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) { // 1
result = true;
}
if (!result && onTouchEvent(event)) { // 2
result = true;
}
}
...
return result;
}我们只看重点部分，这里有一个判断if(onFilterTouchEventForSecurity(event))，这个主要是判断当前事件到来的时候，窗口有没有被遮挡，如果被遮挡则会直接返回false，从而中断事件的处理。如果窗口没被遮挡，那么会正常处理事件。在IF体内部，首先定义了一个ListenerInfo，那么这个ListenerInfo是什么呢？我们跟进去看看：
static class ListenerInfo {
public OnClickListener mOnClickListener;
protected OnLongClickListener mOnLongClickListener;
private OnKeyListener mOnKeyListener;
private OnTouchListener mOnTouchListener;
...
}可以看到，这是View里面的一个内部类，定义了一系列的Listener，其中有我们经常用到的onClickListener，这里是获取当前View所设置的Listener。接着是①号处的一个判断，判断当前View是否设置了onTouchListener，如果设置了onTouchListener的话，则会调用onTouchListener.onTouch方法，然后根据onTouch方法的返回值来设置result，表示事件是否被处理。**这里可以看出：**onTouchListener的优先级最高，如果在onTouchListener#onTouch中返回true即消耗了事件，那么就无必要继续执行下面的语句了。如果没有设置onTouchListener或者该监听器内部没有消耗事件，那么就会执行②号代码，来调用View#onTouchEvent()。
View#onTouchEvent
由于源码较长，这里分段来讲述。
1、先看下面这一段：
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);
}以上判断了当前View是否可用，如果不可用则进入IF体，根据注释我们知道，即使是不可以状态下的View，如果它自身是可点击或者可长按的话，一样会消耗事件，只是不作出任何反应罢了。
2、接着往下看：
if (mTouchDelegate != null) {
if (mTouchDelegate.onTouchEvent(event)) {
return true;
}
}这里判断是否设置了mTouchDelegate，这个表示View的代理，即如果设置了代理，那么当前View的点击事件会交给代理的View来处理，调用代理View的onTouchEvent方法，如果代理View消耗了事件，那么相当于当前View消耗了事件。
3、接下来便是onTouchEvent对View事件的具体处理了：
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) {
...
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) {
// Use a Runnable and post this rather than calling
// performClick directly. This lets other visual state
// of the view update before click actions start.
if (mPerformClick == null) {
mPerformClick = new PerformClick();
}
if (!post(mPerformClick)) {
performClick();
}
}
}
...
break;
...
}
return true;
}首先是判断当前View是否可以点击或者长按，其中一个为true的话，就会进入IF体。进入IF体后，是对事件进行判断，可以看到最后会返回true，即事件最后会被消耗。也就是说，如果一个View是clickable或者long_clickable的话，该onTouchEvent方法会返回true，把事件消耗掉。
我们看看对ACTION_UP的事件进行响应的部分，首先会判断当前View是否是pressed状态，即按下状态，如果是按下状态就会触发performClick()方法，我们看看这个方法做了什么，View#performClick:
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方法，所以我们平时对一个Button设置点击事件之后，都会在其onTouchEvent方法的ACTION_UP逻辑里面得到回调。
这里可以得出结论：onTouchListener、onTouchEvent、onClickListener三者的优先级是：onTouchListener>onTouchEvent>onClickListener。
至此，对于View的事件分发、处理过程分析完毕，接下来总结一下：
1、事件传递给View的时候，会调用dispatchTouchEvent()方法，但是View没有onIntercept方法，所以会接着调用onTouchEvent()方法。
2、如果一个View是可点击的(clickable或long_clickable)，那么它默认会消耗事件。对于一个Button来说，默认是可点击的，对于一个textView来说，默认是不可点击的，而对于一个自定义View来说，默认也是不可点击的，可以在xml布局中设置View的点击性质。
3、如果对一个View设置了onClickListener监听，那么确保它的可点击的，而且接收到了ACTION_DOWN和ACTION_UP事件。
验证性试验
以下是验证性试验，根据这两篇文章所述内容来设置不同的场景来验证以上的源码分析的正确性。
①首先新建一个ViewGroupA，继承自LinearLayout，重写了三个重要方法，但是只是打印了事件，dispatchTouchEvent和onIntercept会调用父类的响应方法，而onTouchEvent方法则返回true。代码如下：
public class ViewGroupA extends LinearLayout {
public ViewGroupA(Context context) {
super(context);
}
public ViewGroupA(Context context, AttributeSet attrs) {
super(context, attrs);
}
public ViewGroupA(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
}
@Override
public boolean onTouchEvent(MotionEvent event) {
int action = event.getAction();
switch (action){
case MotionEvent.ACTION_DOWN:
Log.d("cylog", "ViewGroupA onTouchEvent ACTION_DOWN");
break;
case MotionEvent.ACTION_MOVE:
Log.d("cylog","ViewGroupA onTouchEvent ACTION_MOVE");
break;
}
return true;
}
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
switch (ev.getAction()){
case MotionEvent.ACTION_DOWN:
Log.d("cylog","ViewGroupA dispatchTouchEvent down");
break;
case MotionEvent.ACTION_MOVE:
Log.d("cylog","ViewGroupA dispatchTouchEvent move");
break;
}
return super.dispatchTouchEvent(ev);
}
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
switch (ev.getAction()){
case MotionEvent.ACTION_DOWN:
Log.d("cylog","ViewGroupA onInterceptTouchEvent down");
break;
case MotionEvent.ACTION_MOVE:
Log.d("cylog","ViewGroupA onInterceptTouchEvent move");
break;
}
return super.onInterceptTouchEvent(ev);
}
}②接下来是在ViewGroupA内部的一个子View，ViewA，重写了dispatchToucheEvent和onTouchEvent方法，如下所示：
package com.chenyu.viewstudy;
import android.content.Context;
import android.util.AttributeSet;
import android.util.Log;
import android.view.MotionEvent;
import android.view.View;
/**
* Created by Administrator on 2016/4/17.
*/
public class ViewA extends View {
public ViewA(Context context) {
super(context);
}
public ViewA(Context context, AttributeSet attrs) {
super(context, attrs);
}
public ViewA(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
}
@Override
public boolean onTouchEvent(MotionEvent event) {
switch (event.getAction()){
case MotionEvent.ACTION_DOWN:
Log.d("cylog","ViewA onTouchEvent down");
break;
case MotionEvent.ACTION_MOVE:
Log.d("cylog","ViewA onTouchEvent move");
break;
case MotionEvent.ACTION_UP:
Log.d("cylog","ViewA onTouchEvent up");
break;
}
return super.onTouchEvent(event);
}
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
switch (event.getAction()){
case MotionEvent.ACTION_DOWN:
Log.d("cylog","ViewA dispatchTouchEvent down");
break;
case MotionEvent.ACTION_MOVE:
Log.d("cylog","ViewA dispatchTouchEvent move");
break;
}
return super.dispatchTouchEvent(event);
}
}③MainActivity内部只是设置了布局，并无别的代码，这里不再贴出。
④xml布局文件如下：
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent">
<com.chenyu.viewstudy.ViewGroupA
android:id="@+id/viewgroupa"
android:layout_width="400dp"
android:layout_height="400dp"
android:gravity="center"
android:background="#2e8abb">
<com.chenyu.viewstudy.ViewA
android:id="@+id/viewa"
android:layout_width="200dp"
android:layout_height="200dp"
android:clickable="true"
android:background="#ed132e"/>
</com.chenyu.viewstudy.ViewGroupA>
</RelativeLayout>我们先看看布局图如下：
上面蓝色区域是ViewGroupA,红色区域是ViewA,运行程序，我们在红色区域滑动一下，结果如下所示：
可以看出，事件正常分发，从ViewGroup开始到View,并在View中得到处理。
以下开始改变条件：
1、ViewGroup拦截ACTION_DOWN事件：
在ViewGroupA中做出如下改动：
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
switch (ev.getAction()){
...
}
//对ACTION_DWON拦截，返回true。
if (ev.getAction() == MotionEvent.ACTION_DOWN){
return true;
}
return super.onInterceptTouchEvent(ev);
}运行，结果如下所示：
可以看出，ViewGroupA拦截了ACTION_DOWN事件，那么ViewA接收不到事件了，所以后面的全部事件都由ViewGroupA处理。
2、ViewGroup拦截ACTION_MOVE事件：
同样，在ViewGroupA中做出如下改动：
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
switch (ev.getAction()){
...
}
if (ev.getAction() == MotionEvent.ACTION_MOVE){
return true;
}
return super.onInterceptTouchEvent(ev);
}运行结果如下：
可以看出，ViewA还是能正常处理ACTION_DOWN事件，但是由于ACTION_MOVE事件被ViewGroup拦截了，所以ViewGroup来处理ACTION_MOVE事件，我们注意到，onIntercept方法来拦截成功后，后续的事件分发流程并不会再次调用，所以一个View拦截了事件后，后续的所有事件都交由这个View处理，并不会再次判断是否需要拦截，所以这也符合上一篇文章的分析。
3、基于第2点拦截了MOVE事件，同时ViewGroup的onTouchEvent返回值修改，原来是直接返回true的，表示消耗了事件，那么这里直接返回super.onTouchEvent(ev):
@Override
public boolean onTouchEvent(MotionEvent event) {
int action = event.getAction();
switch (action){
...
}
return super.onTouchEvent(event);
}同时在Activity中重写onTouchEvent()方法：
@Override
public boolean onTouchEvent(MotionEvent event) {
switch (event.getAction()){
case MotionEvent.ACTION_MOVE:
Log.d("cylog","Activity onTouchEvent ACTION_MOVE");
break;
}
return super.onTouchEvent(event);
}结果如下：
可以看出，super.onTouchEvent(ev)返回了false，表示不消耗事件，为什么会这样呢？根据本文分析，一个View只有在可点击的状态下，自身的onTouchEvent方法才会返回true，这里调用的是super.onTouchEvent表示调用父类的onTouchEvent方法，又由于ViewGroupA继承自LinearLayout，本身是不可点击的，所以这里自然会返回false。然后我们看到，最终这些没被消耗的时候回到了Activity，被Activity消耗掉了。其实这也很好理解，上一篇文章说过，事件的分发是从Activity开始的，不断往下寻找能消耗事件的子元素，但如果事件没被子元素消耗，则会逐层返回到Activity。
所以这里得出结论：如果View不消耗除了ACTION_DOWN事件之外的其他事件（因为ACTION_DWON事件会初始化事件序列），这个View依然也会接收后续的事件，同时这些没被消耗的事件最终会被Activity消耗。
4、ViewGroupA不做任何修改，对ViewA修改，为ViewA设置onTouchListener和onClickListener
View viewA = findViewById(R.id.viewa);
viewA.setOnTouchListener(new View.OnTouchListener() {
@Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()){
case MotionEvent.ACTION_DOWN:
Log.d("cylog","ViewA onTouchListener down");
break;
case MotionEvent.ACTION_MOVE:
Log.d("cylog", "ViewA onTouchListener move");
}
return true;
}
});
viewA.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Log.d("cylog","ViewA onClickListener ");
}
});结果如下：
可以看出，事件分发给子View后，如果设置了onTouchListener，那么直接调用它，如果返回true，那么后续并不会调用onTouchEvent以及onClickListener了。如果返回false，继而调用onTouchEvent方法，所以onTouchListener的优先级最高，这也符合本文的分析。但是要注意一点，onClickListener在ACTION_UP中起作用，如果子View重写了onTouchEvent()方法，而最后返回的时候没有返回super.onTouchEvent()，那么不会调用onClickListener。因为压根没有调用到父类的onTouchEvent方法。
至此，对于View的事件分发、处理机制讲述完毕，谢谢阅读。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
