Android事件传递总结

Android中事件传递机制是非常重要但又很复杂的一个知识点，在实现一些自定义View、处理滑动冲突时都需要复写事件传递相关的函数。本文总结了不同事件的传递过程，至于事件传递的dispatchTouchEvent()、onInterceptTouchEvent()、onTouchEvent()这三个函数的具体实现可以阅读源码。

 

Android中的事件分为以下几种 ACTION_DOWN、ACTION_UP、 ACTION_MOVE、ACTION_POINTER_DOWN、ACTION_POINTER_UP、 ACTION_CANCEL 。下面先简单的介绍一下这几个事件，一个完整的事件流都是以 ACTION_DOWN 开始，以 ACTION_UP 结束。在支持多点触摸的屏幕上，当第一根手指按下时，触发 ACTION_DOWN 事件，之后的按下操作触发 ACTION_POINTER_DOWN 事件；同理，非最后一根手指的抬起操作触发 ACTION_POINTER_UP 事件，最后一根手指的抬起操作触发 ACTION_UP 事件。用户的操作不会直接触发 ACTION_CANCEL 事件。

 

下图画了一个简单的Activity布局图，我们以下图中的View布局为例来讲述事件的传递流程。

                                                                              

                                                                                              图1 Activity布局图

ACTION_DOWN事件的传递流程

ACTION_DOWN事件是U字形传递的。假设手指按到View C上，首先由Activity接收到事件，然后事件通过dispatchTouchEvent()函数不断的往下面的View传递，一直传到最下层C的dispatchTouchEvent()上，然后再通过C的onTouchEvent()函数不断的往上面的View传递，直至找到onTouchEvent()返回为true的View，如果没有找到这样的View，则这个事件由Activity消费，传递流程如下图所示。

                                                                              图2 ACTION_DOWN事件传递流程

 

ACTION_UP事件的传递流程

ACTION_DOWN事件是找到要消费该事件流的View，接下来的ACTION_MOVE、ACTION_UP的事件通过L形直接传递到消费该事件流的View，具体传递流程如下图所示，假设C的onTouchEvent返回true。

 

                                                                                      图3 ACTION_UP事件传递流程

即使手指移出了C的区域，后续的ACTION_MOVE、ACTION_UP事件也会传递后C，由于在C的onTouchEvent()函数中判断到该事件已不在C的区域内，所以C不会响应相关的动作。

 

onInterceptTouchEvent()返回值由false变true的情况

假设B的onInterceptTouchEvent()函数一开始返回false(不拦截)，事件由C消费；在手指滑动的过程中B的onInterceptTouchEvent()返回了true(拦截)，此时被拦截的第一个ACTION_MOVE事件被改成ACTION_CANCEL事件并传递给C处理，之后ACTION_MOVE、ACTION_UP事件不会再传递给C，之后的事件传递流程如下图。

 

                                                                             图4 半途被拦截的后续事件传递流程

 

onInterceptTouchEvent()返回值由true变false的情况

这个标题描述的是一种需求，实际开发中通过onInterceptTouchEvent()返回值由true变为false并不能直接把事件传递下去。需求是B一开始拦截事件，但是在滑动到某种情况下B不再拦截事件，要把事件交给C处理。通过onInterceptTouchEvent()返回值由true变为false并不能直接把事件传递下去的原因有以下两条：第一在onInterceptTouchEvent()返回true之后，后续的事件传递过程中不再调用B的onInterceptTouchEvent()方法，具体为什么是这样可以查看源码；第二是View接收事件流必须由ACTION_DOWN开始，此时C接收不到ACTION_DOWN事件，所以C不能处理事件流。那有没有解决办法呢？既然提问那就肯定有了！可以让B的onInterceptTouchEvent()一直返回true，在B的onTouchEvent()函数中增加条件改变的处理逻辑，在滑动满足某种条件B不需要再拦截此事件流后，把当前的ACTION_MOVE事件改成ACTION_DOWN事件传递给C的dispatchTouchEvent()处理，后续在B的onTouchEvent()函数中把接收到的事件传递给C的dispatchTouchEvent()处理。这样就可以实现这个需求了。

 

一般情况下，消费事件的都是View。下面以View的角度描述一下，View接收到的事件种类：
（1）只有ACTION_DOWN，对应的情况是该View接收到ACTION_DOWN事件后，调用它的onTouchEvent()函数返回false；

（2）ACTION_DOWN、ACTION_MOVE、ACTION_MOVE...、ACTION_UP，这是一个完整的事件流，可以消费事件的View（即onTouchEvent()函数返回true）大多数情况下都可以接收这样的事件流；

（3）ACTION_DOWN、ACTION_MOVE、ACTION_MOVE...、ACTION_CANCEL，这种情况对应的是该View可以消费这个事件，但是在滑动的过程中父View拦截了该事件，导致该View最后接收到ACTION_CANCEL事件。