【朝花夕拾】Android自定义View篇之（六）Android事件分发机制（中）从源码分析事件分发逻辑及经常遇到的一些“诡异”现象

前言

转载请注明，转自【https://www.cnblogs.com/andy-songwei/p/11039252.html】谢谢！

在上一篇文章【【朝花夕拾】Android自定义View篇之（五）Android事件分发机制（上）Touch三个重要方法的处理逻辑】【下文简称（五），请先阅读完（五）再阅读本文】，我们通过示例和log来分析了Android的事件分发机制。这些，我们只是看到了现象，如果要进一步了解事件分发机制，这是不够的，我们还需要透过现象看本质，去研究研究源码。本文将从源码（基于Android API-26）出发，去分析我们上一篇文章中看到的现象，以及其它一些和事件相关的常见问题，如：事件是如何传到View中的、requestDisallowInterceptTouchEvent为什么失效、view设置了focusable=“false”，为什么还能触发点击事件、Touch事件和Click事件谁先谁后等！

本文的主要内容如下：

一、事件的前世今生

       前文中研究事件传递是从Activity的dispatchTouchEvent开始的，但是事件的起源肯定不是Activity。因为触摸事件是触摸的硬件，所以很明显事件一定是从底层传过来的。但是，事件是如何传递到View的呢？这一节我们简单了解一下事件传递到Activity的经过。

首先，我们在ViewInner类的dispatchTouchEvent方法中打印调用栈，看看这个方法的调用流程。

 //=============ViewInner.java============
 @Override
 public boolean dispatchTouchEvent(MotionEvent event) {
      Log.i("songzheweiwang",Log.getStackTraceString(new Throwable()));
      return super.dispatchTouchEvent(event);
 }

点击ViewInner区域，得到如下log：

 java.lang.Throwable
 2     at com.example.demos.customviewdemo.ViewInner.dispatchTouchEvent(ViewInner.java:24)
 3     at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
 4     at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
 5     at com.example.demos.customviewdemo.ViewGroupMiddle.dispatchTouchEvent(ViewGroupMiddle.java:23)
 6     at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
 7     at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
 8     at com.example.demos.customviewdemo.ViewGroupOuter.dispatchTouchEvent(ViewGroupOuter.java:23)
 9     at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
10     at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
11     at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
12     at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
13     at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
14     at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
15     at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
16     at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
17     at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
18     at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
19     at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
20     at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
21     at com.android.internal.policy.DecorView.superDispatchTouchEvent(DecorView.java:526)
22     at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1830)
23     at android.app.Activity.dispatchTouchEvent(Activity.java:3410)
24     at com.example.demos.customviewdemo.EventDemoActivity.dispatchTouchEvent(EventDemoActivity.java:37)
25     at android.support.v7.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:68)
26     at com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:475)
27     at android.view.View.dispatchPointerEvent(View.java:12768)
28     at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:5455)
29     at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:5258)
30     at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4766)
31     at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:4819)
32     at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:4785)
33     at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:4934)
34     at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:4793)
35     at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:4991)
36     at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4766)
37     at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:4819)
38     at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:4785)
39     at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:4793)
40     at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4766)
41     at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:7490)
42     at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:7448)
43     at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:7409)
44     at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:7593)
45     at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:199)
46     at android.os.MessageQueue.nativePollOnce(Native Method)
47     at android.os.MessageQueue.next(MessageQueue.java:326)
48     at android.os.Looper.loop(Looper.java:165)
49     at android.app.ActivityThread.main(ActivityThread.java:7477)
50     at java.lang.reflect.Method.invoke(Native Method)
51     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:500)
52     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:865)

