5分钟过一遍Android事件分发(笔记风)

前言

前几篇文章咱们从源码的层面分析了事件分发机制…不过感觉有些时候还是需要记一些笔记般的内容,简单快捷的回忆对应的内容。

正文

布局嵌套层级:ViewGroupA中嵌套ViewGroupB,然后ViewGroupB嵌套ViewGroupC,ViewGroupC中包含ViewD。

基于此,咱们分情况记录一些情况:

一、C的onInterceptTouchEvent()返回true,onTouchEvent()返回false

现象: DOWN走到C的onTouchEvent(),然后逐层回调父View的onTouchEvent(),并且后续MOVE、UP将不再回调。
5分钟过一遍Android事件分发(笔记风)

解读:
DOWN一路下来,因为没有任何onTouchEvent()返回true,那么意味着这条分发链上没有任何View消费事件,也就意味着mFirstTouchTarget为null,因此后续的MOVE、UP事件就不会再重新分发。

二、C的onInterceptTouchEvent()返回false,onTouchEvent()返回true

现象: DOWN一直传到D,然后调D的onTouchEvent(),C的onTouchEvent()。找到消费事件的C,后续事件正常按ABC的顺序调用

5分钟过一遍Android事件分发(笔记风)

解读: 因为不存在任何View拦截,所以事件会一直传递至D。然后逐层倒序回调onTouchEvent()来确定是否有子View消费。而此时我们的C返回了true,所以着mFirstTouchTarget不为null,后续事件就交由C去消费。

三、C的dispatchTouchEvent()直接返回true,且不主动调用super

现象: 正常回调AB、但永远只会回调C的dispatchTouchEvent()

5分钟过一遍Android事件分发(笔记风)

解读: 父View通过子View的dispatchTouchEvent()的返回值来决定分发权。一旦返回true,意味着找到了消费此事件的View。因为我们直接返回了true,所以这个对于父View来说mFirstTouchTarget已经确认。后续事件直接分发到此View。

但是因为我们我们直接true,且不掉super那意味着onTouchEvent()没有时机执行…

尾声

当然可能会有小伙伴说,还有一些情况呢?但其实万变不离其宗,你都会唱、跳、RAP了还差打篮球吗?j你太美就哦了。

最近在看View的绘制体系,不出意外国庆会开始陆续连载~

我是一个应届生,最近和朋友们维护了一个公众号,内容是我们在从应届生过渡到开发这一路所踩过的坑,以及我们一步步学习的记录,如果感兴趣的朋友可以关注一下,一同加油~

5分钟过一遍Android事件分发(笔记风)