Activity 事件分发机制-基础

长期以来对Android 事件分发机制的理解都是停留在模棱两可，甚至可以说是蜻蜓点水的程度，最近系统的学习了一下，理解的较为全面，将自己的理解记录在该博客下，可能会分为几篇博客吧！

本文是在理解了https://www.cnblogs.com/chengxuyinli/p/9979826.html 的基础上整理，感谢大佬的博客，浅显易懂，解决了我长期以来的疑惑。

时间分发的对象

事件	触发场景	单次事件流中触发的次数
MotionEvent.ACTION_DOWN	按下屏幕时	1次
MotionEvent.ACTION_UP	在屏幕上抬起时	0次或1次
MotionEvent.ACTION_MOVE	在屏幕上移动时	0次或多次
MotionEvent.ACTION_CANCEL	滑动超出控件范围	0次或者一次

按下、抬起、移动、取消这几种事件组成一个事件流，从按下开始，中间可能会一次或者多次移动，以抬起或者取消结束；

在Android 事件分发的处理中，主要是对按下进行处理分发，后续事件中的移动，抬起，则能够直接分发给需要处理的组件，所以主要对按下进行处理。

事件分发的组件

事件分发的组件也称为事件分发者，包括Activity、ViewGroup、View，他们的结构如下图：

avatar

其中Activity 包括ViewGroup、ViewGroup 又包括多个View

组件	描述	举例
Activity	Android 视图类	启动页，MainActivity等
ViewGroup	View 容器，可以包含多个View	LinearLayout、RelativeLayout等布局类
View	UI组件	Button、TextView等

Android 事件分发的方法

事件分发的方法有三个，他们是：

dispatchTouchEvent()
onTouchEvent()
onInterceptTouchEvent()

他们在组件中存在的情况

组件	dispatchTouchEvent	onTouchEvent	onInterceptTouchEvent
Activity	存在	存在	不存在
ViewGroup	存在	存在	存在
View	存在	存在	不存在

dispatchTouchEvent()、 onTouchEvent() 都存在于三个组件中，其中ViewGroup 又独有onInterceptTouchEvent() 方法。

ViewGroup 实际是没有onTouchEvent() 方法的，但是由于ViewGroup 继承自View，View 拥有onTouchEvent()，所以ViewGroup 也就可以调用onTouchEvent() 方法了。

事件分发的过程

事件分发的方向概念：

向下传播：从Activity 传递到Layout（ViewGroup）、从Layout（ViewGroup）传递到View为向下传播；

向上传播：与向下传播相反。

不同于Java 中的向上转型，注意概念不要搞混。

dispatchTouchEvent 分发：

该方法主要负责分发，是Android 事件分发中的核心，事件是如何传递的，主要看该方法。

如果某个组件的该方法返回为TRUE，表示该组件已经对该事件就行处理，不用继续调用其他组件，分发停止；

如果某个组件的该方法返回为FALSR，表示该组件不能为该事件进行处理，需要按照规则继续分发，在不复写该方法的情况下，除了一些特殊组件，其余组件都是返回FALSE的。

为何返回TRUE就不用继续分发，而返回FALSE就停止分发呢？为了解决这个疑问，需要看一看该方法的具体分发逻辑。为了便于理解，下面对dispatchTouchEvent方法进行简化，只保留最核心的逻辑。

Activity的dispatchTouchEvent方法

// Activity中该方法的核心部分伪代码
public boolean dispatchTouchEvent(MotionEvent ev) {
    if (child.dispatchTouchEvent(ev)) {
        return true;    //如果子View消费了该事件,则返回TRUE，让调用者知道该事件已被消费
    } else {
        return onTouchEvent(ev);    //如果子View没有消费该事件，则调用自身的onTouchEvent尝试处理。
    }
}

从方法中可以看出：当事件传递到Activity 时，其先将事件分发给子View 进行处理。

