1、在ViewGroup中，事件分为dispatchTouchEvent（事件的分发），onInterceptTouchEvent（事件的拦截），onTouchEvent（事件的处理）。
2、在View中，事件分为dispatchTouchEvent（事件的分发），onTouchEvent（事件的处理）。
可以简单理解为，首先调用dispatchTouchEvent，其内部调用onInterceptTouchEvent。 我们一般并不会对dispatchTouchEvent进行修改，只会对事件进行拦截。也就是调用onInterceptTouchEvent，修改进返回值。
part1:我们以上面的图为例，当down、move、up事件触发在MyView时，整个事件是这样的：
结合流程图，不难发现，如果我对事件既不拦截，也不消费，当触发ACTION_DOWN的时候，事件会经过Activity——MyViewGroupA——MyViewGroupB——MyView一层层的向下进行dispatchTouchEvent（分发）—onInterceptTouchEvent（拦截）调用。当到达最底层MyView后，开始触发消费操作，因为我均不消费，ACTION_DOWN将由底层一层层向上冒，移交上层处理。当抵达最上层Activity后，说明下层均不消费，之后触发的ACTION_MOVE和ACTION_UP将不再向下层分发传递，直接交由Activity分发给自己进行处理。
part2:我们将MyVIewGroupB的onInterceptTouchEvent返回值改为true，其他均是super。这意味着仅仅MyViewGroupB进行事件拦截，但均无消费, 当将onInterceptTouchEvent改为true时，会直接调用同层的 onTouchEvent!
当触发ACTION_DOWN的时候，事件依然是从Activity开始一层层向下传递，当传递到MyViewGroupB时，因为进行了事件拦截，所以执行完onInterceptTouchEvent后不再向下传递，而是直接交由MyViewGroupB的onTouchEvent进行消费处理。由于我们是只拦截，不消费，所以事件向上传递，交由上层处理，最终回到Activity。之后触发的ACTION_MOVE和ACTION_UP也不再向下传递，直接交由Activity分发给自己处理。
part3:我们还是将MyViewGroupB的onInterceptTouchEvent返回super，但是将他的onTouchEvent返回true。这意味着我们不拦截，但是由MyViewGroupB进行事件处理。
可以看出，当触发ACTION_DOWN的时候，事件的分发传递过程和1的时候一样，从Activity开始一层层向下传递，最终传递到最底层MyView，触发消费操作，然后MyView将消费操作移交上层处理，然后到达MyViewGroupB的onTouchEvent，并且进行了消费处理，事件处理到此不在向上移交。当触发ACTION_MOVE和ACTION_UP操作时，事件依然需要由Activity开始向下分发传递，但是当传递到MyViewGroupB后，由于其消费了ACTION_DOWN，事件将不再继续向下分发，而是直接由MyViewGroupB分发给自己的onTouchEvent进行继续处理。事件处理也不再向上移交。
part4:将MyViewGroupB的onInterceptTouchEvent和onTouchEvent的返回值均改为true。这意味着既拦截，又消费。
当触发ACTION_DOWN的时候，依然从Activity开始向下传递，当到达MyViewGroupB的是，因为在onInterceptTouchEvent进行了拦截操作，因此不再继续向下分发传递，而是交由MyViewGroupB的onTouchEvent进行处理消费。MyViewGroupB的onTouchEvent返回的是true，说明它决定对ACTION_DOWN进行处理，因此事件也就不再移交上层处理。当触发ACTION_MOVE和ACTION_UP的时候，事件还是从Activity开始向下传递，当到达MyViewGroupB的时候，由于之前进行了拦截操作，因此，MyViewGroupB直接将事件分发给自己的onTouchEvent进行处理，不在向下分发传递。事件处理也不再向上层移交。
总结：
可以看出，最终是否消费，是靠onTouchEvent的返回值确定！ 当down事件被某层消费，则move、up事件会按照先从上到下，再平行从左到右的路径，进行消费！ 看懂这4part，整个流程也就比较清晰了。
网友评论