事件分发

借用一张下面参考文章里的全景图片,注意这里指的仅仅是 ACTION_DOWN 事件的传递。先解释一下:

白色箭头表示事件传递(函数调用)

箭头上的标注表示调用前提。(supper 表示上一级直接调用,false 表示若上级返回 false 则系统继续向下调用)

白色方块内的消费箭头表示若此函数返回对应值,则事件终止传递(也称作被消费了)

以左上角事件入口为例,首先 Activity 收到事件触发 dispatchTouchEvent,不论返回 true 还是 false 事件均终止,任何组件的任何函数均不会再被调用(包括 activity 自己的 onTouchEvent),只有 return super.dispatchTouchEvent() 也就是调用了 super 才会继续传递到下一级。

对于下一级 ViewGroup 的 dispatchTouchEvent 来讲,返回 true 同样消费事件立即终止传递。返回 false 则会回溯到上一层的 onTouchEvent。调用 super 则继续向下传递。

全程传递

我们假设事件没有被拦截、消费,那么整个传输流程类似 U 型:

不难看出,整个流程分为左右两部分,我们暂且叫做分派与回溯。分派是自顶到底的,主要用于事件的传递。回溯是从底到顶的,主要用于事件的处理。所有方法的默认实现就是 return super.xxx() 因此事件默认情况下可以走完整个流程。

拦截器

ViewGroup

细心的同学应该注意到了,在分派过程中除了整齐的 dispatchTouchEvent 方法外,乱入了一个 onInterceptEvent 方法,可以称之为拦截器。顾名思义拦截器的作用就是拦截此事件供自己使用(就像大理 gov 一样对待口罩那样)。不难看出 dispatchTouchEvent 方法调用后根据内部处理的不同有三个后果,分别是 ①终止传递 ②向下传递 ③向上回溯,而前面提到过,一般来讲处理具体的处理会放在 onTouchEvent 中。那么问题来了,终止传递后我居然自己无法处理事件?(参考 U 型图中的 ViewGroup 层,无论 dispatchTouchEvent 作何响应都无法调用自己的 onTouchEvent)

这时候就需要拦截器登场啦。在 onInterceptEvent 方法中若返回 true 则表示拦截此事件,传递给自己的 onTouchEvent 继续处理并决定是否回溯。一定要与 dispatchTouchEvent 区分开,它返回 true 会终止整个流程,更别提回溯了;而拦截器返回 true 后只是停止向下分派,会从自己开始向上回溯。

所以拦截器的作用就是拦截向下分派、自己处理事件并决定是否继续向上回溯。

View

那么 View 怎么办?拦截器方法只有 ViewGroup 中才有,如果 View 想自己处理事件呢?如果理解了拦截器的作用那么这个问题就非常简单了。因为 View 已经是底层组件,它不需要继续向下传递事件,因此它在 onInterceptEvent 直接调用 super 就可以触发自身的 onTouchEvent。也就是说 View 的 super 实现了 ViewGroup 的拦截器功能。

总结

到此为止 ACTION_DOWN 的传递流程基本上分析完了,最后总结一下在不同的阶段要达到不同的目的应该执行什么操作。

分派阶段

期望行为操作

继续分派调用 super

消费事件,终止整个流程dispatch return true

终止分派,向上回溯dispatch return false

终止分派,交给自己处理ViewGroup: 拦截器返回 true; View: 调用 super

回溯阶段

期望行为操作

继续回溯调用 super 或 return false

消费事件,终止回溯return true

ACTION_MOVE/UP

不同情况

与 DOWN 事件不同,其他的都属于后续事件,只有消费了它的上一个事件(例如DOWN)的控件,及其上层的控件,才能接受到后续事件。这么说太抽象了,画个图看看(下图中红色表示 DOWN 事件,蓝色表示后续事件)

1. ViewGroup2 dispatchTouchEvent 消费事件(return true)

此时对于后续事件来讲,ViewGroup2 消费了上一个事件,而 Activity, ViewGroup1 都是它的上层控件,因此他们都能收到后续事件。

2. View onTouchEvent 消费事件

和上一个情形类似,不再赘述了。

3. ViewGroup1 onTouchEvent 消费事件

这次稍微有点不同,因为 ViewGroup1 消费了事件,因此只有它的上层控件才能收到后续事件,也就是只有 Activity 和它自己。

4. View dispatchTouchEvent 返回 false,ViewGroup onTouchEvent 消费事件

这次我们在 View 的 dispatchTouchEvent 返回了 false,也就是会直接回溯到 ViewGroup2. 通过这个案例可以看出,后续事件的传递仅与消费之前事件的控件及其上层控件有关,与之前事件在消费控件下层的传递路径无关。

5. ViewGroup onInterceptEvent 返回 true 拦截事件,ViewGroup onTouchEvent 消费事件

再次印证了上一个情况得出的结论。

总结

总结后续事件的传递路径,就是一直传递到消费前一个事件的控件,并传递到消费前一个事件的方法。注意,onInterceptEvent 只能拦截事件不能消费事件。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,711评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,932评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,770评论 0 330
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,799评论 1 271
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,697评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,069评论 1 276
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,535评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,200评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,353评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,290评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,331评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,020评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,610评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,694评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,927评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,330评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,904评论 2 341