【Android事件分发机制理解】春衣少年当酒歌，起舞四顾以笑和。这篇文章主要讲述Android事件分发机制理解相关的知识，希望能为你提供帮助。
预备知识 触摸事件 ：

1. 安卓中把触摸事件封装成了一个类MotionEvent，用户的一次点击、触摸或者滑动都会产生一系列的MotionEvent
2. 这个类的内容很简单，就两个东西：事件类型+坐标xy
3. 事件类型有四种
   1. MotionEvent.ACTION_DOWN 表示用户的手指刚接触到屏幕
   2. MotionEvent.ACTION_MOVE 表示用户的手指正在移动
   3. MotionEvent.ACTION_UP 表示用户的手指从屏幕上抬起
   4. Cancel
4. 所以一次用户触摸屏幕可能会产生这些事件:
   1. 点击屏幕然后松开，Down-> Up
   2. 点击屏幕，然后滑动一段距离，松开屏幕 ，Down-> Move-> … -> Move-> Up

  事件分发方法： 在事件分发的过程中，主要涉及到三个方法

1. dispatchTouchEvent(MotionEvent event)
2. onInterceptTouchEvent(MotionEvent event)
3. onTouchEvent(MotionEvent event)

    假设：

1. 只考虑最重要的四个触摸事件，即：DOWN,MOVE,UP和CANCEL
2. 一个手势（gesture）是一个事件列
   1. 以一个DOWN事件开始（当用户触摸屏幕时产生）
   2. 后跟0个或多个MOVE事件（当用户四处移动手指时产生）
   3. 最后跟一个单独的UP或CANCEL事件（当用户手指离开屏幕或者系统告诉你手势（gesture）由于其他原因结束时产生）
3. 当我们说到“ 手势剩余部分” 时指的是手势后续的MOVE事件和最后的UP或CANCEL事件
4. 不考虑多点触摸手势（我们只假设用一个手指）
5. 忽略多个MOVE事件可以被归为一组这一实际情况
6. 假设文中的view都没有注册onTouchListener
7. 假设一种视图层次：
1. 最外层是一个ViewGroup A，包含一个或多个子view（children），其中一个子view是ViewGroup B，ViewGroupB中又包含一个或多个子view，其中一个子view是 View C,C不是一个ViewGroup
2. 忽略同层级view之间可能的交叉叠加
8. 假设情况：
   1. 用户首先触摸到的屏幕上的点是C上的某个点，该点被标记为触摸点（touch point），DOWN事件就在该点产生
   2. 然后用户移动手指并最后离开屏幕，此过程中手指是否离开C的区域无关紧要，关键是手势（gesture）是从哪里开始的
9. 假设不考虑dispatchTouchEvent方法

  假设不考虑onInterceptTouchEvent，同时没有重写事件分发方法时：

1. DOWN事件被传到C的onTouchEvent方法中，该方法返回false，表示“ 我不关心这个手势（gesture）”
2. 因此，DOWN事件被传到B的onTouchEvent方法中，该方法同样返回false，表示B也不关心这个手势
3. 同样，因为B不关心这个手势，DOWN事件被传到A的onTouchEvent方法中，该方法也返回false
4. 由于没有view关心这个手势（gesture），它们将不再会从“ 手势剩余部分” 中接收任何事件

（一个更好的情况描述是打log看哪些方法被调用）   假设不考虑onInterceptTouchEvent，但重写事件分发（加上处理事件） 假设C实际上是关心这个手势（gesture）的，原因可能是C被设置成可点击的（clickable）或者你覆写了C的onTouchEvent方法

1. DOWN事件被传递给C的onTouchEvent方法，该方法可以做任何它想做的事情，最后返回true。
2. 因为C说它正在处理这个手势（gesture），则DOWN事件将不再被传递给B和A的onTouchEvent方法。
3. 因为C说它正在处理这个手势（gesture），所以“ 手势剩余部分” 的事件也将传递给C的onTouchEvent方法，此时该方法返回true或false都无关紧要了，但是为保持一致最好还是返回true。

  从这里可以看出，各个View的onTouchEvent方法对DOWN事件的处理，代表了该View对以此DOWN开始的整个手势（gesture）的处理意愿，返回true代表愿意处理该gesture，返回false代表不愿意处理该gesture   加上onInterceptTouchEvent但不拦截

