概述

UI是Android开发中非常重要的一部分，而事件分发体系是UI开发的重点也是基础。所以，为了能够实现丰富漂亮的UI，这里以简单明了的比喻阐述下分发机制的原理，分析下源代码。

比喻

如果将Activity比作一家事件处理公司的话，那么有些概念就比较好理解。首先，董事长（Activity）管理着所有的管理层和员工（ViewGroup和View），当有业务发生的时候（Touch事件），董事长会吩咐他的秘书（PhoneWindow）去处理这件事情，当然，秘书也不可能自己处理，所以他会告诉总经理（DecorView）说现在有一笔业务，需要在公司内找到合适部门或者人来完成这件事情。
这里呢，公司在成立之初就已经定下了业务执行的规范和流程，以免发生职责不清和层级不明的情况：
1、分发业务（dispatchTouchEvent）：所有的业务都必须由总经理往下分配，且必须依次询问他所直属的部门和个人（DOWN事件），如果有个人或者部门反馈说能够处理这笔业务（return true），那么总经理就将接下来所有的与该笔业务有关的事物（MOVE，UP事件），都交给其处理。
2、所有部门（ViewGroup）都有与总经理相同的处理流程。部门会依次询问其下的员工和子部门，如果有子部门或员工反馈说能够处理，那么该部门就反馈给上级说，这件业务本部门可以处理。但是需要注意一点。所有的部门只能够知道其下级部门和个人的情况，而不能知道子部门的内部的情况。
3、部门如果依次询问了子部门或者员工，发现都无法处理该业务，那么部门本身会去评估自己是否能够处理该业务（调用父类（View)的dispatchTouchEvent方法，这时处理方式和普通的View一样）。然后将能否处理的反馈返回给上级。如果任何一个子部门或者员工反馈了能够处理，那么部门将不会再去评估自己能否去处理，直接反馈能够处理。反馈后将记住能处理的部门或员工。
4、部门还有员工没有的特殊权利，是能够拦截任务的分发。其拦截权利可以是在分发的过程中，也可以是任务执行到一半的时候。如果该部门的子部门或者员工已经拿到该事件的处理权了。那么后续的事件都会经过该部门进行分配。其有权利在任何时刻拦截该任务，一旦拦截了该任务，那么将交由自己来处理。同时非常重要的一点，该部门将会忘记其原先的分配对象，以后每次事件过来，都不会再去分配下去（因为已经忘记了~）。
5、员工或者子部门也有特殊的权利，那就是一开始就告诉部门不要去拦截事件（disallowIntercept），这个优先级要比拦截的优先级要高，所以一旦设置了这个，那么上级部门将无权去拦截。
6、任何部门和个人都有评估和处理的方法（View是onTouch、onTouchEvent。如果子控件不处理，ViewGroup会调用自己的dispatchTouchEvent方法，这和View的过程一样）。处理时有一套默认的流程，但是由于每个部门和个人的情况不一样（不同的VIew和ViewGroup），所以也会有自己独特的处理办法（重写onTouchEvent方法等）。判断后返回自己的申明（true或false）。
7、员工（View）和部门有一点区别（ViewGroup重写了dispatchTouchEvent方法）。员工在分发事件（dispatchTouchEvent）时，由于没有下属，所以他会根据自身的情况来判断能否处理该业务（与ViewGoup没有子类处理交给自身判断一样）。首先他会判断自己是否有整体处理的能力（OnTouchListener），如果有的话那么他会判断自己是否愿意整体处理这个业务（onTouch方法的返回值），如果是的话，那么就反馈，不会去细致处理。
8、如果没有整体处理的能力，那么员工会去判断自己是否能够细致处理（onTouchEvent，默认方法中会去判断CLICKABLE等标志）的能力，如果有的话，则反馈。一般，如果我们自定义员工的话，可以自定义处理的方式。
9、在处理事件的时候，员工会从事件中抽取出相应的模式（onClick，onLongClick），告诉客户需要去处理这件事（具体看点击的功能，程序员去处理）。
10，最后，如果没有部门或者员工去处理这笔业务的话，那么会回传到公司（Activity）自身，那么只能公司自己去处理了（onTouchEvent）。

总结

这里以一种形象的方式讲了事件分发机制。下篇会简要分析下分发的源代码。