Android事件分发机制源码分析

小小感慨一下,做android有一段时间了,一直以来都是习惯整理笔记存到有道笔记上,没有写博客的习惯。以后逐步分类整理出来,也算“复习”一遍了 - _ - 。

android的事件分发相关的方法有三个:

1.public booleandispatchTouchEvent(MotionEvent ev)

2.public boolean onInterceptTouchEvent(MotionEvent ev)

3.public booleanonTouchEvent(MotionEvent event)

第一个方法表示是否分发事件,第二个方法表示是否拦截事件(仅仅ViewGroup有这个方法,View没有) ,第三个方法表示是否消费事件。

分析源码之前,我们先总结一下事件分发的规律,或者说上面3个方法的使用方法:

①当TouchEvent发生时,首先Activity将TouchEvent传递给最顶层的View,一般是一个ViewGroup。TouchEvent最先到达最顶层 view 的 dispatchTouchEvent ,然后由  dispatchTouchEvent 方法进行分发,返回true则不分发,全部事件都交给dispatchTouchEvent 处理,如果dispatchTouchEvent返回 false ,则view以及它的子view都接收不到后续事件,如果调用super.dispatchTouchEvent,则交给interceptTouchEvent
处理。

②如果 interceptTouchEvent 返回 true ,也就是拦截掉了,则后续事件交给它的 onTouchEvent 来处理interceptTouchEvent 不再处理(如果手拿起来在重新点击,down事件还会走一次,后面的move和up不走了),如果onTouchEvent不处理,事件原路返回,后续事件就不交给这个view了,如果 interceptTouchEvent
返回 false 或者调用super.interceptTouchEvent ,那么后续事件仍然经过interceptTouchEvent 处理,但是不经过onTouchEvent。没有interceptTouchEvent方法的普通view不考虑这个方法,其他规律相同

③对于onTouvhEvent返回true表示消费事件,false表示不消费,调用super.onTouchEvent时分两种情况,对于ViewGroup等可以放子View的来说不消费事件,对于不能放子View的View来说消费事件。不消费事件时事件到达最底层的view后会回传,只走onTouchEvent,可能被上层View消费

如果你仅仅是关心这几个方法的使用,然后自己自定义view,那看到这里应该就没神马问题了,反正我知道这几个方法会对事件分发造成什么影响了,至于为啥我就不关心了

但是作为一个积极学习高素质的程序猿来说,我们不仅要弄明白怎么用,还要明白为什么会出现这些情况(此处应有掌声)。我们就按照上面的三点逐点分析。

首先我们看第一点:dispatchTouchEvent。这个方法返回false表示事件不分发,那么可以理解为这个view以及子view都不会消费事件,那后续事件就不会在给你了,反正给了你你也不消费嘛,干嘛还给你,这个很好理解,代码实现是把所有消耗事件的View都保存起来,所以不消费事件的View是不会即受到后续事件的,这部分代码没贴出来,参见ViewGroup代码的第2213行调用addTouchTarget方法的代码。按照常规来想,既然返回false表示不消费事件,那么返回true就应该是消费事件了吧?NO
NO NO,too young to simple。如果你写demo试试就会发现dispatchTouchEvent方法一直走,但是事件却没有分发下去,子view收不到事件,只有返回值是super.dispatchTouchEvent才能把事件分发下去。。。纳尼,这是什么鬼,不按套路出牌啊。好吧,这种情况只能翻源码了。我们以android6.0(API
Level 23)的源码为准进行分析。

下面这段代码是摘自ViewGroup的dispatchTouchEvent方法,在2167行是取到第i个子view。然后到2197行,这里调用了一个方法,将上面取到的第i个子view作为参数之一传了过去。

下面这段代码是刚才说到的在dispatchTouchEvent中调用的这个方法,看第2553行,当child不为空的时候,调用了child的dispatchTouchEvent(具体会走到2553或者2575行,他们本质上是一样的,区别就是对传过来的MotionEvent进行了一个split操作,具体做了啥没去深究。有知道它们区别的小伙伴可以留言赐教)。到这里是不是有一种豁然开朗的感觉呢?ViewGroup之所以能将事件分发给子view是因为在dispatchTouchEvent中又调用了子view的事件分发方法,如果你在ViewGroup的dispatchTouchEvent方法中只返回true而不返回super.dispatchTouchEvent,那么子view的事件分发的方法将不会调用,子view就拿不到事件。明白了吧,我觉得我说的还是挺清楚的。中间我们忽略了其他不相关的代码,如果你想深入了解,可以再去阅读一下源码,看完博客阅读源码,一切so
easy~。

下面的这个方法后面还要用到,dispatchTouchEvent方法中多次调用了这个方法。

再看第二点onInterceptTouchEvent方法:这个方法表示是否拦截事件。如果返回true,那么事件会直接交给自身的onTouchEvent处理。为什么会这样呢?看下面的代码块:

第2104行,按下手机屏幕,走到这里,2106行,这里的disallowIntercept默认的情况下这里得到的是false的(默认初始化出来的值计算),会走到2108行,调用onInterceptTouchEvent,如果我们复写这个方法返回true,这是intercept的值就是true,再往下走会走到2238行,这时候mFirstTouchTarget是为null的,会走到2240。这里又调用了dispatchTransformedTouchEvent方法,也就是本文中的第二个代码块,这时候第三个参数child是null,方法会走到2547或者2566行(具体是哪一个,whatever),然后调用了父类的dispatchTouchEvent方法,我们再去看父类的方法:

