简单理解Android事件分发机制(上)——基础内容及流程梳理

Android事件分发机制是我们开发中常会遇到和使用的一种机制,关于事件分发机制的文章有很多,介绍的都很详细,也很全面。但难免会因为全面详细,而会感觉到很绕,今天我们就来简单抽取一下事件分发机制的主要内容,对其有个宏观的了解。

一、分发的事件

当用户触摸屏幕时(View或ViewGroup派生的控件),将产生触摸事件(Touch事件)。然后触摸事件将会在屏幕中的控件内一层层的传递。Touch事件相关细节(发生触摸的位置、时间、历史记录、手势动作等)被封装成MotionEvent对象。

在MotionEvent对象中包含着一系列需要分发的事件:
MotionEvent.ACTION_DOWN:按下View(所有事件的开始)
MotionEvent.ACTION_MOVE:滑动View
MotionEvent.ACTION_CANCEL:非人为原因结束本次事件
MotionEvent.ACTION_UP:抬起View(与DOWN对应)

每一次在屏幕中的触摸都是一个事件列,以一个DOWN事件开始(当用户触摸屏幕时产生),后跟0个或多个MOVE事件(当用户四处移动手指时产生),最后跟一个单独的UP或CANCEL事件(当用户手指离开屏幕或者系统告诉你手势由于其他原因结束时产生)。
这就是我们需要分发的事件,事件需要在屏幕空间中进行传递。

二、事件传递的空间

既然事件已经被屏幕感知了,那么就需要将感知的触摸事件分发到想要达到的控件内,让该控件获得触摸事件,然后进行处理操作。
事件传递的空间有三种:Activity,ViewGroup ,View。
这三种空间的事件传递和处理是互相联系的。

事件传递有如下类型:

Activity->ViewGroup(根布局,Window的布局)

ViewGroup->子ViewGroup

ViewGroup->View

事件处理的顺序有如下类型:

ViewGroup(根布局,Window的布局)->Activity

子ViewGroup->ViewGroup

View->ViewGroup

默认的事件传递和处理顺序是:Activity->根布局ViewGroup ->子 ViewGroup -> View,一层层传递,并没有拦截事件进行处理。然后从View开始处理事件,View ->子 ViewGroup ->根布局ViewGroup ->Activity,也没有停止事件的传递,而是一层层传递,最后让Activity处理。


以上是默认的事件处理流程,如果想要让某一控件截取并处理事件,则要用到事件分的三大利器,达到想要的效果。

三、事件分发三大利器

每种利器对应三种处理情况,每种情况又因为对应的空间不同,有不同的处理对策。
三种情况为:a.直接使用父类的默认方法super b.重写方法,返回false。 c.重写方法,返回true。
针对这三种情况,在Activity,ViewGroup ,View中有不同的含义。

1.dispatchTouchEvent(分发器):

①默认情况,分发事件,交给该层的onInterceptTouchEvent(拦截器)处理;在Activity中默认情况下,是交给根布局的ViewGroup的dispatchTouchEvent(分发器)处理。在View中默认情况下,是交给该View的onTouchEvent(处理器)处理,因为View中没有onInterceptTouchEvent(拦截器)。

②该方法返回false,不关心事件交给父控件的onTouchEvent(处理器)处理,当前控件仍接收该事件列的其他事件。

③该方法返回true,消费事件,停止分发,该事件列的后续事件会继续分发到该控件。

所以,默认情况(super)下,在Activty,ViewGroup,View中的处理方式各不相同。

2.onInterceptT1ouchEvent(拦截器):

特殊的存在,只在ViewGroup中存在

①默认情况,不拦截控件,交给子控件的dispatchTouchEvent(分发器)处理。

②该方法返回true,拦截事件,事件停止传递,交给该层的控件onTouchEvent(处理器)处理。事件列的其他事件直接交由该ViewGroup实现,并且该方法不会再次调用,即在true的情况下只会触发一次。

③该方法返回false,不拦截控件,交给子控件的dispatchTouchEvent(分发器)处理。当前ViewGroup仍然接收此事件列的其他事件。

3.onTouchEvent(处理器):

①默认情况,不处理事件,将事件上传给父控件的onTouchEvent(处理器)处理。当前View不再接收此事件列的其他事件(比较傲娇,与其他两个利器不同)。

②该方法返回true,消费事件,停止传递。当前View会处理其后续事件。

③该方法返回false,不处理事件,将事件上传给父控件的onTouchEvent(处理器)处理。当前View不再接收此事件列的其他事件(比较傲娇,与其他两个利器不同)。

掌握了以上情况,那么你便会理解下图的各种情况。


参考文章:
Android事件分发机制详解:史上最全面、最易懂
图解 Android 事件分发机制
可能是讲解Android事件分发最好的文章

事件分发机制确实是一个难点,其源码以及具体的一些特殊情况并没有进行介绍,只是对事件分发机制进行概括了解,下篇文章将从源码角度解析分发机制的具体流程以及一些特殊情况。

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

推荐阅读更多精彩内容