本文目录：
一、责任链模式
责任链模式是一种行为模式,为请求创建一个接收者的对象链.这样就避免,一个请求链接多个接收者的情况.进行外部解耦.类似于单向链表结构。
优点：
1. 降低耦合度。它将请求的发送者和接收者解耦。
2. 简化了对象。使得对象不需要知道链的结构。
3. 增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次 序，允许动态地新增或者删除责任。
4. 增加新的请求处理类很方便。
缺点：
1. 不能保证请求一定被接收。
2. 系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。
3. 可能不容易观察运行时的特征，有碍于除错。
在Android事件分发机制是责任链模式最典型的应用：
dispatchTouchEvent的,就是责任链中的将事件交给下一级处理的.
onInterceptTouchEvent ,就是责任链中,处理自己处理事务的方法.
onTouchEvent 是责任链中 事件上报的事件链。
下面我们来通过Android事件分发机制来感悟一下责任链模式在Android中的应用。
二、Android 事件分发传递机制
1. View事件传递分发层级结构
a). 事件收集之后最先传递给 Activity， 然后依次向下传递，大致如下：
Activity －> PhoneWindow －> DecorView －> ViewGroup －> ... －> View</pre>
这样的事件分发机制逻辑非常清晰，可是，你是否注意到一个问题？如果最后分发到View，如果这个View也没有处理事件怎么办，就这样让事件浪费掉？当然不会啦。
b). 如果没有任何View消费掉事件，那么这个事件会按照反方向回传，最终传回给Activity，如果最后 Activity 也没有处理，本次事件才会被抛弃:
Activity <－ PhoneWindow <－ DecorView <－ ViewGroup <－ ... <－ View</pre>
可以看到，这是一个非常经典的责任链模式，如果我能处理就拦截下来自己干，如果自己不能处理或者不确定就交给责任链中下一个对象。 这种设计是非常精巧的，上层View既可以直接拦截该事件，自己处理，也可以先询问(分发给)子View，如果子View需要就交给子View处理，如果子View不需要还能继续交给上层View处理。既保证了事件的有序性，又非常的灵活。
View点击事件分发有三个关键流程方法:
1.dispatchTouchEvent：事件下发 --- View和ViewGroup都有的方法
2.onInterceptTouchEvent：拦截下发的事件,并交给自己OnTouchEvent处理处理 ---ViewGroup才有的方法
3.onTouchEvent：事件上报 --- View和ViewGroup都有的方法
以下是不同层级对事件的分发、拦截和消费的功能表：
image
可以看到 Activity 和 View 都是没有事件拦截的：
a). Activity 作为原始的事件分发者，如果 Activity 拦截了事件会导致整个屏幕都无法响应事件，这肯定不是我们想要的效果。
b). View最为事件传递的最末端，要么消费掉事件，要么不处理进行回传，根本没必要进行事件拦截。
下图是点击View，事件传递但是都没有被处理，生成的一个完整的事件分发流程图：
image
如果事件被View处理了，那么事件分发流程图应该如下：
image
如果事件被ViewGroup拦截处理了， 那么事件分发流程图应该如下：
image
从上面的流程，我们可以概括Android的事件分发机制为：责任链模式，事件层层传递，直到被消费。
三、Q&A
上面我们讲解了一下Android的事件分发机制，可能很多人会有疑惑，下面我们针对部分疑惑进行分析和说明：
1. 为什么 View 会有 dispatchTouchEvent ?
答：我们知道 View 可以注册很多事件监听器，例如：单击事件(onClick)、长按事件(onLongClick)、触摸事件(onTouch)，并且View自身也有 onTouchEvent 方法，那么问题来了，这么多与事件相关的方法应该由谁管理？毋庸置疑就是 dispatchTouchEvent，所以 View 也会有事件分发。
View的dispatchTouchEvent源码：
View Code
2. View事件分发时各个方法调用顺序是怎样的？
a). 单击事件(onClickListener) 需要两个两个事件(ACTION_DOWN 和 ACTION_UP )才能触发，如果先分配给onClick判断，等它判断完再交由其他相应时间显然是不合理的，会造成 View 无法响应其他事件，应该最后调用。(所以此调用顺序最后)
b). 长按事件(onLongClickListener) 同理，也是需要长时间等待才能出结果，肯定不能排到前面，但因为不需要ACTION_UP，应该排在 onClick 前面。(onLongClickListener > onClickListener)
c). 触摸事件(onTouchListener) 如果用户注册了触摸事件，说明用户要自己处理触摸事件了，这个应该排在最前面。(最前)
d). View自身处理(onTouchEvent) 提供了一种默认的处理方式，如果用户已经处理好了，也就不需要了，所以应该排在 onClickListener 后面。(onTouchListener > onClickListener)
所以事件的调度顺序应该是 onTouchListener > onTouchEvent > onLongClickListener > onClickListener。
3. ViewGroup 的事件分发流程又是如何的呢？
在默认的情况下 ViewGroup 事件分发流程是这样的。
a). 判断自身是否需要(询问 onInterceptTouchEvent 是否拦截)，如果需要，调用自己的 onTouchEvent。
b). 自身不需要或者不确定，则询问 ChildView ，一般来说是调用手指触摸位置的 ChildView。
c). 如果子 ChildView 不需要则调用自身的 onTouchEvent。
ViewGroup的dispatchTouchEvent源码：
View Code
可能看这么长的代码，我们会比较懵，下面我们用伪代码来表示一下：
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean consume = false;
if (onInterceptTouchEvent(ev)) {
consume = onTouchEvent(ev);
} else {
consume = child.dispatchTouchEvent(ev)
} return consume;
}
这样我们就能更直白的看懂View事件的传递机制了。
4. ViewGroup将事件分发给ChildView的机制
- ViewGroup分发事件时会遍历 ChildView，如果手指触摸的点在 ChildView 区域内就分发给这个View。当 ChildView 重叠时，一般会分配给显示在最上面的 ChildView。
- ViewGroup判断是否需要拦截，主要是根据onInterruptTouchEvent的返回值进行判断。
- 在Down事件中将touch事件分发给ChildView，如果有ChildView捕获消费了Down事件，就会对mFirstTouchTarget进行赋值。mFirstTouchTarget的作用就是记录消费事件的View。
- 在ViewGroup的dispatchTouchEvent方法中，会根据mFirstTouchTarget 是否为 null，决定是自己处理 touch 事件，还是分发给子 View。
- Down事件是touch事件序列的起点，决定了后续的事件由谁来消费处理。Cancel事件的触发场景为：父View先不拦截，但在MOVE事件中又重新拦截，此时子View会收到一个Cancel事件，
5. ViewGroup 和 ChildView 同时注册了事件监听器(onClick等)，哪个会执行?
事件优先给 ChildView，会被 ChildView消费掉，ViewGroup 不会响应。
网友评论