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方法

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

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

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事件，两者是独立的

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方法，并对传递进来的事件做任何你想做的处理

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

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

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

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

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的滑动冲突

Android事件分发机制理解