Android面试必问—事件分发机制

旧城等待， 2022-08-28 11:51 195阅读 0赞

1.面试必问的一道题：  
说说你对事件分发机制的理解？  
如果触发一个点击事件，都没有消费，最后回到哪里？  
分析一下触摸屏幕后源码流程？

事件分发的顺序是activity—>viewgroup—>view，即一个点击事件发生后，事件先传递到activity，再传到viewgroup，最终传到view。  
关于事件分发机制有三个重要方法：  
dispatchTouchEvent  
onInterceptTouchEvent  
onTouchEvent  
这三个方法的关系是onInterceptTouchEvent和onTouchEvent在dispatchTouchEvent中执行。  
①当有一个点击事件时，最先activity会来处理，然后传递给PhoneWindow，再传递给DecorView，最后传给顶层ViewGroup。  
对于根ViewGroup，会先传递到它的dispatchTouchEvent，如果onInterceptTouchEvent返回true，表示这个ViewGroup要拦截，那么交由它的onTouchEvent处理。如果返回false，最后回到底层子View的onTouchEvent处理。  
②如果子View的onTouchEvent返回true，表示这个事件就消费了，如果返回false，就会传递到父ViewGroup的onTouchEvent处理。如果还返回false，就交给父View的父View，如此反复。

2.事件分发流程  
下面根据一张事件分发流程图来说明事件从用户点击之后，在不同函数不同返回值的情况的最终走向。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plbm1lbGEyMDEx_size_16_color_FFFFFF_t_70]  
注：目前所有的图的事件是针对ACTION\_DOWN的，对于ACTION\_MOVE和ACTION\_UP我们最后做分析。

仔细看整个图，我们得出事件流走向的几个结论：  
①如果事件不被中断，整个事件流向是一个类U型图，我们来看下这张图，可能更能理解U型图的意思。  
![在这里插入图片描述][20210929111135182.png]  
所以如果我们没有对控件里面的方法进行重写或更改返回值，而直接用super调用父类的默认实现，那么整个事件流向应该是从Activity---->ViewGroup—>View 从上往下调用dispatchTouchEvent方法，一直到叶子节点（View）的时候，再由View—>ViewGroup—>Activity从下往上调用onTouchEvent方法。  
②dispatchTouchEvent 和 onTouchEvent 一旦return true,事件就停止传递了（到达终点，没有谁能再收到这个事件）。对于return true我们经常说事件被消费了。  
③dispatchTouchEvent 和 onTouchEvent return false的时候事件都回传给父控件的onTouchEvent处理。  
对于dispatchTouchEvent 返回 false 的含义应该是：事件停止往子View传递和分发同时开始往父控件回溯（父控件的onTouchEvent开始从下往上回传直到某个onTouchEvent return true），事件分发机制就像递归，return false 的意义就是递归停止然后开始回溯。  
对于onTouchEvent 返回false 就比较简单了，它就是不消费事件，并让事件继续往父控件的方向从下往上流动。  
④dispatchTouchEvent、onTouchEvent、onInterceptTouchEvent  
ViewGroup 和View的这些方法的默认实现就是会让整个事件安装U型完整走完，所以 return super.xxxxxx() 就会让事件依照U型的方向的完整走完整个事件流动路径），中间不做任何改动，不回溯、不终止，每个环节都走到。  
所以如果看到方法return super.xxxxx() 那么事件的下一个流向就是走U型下一个目标，稍微记住上面这张图，你就能很快判断出下一个走向是哪个控件的哪个函数。  
⑤ViewGroup 和View 的dispatchTouchEvent方法返回super.dispatchTouchEvent()的时候事件流走向：  
首先看下ViewGroup 的dispatchTouchEvent。之前说的return true是终结传递，return false 是回溯到父View的onTouchEvent，那么ViewGroup怎样通过dispatchTouchEvent方法能把事件分发到自己的onTouchEvent处理呢，return true和false 都不行，那么只能通过Interceptor把事件拦截下来给自己的onTouchEvent，所以ViewGroup dispatchTouchEvent方法的super默认实现就是去调用onInterceptTouchEvent，记住这一点。  
同理，对于View的dispatchTouchEvent return super.dispatchTouchEvent()的时候呢事件会传到哪里呢？View没有拦截器，return true是终结，return false 是回溯会父类的onTouchEvent，怎样把事件分发给自己的onTouchEvent 处理呢，那只能return super.dispatchTouchEvent,View类的dispatchTouchEvent（）方法默认实现就是能帮你调用View自己的onTouchEvent方法的。  
总结一下：  
①对于dispatchTouchEvent，onTouchEvent，return true是终结事件传递。return false 是回溯到父View的onTouchEvent方法。  
②ViewGroup想把自己分发给自己的onTouchEvent，需要拦截器onInterceptTouchEvent方法return true 把事件拦截下来。  
③ViewGroup的拦截器onInterceptTouchEvent 默认是不拦截的，所以return super.onInterceptTouchEvent()=return false；  
④View没有拦截器，为了让View可以把事件分发给自己的onTouchEvent，View的dispatchTouchEvent默认实现（super）就是把事件分发给自己的onTouchEvent。

