宝贝到底归谁？（Android View事件分发机制）

    在《Android开发艺术探索》一书中，作者大篇幅的讲解了关于View的事件体系。对于这一章节的内容，我有较多想要叙述和温习的地方，所以，在以下的文章中，我会着重与阐述关于整个View和ViewGroup的事件分发机制以及我对他们的理解。

一、什么是事件
首先，了解Android中View的事件分发机制，就必须先知道什么是事件？在手机软件中，每个不同部分的内容或者组件几乎都有一项基础的功能，那就是点击，拖动，长按，等等。这些动作，会被Android系统进行拦截，并且拆分成不同的动作类型，而后交由各个对应的组件完成处理，最终处理结果反馈给用户。那么，我们可以粗略的认为点击，拖动，长按，等等用户产生的与屏幕点击有关的动作就是事件，这一系列的动作就被成为一个完整的事件。事件的产生也就推动了整个Android系统分发机制的产生和完善。

二、事件拦截，事件分发
既然有了一整套完整的事件，那么就会产生几个问题，一个界面上有许许多多的组件，他们都可以对这一整套事件进行拦截和处理，那么应该交给谁呢？谁又是真正需要这整套事件的组件呢？这些问题将由Android系统中的事件分发机制来进行解答。在详细描述事件分发机制前，我要先明确一个概念，那就是事件拦截。因为有了事件拦截，所以手机中的各个组件也才能捕捉得到整个事件。也是通过事件拦截，才能判断这整套事件应该有谁处理，谁想要进行处理。于是，对应着事件拦截，现在我要隆重介绍这个函数，那就是public boolean onInterceptTouchEvent（MotionEven ev）。如果把整个事件理解为一件宝物，那么对于这个函数而言，他就是宝物的竞拍人，他会对这个宝物（事件）进行分析，看看自己对宝物有没有兴趣，看看自己有没有能力将宝物收入囊中，如果有兴趣，有能力，则会亮出自己的竞价牌（返回true），否则他将放弃竞争机会（返回false），而后将宝物收入自己囊中（交由家里人进行处理）。

   现在就会有两种情况发生，第一种情况，如果第一个竞价人（View组件）顺利的拿下了这件宝物（拦截事件，onInterceptTouchEvent 函数返回true），则他会将这一系列的点击事件交给家中人进行进一步的处理。第二种情况，如果第一个竞价人没有意愿或者没有能力拿下这一宝物（不拦截事件，onInterceptTouchEvent 函数返回false），那么拍卖行（系统）就会询问下一个竞拍人（下一层的View组件），以此类推，直到找到需要或者有能力拿下宝物的人出现，如果问遍了拍卖行中的所有竞拍人，都没有人回应，那么，拍卖行就会自行将其进行处理。

   在拍卖行进行逐个人询问时，如何来确定询问的那个人是否有资格来进行竞拍呢？这个时候，就会需要每个竞拍人都要挂有一个入场证，也就是函数 public boolean dispatchTouchEvent（MotionEvent ev）。只要有这个牌子，那么这个人就可以进场参加拍卖。而且每次在上个竞拍人（上层View组件）没有成交后（未拦截事件），拍卖行都会先查看下个拍卖人的挂牌（调用dispatchTouchEvent 函数），之后，再询问其是否会竞拍该宝物。

三、事件处理
在拍卖人把宝物拿回家之后，就会按照家中辈分顺序来对这件宝物进行处理，首先是大哥onTouch（），如果大哥能把这件宝物处理好，那么他就会告诉大家，宝物在我这里处理OK啦（onTouch返回true）。那么后边的二哥onTouchEvent（）便不会再过问。交易行也会得知这一消息，并且不再挂出该宝物（该事件信息）。

   但是，如果大哥发现这件宝物在他这里没有处理好，那么他就会告诉大家，哎鄙人没办法处理这个宝物啊喂（onTouch返回false）。那么，这个宝物（事件）就会交由二哥继续处理，同样的，二哥如果能够处理好那么他也会告诉大家（onTouchEvent返回true）。如果没能处理好（返回false），那么，他会把这件宝物交还个拍卖行。不好意思，另请高明吧。那么，拍卖行又会继续把这件宝物向接下来的竞拍人兜售。直到宝物被接收并且安放妥当。

    这就是View中的事件分发过程，这只是在View层进行了讲解。接下来我们要了解另一个东西，那就是ViewGroup。

    通过英语直译我们就能直到，这货肯定是View们的组长了，他是承载所有View的容器。你想，管理了那么多的View，那么事件分发时，能少了他，能怠慢他吗？那显然是不可能的，所以，我们一定要记住了有好东西，一定要先想着老大哥，有了老大哥一口肉吃，才有你们一口汤喝（点击事件首先要经过ViewGroup，通过ViewGroup才能向上层的View传递）- _ -!，人在屋檐下不得不低头，连代码界都是如此。不过老大哥（ViewGroup）还是很无私的，他不会主动截留宝物（事件），而是把宝物通过拍卖行询问小弟们（各个子View组件）是否需要。如果老大哥（ViewGroup）需要这件宝物，那么他留下之后，便不会再给小弟们一点得到这件宝物的机会了。

四、总结
好了，了解了这几个必要的原理之后，那么我们现在就需要对这个原理进行总结，首先，再点击事件被系统捕捉之后，会将其传递给Activity，而后Activity再将这个事件传递给Window，也就是PhoneWindow对象，通过这个对象找到顶级View，也就是ViewGroup，而后再从ViewGroup出发，遍历整个子View布局，从而找到能够消耗这一个事件的View。

   当View接收到事件之后，就会将其进行相应的处理，一般为onTouch（）到onTouchEvent（）。而我们熟知的onClick（）函数，其实就是在onTouchEvent（）中被调用的，他是位于整个事件消耗的尾端，当所有动作都不消耗事件时，他才会被用来判断是否需要事件。同时，我们也需要注意的是，只有当前View组件可以点击同时有onClickListener时，我们才能使用onTouch（）来进行业务逻辑的书写。否则，我们应使用onTouchEvent（）进行代码编写。

   这就是我对于View事件分发体系宏观上的理解，如果有理解错误或者笔误，请大家指出。

   如果想要从源码角度理解这一机制，可以参看郭霖大神的博客：http://blog.csdn.net/guolin_blog/article/details/9153747