实际上，Android输入事件的源头是位于/dev/input/下的设备节点，而输入事件的终点是由WMS管理的某个窗口，最终由窗口中的View处理。最初的输入事件为内核生成的原始事件，而最终交付给窗口的则是KeyEvent（键盘）或MotionEvent（鼠标和触摸屏）对象。上述log中（从下往上看），用三种颜色标注了3个阶段：红色部分表示底层活动，这里我们看到了不少熟悉的身影，ZygoteInit，ActivityThread，Native Method等；绿色部分第45行的InputEventReceiver.dispatchInputEvent(）方法，事件通过该方法由Native层进入到Java层，并传递到Activity中，这里我们也看到了不少熟悉的身影，ViewRootImpl，DecorView等；从第24行开始，就是我们前面熟悉的，从Acitivty开始调用dispatchTouchEvent一层层来分发事件。可能读者看到从第20~9行会有疑惑，为什么中间还有这么多过程？如果了解Android的View层次结构的话就会知道，在DecorView和开发者定义的布局（如ViewGroupOuter）之间，隔着很多层ViewGroup，也需要一层层传递，这一点我在本系列第一篇【【朝花夕拾】Android自定义View篇之（一）View绘制流程】【后面简称（一）】的第二节做过讲解，不明白的可以先去看看。

本文的重点是从Activity开始的事件分发，至于前面从底层到Activity的事件流程，咱们这里做一定的了解即可，有兴趣的可以自行研究。

二、事件从Activity到View体系

在上一篇文章的代码示例中，我们的Boss——EventDemoActivity类中有如下代码

 //=============Boss:EventDemoActivity.java============
  @Override
  public boolean dispatchTouchEvent(MotionEvent ev) {
      Log.i("songzheweiwang", "[EventDemoActivity-->dispatchTouchEvent]ev=" + EventUtil.parseAction(ev.getAction()));
      return super.dispatchTouchEvent(ev);
  }

  @Override
  public boolean onTouchEvent(MotionEvent event) {
      Log.i("songzheweiwang", "[EventDemoActivity-->onTouchEvent]event=" + EventUtil.parseAction(event.getAction()));
      return super.onTouchEvent(event);
  }

Activity是事件的起点，dispatchTouchEvent又是整个逻辑中最早分发事件的地方。但是Activity并不是View体系中的一员，那它是怎样把事件分发到View体系中的呢？追踪super.dispatchTouchEvent方法，进入到Activity.java的方法中：

 //==========================Activity.java=======================
 /**
  * Called to process touch screen events.  You can override this to
  * intercept all touch screen events before they are dispatched to the
  * window.  Be sure to call this implementation for touch screen events
  * that should be handled normally.
  *
  * @param ev The touch screen event.
  *
  * @return boolean Return true if this event was consumed.
  */
 public boolean dispatchTouchEvent(MotionEvent ev) {
     if (ev.getAction() == MotionEvent.ACTION_DOWN) {
         onUserInteraction();
     }
     if (getWindow().superDispatchTouchEvent(ev)) {
         return true;
     }
     return onTouchEvent(ev);
 }

如注释中所说，在事件分发到window之前，可以重写这个方法来拦截所有的屏幕事件，如果事件被消费了，这个方法会返回true。这个方法咱们只关注第15~18行。第15行中如果getWindow().superDispatchTouchEvent值为true，表示后续的View体系把事件消费了，那么执行第16行，直接返回true了，后面该Activity的onTouchEvent方法就不再执行了。如果其值为false，则表示事件没有被消费，那该Activity就调用自己的onTouchEvent来消费该事件。这一点，在上一篇文章中多份log都体现了这个结论。当然我们还是需要继续看看getWindow().superDispatchTouchEvent是如何实现的。

其主要代码如下：

 //=================Activity.java=================
 ......
 private Window mWindow;
 ......
 public Window getWindow() {
    return mWindow;
 }
 ......

 //================Window.java================
 /**
  * ......
  * <p>The only existing implementation of this abstract class is
  * android.view.PhoneWindow, which you should instantiate when needing a
  * Window.
  */
 public abstract class Window {
   ......
     public abstract boolean superDispatchTouchEvent(MotionEvent event);
   ......
 }

superDispatchTouchEvent在Window.java中是个抽象方法，需要在实现类中来实现。如注释所说，PhoneWindow是该抽象类唯一存在的实现类，所以我们追踪到PhoneWindow中。

 //=============PhoneWindow.java==========
 ......
 // This is the top-level view of the window, containing the window decor.
 private DecorView mDecor;
 ......
 @Override
 public boolean superDispatchTouchEvent(MotionEvent event) {
     return mDecor.superDispatchTouchEvent(event);
 }

 //===========DecorView.java==========
 ......
 public boolean superDispatchTouchEvent(MotionEvent event) {
     return super.dispatchTouchEvent(event);
 }
 ....

 //========ViewGroup.java=======
 @Override
 public boolean dispatchTouchEvent(MotionEvent ev) {
 ......
 }

在本系列第一篇文章【（一）】中，对DecorView做过讲解，如果有看过这篇文章，那么此时看到如上代码，就不会陌生了。DecorView是整个View体系的根view，它是一个ViewGroup，所以事件流程就进入到ViewGroup中的dispatchTouchEvent中了。通过上述流程，Activity就通过dispatchTouchEvent将事件分发到View体系中来了。

如果View体系没有消费掉事件，就会调用Activity自己的onTouchEvent方法，看看其源码。

 /**
  * Called when a touch screen event was not handled by any of the views
  * under it.  This is most useful to process touch events that happen
  * outside of your window bounds, where there is no view to receive it.
  *
  * @param event The touch screen event being processed.
  *
  * @return Return true if you have consumed the event, false if you haven't.
  * The default implementation always returns false.
  */
 public boolean onTouchEvent(MotionEvent event) {
     if (mWindow.shouldCloseOnTouch(this, event)) {
         finish();
         return true;
     }
     return false;
 }

这里注释说得非常明确了：当它下面的所有view都没有处理掉屏幕触摸事件时，Activity中的这个方法会调用。当触摸事件发生在window边界以外的地方时，这个方法尤为有用，因为这些地方，没有view来接收这个事件。【（五）】的第三点中有个模型图，当触摸白色的Boss区域时，下面三个区域中的view接收不到触摸事件，所以最后只有Activity中的onTouchEvent响应了，【（五）】的第六节中log可以明确这一点。如果您消费了这个事件，返回true；消费不了，则返回false，默认的实现，总是返回false。这一点好理解，Boss嘛，只安排底下的员工干活，自己绝不会动手，就算他们干不了，把事件返回到Boss这里，自己也不会处理的。这里可以改动EventDemoActivity.java中重写的onTouchEvent方法来验证一下：

 @Override
 public boolean onTouchEvent(MotionEvent event) {
     boolean b = super.onTouchEvent(event);
     Log.i("songzheweiwang", "[EventDemoActivity-->onTouchEvent]event=" + EventUtil.parseAction(event.getAction())+";b="+b);
     return b;
 }

最终发现，打印的log中，b值总是false。

到这里，Activity中的两个重要方法就讲完了，后面再来看看事件从Activity分发到View体系后，事件流程是如何在其中一层层分发和处理的。

三、叶子View的事件处理逻辑

控件分为两种：一种是容器类控件，即继承自ViewGroup，如LinearLayout等；一种是叶子View，View的派生类，如TextView，Button等。与之对应，处理事件分发也分为两种情形：一种是ViewGroup处理事件分发；另一种是View处理事件逻辑。ViewGroup会递归遍历子View，如果是叶子View也会调用到View中的dispatchTouchEvent方法。所以，这里咱们先从叶子View处理事件开始分析。

1、叶子View处理事件常见的若干场景

（1）onTouch、onTouchEvent和onClick方法执行顺序问题

我们工作中经常需要为控件设置监听Touch事件和Click事件。这里对【（五）】中的实例代码做一点改动，为ViewInner控件添加触摸事件和点击事件，如下所示：

 //===========EventDemoActivity==========
 ViewInner mViewInner = findViewById(R.id.viewInner);
 mViewInner.setOnClickListener(new View.OnClickListener() {
     @Override
     public void onClick(View v) {
         Log.i("songzheweiwang-2", "[EventDemoActivity-->onclick]");
     }
 });
 mViewInner.setOnTouchListener(new View.OnTouchListener() {
     @Override
     public boolean onTouch(View v, MotionEvent event) {
         Log.i("songzheweiwang-2", "[EventDemoActivity-->onTouch]event="+EventUtil.parseAction(event.getAction()));
         return false;
     }
 });

点击ViewInner控件后得到如下log：

1 06-14 01:19:59.246 25518-25518/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_DOWN
2 06-14 01:19:59.246 25518-25518/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
3 06-14 01:19:59.277 25518-25518/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_UP
4 06-14 01:19:59.277 25518-25518/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP
5 06-14 01:19:59.278 25518-25518/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onclick]