1. onInterceptTouchEvent方法它只存在于ViewGroup中，普通的View中没有这个方法
2. 在任何一个view的onTouchEvent被调用之前，它的父辈们将先获得拦截这个事件的一次机会
3. 换句话说，它们可以窃取该事件。在刚才的“ 处理事件” 部分中，我们遗漏了这一过程

  现在我们把它加上，情况是这样：

1. DOWN事件被传给A的onInterceptTouchEvent，该方法返回false，表示它不想拦截。
2. DOWN又被传递给B的onInterceptTouchEvent，它也不想拦截，因此该方法也返回false。
3. 现在，DOWN事件被传递到C的onTouchEvent方法，该方法返回true，因为它想处理以该事件为首的手势（gesture）。
4. 现在，该手势的下一个事件MOVE到来了。这个MOVE事件再一次被传递给A的onInterceptTouchEvent方法，该方法再一次返回false，B也同样如此。
5. 然后，MOVE事件被传递给C的onTouchEvent，就像在前一部分中一样。
6. “ 手势剩余部分” 中其他事件的处理过程和上面一样，假如A和B的onInterceptTouchEvent方法继续返回false的话

  这里有两点需要注意：

1. 虽然ViewGroup A和B的onInterceptTouchEvent方法对DOWN事件返回了false，后续的事件依然会传递给它们的onInterceptTouchEvent方法，这一点与onTouchEvent的行为是不一样的
2. 假如DOWN事件传给C的onTouchEvent方法时，它返回了false，DOWN事件会继续向上传递给B和A的onTouchEvent，即使它们在onInterceptTouchEvent方法中说它们不想拦截这个DOWN事件，两者是独立的

  由此可见，DOWN事件的处理实际上经历了一下一上两个过程，下是指A-> B的onInterceptTouchEvent，上是指C-> B-> A的onTouchEvent，当然，任意一步的方法中返回true,都能阻止它继续传播。   在onInterceptTouchEvent拦截事件 让我们更进一步，假设B没有拦截DOWN事件，但它拦截了接下来的MOVE事件。原因可能是B是一个scrolling view。当用户仅仅在它的区域内点击（tap）时，被点击到的元素应当能处理该点击事件。但是当用户手指移动了一定的距离后，就不能再视该手势（gesture）为点击了— — 很明显，用户是想scroll。这就是为什么B要接管该手势（gesture）。   下面是事件被处理的顺序：

1. DOWN事件被依次传到A和B的onInterceptTouchEvent方法中，它们都返回的false，因为它们目前还不想拦截。
2. DOWN事件传递到C的onTouchEvent方法，返回了true。
3. 在后续到来MOVE事件时，A的onInterceptTouchEvent方法仍然返回false。
4. B的onInterceptTouchEvent方法收到了该MOVE事件，此时B注意到用户手指移动距离已经超过了一定的threshold（或者称为slop）。因此，B的onInterceptTouchEvent方法决定返回true，从而接管该手势（gesture）后续的处理。
5. 然后，这个MOVE事件将会被系统变成一个CANCEL事件，这个CANCEL事件将会传递给C的onTouchEvent方法。
6. 现在，又来了一个MOVE事件，它被传递给A的onInterceptTouchEvent方法，A还是不关心该事件，因此onInterceptTouchEvent方法继续返回false。
7. 此时，该MOVE事件将不会再传递给B的onInterceptTouchEvent方法，该方法一旦返回一次true，就再也不会被调用了。事实上，该MOVE以及“ 手势剩余部分” 都将传递给B的onTouchEvent方法（于是根本不会传给子view）（除非A决定拦截“ 手势剩余部分” ）。
8. C再也不会收到该手势（gesture）产生的任何事件了

  下面的一些小事情可能会令你感到吃惊：

1. 如果一个ViewGroup拦截了最初的DOWN事件，该事件仍然会传递到该ViewGroup的onTouchEvent方法中。
2. 另一方面，如果ViewGroup拦截了一个半路的事件（比如，MOVE），这个事件将会被系统变成一个CANCEL事件，并传递给之前处理该手势（gesture）的子View，而且不会再传递（无论是被拦截的MOVE还是系统生成的CANCEL）给ViewGroup的onTouchEvent方法。只有再到来的事件才会传递到ViewGroup的onTouchEvent方法中。

  从此开始，你可以更进一步：

