android 拦截机制的分析

      平常经常用到 onTouchEvent()这个方法，在重写view对触摸事件的处理时返回true对触摸事件进行响应处理.......

       今天对android拦截机制做一下总结，形象比喻来说这拦截机制像一个效能好高的机制一样。

        假设显示在屏幕中有三层view，第一层viewgroupA、第二层viewgroupB，第三层就是我们想看到的myview，当我们重新这些view时发现viewgroup中有三个处理触摸事件的方法dispatchTouchEvent()，onInterceptTouchEvent()，onTouchEvent()三个方法;重写myview的时候发现只有dispatchTouchEvent()和OntouchEvent()两个方法。

        好了好戏开场了，当我们点击屏幕的时候最先感应到点击事件的是viewgroupA（第一层），viewgroupA对事件迅速做出处理：先经过方法dispatchTouchEvent()分发事件吧，分配之后先自己考虑一下经过方法onInterceptTouchEvent()，看看自己能不能做——1）false不能做，接着往下走分给viewgroupB对事件进行处理同样先经过方法dispatchTouchEvent()分发事件吧，分配之后先经过方法onInterceptTouchEvent()自己考虑一下，看看自己能不能做，接着返回false自己不能做，事件终于落到了myview的头上芝麻的大的官也有模有样的学者对事件进行分发onInterceptTouchEvent()没人理没人抢好了自己直接干吧myview的onTouchEvnt()方法上场,myview是个低调的人做完事不要求领赏onTouchEvnt()方法返回true不告诉上级整个方法走完了,myview是个高调的人做完了给上级反映一下返回false让上夸奖一下，经过viewgroupB的onTouchEvnt()然后viewgroupB在看看myview做的怎么样啊，好了（返回false）直接反应给viewgroupA接着冒名顶替，不好（true）直接给你拦截掉。。。

2)返回true，viewgroupA自己能做，好了直接由viewgroupA的onTouchEvent()方法进行处理完事。。。

3)返回false，viewgroupA没有拦截交给viewgroupB处理，到viewgropeB的onInterceptTouchEvent时候返回true拦截掉可以自己干，进入viewgroupB的ontouchEvent的方法进行处理，处理完成选择告诉不告诉viewgroupA，ontouchEvent返回false告诉viewgroupA，进入viewgroupA的ontouchEvent的进行处理。

总结：情况比较多不做一一举例子，简单来讲就是分配事件的时候经过dispatchTouchEvent(),在经过viewgroup的onInterceptTouchEvent()看看是拦截掉自己做还是给下一级别做。

做事情的时候就是onTouchEvnt()，通过返回true（不告诉上级）做了事情不炫耀低调行的；返回false（告诉上级）做了事情很高调告诉上级，再有上级同样的处理方法.....