3.关于action\_move和action\_up  
上面讲解的都是针对ACTION\_DOWN的事件传递，ACTION\_MOVE和ACTION\_UP在传递的过程中并不是和ACTION\_DOWN 一样，如果在执行ACTION\_DOWN的时候返回了false，后面一系列其它的action就不会再得到执行了。简单的说，就是当dispatchTouchEvent在进行事件分发的时候，只有前一个事件（如ACTION\_DOWN）返回true，才会收到ACTION\_MOVE和ACTION\_UP的事件。我们来看一下下面的具体分析。  
首先要知道，并不是哪个函数收到了ACTION\_DOWN，就会收到 ACTION\_MOVE 等后续的事件的。

讨论的布局如下：  
![在这里插入图片描述][20210929145607103.png]  
下面通过几张图看看不同场景下ACTION\_MOVE事件和ACTION\_UP事件的具体走向并总结一下规律。  
①我们在ViewGroup1 的dispatchTouchEvent 方法返回true消费这次事件。  
ACTION\_DOWN 事件从（Activity的dispatchTouchEvent）--------> （ViewGroup1 的dispatchTouchEvent） 后结束传递，事件被消费（如下图红色的箭头代码ACTION\_DOWN 事件的流向）。  
//打印日志  
Activity | dispatchTouchEvent --> ACTION\_DOWN  
ViewGroup1 | dispatchTouchEvent --> ACTION\_DOWN  
\---->消费  
![在这里插入图片描述][20210929150220403.png]  
在这种场景下ACTION\_MOVE和ACTION\_UP 将如何呢，看下面的打出来的日志：  
Activity | dispatchTouchEvent --> ACTION\_MOVE  
ViewGroup1 | dispatchTouchEvent --> ACTION\_MOVE

Activity | dispatchTouchEvent --> ACTION\_UP  
ViewGroup1 | dispatchTouchEvent --> ACTION\_UP  
下图中，红色的箭头代表ACTION\_DOWN 事件的流向，蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向。  
![在这里插入图片描述][20210929150555874.png]  
②我们在ViewGroup2 的dispatchTouchEvent 返回true消费这次事件。  
Activity | dispatchTouchEvent --> ACTION\_DOWN  
ViewGroup1 | dispatchTouchEvent --> ACTION\_DOWN  
ViewGroup1 | onInterceptTouchEvent --> ACTION\_DOWN  
ViewGroup2 | dispatchTouchEvent --> ACTION\_DOWN  
\---->消费  
Activity | dispatchTouchEvent --> ACTION\_MOVE  
ViewGroup1 | dispatchTouchEvent --> ACTION\_MOVE  
ViewGroup1 | onInterceptTouchEvent --> ACTION\_MOVE  
ViewGroup2 | dispatchTouchEvent --> ACTION\_MOVE

