网络测速全解析之一：自定义View基础知识（七）

一、自定义View的事件分发机制：

1.事件分发机制的意义：

view是树形结构的，而且view会重叠到一起，当我们点击某个view的时候，他可能有多个层次的view都响应。如何处理这些响应，而让我们可以更好的选择，所以有v事件的分发机制。制定一种规则来解决这些问题，让事件可以有顺序的执行起来。

                                                                                    View的结构

事件分发、拦截与消费

类型	相关方法	Activity	ViewGroup	View
事件分发	dispatchTouchEvent	√	√	√
事件拦截	onInterceptTouchEvent	X	√	X
事件消费	onTouchEvent	√	√	√

这个三个方法均有一个 boolean(布尔) 类型的返回值，通过返回 true 和 false 来控制事件传递的流程。

PS: 从上表可以看到 Activity 和 View 都是没有事件拦截的，这是因为：

Activity 作为原始的事件分发者，如果 Activity 拦截了事件会导致整个屏幕都无法响应事件，这肯定不是我们想要的效果。

View最为事件传递的最末端，要么消费掉事件，要么不处理进行回传，根本没必要进行事件拦截。

事件分发流程

前面我们了解到了我们的View是树形结构的，基于这样的结构，我们的事件可以进行有序的分发。

事件收集之后最先传递给 Activity， 然后依次向下传递，大致如下：

Activity －> PhoneWindow －> DecorView －> ViewGroup －> ... －> View

这样的事件分发机制逻辑非常清晰，可是，你是否注意到一个问题？如果最后分发到View，如果这个View也没有处理事件怎么办，就这样让事件浪费掉？

当然不会啦，如果没有任何View消费掉事件，那么这个事件会按照反方向回传，最终传回给Activity，如果最后 Activity 也没有处理，本次事件才会被抛弃:

Activity <－ PhoneWindow <－ DecorView <－ ViewGroup <－ ... <－ View

看到这里，我不禁微微一皱眉，这个东西咋看起来那么熟悉呢？再仔细一看，这不就是一个非常经典的责任链模式吗， 如果我能处理就拦截下来自己干，如果自己不能处理或者不确定就交给责任链中下一个对象。

这种设计是非常精巧的，上层View既可以直接拦截该事件，自己处理，也可以先询问(分发给)子View，如果子View需要就交给子View处理，如果子View不需要还能继续交给上层View处理。既保证了事件的有序性，又非常的灵活。在我第一次将这个逻辑弄清楚的时候，看着这样精妙的设计，简直想欢呼庆贺一下。

 

事件传递机制：

 

点击 View1 区域且事件被 View1 消费

 

点击 View1 区域但事件被 ViewGroupA 拦截

其他情况

事件分发机制设计情形非常多，这里就不一一列举了，记住以下几条原则就行了。

• 1.如果事件被消费，就意味着事件信息传递终止。

• 2.如果事件一直没有被消费，最后会传给Activity，如果Activity也不需要就被抛弃。

• 3.判断事件是否被消费是根据返回值，而不是根据你是否使用了事件。