1. 比如对覆写 requestDisallowInterceptTouchEvent，C可以用该方法阻止B窃取事件
2. 如果你想更加疯狂一点，你可以在你自己的ViewGroup中直接覆写dispatchTouchEvent方法，并对传递进来的事件做任何你想做的处理

但这样的话你可能会破坏一些约定，所以应当小心   假设不考虑事件的类型 同时考虑第一个dispatch方法，并且在三个方法中打上log，能看到事件传递过程是这样的（android群英传里写得很好）   ViewGroup能说三句话：我收到了，我转发了，我尝试处理一下 View只能说两句话：我收到了，我尝试处理一下 一个事件传递进来

1. ViewGroupA首先收到事件，说一声，我收到了
2. 但是他先不处理，它先转发给子View，然后说，我转发了
3. ViewGroupB然后收到事件，也说一声，我收到了
4. 但是他也先不处理，它先转发给子View，然后说，我转发了
5. ViewC最后收到事件，那也说一声，我收到了
6. （--------上面是事件传递过程，下面是事件处理过程--------）
7. 他直接尝试处理，说，我尝试处理一下
8. （结果发现自己无法处理，没有消耗事件，于是事件原路返回）
9. ViewGroupB收到返回的事件，那就处理一下呗，于是说，我尝试处理一下
10. ViewGroupB也收到返回的事件，也说，我尝试处理一下

三句话对应的ViewGroup的方法是（感觉对应得有点怪，因为这个中文名只是为了好记，其实并不是本意）

1. 我收到了：dispatchTouchEvent [派遣，发送]
2. 我转发了：onInterceptTouchEvent [拦截]
3. 我尝试处理一下：onTouchEvent

  然后这三个方法都有返回值

1. 前两句话是事件传递过程的
   1. 返回true，表示拦截，到此中断，就不往下走了；
   2. 返回false，表示不拦截，继续往下走
2. 第三句话是事件处理过程的（完全一模一样，只是意义不同）
   1. 返回true，表示拦截，到此中断，就不往下走了；
   2. 返回false，表示不拦截，继续往下走
3. 默认情况下，三个方法都是返回false
   1. 而每个地方其实都可以改成true，这样，回路就直接中断了
   2. 但是如果在onInterceptTouchEvent这个方法中返回true，那么不是直接结束回路，而是会跳到对应的onTouchEvent回路也就是事件处理回路中，并且所有外层的onTouchEvent都会被执行
   3. 在 onTouchEvent方法中返回true，就确实是直接中断

  而在重写方法时，虽然dispatchTouchEvent是第一步，但是我们一般不会重写它，所以我们一般关注后两个方法   论事件的流向的复杂性   事件的流向跟这几个因素有关：

1. 这个View是什么；两种情况：View、ViewGroup；会影响回调方法数
2. 这个方法是什么；三种情况：；两类情况：事件传递过程、事件处理过程；会影响后续怎么跳
3. 这个方法返回什么；两种情况：true、false；会影响是否结束回路
4. 这个事件的类型；四种情况：DOWN,MOVE,UP和CANCEL ；

所以这块的逻辑真是有点乱。。。   伪代码解释法   很多人用这段伪代码来理清三个分发方法间的关系（我个人是觉得一下子拔高了理解门槛）：

public boolean dispatchTouchEvent(MotionEvent event) {       boolean consume = false;       if (onInterceptTouchEvent(event)) {               consume = onTouchEvent(event);       } else {               consume = child.dispatchTouchEvent(event);       }       return consume; }

这段解释倒是不错：

1. 在dispatchTouchEvent中，先调用ViewGroup自身的onInterceptTouchEvent方法，判断自己是否要拦截
   1. 如果这时候自己拦截，那就调用自己的onTouchEvent方法
      1. 如果onTouchEvent方法返回了True，那么这次的事件就算消耗了，事件传递到此为止
      2. 如果返回了False，证明这次没有消耗这次MotionEvent，那么这次的事件就会往上返回，由上一级继续处理；
   2. 如果当前ViewGroup的onInterceptTouchEvent返回了False，那就会调用它的子view的dispatchTouchEvent方法，这样这个事件就传递下去了