Activity | dispatchTouchEvent --> ACTION\_UP  
ViewGroup1 | dispatchTouchEvent --> ACTION\_UP  
ViewGroup1 | onInterceptTouchEvent --> ACTION\_UP  
ViewGroup2 | dispatchTouchEvent --> ACTION\_UP  
红色的箭头代表ACTION\_DOWN 事件的流向  
蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向。  
![在这里插入图片描述][20210929150853720.png]  
③我们在View 的dispatchTouchEvent 返回true消费这次事件  
这个我不就画图了，效果和在ViewGroup2 的dispatchTouchEvent return true的差不多，同样的收到ACTION\_DOWN 的dispatchTouchEvent函数都能收到 ACTION\_MOVE和ACTION\_UP。  
所以我们就基本可以得出结论：如果在某个控件的dispatchTouchEvent 返回true消费终结事件，那么收到ACTION\_DOWN 的函数也能收到 ACTION\_MOVE和ACTION\_UP。  
④我们在View 的onTouchEvent 返回true消费这次事件。  
红色的箭头代表ACTION\_DOWN 事件的流向，蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向  
![在这里插入图片描述][20210929151034318.png]  
⑤我们在ViewGroup 2 的onTouchEvent 返回true消费这次事件。  
红色的箭头代表ACTION\_DOWN 事件的流向，蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向  
![在这里插入图片描述][20210929151140473.png]  
⑥我们在ViewGroup 1 的onTouchEvent 返回true消费这次事件。  
红色的箭头代表ACTION\_DOWN 事件的流向，蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向  
![在这里插入图片描述][20210929151230275.png]  
⑦我们在Activity 的onTouchEvent 返回true消费这次事件。  
红色的箭头代表ACTION\_DOWN 事件的流向，蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向  
![在这里插入图片描述][20210929151309359.png]  
⑧我们在View的dispatchTouchEvent 返回false并且Activity 的onTouchEvent 返回true消费这次事件。  
红色的箭头代表ACTION\_DOWN 事件的流向，蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向  
![在这里插入图片描述][20210929151347431.png]  
⑨我们在View的dispatchTouchEvent 返回false并且ViewGroup 1 的onTouchEvent 返回true消费这次事件。  
红色的箭头代表ACTION\_DOWN 事件的流向，蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向  
![在这里插入图片描述][20210929151450791.png]  
⑩我们在View的dispatchTouchEvent 返回false并且在ViewGroup 2 的onTouchEvent 返回true消费这次事件  
红色的箭头代表ACTION\_DOWN 事件的流向，蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向  
![在这里插入图片描述][20210929151523592.png]  
⑩我们在ViewGroup2的dispatchTouchEvent 返回false并且在ViewGroup1 的onTouchEvent返回true消费这次事件  
红色的箭头代表ACTION\_DOWN 事件的流向，蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向  
![在这里插入图片描述][20210929151822270.png]  
⑩我们在ViewGroup2的onInterceptTouchEvent 返回true拦截此次事件并且在ViewGroup 1 的onTouchEvent返回true消费这次事件。  
红色的箭头代表ACTION\_DOWN 事件的流向  
蓝色的箭头代表ACTION\_MOVE 和 ACTION\_UP 事件的流向  
![在这里插入图片描述][20210929151858519.png]  
相信你也看出规律了，对于在onTouchEvent消费事件的情况：在哪个View的onTouchEvent 返回true，那么ACTION\_MOVE和ACTION\_UP的事件从上往下传到这个View后就不再往下传递了，而直接传给自己的onTouchEvent 并结束本次事件传递过程。

对于ACTION\_MOVE、ACTION\_UP总结：ACTION\_DOWN事件在哪个控件消费了（return true）， 那么ACTION\_MOVE和ACTION\_UP就会从上往下（通过dispatchTouchEvent）做事件分发往下传，就只会传到这个控件，不会继续往下传，如果ACTION\_DOWN事件是在dispatchTouchEvent消费，那么事件到此为止停止传递，如果ACTION\_DOWN事件是在onTouchEvent消费的，那么会把ACTION\_MOVE或ACTION\_UP事件传给该控件的onTouchEvent处理并结束传递。

3.view的事件分发  
下面从源码的角度先分析View的事件分发。  
从一个简单的例子入手。比如说你当前有一个非常简单的项目，只有一个Activity，并且Activity中只有一个按钮。如果想要给这个按钮注册一个点击事件，只需要调用：  
button.setOnClickListener(new OnClickListener() \{  
@Override  
public void onClick(View v) \{  
Log.d(“TAG”, “onClick execute”);  
\}  
\});  
这样在onClick方法里面写实现，就可以在按钮被点击的时候执行。  
如果想给这个按钮再添加一个touch事件，只需要调用：  
button.setOnTouchListener(new OnTouchListener() \{  
@Override  
public boolean onTouch(View v, MotionEvent event) \{  
Log.d(“TAG”, "onTouch execute, action " + event.getAction());  
return false;  
\}  
\});  
onTouch方法里能做的事情比onClick要多一些，比如判断手指按下、抬起、移动等事件。  
那么如果我两个事件都注册了，哪一个会先执行呢？我们来试一下就知道了，运行程序点击按钮，打印结果如下：  
![在这里插入图片描述][20210927202001989.jpg]  
可以看到，onTouch是优先于onClick执行的，并且onTouch执行了两次，一次是ACTION\_DOWN，一次是ACTION\_UP(你还可能会有多次ACTION\_MOVE的执行，如果你手抖了一下)。因此事件传递的顺序是先经过onTouch，再传递到onClick。

细心的朋友应该可以注意到，onTouch方法是有返回值的，这里我们返回的是false，如果我们尝试把onTouch方法里的返回值改成true，再运行一次，结果如下：  
![在这里插入图片描述][20210927202118639.png]  
我们发现，onClick方法不再执行了！  
也就是说，onTouch方法返回true就认为这个事件被onTouch消费掉了，因而不会再继续向下传递。