如果经过子View 层层传递后，返回值为True，那么就代表子View 消费了该事件，Activity 的分发方法返回值也为True；
如果经过子View 层层传递后，返回值为False，那么代表子View 没有消费该事件，则调用Activity 自身的onTouchEvent()尝试进行处理；
如果onTouchEvent() 返回True，就代表已消费该事件，这个True 作为dispatchTouchEvent 的返回值，让调用的对象知道Activity 已经消费该事件；
如果onTouchEvent() 返回False ，代表没有消费该事件，那么返回False，这个FALSE 作为dispatchTouchEvent 的返回值，让调用的对象知道Activity 没有消费该事件，需要继续处理。

ViewGroup的dispatchTouchEvent方法

// ViewGroup中该方法的核心部分伪代码
public boolean dispatchTouchEvent(MotionEvent ev) {
    if (!onInterceptTouchEvent(ev)) {
        return child.dispatchTouchEvent(ev);    //不拦截，则传给子View进行分发处理
    } else {
        return onTouchEvent(ev);    //拦截事件，交由自身对象的onTouchEvent方法处理
    }
}

ViewGroup 的处理与Activity 类似，但是多了一个onInterceptTouchEvent() 方法，当事件传入时会首先调用onInterceptTouchEvent() ：

如果返回false（表示不拦截），则交给子View 调用dispatchTouchEvent()进行分发处理；
如果返true（表示拦截），则调用自身的onTouchEvent() 处理，能否处理以``onTouchEvent() 的实际情况决定。

实际上，在onInterceptTouchEvent() 返回TURE表示拦截时，实际调用的是super.dispatchTouchEvent() 方法，即View 的该方法，进而由该方法调用onTouchEvent()。

View的dispatchTouchEvent方法

// View中该方法的核心部分伪代码
public boolean dispatchTouchEvent(MotionEvent ev) {
    //如果该对象的监听成员变量不为空，则会调用其onTouch方法，
    if (mOnTouchListener != null && mOnTouchListener.onTouch(this, event)) {
        return true;    //若onTouch方法返回TRUE，则表示消费了该事件，则dispachtouTouchEvent返回TRUE，让其调用者知道该事件已被消费。
    }
    return onTouchEvent(ev);    //若监听成员为空或onTouch没有消费该事件，则调用对象自身的onTouchEvent方法处理。
}

从该方法的核心逻辑中可以看到，事件传递进来后，首先会对mOnTouchListener判空，如果之前Set了Listener，则会调用其onTouch方法。

若onTouch方法返回TRUE，则dispatchTouchEvent也会返回TRUE，表示消费该事件。
若onTouch方法返回FALSE，或者mOnTouchListener本来就是空，则调用自身的onTouchEvent()来处理，是否消费事件，可以由其返回值判断。

实际上，在View的onTouchEvent方法中，如果设置了onClickListener监听对象，则会调用其onClick方法。

在同时设置了onTouchListener与onClickListener对象的情况下，正是由于View的dispacthTouchEvent方法会先调用mOnTouchListener的onTouch,才会调用onTouchEvent方法，所以onTouchListener对象的onTouch方法是优先于onClickListener对象的onClick方法调用的。这里只简单描述结论，具体源码请查看本文对应的高级篇内容。

小节：dispatchTouchEvent方法

上面Activity、ViewGroup和View中的dispatchTouchEvent方法，它们大体都可以分为两部分，前一部分是交由子View的dispatchTouchEvent方法或onTouch方法进行处理，后一部分是交给自身的onTouchEvent方法处理。

为了便于记忆和理解，可以将各组件的dispatchTouchEvent方法分为两部分：

子View的dispatchTouchEvent 或 onTouch方法
自身的onTouchEvent方法

这个结构有点类似于递归的过程，就是组件的dispatchTouchEvent会自用子组件的同名方法，子组件一样会调用子子组件的同名方法，直到递归到底，然后在从递归底部返回上层，直到返回到最上层，整个过程结束。或者在这个过程中，事件传递到某个子View，该子View决定处理该事件，则事件交给其自身的onTouchEvent方法处理，如果onTouchEvent方法处理不了，再交由父组件的同名方法处理，直到向上传递到顶层结束。

根据以上整理出如下U型图：

avatar

