Android 事件分发机制

当我们点击屏幕时，事件最先传递给Activity ，在 Activity 的dispatchTouchEvent() 回调中，默认首先调用 getWindow().superDispatchTouchEvent(ev) 将事件交给window 处理，如果window 返回true之后，则直接return true。在 getWindow().superDispatchTouchEvent(ev) 调用的时候，我们能发现事件一步步传递：

1、PhoneWindow.superDispatchTouchEvent
2、DecorView.dispatchTouchEvent()
3、ViewGroup. dispatchTouchEvent()

代码可以参考（Carson的）：

/**  * 源码分析：Activity.dispatchTouchEvent（）  */ 
  public boolean dispatchTouchEvent(MotionEvent ev) {

    // 仅贴出核心代码

    // ->>分析1
    if (getWindow().superDispatchTouchEvent(ev)) {

        return true;
        // 若getWindow().superDispatchTouchEvent(ev)的返回true
        // 则Activity.dispatchTouchEvent（）就返回true，则方法结束。即 ：该点击事件停止往下传递 & 事件传递过程结束
        // 否则：继续往下调用Activity.onTouchEvent

    }
    // ->>分析3
    return onTouchEvent(ev);
  }

/**  * 分析1：getWindow().superDispatchTouchEvent(ev)  * 说明：  *     a. getWindow() = 获取Window类的对象  *     b. Window类是抽象类，其唯一实现类 = PhoneWindow类  *     c. Window类的superDispatchTouchEvent() = 1个抽象方法，由子类PhoneWindow类实现  */
  @Override
  public boolean superDispatchTouchEvent(MotionEvent event) {

      return mDecor.superDispatchTouchEvent(event);
      // mDecor = 顶层View（DecorView）的实例对象
      // ->> 分析2
  }

/**  * 分析2：mDecor.superDispatchTouchEvent(event)  * 定义：属于顶层View（DecorView）  * 说明：  *     a. DecorView类是PhoneWindow类的一个内部类  *     b. DecorView继承自FrameLayout，是所有界面的父类  *     c. FrameLayout是ViewGroup的子类，故DecorView的间接父类 = ViewGroup  */
  public boolean superDispatchTouchEvent(MotionEvent event) {

      return super.dispatchTouchEvent(event);
      // 调用父类的方法 = ViewGroup的dispatchTouchEvent()
      // 即将事件传递到ViewGroup去处理，详细请看后续章节分析的ViewGroup的事件分发机制

  }
  // 回到最初的分析2入口处

/**  * 分析3：Activity.onTouchEvent()  * 调用场景：当一个点击事件未被Activity下任何一个View接收/处理时，就会调用该方法  */
  public boolean onTouchEvent(MotionEvent event) {

        // ->> 分析5
        if (mWindow.shouldCloseOnTouch(this, event)) {
            finish();
            return true;
        }

        return false;
        // 即 只有在点击事件在Window边界外才会返回true，一般情况都返回false，分析完毕
    }

/**  * 分析4：mWindow.shouldCloseOnTouch(this, event)  * 作用：主要是对于处理边界外点击事件的判断：是否是DOWN事件，event的坐标是否在边界内等  */
  public boolean shouldCloseOnTouch(Context context, MotionEvent event) {

  if (mCloseOnTouchOutside && event.getAction() == MotionEvent.ACTION_DOWN
          && isOutOfBounds(context, event) && peekDecorView() != null) {

        // 返回true：说明事件在边界外，即 消费事件
        return true;
    }

    // 返回false：在边界内，即未消费（默认）
    return false;
  } 

之后，就进入了ViewGroup的事件分发流程。用一张图(这张图转载自Carson_Ho)来描绘下整体的过程：

接下来主要关注的是 Android 中 ViewGroup 事件分发机制。它总体来说可以用几张图说明白，相比在代码中打印Log，这种方式更容易理解和记住。

针对 ACTION_DOWN 事件

只针对 ACTION_DOWN 事件时，事件的完整流向是一个U形图，如下图所示：

如果没有中断事件，可能看起来更直观一些，Activity、ViewGroup、View的层次更加清晰：

针对 ACTION_MOVE 和 ACTION_UP

上面讲解的都是针对ACTION_DOWN的事件传递，ACTION_MOVE和ACTION_UP在传递的过程中并不是和ACTION_DOWN 一样，你在执行ACTION_DOWN的时候返回了false，后面一系列其它的action就不会再得到执行了。简单的说，就是当dispatchTouchEvent在进行事件分发的时候，只有前一个事件（如ACTION_DOWN）返回true，才会收到ACTION_MOVE和ACTION_UP的事件。

ViewGroup1 的dispatchTouchEvent 中返回true消费事件

红色的箭头代表ACTION_DOWN 事件的流向，蓝色的箭头代表ACTION_MOVE 和 ACTION_UP 事件的流向：

ViewGroup2 的dispatchTouchEvent 中返回true消费事件

在View 的dispatchTouchEvent 返回true消费事件,就不画图了，效果和在ViewGroup2 的dispatchTouchEvent return true的差不多，同样的收到ACTION_DOWN 的dispatchTouchEvent函数都能收到 ACTION_MOVE和ACTION_UP。

在View 的onTouchEvent 中返回true消费事件

在ViewGroup 2 的onTouchEvent 中返回true消费事件

在ViewGroup 1 的onTouchEvent 中返回true消费事件

在View的dispatchTouchEvent 中返回false并且ViewGroup 1 的onTouchEvent 返回true消费事件

在View的dispatchTouchEvent 中返回false并且Activity 的onTouchEvent 返回true消费事件

经过这么多图能得出以下规律：

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

以上文章参考自 Kelin ,这里图片形式贴出来仅仅只是个人做的笔记，方便记忆。