下面让我们从源码的角度分析一下，出现上述现象的原理是什么。  
首先你需要知道，只要你触摸到了任何一个控件，就一定会调用该控件的dispatchTouchEvent方法。那当我们去点击按钮的时候，就会去调用Button类里的dispatchTouchEvent方法，可是你会发现Button类里并没有这个方法，那么就到它的父类TextView里去找一找，你会发现TextView里也没有这个方法，只好继续在TextView的父类View里找一找，这个时候你终于在View里找到了这个方法：  
public boolean dispatchTouchEvent(MotionEvent event) \{  
if (mOnTouchListener != null && (mViewFlags & ENABLED\_MASK) == ENABLED &&  
mOnTouchListener.onTouch(this, event)) \{  
return true;  
\}  
return onTouchEvent(event);  
\}  
这个方法非常的简洁，只有短短几行代码！我们可以看到，在这个方法内，首先是进行了一个判断，如果mOnTouchListener != null，(mViewFlags & ENABLED\_MASK)==ENABLED和mOnTouchListener.onTouch(this, event)这三个条件都为真，就返回true，否则就去执行onTouchEvent(event)方法并返回。  
先看一下第一个条件，mOnTouchListener这个变量是在哪里赋值的呢？我们寻找之后在View里发现了如下方法：  
public void setOnTouchListener(OnTouchListener l) \{  
mOnTouchListener = l;  
\}  
可见mOnTouchListener是在setOnTouchListener方法里赋值的，也就是说只要我们给控件注册了touch事件，mOnTouchListener就一定被赋值了。  
第二个条件(mViewFlags & ENABLED\_MASK)==ENABLED是判断当前点击的控件是否是enable的，按钮默认都是enable的，因此这个条件恒定为true。  
第三个条件就比较关键了，mOnTouchListener.onTouch(this, event)，其实也就是去回调控件注册touch事件时的onTouch方法，也就是说如果我们在onTouch方法里返回true，就会让这三个条件全部成立，从而整个方法直接返回true。如果我们在onTouch方法里返回false，就会再去执行onTouchEvent(event)方法。  
现在我们可以结合前面的例子来分析一下了，首先在dispatchTouchEvent中最先执行的就是onTouch方法，因此onTouch肯定是要优先于onClick执行的，也是印证了刚刚的打印结果。而如果在onTouch方法里返回了true，就会让dispatchTouchEvent方法直接返回true，不会再继续往下执行。而打印结果也证实了如果onTouch返回true，onClick就不会再执行了。