我们发现，从执行顺序上看，onTouch > onTouchEvent > onClick，并且onTouch方法执行了两次，onClick在ACTION_UP之后才被执行。

（2）onTouch返回true的场景

另外，我们发现，oTouch是一个boolean型方法，默认返回的是false。如果将其返回值该为true，结果又怎样呢？

1 06-14 01:59:00.487 25760-25760/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_DOWN
2 06-14 01:59:00.492 25760-25760/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_UP

打印log发现，onTouchEvent和onClick方法都没有执行。

（3）控件设置clickable=“false”的场景

在【（五）】中我们讲过，如果控件的clickable属性为false，那么它是无法消费触摸事件的。这里加上Touch和Click事件后，情形如何呢？

1 06-14 02:15:50.279 26161-26161/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_DOWN
2 06-14 02:15:50.279 26161-26161/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
3 06-14 02:15:50.328 26161-26161/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_UP
4 06-14 02:15:50.328 26161-26161/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP
5 06-14 02:15:50.330 26161-26161/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onclick]

这里发现和clickable为true时打印的log一样，也就是说，此时clickable=“false”失效了，这是什么原因呢？

（4）控件设置setEnable(false)时的场景

默认情况下，控件都是enable的，如果给控件执行setEnable(false)，结果会怎样呢？