从U型图中可以发现，其实安卓事件分发的主体思路非常简单，即由父组件不断向子组件分发，若子组件能够处理，则立刻返回。若子组件都不处理，那传递到底层的子组件，再返回回来。这个过程类似上面说的递归的过程。

这里对这个U型图做一下说明，先看图中左上角，事件传到Activity，首先调用其dispatchTouchEvent方法，其会传递给子View处理，该子View（在图中是ViewGroup）会调用其dispatchTouchEvent方法，如果该方法被覆写直接返回TRUE,则立即返回Activity，表示已经消费事件。如果该方法没有被覆写或调用了super的同名方法，则会调用onInterceptTouchEvent方法，如果该方法返回TRUE拦截事件，则交给自身的onTouchEvent处理，如果该方法返回FALSE不拦截，则继续传给子子View（图中是View）的dispatchTouchEvent方法处理。此时，再看看这个U型图，该递归调用已经到底了，若在该方法中的onTouchListener方法不处理，则调用自身的onTouchEvent处理。若还是处理不了，则从递归底部向上返回，依次调用ViewGroup的、Activity的onTouchEvent方法。

实际上，用这个U型图来描述安卓的事件分发机制并不一定准确，因为同一对象的dispatchTouchEvent方法实际是包含了另外几个方法的（Activity与View只包含onTouchEvent),但是在这个图中，却是将几个方法分别画在不同的框中。所以通过该U型图来理解事件分发机智是不准确的。但是对于部分读者可能会有所帮助。要准确理解事件调用机制，还是应该回到上面，查看三个核心方法的核心逻辑，就能够准确理解。

强调说明，安卓事件分发的‘向上’与‘向下‘传播，不要与面向对象程序语言中基类与子类关系，或子类向上调用父类方法等概念搞混淆。对于安卓事件分发的‘向上’与‘向下‘传播，这里的上与下，是指在’递归‘调用过程中的上与下（也体现到U型图里的上与下）。这个概念，体现到布局中，就是外与内。即这里所说的事件’向下‘传播，等同于在布局上，由外向内传播，而’向上’传播，等同于在布局上，由内向外传播。

在面向对象程序语言中，对于子类覆盖父类方法，或子类调用父类方法，这些‘上’与‘下’的关系，在布局层面上并没有跨越布局层次，不要与事件传播的方向概念相混淆。

拦截方法onInterceptTouchEvent

该方法是ViewGroup类对象所独有的，用于对事件进行提前拦截。在一般情况下，该方法是默认返回FALSE的，即不拦截。如果自定义的ViewGroup希望拦截事件，不希望事件继续往子View传播，可以覆写该方法，返回TRUE，即可阻止向下的传播过程。

实际上，从上面的核心逻辑的伪代码中可以看出，在ViewGroup调用dispatchTouchEvent后，肯定会调用该方法，根据该方法的返回值来确定如何处理。若该方法返回True，则会将事件拦截掉，就给自身的onTouchEvent处理。如果返回False,则继续传递给child执行分发流程。、

处理方法onTouchEvent

该方法主要对事件进行处理，若返回True表示已经处理了事件，若返回False则表示没有对事件进行处理，需要继续传递事件。一般情况下，默认为FALSE。在View的onTouchEvent方法中，如果设置了onClickListener监听对象，则会调用其onClick方法。

总结

本文在介绍了事件分发基本概念的基础上，介绍了负责参与事件分发的核心方法，包括dispatchTouchEvent()、onInterceptTouchEvent与onTouchEvent方法。通过伪代码的形式介绍了这些方法的核心逻辑，重点分析了在Activity、ViewGroup与View中的dispatchTouchEvent方法。它们三者中的该方法结构类似，都是先调用子View的同名方法或者listener方法，然后再调用自身的onTouchEvent方法。

这些方法在调用关系中体现了一个类似‘递归’的调用过程，通过dispatchTouchEvent将事件传递下去，又通过onTouchEvent将事件传递上来。中间的这一过程可以通过让onInterceptTouchEvent方法（对于ViewGroup），或者另外的负责分发的方法返回TRUE，均可以提前终止这一类似’递归‘的调用过程，进而让事件的处理符合我们的预期。

XJL's Blog