Android 的事件分发研究

一直都android的各种事件很是觉得好奇，工作当中也曾因为一个返回值出现很多问题。接下来我就用一个简单的例子来自我描述下事件的分发机制。

1. Android的事件无非就是这三个dispatchTouchEvent, onInterceptTouchEvent 和onTouchEvent.故名诗意。他们分别代表着事件的分发，拦截和处理。此三者之间存在一个什么关联的。如图：

备注：针对于activity，父view和子view的事件传递。

说明：以上的流程关系图仅限于当所有的事件都是正常的默认返回值的时候。事件处理的过程是step1-step2-step3-step4-step5-step6-step7-step8

2.针对于以上的正常情况下，我们来尝试改变一下各个事件的返回值。首先修改activity里面的dispatchTouchEvent.使之return true看是什么情况：

从上面结果来看，如果在activity的dispatchTouchEvent returntrue的话，事件不会继续传递下去，并且activy本身的onTouchEvent事件也不会执行。而所有的处理只是在本dispatchTouchEvent中处理。

如果不改变activity里的dispatchTouchEvent的返回值而是改变父view里的值为true呢？大家猜猜回事是什么情况？

实际结果：

不错结果和预想的一样，事件在父view里面开始终止传递，并且处理也会在本身的view里面dispatchTouchEvent做处理和上面不同的是，会向上传递。传递给activity。

通过上面两个实验，第三中在子view里面改变dispatchTouchEvent的值应该也是会向上传递，在子view的dispatchTouchEvent内进行事件处理而不去执行子view的onTouchEvent事件。在这里就不再做实验了。

3. 尝试改变各个view的onInterceptEvent事件的返回值为true会是什么情况。

如果改变父view的拦截事件的返回值为true。会是怎样？敢大胆的猜测吗？

实际输出结果：

通过输出结果可以看到，父view成功拦截事件。也就是说事件不会再传递给子view，但是会继续网上传递。把事件交给自己的onTouchEvent去处理。

如果改变子view的拦截还回值呢？大家不用我再解释了，理解到上面的知识，下面的结果不难猜出。没错就是这样的：

只要ziview不再有子view在这个demo里传递就等于是正常传递了，如果还有子view那就和上面的情况一样了。

总结：讲了这么一些，下面我们可以简单形象的总结下。针对以上三种事件的关联无非就是上级对下级任务的派发执行。

dispathTouchEvent是每个级别的派发部门一旦接受到任务，他就分发出去，这时候就被多管闲事的onInterceptEvent所拦截了，他非要看看这个事情可不可以继续安排下去，如果他点头了，那么事情就可以继续传递下去，让小兵onTouchEvent进行具体处理。否则的话就不往下传递了就让自己部门的小兵处理。小兵处理完之后再一级级向上汇报。就这样完成了整个事件的流程。