1 06-14 02:19:56.369 26359-26359/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
2 06-14 02:19:56.401 26359-26359/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP

发现onTouch和onClick都没有执行。为什么？

上面4种场景是工作中经常会碰到的与事件相关的场景，下面我们从源码的角度来分析其原因。

2、View.dispatchTouchEvent方法

View类中用于处理事件分发逻辑的两个主要方法是dispatchTouchEvent和onTouchEvent，前者是事件分发到该控件时最先执行的方法，先分析这个方法。

 //=========================View.java==================
 /**
  * Pass the touch screen motion event down to the target view, or this
  * view if it is the target.
  * ......
  * @return True if the event was handled by the view, false otherwise.
  */
 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)) {
             result = true;
         }
         if (!result && onTouchEvent(event)) {
             result = true;
         }
     }
     ......
     return result;
 }

先看注释：将屏幕动作事件传递给目标view，如果自己就是这个目标则将事件传给自己。如果这个事件被该目标view处理了，会返回true，否则会返回false。当ViewInner被触摸时，会执行到这里。

第11行有个if语句判断，它的作用是为了安全判断当前TouchEvent是否被过滤掉了，比如该控件不在最顶部，被其它控件遮住了等情形。如果被过滤了，该方法就会返回false，事件没有被消费。我们前面的几种场景下，该函数返回的都是true。第16~18行中有多个判断条件，我们来看看这些条件：

 //============View.java===========
 static class ListenerInfo {
     ......
     private OnTouchListener mOnTouchListener;
     ......
 }

 /**
  * Register a callback to be invoked when a touch event is sent to this view.
  * @param l the touch listener to attach to this view
  */
 public void setOnTouchListener(OnTouchListener l) {
     getListenerInfo().mOnTouchListener = l;
 }

前面在EventDemoActivity类中ViewInner调用了该方法，并设置了OnTouchListener，所以li.mOnTouchListener的值这里不是null。(mViewFlags & ENABLED_MASK) == ENABLED表示该view是enable的，默认情况下控件都是enable；li.mOnTouchListener.onTouch(this, event)，就是我们EventDemoActivity中ViewInner的onTouch方法的返回值，默认是返回falsle。所以会跳出该if判断，进入到第21行。由于前面的if条件为false，所以这里result的值还是false，后面那个条件就开始执行onTouchEvent方法了。如果事件被处理了，onTouchEvent会返回true，返回的result值也就为true了，这个事件就完美处理掉了；如果没有处理掉，onTouchEvent就返回false，那返回值result自然就是false了，事件没有被处理掉。所以此时，onTouchEvent方法都是执行了的。如果在onTouch方法中返回了true，那么第16行的判断条件就是true了，此时result被赋值为true，那么第21行的onTouchEvent方法就没有机会执行了，这就是咱们前面说的第（2）种场景“onTouch返回true的场景”了。这种情形下，dispatchTouchEvent返回true，事件也被处理掉了。这里给一个结论：当控件是enable的时候，如果onTouch事件返回true，onTouchEvent和onClick方法均不会执行，且事件仍会被消费。下面，我们再看看onTouchEvent方法的源码。

