总结

• View 事件分发的本质是递归。

• 递归的本质是，任务的下发和结果的上报。

• View 事件分发设计成递归，是为了配合 View 的排版规则，形成符合用户直觉的触控体验。

• View 事件分发的对象是一个 MotionEvent。

• 一次用户触控操作包含多个 MotionEvent（例如从 ACTION_DOWN 到 ACTION_UP ），也即会走多次事件分发流程。

• 一次 View 事件分发流程包含 “递” 流程和 “归” 流程，“递” 流程可以因 ViewGroup 的拦截而提前步入 “归” 流程。

• child 可以通过 getParent.requestDisallowInterceptTouchEvent 阻止父容器的拦截。因而需要差异化地配置阈值，来确保 child 执行 getParent.requestDisallowInterceptTouchEvent 优先于父容器 onInterceptTouchEvent 返回 true（不然都先被拦截了，child 哪有机会阻止？）

• 在“归”流程中，唯有当前层级的 super.dispatchTouchEvent 返回了 true，才认定被消费，被消费前，下级都有干活，只是结果不 OK。被消费后，上级都不需要干活，直接向上传达消费者的功。

View 事件分发

Android事件分发机制详解：史上最全面、最易懂

image.png

Android面试必问：事件分发机制你肯定得懂！

image.png

事件分发的顺序

事件传递的顺序：Activity->Window->DecorView->ViewGroup->View。一个点击事件发生后，总是先传递给当前的Activity，然后通过Window传给DecorView再传给ViewGroup,最终传到View。

在《开发艺术探索》中的事件分发的顺序是：Activity->Window->View，而有的博客上的顺序是：Activity->ViewGroup->View，不过其实两者是一样的（下列会从源码进行分析）。Window是抽象类，其唯一实现类为PhoneWindow，PhoneWindow将事件直接传递给DecorView,而DecorView继承FrameLayout,FrameLayout又是ViewGroup的子类，所以兜兜转转最后也可以认为Window事件分发的实现其实是ViewGroup来实现的。所以也可以认为事件传递的顺序是：Activity->ViewGroup->View。

核心方法

View的事件分发机制主要由事件分发->事件拦截->事件处理三步来进行逻辑控制，很巧的这三步刚好对应了三个核心方法

• dispatchTouchEvent
• onInterceptTouchEvent
• onTouchEvent

三者关系

/**
  * 点击事件产生后
  */ 
  // 步骤1：调用dispatchTouchEvent（）
  public boolean dispatchTouchEvent(MotionEvent ev) {

    boolean consume = false; //代表 是否会消费事件
    
    // 步骤2：判断是否拦截事件
    if (onInterceptTouchEvent(ev)) {
      // a. 若拦截，则将该事件交给当前View进行处理
      // 即调用onTouchEvent (）方法去处理点击事件
        consume = onTouchEvent (ev) ;

    } else {

      // b. 若不拦截，则将该事件传递到下层
      // 即 下层元素的dispatchTouchEvent（）就会被调用，重复上述过程
      // 直到点击事件被最终处理为止
      consume = child.dispatchTouchEvent (ev) ;
    }

    // 步骤3：最终返回通知 该事件是否被消费（接收 & 处理）
    return consume;

   }