因此下面的工作流程中都是指down事件的分发 ，而不是ACTION_MOVE或ACTION_UP的分发。因为消费了down事件，意味着接下来的move和up事件都会给这个view处理，也就无所谓分发了。但同时注意事件序列是可以被viewGroup的onInterceptTouchEvent中断的，这些就属于其他的情况了。
细心的读者还会发现事件分发中包含了多点触控。在多点触控的情况下，ACTION_POINTER_DOWN与ACTION_DOWN的分发规则是不同的，具体可前往第二篇文章了解详细。ACTION_POINTER_DOWN在ACTION_DOWN的分发模型上稍作了一些修改而已，后面会详细解析，
工作流程模型工作流程模型，本质上就是不同的控件对象，viewGroup和view之间事件分发方法的关系。需要注意的是，这里讨论的是viewGroup和view的默认方法实现，不涉及其他实现类如DecorView的重写方法。
下面用一段伪代码来表示三个事件分发方法之间的关系（ 这里再次强调，这里的事件分发模型分发的事件类型是ACTION_DOWN且都是默认的方法，没有经过重写，这点很重要 ）：
public boolean dispatchTouchEvent(MotionEvent event){ // 先判断是否拦截 if (onInterceptTouchEvent()){ // 如果拦截调用自身的onTouchEvent方法判断是否消费事件 return onTouchEvent(event); } // 否则调用子view的分发方法判断是否处理事件 if (childView.dispatchTouchEvent(event)){ return true; }else{ return onTouchEvent(event); } }这段代码非常好的展示了三个方法之间的关系：在viewGroup收到触摸事件时，会先去调用 onInterceptTouchEvent 方法判断是否拦截，如果拦截则调用自己的 onTouchEvent 方法处理事件，否则调用子view的 dispatchTouchEvent 方法来分发事件。因为子view也有可能是一个viewGroup，这样就形成了一个类似递归的关系。
这里我再补上view分发逻辑的简化伪代码：
public boolean dispatchTouchEvent(MotionEvent event){ // 先判断是否存在onTouchListener且返回值为true if (mOnTouchListener!=null && mOnTouchListener.onTouch(event)){ // 如果成功消费则返回true return true; }else{ // 否则调用onTouchEvent消费事件 return onTouchEvent(event); } }view与viewGroup不同的是他不需要分发事件，所以也就没有必要拦截事件。view会先检查是否有onTouchListener且返回值是否为true，如果是true则直接返回，否则调用onTouchEvent方法来处理事件。
基于上述的关系，可以得到下面的工作流程图：
这里为了展示类递归关系使用了画了两个viewGroup，只需看中间一个即可，下面对这个图进行解析：
viewGroup
viewGroup的dispatchTouchEvent方法接收到事件消息，首先会去调用onInterceptTouchEvent判断是否拦截事件
如果拦截，则调用自身的onTouchEvent方法
如果不拦截则调用子view的dispatchTouchEvent方法
子view没有消费事件，那么会调用viewGroup本身的onTouchEvent
上面1、2步的处理结果为viewGroup的dispatchTouchEvent方法的处理结果，并返回给上一层的onTouchEvent处理
view
view的dispatchTouchEvent默认情况下会调用onTouchEvent来处理事件，返回true表示消费事件，返回false表示没有消费事件
第1步的结果就是dispatchTouchEvent方法的处理结果，成功消费则返回true，没有消费则返回false并交给上一层的onTouchEvent处理
可以看到整个工作流程就是一个“U”型结构，在不拦截的情况下，会一层层向下寻找消费事件的view。而如果当前view不处理事件，那么就一层层向上抛，寻找处理的viewGroup。
上述的工作流程模型并不是完整的，还有其他的特殊情况没有考虑。下面讨论几种特殊的情况：
事件序列被中断我们知道，当一个view接收了down事件之后，该触控点接下来的事件都会被这个view消费。但是，viewGroup是可以在中途掐断事件流的，因为每一个需要分发给子view的事件都需要经过拦截方法：onInterceptTouchEvent （当然，这里不讨论子view设置不拦截标志的情况）。那么当viewGroup掐断事件流之后，事件的走向又是如何的呢？参看下图：（注意，这里不讨论多指操作的情况，仅讨论单指操作的move或up事件被viewGroup拦截的情况）
当viewGroup拦截子view的move或up事件之后，会将当前事件改为cancel事件并发送给子view
如果当前事件序列还未结束，那些接下来的事件都会交给viewGroup的ouTouchEvent处理
此时不管是viewGroup还是view的onTouchEvent返回了false，那么将导致整个控件树的dispatchTouchEvent方法返回false