3、View.onTouchEvent方法

方法很长，这里选取比较关键的代码进行分析。

 /**
  * Implement this method to handle touch screen motion events.
  * ......
  * @return True if the event was handled, false otherwise.
  */
 public boolean onTouchEvent(MotionEvent event) {
     ......
     final int action = event.getAction();
     final boolean clickable = ((viewFlags & CLICKABLE) == CLICKABLE
             || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)
             || (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE;
     if ((viewFlags & ENABLED_MASK) == DISABLED) {
         if (action == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) {
             setPressed(false);
         }
         mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN;
         // A disabled view that is clickable still consumes the touch
         // events, it just doesn't respond to them.
         return clickable;
     }
     ......
     if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
         switch (action) {
             case MotionEvent.ACTION_UP:
                 ......
                 // 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;
             case MotionEvent.ACTION_DOWN:
                 ......
                 break;
             case MotionEvent.ACTION_CANCEL:
                 ......
                 break;
             case MotionEvent.ACTION_MOVE:
                 ......
                 break;
         }
         return true;
     }
     return false;
 }

看看注释：实现该方法来处理屏幕触摸事件，如果处理了就返回true，否则返回false。这里需要对比一下dispatchTouchEvent的注释，它的关键字是“pass”，而onTouchEvent的关键字是“handle”，这里可以区别两者的作用。

第9行中的clickable值，前说过，有的控件默认是true，有的则是false。控件的flag为可以一般点击和长按，都表示是可点击的。第12行中，如果控件为disable的，即调用了setEnable(false)时，这里就return了，该方法后面的流程就结束了。如果该控件是可点击的，即clickable的值为true，那onTouchEvent返回的就是true，事件仍然被消费了；反之，控件不可点击，那返回的就是false，事件没有被消费，传递到上一级的onTouchEvent方法中，这一点我们在【（五）】中有讲过。第17、18行的注释也明确说明了：一个可以点击的disable的控件，仍然可以消费触摸事件，只不过它不能回应这些控件。

第22行的第二个条件，tooltip的说明如下：

 //=========================View.java====================
 1 /**
 2  * <p>Indicates this view can display a tooltip on hover or long press.</p>
 3  * {@hide}
 4  */
 5 static final int TOOLTIP = 0x40000000;

这是一种比较特殊的用途，这里不继续深究，我们平时的使用以及这里demo中没有使用该功能。所以咱们这里只考虑第一个条件。

能够走到第22行，说明该控件是enable的。如果该控件是不可点击的，那么这个if语句就跳过去了，返回false，此时前面的dispatchTouchEvent方法返回的也一定是false了，说明该控件没有消费掉事件。相反，如果是可点击的，可以看到，后面一定是会返回true的，那么事件就能被消费了。到这里，结合第19行和dispatchTouchEvent方法，我们可以得到一个结论：如果控件是clickable且没有被过滤的，那么这个控件一定是可以消费掉事件的。在ACTION_UP的时候，会走到第29行。这里我们需要关注一下PerformClick类，其源码如下：

 private final class PerformClick implements Runnable {
     @Override
     public void run() {
         performClick();
     }
 }

而第32行的post方法，本质上就是一个Handler发的post，所以第32、33行是一定要执行performClick()方法的。我们着重看一看这个方法：

 //====================View.java================
 /**
  * Call this view's OnClickListener, if it is defined.  Performs all normal
  * actions associated with clicking: reporting accessibility event, playing
  * a sound, etc.
  *
  * @return True there was an assigned OnClickListener that was called, false
  *         otherwise is returned.
  */
 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;
     }
     ......
     return result;
 }

这个方法就是用来执行点击相关的工作的，第13行播放点击音效，第14行响应点击事件等。

 //===============View.java=============
 static class ListenerInfo {
     ......
     public OnClickListener mOnClickListener;
     ......
 }
 ......
 /**
  * Register a callback to be invoked when this view is clicked. If this view is not
  * clickable, it becomes clickable.
  *
  * @param l The callback that will run
  *
  * @see #setClickable(boolean)
  */
 public void setOnClickListener(@Nullable OnClickListener l) {
     if (!isClickable()) {
         setClickable(true);
     }
     getListenerInfo().mOnClickListener = l;
 }

