事件分发机制，是指将一系列事件分发到某个View执行的过程，分发流程为Activity ->phoneWindow->DecorView->ViewGroup->View,从上往下分发，然后事件处理顺序是从下往上，View最先处理，如果都不处理则会交给Activity处理。
有三个具体的方法。
public boolean dispatchTouchEvent(MotionEvent ev)；分发方法
public boolean onInterceptTouchEvent(MotionEvent ev) ;拦截方法 该方法只有ViewGroup才有
public boolean onTouchEvent(MotionEvent event); 处理方法 该方法只有Activity 和 View才有
基本的事件
ACTION_DOWN 按下屏幕时出发
ACTION_MOVE 滑动时触发，会执行多次
ACTION_UP 抬起时触发
ACTION_CANCEL 事件被上层拦截时触发
基本逻辑差不多是这样，但是还不知道为什么，让我们来看看关于事件分发，源码里是怎样的。
先从Activity开始。
onUserInteraction（）为空方法，不管它。来看这句代码。 getWindow().superDispatchTouchEvent(ev) ，可以看出该方法返回true，则结束，返回false，则会调用自己的onTouchEvent()，进去看看
superDispatchTouchEvent()方法为window的抽象方法，window的唯一实现类为phoneWindow,我们进入phoneWindow看看
phoneWindow中实现了superDispatchTouchEvent()并调用了mDecor.superDispatchTouchEvent(event)，并把返回值返回，mDecor就是 DecorView 的对象，我们进入 DecorView类
在DecorView类中调用super.dispatchTouchEvent(event)，就会调用到ViewGroup的dispatchTouchEvent
到这里我们印证前面所说的分发流程，并发现所有的dispatchTouchEvent()方法的返回值都是根据其下一层的dispatchTouchEvent的返回值，
这说明是从下往上返回。然后我们开始分析ViewGroup中的dispatchTouchEvent()方法,我们假设此时为down事件
先是在DOWN事件下，重置一些参数
其中比较重要的一点是，mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT，结合上上图中final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;代表着在DOWN事件下disallowIntercept肯定为false，则onInterceptTouchEvent()拦截方法肯定会执行
接着往下
这里判断了if (!canceled && !intercepted) ，假如事件没有canceled，也没有被拦截
这2张图结合起来看，从最外层的if(actionMasked == MotionEvent.ACTION_DOWN || (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN) || actionMasked == MotionEvent.ACTION_HOVER_MOVE)来看，当前为DOWN事件，进入，然后进入到if(newTouchTarget == null && childrenCount != 0)，newTouchTarget在前面已经被=nul了，childrenCount肯定也不会等于0，然后继续进入，然后来看看buildTouchDispatchChildList()这个方法
这个方法的主要作用为，根据View的Z值从小到大进行排序(最上层的View则Z值最大),然后放入ArrayList中返回，结合上上图中的for (int i = childrenCount - 1; i >= 0; i--)倒着拿数据，意味着最先拿到的View为最上层的，则印证了最开始的观点，最上层的View先处理事件。根据代码中拿到的View，然后判断当前点击的位置是否是View的区域中，如果不是则continue，进行下一次循环，继续往下
来看看dispatchTransformedTouchEvent()方法，注意该方法的参数
此方法的后半段，判断child，此时会调用handled = child.dispatchTouchEvent(transformedEvent);则就分发到了child中，则调用了View的dispatchTouchEvent(),进入到View的 dispatchTouchEvent()一看
这部分的逻辑可以看出，onTouch方法会优先于onTouchEvent方法，如果onTouch方法返回了true则onTouchEvent不会执行，这2个方法任意一个返回了true，则result=true，并返回，则代表着事件得到了处理，然后我们回到前面ViewGroup的if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign))，(上上上图)，如果事件得到了处理，则会进入到这个if中来，这里面将alreadyDispatchedToNewTouchTarget设置为true并调用了addTouchTarget()方法，然后break循环(倒着拿View的for循环)，进去 addTouchTarget 看看
这里用链表的方式将链表表头mFirstTouchTarget赋值，将target.next至于null，因为一开始 mFirstTouchTarget =null,至此结束循环。事件得到了处理，并将 mFirstTouchTarget指向该View
这时候mFirstTouchTarget不等于null，然后进入while，将mFirstTouchTarget赋值给target，判断target！=null，然后后又将next = target.next，next=null。然后又将next赋值给target，while循环结束，说明此循环只执行一次。然后前面在事件得到执行的代码中，alreadyDispatchedToNewTouchTarget设置为了true，addTouchTarget方法中又将mFirstTouchTarget赋值给了newTouchTarget，然后mFirstTouchTarget又赋值给了target，则if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) 成立 handled = true; 然后返回给dispatchTouchEvent
到此Down事件分析完毕，我们接着分析MOVE事件
又回到了这里，这是的mFirstTouchTarget！=null了。但还是会进入到拦截方法中来，接着往下
这时的actionMasked为MOVE事件了。所以也不会往下面走了，也不会进入到循环获取view进行分发的逻辑中了，直接跳过
还是一样mFirstTouchTarget不为空，将mFirstTouchTarget赋值给target，进入while，注意，此时这里的alreadyDispatchedToNewTouchTarget=false
因为在判断拦截标志和canceld时初始化为false了，然后则又会调用dispatchTransformedTouchEvent(ev, cancelChild, target.child, target.pointerIdBits),则又会调用handled = child.dispatchTouchEvent(transformedEvent);注意这里的target.child，这个child其实就是在事件得到处理的时候，addTouchTarget方法中赋值的，代表着之前down事件时获取到事件的View = target.child，我们来看看是怎么赋值的
obtain方法进去
至此，得出一个结论，在某一个View处理了down事件之后，后面的MOVE事件都是交给该View来执行
然后，当然了，在事件拦截方法中，返回true会怎么样
拦截的话，则该if进不去，则后面的for循环拿View分发，链表表头mFirstTouchTarget不会被赋值，则会调用
这时child参数为null，则
super.dispatchTouchEvent(transformedEvent)自己处理。
如果某一个View处理了事件，mFirstTouchTarget被赋值，之后在MOVE事件的时候该事件又被父View拦截则会怎么样呢
还是一样，会调用dispatchTransformedTouchEvent()方法，但是此时的cancelChild为true了，因为final boolean cancelChild = resetCancelNextUpFlag(target.child) || intercepted; 这句代码中的intercepted==true， dispatchTransformedTouchEvent的第二个参数为true了，然后还能看到下面的判断，predecessor==null，将mFirstTouchTarget设置为null了，然后我们再次进入dispatchTransformedTouchEvent方法
可以看到，将此事事件设置为了ACTION_CANCEL，再执行handled = child.dispatchTouchEvent(event)，然后我们再走一遍流程，记住此时的mFirstTouchTarget=null，
可以看到，在MOVE事件，mFirstTouchTarget也被赋值为null，则直接等于拦截，然后又会回到之前分析过的流程，ViewGroup自己处理，得出结论，ACTION_CANCEL为当事件被上层拦截时出发。
还有一个方法忘了分析，就是requestDisallowInterceptTouchEvent()
告诉父控件不要拦截我，那么是怎么做到的呢？
看到这里就明白了把，就是修改mGroupFlags的值，来做到不走拦截方法，但是DOWN事件除外，因为之前前面分析过了，在DOWN事件的时候会重置 mGroupFlags的值。
大概的流程就是这样，如果有分析的不对和遗漏的地方，多多包涵。