看到红框框中的代码了没,直接调用了onTouchEvent。所以如果你的onInterceptTouchEvent返回true时会调用自身的onTouchEvent,事件就传到自己的onTouchEvent了。

第三点,为啥事件不消费时会回传给父view,我有点词穷了。。。不知道该如何描述,原因就是递归。父View传递事件的时候是递归调用disPatchTouchEvent,当事件没有被子View消费时,就会调用自己的onTouchEvent方法,所以从日志看起来的效果就是事件被回传回去了。

关于自己对这方面的理解,总体上就这么多,源码的解析不太详细,就大概理出来了个初步的条理,可能理解的存在问题甚至错误,欢迎指正。

时间: 2024-10-13 16:39:26

Android事件分发机制源码分析的相关文章

Android查缺补漏(View篇)--事件分发机制源码分析

在上一篇博文中分析了事件分发的流程及规则,本篇会从源码的角度更进一步理解事件分发机制的原理,如果对事件分发规则还不太清楚的童鞋,建议先看一下上一篇博文 <Android查缺补漏(View篇)--事件分发机制> ,先来看一下本篇的分析思路,一会儿会按照事件传递的顺序,针对以下几点进行源码分析: Activity对点击事件的分发过程 PhoneWindow是如何处理点击事件的 顶级View对点击事件的分发过程 View对点击事件的处理过程 Activity对点击事件的分发过程 通过上一篇博文中我们

Qt事件分发机制源码分析之QApplication对象构建过程

我们在新建一个Qt GUI项目时,main函数里会生成类似下面的代码: int main(int argc, char *argv[]) { QApplication application(argc, argv); CQDialog dialog(NULL); dialog.show(); return application.exec(); } 对应的步骤解释如下 1.构建QApplication对象 2.构建CQDialog主界面 3.主界面显示 4.QApplication对象进入事件循

Android View 事件分发机制源码详解(View篇)

前言 在Android View 事件分发机制源码详解(ViewGroup篇)一文中,主要对ViewGroup#dispatchTouchEvent的源码做了相应的解析,其中说到在ViewGroup把事件传递给子View的时候,会调用子View的dispatchTouchEvent,这时分两种情况,如果子View也是一个ViewGroup那么再执行同样的流程继续把事件分发下去,即调用ViewGroup#dispatchTouchEvent:如果子View只是单纯的一个View,那么调用的是Vie

Android View 事件分发机制 源码解析 (上)

一直想写事件分发机制的文章,不管咋样,也得自己研究下事件分发的源码,写出心得~ 首先我们先写个简单的例子来测试View的事件转发的流程~ 1.案例 为了更好的研究View的事件转发,我们自定以一个MyButton继承Button,然后把跟事件传播有关的方法进行复写,然后添加上日志~ MyButton [java] view plain copy package com.example.zhy_event03; import android.content.Context; import andr

安卓中的事件分发机制源码解析

安卓中的事件分发机制主要涉及到两类控件,一类是容器类控件ViewGroup,如常用的布局控件,另一类是显示类控件,即该控件中不能用来容纳其它控件,它只能用来显示一些资源内容,如Button,ImageView等控件.暂且称前一类控件为ViewGroup类控件(尽管ViewGroup本身也是一个View),后者为View类控件. 安卓中的事件分发机制主要涉及到dispatchTouchEvent(MotionEvent ev).onInterceptTouchEvent(MotionEvent e

Android异步消息传递机制源码分析&amp;&amp;相关知识常被问的面试题

1.Android异步消息传递机制有以下两个方式:(异步消息传递来解决线程通信问题) handler 和 AsyncTask 2.handler官方解释的用途: 1).定时任务:通过handler.postDelay(Runnable r, time)来在指定时间执行msg. 2).线程间通信:在执行较为耗时操作的时候,在子线程中执行耗时任务,然后handler(主线程的)把执行的结果通过sendmessage的方式发送给UI线程去执行用于更新UI. 3.handler源码分析 一.在Activ

拨云见日---android异步消息机制源码分析

做过windows GUI的同学应该清楚,一般的GUI操作都是基于消息机制的,应用程序维护一个消息队列,开发人员编写对应事件的回调函数就能实现我们想要的操作 其实android系统也和windows GUI一样,也是基于消息机制,今天让我们通过源码来揭开android消息机制的神秘面纱 谈起异步消息,就不能不提及Handler,在安卓中,由于主线程中不能做耗时操作,所以耗时操作必须让子线程执行,而且只能在主线程(即UI线程)中执行UI更新操作,通过Handler发送异步消息,我们就能更新UI,一

Android事件分发机制详解:史上最全面、最易懂

前言 Android事件分发机制是每个Android开发者必须了解的基础知识 网上有大量关于Android事件分发机制的文章,但存在一些问题:内容不全.思路不清晰.无源码分析.简单问题复杂化等等 今天,我将全面总结Android的事件分发机制,我能保证这是市面上的最全面.最清晰.最易懂的 本文秉着"结论先行.详细分析在后"的原则,即先让大家感性认识,再通过理性分析从而理解问题: 所以,请各位读者先记住结论,再往下继续看分析: 文章较长,阅读需要较长时间,建议收藏等充足时间再进行阅读 目

Android事件分发机制详解

我们通过一个示例来分析Touch事件的分发过程. 示例: 布局文件: <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:id=&