我们在EventDemoActivity中ViewInner通过该方法设置了OnClickListener，所以EventDemoActivity中的onClick方法在这里就被调用了，此时点击事件就产生了。我们可以看到，点击事件是发生在onTouchEvent方法的ACTION_UP事件中的。这里结合前面讲的onTouch方法，就可以解释场景（1）“onTouch、onTouchEvent和onClick方法执行顺序问题”了：onTouch > onTouchEvent > onClick，并且要在ACTION_UP后才会有onClick。在setOnClickListener方法中第17、18行，我们还可以看到，如果这个控件本身不是clickable的，也会先让它变成clickable的。所以，只要控件调用了setOnClickListener方法，那么之前设置的clickable=“false”就会失效。这里就解释了场景（3）“控件设置clickable=“false”的场景”。此时，我们返回去看看onTouchEvent方法的第19行，就会发现，即使控件是enable的，由于我们设置了点击事件监听，所以这里是返回true的，事件仍然被消费了，再结合前面dispatchTouchEvent的第17行，就能够解释场景（4）“控件设置setEnable(false)时的场景”下，没有执行onTouch和onClick方法，但onTouchEvent方法仍然消费了事件。

这里对关键的源码进行了详细的讲解，且对前面提到的几种常见的现象，从源码角度进行了解释，希望通过这些来加深对View事件分发的认识和理解。关于View中事件的分发，要讲的就是这些了。

四、ViewGroup事件分发处理解析

ViewGroup中处理事件逻辑的方法有两个，分别是dispatchTouchEvent和onInterceptTouchEvent。当一个ViewGroup控件收到上一级传递来的事件时，也是先经过dispatchTouchEvent处理。咱们先看看该方法的源码，该方法很长，这里仅截取了其中关键流程的代码：

 //=========================ViewGroup.java========================
 @Override
 public boolean dispatchTouchEvent(MotionEvent ev) {
     ......
     boolean handled = false;
     //该判断条件在View的dispatchTouchEvent部分讲过，这个方法用于判断控件是否被遮挡。
     if (onFilterTouchEventForSecurity(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.
             /**当开始一个新的触摸时，这两句会清除掉以前的状态，
              * 清除FLAG_DISALLOW_INTERCEPT设置，
              * 代码中还会执行mFirstTouchTarget = null
              */
             cancelAndClearTouchTargets(ev);
             resetTouchState();
         }
         // Check for interception.
         final boolean intercepted;
         /**事件由子View去处理时mFirstTouchTarget会赋值并指向子View。
          * mFirstTouchTarget != null表示事件由子View来处理;
          * mFirstTouchTarget = null表示事件由自己处理
          */
         if (actionMasked == MotionEvent.ACTION_DOWN
                 || mFirstTouchTarget != null) {
             /**FLAG_DISALLOW_INTERCEPT是子View通过requestDisallowInterceptTouchEvent(true)来设置的
              * disallowIntercept等同于表示是否调用了该方法。
              */
             final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
             if (!disallowIntercept) {
                 //子View通过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.
             //没有找到处理事件的子View，并且这个action不是ACTION_DOWN，所以该View开始拦截触摸事件。
             intercepted = true;
         }
         ......
         //如果事件没有取消且没有被拦截
         if (!canceled && !intercepted) {
             ......
             //寻找能够接收该事件的View
             for (int i = childrenCount - 1; i >= 0; i--) {
                 ......
                 final View child = getAndVerifyPreorderedView(
                         preorderedList, children, childIndex);
                 ......
                 /**这两个判断条件分别为1、View可见并且没有播放动画；
                  * 2、点击事件的坐标在View的范围内。
                  * 如果其中一个条件不满足，就进行下一次循环。
                  */
                 if (!canViewReceivePointerEvents(child)
                         || !isTransformedTouchPointInView(x, y, child, null)) {
                     ev.setTargetAccessibilityFocus(false);
                     continue;
                 }
                 ......
                 //true表示找到了子View来处理事件，false表示没有子View来处理。
                 if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign))
                     // Child wants to receive touch within its bounds.
                     ......
                     //addTouchTarget方法中，会给mFirstTouchTarget赋值。
                     newTouchTarget = addTouchTarget(child, idBitsToAssign);
                     ......
                     break;
                 }
                ......
             }
         }
         //没有找到可以处理事件的子View，需要自身来处理。
         if (mFirstTouchTarget == null) {
             // No touch targets so treat this as an ordinary view.
             handled = dispatchTransformedTouchEvent(ev, canceled, null,
                     TouchTarget.ALL_POINTER_IDS);
         } else {
             ......
             //这里有一部分源码暂时没有读懂
         }
         ......
     }
     ......
     return handled;
 }