根据以上源码的分析，从原理上解释了我们前面例子的运行结果。而上面的分析还透漏出了一个重要的信息，那就是onClick的调用肯定是在onTouchEvent(event)方法中的！那我们马上来看下onTouchEvent的源码，如下所示：  
public boolean onTouchEvent(MotionEvent event) \{  
final int viewFlags = mViewFlags;  
if ((viewFlags & ENABLED\_MASK)==DISABLED) \{  
return (((viewFlags & CLICKABLE)==CLICKABLE ||  
(viewFlags & LONG\_CLICKABLE)==LONG\_CLICKABLE));  
\}  
if (mTouchDelegate != null) \{  
if (mTouchDelegate.onTouchEvent(event)) \{  
return true;  
\}  
\}  
if (((viewFlags & CLICKABLE)==CLICKABLE ||  
(viewFlags & LONG\_CLICKABLE)LONG\_CLICKABLE)) \{  
switch (event.getAction()) \{  
case MotionEvent.ACTION\_UP:  
boolean prepressed = (mPrivateFlags & PREPRESSED) != 0;  
if ((mPrivateFlags & PRESSED) != 0 || prepressed) \{  
boolean focusTaken = false;  
if (isFocusable() && isFocusableInTouchMode() && !isFocused()) \{  
focusTaken = requestFocus();  
\}  
if (!mHasPerformedLongPress) \{  
removeLongPressCallback();  
if (!focusTaken) \{  
if (mPerformClicknull) \{  
mPerformClick = new PerformClick();  
\}  
if (!post(mPerformClick)) \{  
performClick();  
\}  
\}  
\}  
if (mUnsetPressedState ==null) \{  
mUnsetPressedState = new UnsetPressedState();  
\}  
if (prepressed) \{  
mPrivateFlags |= PRESSED;  
refreshDrawableState();  
postDelayed(mUnsetPressedState,  
ViewConfiguration.getPressedStateDuration());  
\} else if (!post(mUnsetPressedState)) \{  
mUnsetPressedState.run();  
\}  
removeTapCallback();  
\}  
break;  
case MotionEvent.ACTION\_DOWN:  
if (mPendingCheckForTap ==null) \{  
mPendingCheckForTap = new CheckForTap();  
\}  
mPrivateFlags |= PREPRESSED;  
mHasPerformedLongPress = false;  
postDelayed(mPendingCheckForTap, ViewConfiguration.getTapTimeout());  
break;  
case MotionEvent.ACTION\_CANCEL:  
mPrivateFlags &= ~PRESSED;  
refreshDrawableState();  
removeTapCallback();  
break;  
case MotionEvent.ACTION\_MOVE:  
final int x = (int) event.getX();  
final int y = (int) event.getY();  
int slop = mTouchSlop;  
if ((x < 0 - slop) || (x >= getWidth() + slop) ||  
(y < 0 - slop) || (y >= getHeight() + slop)) \{  
// Outside button  
removeTapCallback();  
if ((mPrivateFlags & PRESSED) != 0) \{  
// Remove any future long press/tap checks  
removeLongPressCallback();  
// Need to switch from pressed to not pressed  
mPrivateFlags &= ~PRESSED;  
refreshDrawableState();  
\}  
\}  
break;  
\}  
return true;  
\}  
return false;  
\}  
相较于刚才的dispatchTouchEvent方法，onTouchEvent方法复杂了很多。首先从  
if (((viewFlags & CLICKABLE) ==CLICKABLE可以看出，如果该控件是可以点击的就会进入到下面的switch判断中去，而如果当前的事件是抬起手指，则会进入到MotionEvent.ACTION\_UP这个case当中。在经过种种判断之后，会执行到performClick()方法，那我们进入到这个方法里瞧一瞧：  
public boolean performClick() \{  
sendAccessibilityEvent(AccessibilityEvent.TYPE\_VIEW\_CLICKED);  
if (mOnClickListener != null) \{  
playSoundEffect(SoundEffectConstants.CLICK);  
mOnClickListener.onClick(this);  
return true;  
\}  
return false;  
\}  
可以看到，只要mOnClickListener不是null，就会去调用它的onClick方法，那mOnClickListener又是在哪里赋值的呢？经过寻找后找到如下方法：  
public void setOnClickListener(OnClickListener l) \{  
if (!isClickable()) \{  
setClickable(true);  
\}  
mOnClickListener = l;  
\}  
到现在为止，一切都清楚了！当我们通过调用setOnClickListener方法给控件注册一个点击事件时，就会给mOnClickListener赋值。然后每当控件被点击时，都会在performClick()方法里回调被点击控件的onClick方法。

这样View的整个事件分发的流程就搞清楚了！不过还有一个很重要的知识点需要说明，就是touch事件的层级传递。我们都知道如果给一个控件注册了touch事件，每次点击它的时候都会触发一系列的ACTION\_DOWN，ACTION\_MOVE，ACTION\_UP等事件。这里需要注意，如果在执行ACTION\_DOWN的时候返回了false，后面一系列其它的action就不会再得到执行了。简单的说，就是当dispatchTouchEvent在进行事件分发的时候，只有前一个action返回true，才会触发后一个action。  
说到这里，很多的朋友肯定要有巨大的疑问了。这不是在自相矛盾吗？前面的例子中，明明在onTouch事件里面返回了false，ACTION\_DOWN和ACTION\_UP不是都得到执行了吗？其实你只是被假象所迷惑了，让我们仔细分析一下，在前面的例子当中，我们到底返回的是什么。  
参考着我们前面分析的源码，首先在onTouch事件里返回了false，就一定会进入到onTouchEvent方法中，然后我们来看一下onTouchEvent方法的细节。由于我们点击了按钮，就会进入到if判断的内部，然后你会发现，不管当前的action是什么，最终都一定会走到后面的return ture，返回一个true。  
是不是有一种被欺骗的感觉？明明在onTouch事件里返回了false，系统还是在onTouchEvent方法中帮你返回了true。就因为这个原因，才使得前面的例子中ACTION\_UP可以得到执行。

那我们可以换一个控件，将按钮替换成ImageView，然后给它也注册一个touch事件，并返回false。如下所示：  
imageView.setOnTouchListener(new OnTouchListener() \{  
@Override  
public boolean onTouch(View v, MotionEvent event) \{  
Log.d(“TAG”, "onTouch execute, action " + event.getAction());  
return false;  
\}  
\});  
运行一下程序，点击ImageView，你会发现结果如下：  
![在这里插入图片描述][20210928160708792.jpg]  
在ACTION\_DOWN执行完后，后面的一系列action都不会得到执行了。这又是为什么呢？因为ImageView和按钮不同，它是默认不可点击的，因此在onTouchEvent的if判断时无法进入到if的内部，直接跳到最后返回了false，也就导致后面其它的action都无法执行了。

view的事件分发就结束了，总结一下：  
1.onTouch和onTouchEvent有什么区别，又该如何使用？  
从源码中可以看出，这两个方法都是在View的dispatchTouchEvent中调用的，onTouch优先于onTouchEvent执行。如果在onTouch方法中通过返回true将事件消费掉，onTouchEvent将不会再执行。  
另外需要注意的是，onTouch能够得到执行需要两个前提条件，第一mOnTouchListener的值不能为空，第二当前点击的控件必须是enable的。因此如果你有一个控件是非enable的，那么给它注册onTouch事件将永远得不到执行。对于这一类控件，如果我们想要监听它的touch事件，就必须通过在该控件中重写onTouchEvent方法来实现。  
2.为什么给ListView引入了一个滑动菜单的功能，ListView就不能滚动了？  
滑动菜单的功能是通过给ListView注册了一个touch事件来实现的。如果你在onTouch方法里处理完了滑动逻辑后返回true，那么ListView本身的滚动事件就被屏蔽了，自然也就无法滑动(原理同前面例子中按钮不能点击)，因此解决办法就是在onTouch方法里返回false。

3.viewGroup的事件分发  
搞明白了view的事件分发，接下来看viewgroup的事件分发。  
ViewGroup就是一组View的集合，它包含很多的子View和子VewGroup，是Android中所有布局的父类或间接父类，像LinearLayout、RelativeLayout等都是继承自ViewGroup的。但ViewGroup实际上也是一个View，只不过比起View，它多了可以包含子View和定义布局参数的功能。  
下面我们现在通过一个Demo来演示一下Android中VewGroup的事件分发流程吧。  
首先我们来自定义一个布局，命名为MyLayout，继承自LinearLayout，如下所示：  
public class MyLayout extends LinearLayout \{  
public MyLayout(Context context, AttributeSet attrs) \{  
super(context, attrs);  
\}

\}  
然后，打开主布局文件activity\_main.xml，在其中加入我们自定义的布局：  
<com.example.viewgrouptouchevent.MyLayout xmlns:android=“http://schemas.android.com/apk/res/android”  
xmlns:tools=“http://schemas.android.com/tools”  
android:id="@+id/my\_layout"  
android:layout\_width=“match\_parent”  
android:layout\_height=“match\_parent”  
android:orientation=“vertical” >  
  
  
</com.example.viewgrouptouchevent.MyLayout>  
可以看到，我们在MyLayout中添加了两个按钮，接着在MainActivity中为这两个按钮和MyLayout都注册了监听事件：  
myLayout.setOnTouchListener(new OnTouchListener() \{  
@Override  
public boolean onTouch(View v, MotionEvent event) \{  
Log.d(“TAG”, “myLayout on touch”);  
return false;  
\}  
\});  
button1.setOnClickListener(new OnClickListener() \{  
@Override  
public void onClick(View v) \{  
Log.d(“TAG”, “You clicked button1”);  
\}  
\});  
button2.setOnClickListener(new OnClickListener() \{  
@Override  
public void onClick(View v) \{  
Log.d(“TAG”, “You clicked button2”);  
\}  
\});  
我们在MyLayout的onTouch方法，和Button1、Button2的onClick方法中都打印了一句话。现在运行一下项目，分别点击一下Button1、Button2和空白区域，打印结果如下所示：  
![在这里插入图片描述][2021092816275891.png]  
你会发现，当点击按钮的时候，MyLayout注册的onTouch方法并不会执行，只有点击空白区域的时候才会执行该方法。你可以先理解成Button的onClick方法将事件消费掉了，因此事件不会再继续传递。  
查阅文档可以看到，ViewGroup中有一个onInterceptTouchEvent方法，我们来看一下这个方法的源码：  
public boolean onInterceptTouchEvent(MotionEvent ev) \{  
return false;  
\}  
源码竟然如此简单！只有一行代码，返回了一个false！  
好吧，既然是布尔型的返回，那么只有两种可能，我们在MyLayout中重写这个方法，然后返回一个true试试，代码如下所示：  
public class MyLayout extends LinearLayout \{  
public MyLayout(Context context, AttributeSet attrs) \{  
super(context, attrs);  
\}

@Override  
public boolean onInterceptTouchEvent(MotionEvent ev) \{  
return true;  
\}  
\}  
现在再次运行项目，然后分别Button1、Button2和空白区域，打印结果如下所示：  
![在这里插入图片描述][20210928163611515.png]  
你会发现，不管你点击哪里，永远都只会触发MyLayout的touch事件了，按钮的点击事件完全被屏蔽掉了！这是为什么呢？  
只有通过阅读源码，搞清楚Android中ViewGroup的事件分发机制了。首先要知道，Android中touch事件的传递，是先传递到ViewGroup，再传递到View的。当你点击了某个控件，首先会去调用该控件所在布局的dispatchTouchEvent方法，然后在布局的dispatchTouchEvent方法中找到被点击的相应控件，再去调用该控件的dispatchTouchEvent方法。如果我们点击了MyLayout中的按钮，会先去调用MyLayout的dispatchTouchEvent方法，可是你会发现MyLayout中并没有这个方法。那就再到它的父类LinearLayout中找一找，发现也没有这个方法。那只好继续再找LinearLayout的父类ViewGroup，你终于在ViewGroup中看到了这个方法，按钮的dispatchTouchEvent方法就是在这里调用的。  
快去看一看ViewGroup中的dispatchTouchEvent方法的源码吧！代码如下所示：  
public boolean dispatchTouchEvent(MotionEvent ev) \{  
final int action = ev.getAction();  
final float xf = ev.getX();  
final float yf = ev.getY();  
final float scrolledXFloat = xf + mScrollX;  
final float scrolledYFloat = yf + mScrollY;  
final Rect frame = mTempRect;  
boolean disallowIntercept = (mGroupFlags & FLAG\_DISALLOW\_INTERCEPT) != 0;  
if (actionMotionEvent.ACTION\_DOWN) \{  
if (mMotionTarget != null) \{  
mMotionTarget = null;  
\}  
if (disallowIntercept || !onInterceptTouchEvent(ev)) \{  
ev.setAction(MotionEvent.ACTION\_DOWN);  
final int scrolledXInt = (int) scrolledXFloat;  
final int scrolledYInt = (int) scrolledYFloat;  
final View\[\] children = mChildren;  
final int count = mChildrenCount;  
for (int i = count - 1; i >= 0; i–) \{  
final View child = children\[i\];  
if ((child.mViewFlags & VISIBILITY\_MASK)VISIBLE  
|| child.getAnimation() != null) \{  
child.getHitRect(frame);  
if (frame.contains(scrolledXInt, scrolledYInt)) \{  
final float xc = scrolledXFloat - child.mLeft;  
final float yc = scrolledYFloat - child.mTop;  
ev.setLocation(xc, yc);  
child.mPrivateFlags &= ~CANCEL\_NEXT\_UP\_EVENT;  
if (child.dispatchTouchEvent(ev)) \{  
mMotionTarget = child;  
return true;  
\}  
\}  
\}  
\}  
\}  
\}  
boolean isUpOrCancel = (actionMotionEvent.ACTION\_UP) ||  
(actionMotionEvent.ACTION\_CANCEL);  
if (isUpOrCancel) \{  
mGroupFlags &=~FLAG\_DISALLOW\_INTERCEPT;  
\}  
final View target = mMotionTarget;  
if (target ==null) \{  
ev.setLocation(xf, yf);  
if ((mPrivateFlags & CANCEL\_NEXT\_UP\_EVENT) != 0) \{  
ev.setAction(MotionEvent.ACTION\_CANCEL);  
mPrivateFlags &= ~CANCEL\_NEXT\_UP\_EVENT;  
\}  
return super.dispatchTouchEvent(ev);  
\}  
if (!disallowIntercept && onInterceptTouchEvent(ev)) \{  
final float xc = scrolledXFloat - (float) target.mLeft;  
final float yc = scrolledYFloat - (float) target.mTop;  
mPrivateFlags &= ~CANCEL\_NEXT\_UP\_EVENT;  
ev.setAction(MotionEvent.ACTION\_CANCEL);  
ev.setLocation(xc, yc);  
if (!target.dispatchTouchEvent(ev)) \{  
\}  
mMotionTarget = null;  
return true;  
\}  
if (isUpOrCancel) \{  
mMotionTarget = null;  
\}  
final float xc = scrolledXFloat - (float) target.mLeft;  
final float yc = scrolledYFloat - (float) target.mTop;  
ev.setLocation(xc, yc);  
if ((target.mPrivateFlags & CANCEL\_NEXT\_UP\_EVENT) != 0) \{  
ev.setAction(MotionEvent.ACTION\_CANCEL);  
target.mPrivateFlags &= ~CANCEL\_NEXT\_UP\_EVENT;  
mMotionTarget = null;  
\}  
return target.dispatchTouchEvent(ev);  
\}  
这个方法代码比较长，我们只挑重点看。首先从if (disallowIntercept || !onInterceptTouchEvent(event)  
可以看到一个条件判断，如果disallowIntercept和!onInterceptTouchEvent(ev)两者有一个为true，就会进入到这个条件判断中。disallowIntercept是指是否禁用掉事件拦截的功能，默认是false，也可以通过调用requestDisallowInterceptTouchEvent方法对这个值进行修改。那么当第一个值为false的时候就会完全依赖第二个值来决定是否可以进入到条件判断的内部，第二个值是什么呢？竟然就是对onInterceptTouchEvent方法的返回值取反！也就是说如果我们在onInterceptTouchEvent方法中返回false，就会让第二个值为true，从而进入到条件判断的内部，如果我们在onInterceptTouchEvent方法中返回true，就会让第二个值为false，从而跳出了这个条件判断。  
这个时候你就可以思考一下了，由于我们刚刚在MyLayout中重写了onInterceptTouchEvent方法，让这个方法返回true，导致所有按钮的点击事件都被屏蔽了，那我们就完全有理由相信，按钮点击事件的处理就是在if条件判断的内部进行的！  
那我们重点来看下条件判断的内部是怎么实现的。通过 一个for循环：for (int i = count - 1; i >= 0; i–) ，遍历了当前ViewGroup下的所有子View，然后通过if (frame.contains(scrolledXInt, scrolledYInt)) 判断当前遍历的View是不是正在点击的View，如果是的话就进入到该条件判断的内部，然后通过if (child.dispatchTouchEvent(ev))  
调用了该View的dispatchTouchEvent，之后的流程是上面讲过的view的事件分发了。我们也因此证实了，按钮点击事件的处理确实就是在这里进行的。  
需要注意一下，调用子View的dispatchTouchEvent后是有返回值的。我们已经知道，如果一个控件是可点击的，那么点击该控件时，dispatchTouchEvent的返回值必定是true。因此会导致if (child.dispatchTouchEvent(ev))的条件判断成立，于是给ViewGroup的dispatchTouchEvent方法直接返回了true。这样就导致后面的代码无法执行到了，也是印证了我们前面的Demo打印的结果，如果按钮的点击事件得到执行，就会把MyLayout的touch事件拦截掉。  
那如果我们点击的不是按钮，而是空白区域呢？这种情况下就不会进入到if (child.dispatchTouchEvent(ev))内部返回true了，而是会继续执行后面的代码。那我们继续往后看，if (target ==null)如果target等于null，就会进入到该条件判断内部，这里一般情况下target都会是null，因此会调用后面的super.dispatchTouchEvent(ev)。这句代码会调用到哪里呢？当然是View中的dispatchTouchEvent方法了，因为ViewGroup的父类就是View。之后的处理逻辑又和前面所说的是一样的了，也因此MyLayout中注册的onTouch方法会得到执行。之后的代码在一般情况下是走不到的了，我们也就不再继续往下分析。

再看一下整个ViewGroup事件分发过程的流程图吧，相信可以帮助大家更好地去理解：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plbm1lbGEyMDEx_size_16_color_FFFFFF_t_70 1]  
最后，总结一下：  
①Android事件分发是先传递到ViewGroup，再由ViewGroup传递到View的。  
②在ViewGroup中可以通过onInterceptTouchEvent方法对事件传递进行拦截，onInterceptTouchEvent方法返回true代表不允许事件继续向子View传递，返回false代表不对事件进行拦截，默认返回false。  
③子View中如果将传递的事件消费掉，ViewGroup中将无法接收到任何事件。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plbm1lbGEyMDEx_size_16_color_FFFFFF_t_70]: /images/20220828/77d9c0a195344dee9175759808c0cd78.png
[20210929111135182.png]: /images/20220828/34362771b2c9486985814b69637a2014.png
[20210929145607103.png]: /images/20220828/e199982eb6c74d548e1ef362e9e9db63.png
[20210929150220403.png]: /images/20220828/9c93b6ffad994ea4b81a8950002674b0.png
[20210929150555874.png]: /images/20220828/5a9e1cd89d574afbb125384d8837ad5e.png
[20210929150853720.png]: /images/20220828/a695f225802742109862deb5159ff6e4.png
[20210929151034318.png]: /images/20220828/ed48ac357bff499596889d32db2414e7.png
[20210929151140473.png]: /images/20220828/1ed57b3f545a4e2dbbf85c311e7bfaec.png
[20210929151230275.png]: /images/20220828/4a9cee6e0da745759dd2ace6c757e515.png
[20210929151309359.png]: /images/20220828/5041bcc2ec384c4d9394e27ed1e6cef0.png
[20210929151347431.png]: /images/20220828/bb55a376f1344396882711ed0f21c618.png
[20210929151450791.png]: /images/20220828/fd442013992343009d9c6d68cda35354.png
[20210929151523592.png]: /images/20220828/f6280622fd36469ba10aea708d20a72a.png
[20210929151822270.png]: /images/20220828/97b550747c2f453ca3f01fdeb5ab6ecd.png
[20210929151858519.png]: /images/20220828/dec6e7e6e6f74bf691e4d80e6bbbb8b9.png
[20210927202001989.jpg]: /images/20220828/54117eba547d44e5aeb46f57ebc1db5a.png
[20210927202118639.png]: /images/20220828/15d216b4e7c245fa8a97fd15efafecad.png
[20210928160708792.jpg]: /images/20220828/fe4c25386b8e4ad88df3bf656e9bbb66.png
[2021092816275891.png]: /images/20220828/4ff70025931c45dfaa165af6b04a7224.png
[20210928163611515.png]: /images/20220828/060e0417ea26471d9b434991b9fd209e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plbm1lbGEyMDEx_size_16_color_FFFFFF_t_70 1]: /images/20220828/bb1fe0e7cf4c40739b5957868a7cc072.png