一直以来，都被Android中的事件传递和处理机制深深的困扰！今天特意来好好的探讨一下。现在的感觉是，只要你理解到位，其实事件的传递和处理机制并没有想象中的那么难。总之，不要自己打击自己，要相信自己能掌握这块知识。好了，下面是我今天的收获，希望也能对你有一点帮助。
一、拟人化来理解android中的事件机制
其实android中的事件传递与处理机制跟我们生活中的事件处理是一样的。这里有一个生活中的例子，很能说明这个问题。阐述如下：
你是一个公司的员工，你的上头有一个主管，主管上头呢还有一个经理。为了简单，你们这个团队就有这三个人。那么如果上头安排一件事下来要处理，流程是怎样的呢？
显然应该是由你的经理将这件事安排给你的主管来处理，你的主管再将这件事安排给你来处理。等你把这件事办好了，你就应该给你的主管报告，再由你的主管来向你的经理
报告。显然，你的主管和经理也有处理这件事的权限，如果他们觉得事情很复杂，你办不了，或者他们比较照顾下级，可能就自己把这件事给办了，这个时候这件事就不会再
传递给下一级来处理了。这个事件处理的过程，是不是太容易理解了！
其实android中的事件处理流程就是跟生活中的事件处理是一样的。比如你在ViewGroupA中嵌套了一个VewiGroupB，然后又在ViewGroupB中嵌套了一个MyView。那么一个触摸事件传递过来，会发生什么情况呢？类比上面的公司员工的处理事件，显然会发生下面的过程：
触摸事件传递过来后，ViewGroupA一看自己里面还有一个员工可以利用，就是ViewGroupB，那不用白不用，就会把这个事件传递给ViewGroupB，告诉他，你给我把这个事件处理了！
ViewGroupB呢一看，我不怕，我里面也有一个员工就是MyView，它得给我干活，于是又会把这个事件传递给MyView，让它来处理。MyView一看，没办法啊，我手底下没有员工了，那怎么办，我只能自己处理了（前提是它有处理这个事件的能力），所以就把这个触摸事件给处理了。处理完成后呢？MyView就是给ViewGroupB报告，我已经把事情办好了，你来审核一下，看看办理的咋样。ViewGroupB一审核，觉得不错，就再将结果呈现给ViewGroupA。ViewGroupA再审核，通过了才算通过。在这个过程中，也可能出现几种情况：
（1）MyView说，完蛋了，这事我的能力办不好啊，于是就向VeiwGroupB报告，我没有处理，请你来处理，你是我上司，能力比我强。于是ViewGroupB就会来帮忙处理。当然了，如果ViewGroupB也没能力处理，那就只能反馈给VeiwGroupA，让它来消化这个事件。
（2）也可能MyView处理非常完美，向ViewGroupB一报告，ViewGroupB一开心就说不用再交给ViewGroupA审核了，我担保通过，于是事件到此直接终止。
上面用很形象的话来讲adnroid中的事件传递和处理机制讲解了一下。android用下面的几个方法将上面的过程完美封装了：
在ViewGroup中，有下面三个方法：
（1）dispatchTouchEvent 该方法用来分发事件，一般不会重写这个方法
（2）onInterceptTouchEvent 用来拦截事件
（3）onTouchEvent 用来处理事件，这个方法应该大家很常见了吧
而View中，只有两个方法，即：
（1）dispatchTouchEvent 该方法用来分发事件，一般不会重写这个方法
（2）onTouchEvent 用来处理事件，这个方法应该大家很常见了吧
那么我们就来写一个实际的代码，来验证一下这些方法都对应上面的哪些过程。这样子就会对这个些方法有更透彻的理解。