代码中梳理出了关键的流程，并对几处要点做了一些注释说明，咱们这里再解读一下这段代码：

（1）第11行中，当一个新的事件开始时，即ACTION_DOWN触发时，会进行初始化，清理掉之前的一些状态，这一点很容易理解。

（2）第24~27行对字段mFirstTouchTarget进行了简单的说明，这里不再赘述了，后面几个关键点需要用到这个字段来进行判断。

（3）第28行，如果是ACTION_DOWN事件或者其它事件下找到了处理事件的子View时，会进入到该方法中。

（4）第30~33行，主要是FLAG_DISALLOW_INTERCEPT相关。这里需要简单介绍一下requestDisallowInterceptTouchEvent(boolean disallowIntercept)方法，该方法用于子View请求父View，不让父View拦截，即让父View的onInterceptTouchEvent方法返回true时，失效。在没有调用该方法时，默认其参数为false，即requestDisallowInterceptTouchEvent(false)效果等同于没有调用该方法。FLAG_DISALLOW_INTERCEPT的标志位就是通过该方法来进行设置的。该方法对除ACTION_DOWN之外的事件有效，对ACTION_DOWN事件无效，在第12~20行中讲过，ACTION_DOWN时，会清除之前状态，FLAG_DISALLOW_INTERCEPT标志位也被恢复。这里简单演示一下该方法的使用：

首先在ViewGroupMiddle类中修改onInterceptTouchEvent为以下代码，ViewInner中先不做修改，且为了做对比，要让ViewInner添加clickable=“true”，能够消费事件：

 //===========ViewGroupMiddle.java===========
 @Override
 public boolean onInterceptTouchEvent(MotionEvent ev) {
     Log.i("songzheweiwang-2", "[ViewGroupMiddle-->onInterceptTouchEvent]ev=" + EventUtil.parseAction(ev.getAction()));
     switch (ev.getAction()) {
         case MotionEvent.ACTION_DOWN:
             return false;
         default:
             return true;
     }
 }

查看log为：

06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_DOWN
06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->onInterceptTouchEvent]ev=ACTION_DOWN
06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_DOWN
06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_UP
06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->onInterceptTouchEvent]ev=ACTION_UP
06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_CANCEL
06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_CANCEL

ACTION_DOWN没有被拦截，正常传递到了ViewInner中，而其他事件却被拦截了。这里还可以看到，一个完整的事件，如果只有ACTION_DOWN，却没有ACTION_UP，最终会触发ACTION_CANCEL。

现在在ViewInner类的onTouchEvent方法中调用getParent().requestDisallowInterceptTouchEvent(true)方法，如下所示：

 //=============ViewInner.java=============
 @Override
 public boolean onTouchEvent(MotionEvent event) {
     Log.i("songzheweiwang-2","[ViewInner-->onTouchEvent]event="+EventUtil.parseAction(event.getAction()));
     getParent().requestDisallowInterceptTouchEvent(true);
    return super.onTouchEvent(event);
 }

之所以要在ViewGroup类中不拦截ACTION_DOWN事件，是因为如果这里拦截了，ViewInner中的方法就不会执行了，第5行的代码也自然起不到效果。得到的log如下：

1 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_DOWN
2 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->onInterceptTouchEvent]ev=ACTION_DOWN
3 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_DOWN
4 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
5 06-12 00:37:24.524 7509-7509/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_UP
6 06-12 00:37:24.524 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_UP
7 06-12 00:37:24.524 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP

可以看到，ACTION_UP事件在ViewInner中正常执行了。所以在第33行的disallowIntercept变量值，在调用该方法且当前事件不是ACTION_DOWN时（因为会清除掉该方法的效果），其值为true，反之则为false。在这里，可以看到，由于调用了该方法，所以在ACTION_UP事件中，ViewGroupMiddle中的onInterceptTouchEvent方法没有执行了。

