按下、滑动、抬起、取消这几种事件组成了一个事件流。事件流以按下为开始,中间可能有若干次滑动,以抬起或取消作为结束。
在安卓对事件分发的处理过程中,主要是对按下事件作分发,进而找到能够处理按下事件的组件。对于事件流中后续的事件(如滑动、抬起等),则直接分发给能够处理按下事件的组件。故本文讨论的内容则是主要针对按下事件的。
3. 分发事件的组件
分发事件的组件,也称为分发事件者,包括Activity、View和ViewGroup。它们三者的一般结构为:
从上图中可以看出,Activity包括了ViewGroup,ViewGroup又可以包含多个View。
组件 | 特点 | 举例 |
---|---|---|
Activity | 安卓视图类 | 如MainActivity |
ViewGroup | View的容器,可以包含若干View | 各种布局类 |
View | UI类组件的基类 | 如按钮、文本框 |
4. 分发的核心方法
负责对事件进行分发的方法主要有三个,分别是:
- dispatchTouchEvent(
- onTouchEvent()
- onInterceptTouchEvent()。
它们并不存在于所有负责分发的组件中,其具体情况总结于下面的表格中:
组件 | dispatchTouchEvent | onTouchEvent | onInterceptTouchEvent |
---|---|---|---|
Activity | 存在 | 存在 | 不存在 |
ViewGroup | 存在 | 存在 | 存在 |
View | 存在 | 存在 | 不存在 |
从表格中看,dispatchTouchEvent,onTouchEvent方法存在于上文的三个组件中。而onInterceptTouchEvent为ViewGroup独有。这些方法的具体作用在下文作介绍。
ViewGroup类中,实际是没有onTouchEvent方法的,但是由于ViewGroup继承自View,而View拥有onTouchEvent方法,故ViewGroup的对象也是可以调用onTouchEvent方法的。故在表格中表明ViewGroup中存在onTouchEvent方法的。
5. 事件分发过程
这一小节是本文的核心内容,会从整体上对事件的分发过程作介绍。
对于事件分发过程从,笔者认为网上的一些教程中的观点是有误的。
- 网上部分教程认为事件是从内部(如Button)开始分发的,这是有误的。
- 网上部分教程常使用’向上‘、’向下‘传播等描述,但又未对‘何为上’、‘何为下’作解释。
- 网上部分教程将Java的子类对象调用父类方法(向上转型)的过程也称为‘向上’传播,即将事件在组件之间的传播与程序语言多态特性混为一谈,让初学者费解。
- 子类在覆写的方法中调用父类的同名方法,被称为’向上传播‘,这也是不对的。
为此在介绍分发过程之前,先对一些概念作定义:
- 向下传播:Activity包括Layout,事件从Activity向Layout传播被称作’向下传播‘。Layout包含若干View,事件从Layout向其子View传播,也被称为’向下传播‘。
- 向上传播:与’向下传播‘相反。
’向上转型‘不能称为传播,即子类对象调用父类方法,或在覆写的方法中调用父类方法,都不能称为传播。不能将面向对象程序语言中的概念与布局层次中的上下传播混为一谈。
分发方法dispatchTouchEvent
从方法的名称中可以看出该方法主要是负责分发,是安卓事件分发过程中的核心。事件是如何传递的,主要就是看该方法,理解了这个方法,也就理解了安卓事件分发机制。
在了解该方法的核心机制之前,需要知道一个结论:
- 如果某个组件的该方法返回TRUE,则表示该组件已经对事件进行了处理,不用继续调用其余组件的分发方法,即停止分发。
- 如果某个组件的该方法返回FALSE,则表示该组件不能对该事件进行处理,需要按照规则继续分发事件。在不复写该方法的情况下,除了一些特殊的组件,其余组件都是默认返回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),则Activity的分发方法也返回TRUE,同样也表示该事件已经被消费了。
- 如果经过子View层层传递或处理后,该事件没有被消费(即返回了FALSE),则Activity的分发方法就不会返回TRUE了,而是调用onTouchEvent()去处理,看其实际的处理情况。
- 如果onTouchEvent消费了事件,那依然能返回TRUE(表示已消费事件),这个TRUE作为dispatchTouchEvent的返回值,让调用它的对象知道该Activity已经消费了事件。
- 如果onTouchEvent没有消费该事件,那就返回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(表示拦截),则直接交给该ViewGroup对象的onTouchEvent(ev)方法处理,具体是否能处理以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()来处理,是否消费事件,可以由其返回值判断。
ispatchTouchEvent也会返回TRUE,表示消费该事件。 - 若onTouch方法返回FALSE,或者mOnTouchListener本来就是空,则调用自身的onTouchEvent()来处理,是否消费事件,可以由其返回值判断。