2. 如果它的子View处理不了，那么还会回来调用ViewGroup的onTouchEvent方法，当然这一点是没有在这一段伪代码里体现的

  这就是ViewGroup层的事件分发，当然不是这么简单，这只不过是通过简单的方式去理解，其实在真实的事件分发中，有很多问题需要注意：

1. 一个完成的事件序列以Down开始，中间可能包含若干个Move，然后以Up结束
2. 一个view一旦拦截某个事件，当前事件所在的完整事件序列将都会由这个view去处理
   1. 反应在真实的代码中，就是一旦view拦截了down事件，那么此后的move和up事件都将不调用onInterceptTouchEvent，而直接由它处理
   2. 这就也意味着在onInterceptTouchEvent处理事件是不合适的，因为有可能来了事件，却直接跳过onInterceptTouchEvent方法
   3. 这个也意味着，一旦一个ViewGroup没有拦截ACTION_DOWN，那么这个事件序列的其他Action，它都将收不到，所以在处理ACTION_DOWN的时候，尤其需要谨慎
   4. （ 哦，所以这就很清晰了，dispatch只是入口，它什么都不干，然后intercept是一个第一次拦截的标志，只会被调用一次，最后ontouch才是真正处理事情，根据不同的event做不同的处理 ）
3. onTouchEvent中是要判断MotionEvent的Action，因为一次点击操作就会调用两次onTouchEvent方法，一次是ACTION_DOWN，一次是ACTION_UP，如果手滑一下，还会有若干个ACTION_MOVE
4. ViewGroup默认不拦截任何事件，源码中ViewGroup的onInterceptTouchEvent方法默认返回的是false
5. 整个事件分发，看起来都是由外向内传递的，父View将事件传递给子View，理论上来看，子View是没有办法影响到父View的事件处理的，但是有一个标示位，requestDisallowInterceptTouchEvent方法，通过这个方法 ，子View能够影响父view的事件处理，这个可以用于解决父view和子view的滑动冲突

  参考资料：http://www.jianshu.com/p/2be492c1df96

推荐阅读

• 

  金元宝简笔画
• 

  顺丰速打软件如何过滤掉重复单？
• 

  对不起，您的撒娇限额已到期！
• 

  王者荣耀中那个英雄最值得去练？
• 

  钱乐宝有下款的吗？钱乐宝支付宝认证不了怎么回事
• 

  消防改革吧十月底涨工资 消防改革吧最新
• 

  荨麻疹|荨麻疹很难好吗？专家提醒：做好4点，烦恼渐渐去除
• 

  绝地求生跑毒杀人决战吃鸡流程图文攻略 怎么吃鸡 整体思路
• 

  住宅梦物语完美房间攻略 住宅梦物语初期如何打造完美房间
• 

  如何还原照片清晰度，怎样恢复图片的分辨率和清晰度
• 

  你见过演技最差的明星是谁？
• 

  翡翠挂件用什么链佩带，翡翠挂件怎么戴
• 

  犀牛是什么软件
• 

  3200频率选什么cpu，3200频率可以超多少
• 

  离婚按揭房变更房产贷款人 离婚按揭房如何变更
• 

  黄金变黑了怎么清洗
• 

  2023内乡县养老保险待遇认证时间 内乡县社保服务中心
• 

  瓷都景德镇位于哪个省 瓷都景德镇在哪个省
• 

  新手小白如何做新媒体运营师，新媒体运营小白如何入行?
• 

  本人失业中,什么都没有,什么都不会,自己可以做点什么小生意？

• No.2 IonicAndroid打包
• Android 手机卫士--自定义属性
• Android Multimedia框架总结（十四）Camera框架初识及自定义相机案例
• 程序员带你学习安卓开发系列-Android文件存储
• Android独立音量播放器
• android MVP模式初认识-1
• android studio出现Error:compileSdkVersion android-x requires compiling with JDK 7问题
• Android Studio 快捷键一览
• Android数据库的运用