该方法在日常解决事件冲突时经常会用到，所以这里花了一点篇幅来讲解了一下该方法。

（5）第36行中，调用了onInterceptTouchEvent方法。这个方法我们在【（五）】中提到无数遍了，这里总算看到了它的身影。自然，这里一定要去看看其源码。

 //=================ViewGroup.java=============
 public boolean onInterceptTouchEvent(MotionEvent ev) {
     if (ev.isFromSource(InputDevice.SOURCE_MOUSE)
             && ev.getAction() == MotionEvent.ACTION_DOWN
             && ev.isButtonPressed(MotionEvent.BUTTON_PRIMARY)
             && isOnScrollbarThumb(ev.getX(), ev.getY())) {
         return true;
     }
     return false;
 }

What？这么简单？if语句看起来是和鼠标有关系的，貌似和咱们的示例及平时使用没有半毛钱的关系，所以除去这个判断语句，其实就只有第8行的代码了。这里，在【（五）】中讲过，对于重写的onInterceptTouchEvent方法，返回false和返回默认的super.onInterceptTouchEvent，结果是一样的。

（6）第28~46行就确定了是否需要对事件进行拦截了。这里也可以明确看到，onInterceptTouchEvent方法，不一定每次都会被调用了。这里我们在【（五）】中也多次看到这种情形。

（7）第49行中，我们关注后面这个条件，在没有被拦截的情况下才会进入这个if语句内部。它的主要作用就是递归遍历其子view，找到可以接收该事件的view。这里重点需要关注的是第68行的dispatchTransformedTouchEvent方法。这个方法我们在第一节的log中就多次看到过，在ViewGroup中它和dispatchTouchEvent方法总是成对出现的。它的源码如下：

 //===============ViewGroup.java==============
 private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
             View child, int desiredPointerIdBits) {
      final boolean handled;
      ......
      //transformedEvent是对event的加工处理
      if (child == null) {
             handled = super.dispatchTouchEvent(transformedEvent);
         } else {
            ......
             handled = child.dispatchTouchEvent(transformedEvent);
      }
      return handle;
 }

这里传入的child参数是有值的，不是null，所以会调用第10行，进行递归。当遍历到叶子View的时候，就跳转到View类中的diapatchTouchEvent方法中了，我们前面已经讲解过了。所以，如果找到了处理事件的view了，handle就是true，该方法返回true，就会跳出for循环，不再需要便利了，否则继续便利。这里面有个addTouchTarget方法，其中会对mFirstTouchTarge进行赋值，说明找到了处理事件的子View，如果没找到，这个值会一直为null。

（8）第79~83行，既然前面没有找到可以处理该事件的子view，那么就只能自己来接手该事件了。第82行，第三个参数传入的是nul，所以该方法体中就会执行第7行。ViewGroup的父类是View，所以会走到View类中，走View处理事件的逻辑了，这里也需要注意，不要混淆父类和父控件了。而如果子View能够处理该事件，那后面当前ViewGroup控件就和这个事件没啥关系了。现在，我们也就能够解释【（五）】中的很多现象了，如：ViewInner无法消费掉事件时，ViewGroupMiddle会回调自身的onTouchEvent方法；如果ViewInner消费了当前的事件，那么本次事件就不会再返回到上级控件了。

（9）最后该方法的返回值仍然是，如果返回true，那么表示事件被消费了，否则返回false。

ViewGroup类中重点需要关注的方法就讲完了，其实主要就是dispatchTouchEvent方法的逻辑。现在我们应该可以理解，在【（五）】在各种现象和结论了吧。

五、参考文章

【Android View 事件分发机制】

【一文读懂Android View事件分发机制】

【Android事件分发机制完全解析，带你从源码的角度彻底理解(上)】

【Android事件分发机制完全解析，带你从源码的角度彻底理解(下)】

结语

Android的View事件传递机制的源码分析，到这里就讲完了，不知道本文中提到的一些场景，是不是也曾经困扰过读者呢？当然，笔者这里只是抓取了主要的关键流程和方法进行了讲解，真实的源码逻辑远远比这要复杂，因为平时会碰到各种不同的情况，比如长按，tip功能的逻辑处理等。总的来说，本文还只不过是登堂入室的开始而已，其中如果有不妥或者不正确的地方，欢迎来拍砖。