Android事件分发机制的理解

1、首先假设：有一个Activity 里面有一个ViewGroupA（这是你爷爷）,A里面有一个ViewGroupB（这是你爸爸），B里面有一个View，这就是你了。

2、先说down事件。任何操作都是由down事件开始的，down事件的传播目的就是为了找到这个事件的直接处理者。down事件到达的时候依次从你爷爷--你爸爸-你，看谁可以处理这个事件，你如果处理不了就再向上到你爸爸的onTouchEvent--你爷爷的onTouchEvent，如果所有的View和ViewGroup都不能对down事件返回true，也就是view中没有事件的直接处理者，那么down事件就会被activity的onTouchEvent消费，这些View和ViewGroup就不会收到后续的一系列事件了，后续事件全部传递给activity。

3、如果只有你爸爸拦截了down事件，那就调用你爸的onTouchEvent方法去处理，能处理，后续的事件正常分发，不能处理，那你拦截我做什么？蛇精病！最终还是层层网上看有没有谁可以处理，如果都不能，那这个事件就还是没有直接处理者，down事件最终会让activity消费，这样的话View和ViewGroup也不会收到后续的一系列事件了。

4、孙子处理了down事件，那也就是孙子是这个事件的处理者了，后续事件应该依次传给孙子。可是爸爸拦截了move事件，
这样你爸就变成了事件的直接处理者了，
当继down之后的第一个move到达的爸爸时候，爸爸就把它变成了一个cancle事件，并且继续往下传递，用来通知你，现在由他来处理这个事件了。后续事件到达的时候就直接从你爸的dispatchTouchEvent到你爸的onTouchEvent了，这些事件你爸能处理就处理，处理不了就传给activity而不是你爷爷!
5、你爷爷（根节点）拦截了down那就认定你爷爷是事件的处理者了，并不调用你爷爷的onTouchEvent处理down事件，后续事件到达的时候，就直接从你爷爷的dispatchTouchEvent到你爷爷的onTouchEvent了，你爷爷能处理就处理，处理不了就交给activity。

6、假如你现在也有儿子了，那你就是一个viewGroup了，你就有事件拦截方法了，你虽然拦截了down事件，但是你的onTouchEvent返回false也就是你自己不能处理，层层网上到你爸的onTouchEvent你爸帮你处理了，也就是你爸才是直接处理者，那后续事件直接从全部你爸的dispatchTouchEvent到你爸的onTouchEvent了，你爸能处理后续事件就处理，处理不了就到activity的onTouchEvent了，反正没你啥事儿了

7、一句话总结，对于一个动作，View的事件拦截方法一旦返回true，就不会再次调用。默认都返回true了。谁在onTouchEvent中对down事件返回true，谁就是这个事件的直接处理者，后续事件将从VIew树上，以最短路径传递到事件的直接处理者的onTouchEvent。如果后续事件在传递过程中被某个先辈（你爸、你爷爷）所拦截（事件当前的直接处理者是拦截者的后辈），这个后续事件会变成一个Cancle事件传递给事件当前的直接处理者，用来通知你做某些清除工作，然后拦截事件的那个先辈就变成了事件的直接处理者了，后面的后续事件就交给他处理了，不会再传递给你了。。他能处理就处理，不能处理就交给Activity。

语文不好，不知道有没有说清楚。如果有错漏的地方，欢迎大神留言讨论！