android事件的传递机制

㈠ android事件分发机制 什么意思

android事件分发机制 就是一个触摸事件发生了，从一个窗口传递到一个视图，再传递到另外一个视图，最后被消费的过程，在android中还是比较复杂的传递流程如下：

(1) 事件从Activity.dispatchTouchEvent()开始传递，只要没有被停止或拦截，从最上层的View(ViewGroup)开始一直往下(子View)传递。子View可以通过onTouchEvent()对事件进行处理。

(2) 事件由父View(ViewGroup)传递给子View，ViewGroup可以通过onInterceptTouchEvent()对事件做拦截，停止其往下传递。

(3) 如果事件从上往下传递过程中一直没有被停止，且最底层子View没有消费事件，事件会反向往上传递，这时父View(ViewGroup)可以进行消费，如果还是没有被消费的话，最后会到Activity的onTouchEvent()函数。

(4) 如果View没有对ACTION_DOWN进行消费，之后的其他事件不会传递过来。

(5) OnTouchListener优先于onTouchEvent()对事件进行消费。

上面的消费即表示相应函数返回值为true。

㈡ Android 点击回调传递

在使用MultiTypeAdapter实现RecyclerView多类型显示的时候，会创建一个ViewHolder和ViewBinder，此时如果要在Activity或者Fragment相应点击事件的时候，需要在ViewHolder和ViewBinder之间做传递。如果一个ViewHolder下有RecyclerView，然后也使用了MultiTypeAdapter，那么这个点击事件的回调将会是一件相当头疼的事情。

在使用 LifeCycle 时，发现他只需要当前类实现 LifecycleObserver ，然后通过调用 addObserver 方法即可实现事件传递。由此想到点击事件是否也可以使用此种形式来实现。

DEMO

在受到 LifeCycle 的启发下，模仿这写了几个类。

一个点击事件如果在某个类中如果需要做操作，那么需要实现该接口。

继承OnItemClick，并实现具体的方法。

基本点击事件Observer

这一层，对事件在OnBindViewHolder中做了一次传递，通过dispatchObserver方法，将ViewBinder中的事件传递到了ViewHolder中。

定义两个点击事件。

创建实体类，和Binder相对应。

在覆写 setData 方法的时候，一定要调用super。不然事件无法传递。

响应事件的回调，只需要调用 getObserver 方法，然后传入对应的Observer，如果有，就直接调用方法。

adapter传递事件，也是通过dispatchObserver方法。

ViewBinder其实就不需要做什么事情了，比较简单。

㈢ Android-从重叠view响应问题到安卓事件分发机制

工作当中遇到一个需求：有两个重叠并且全屏的Framelayout，交互逻辑是点击上层的button使得上层消失，下层可见；再点击下层使得下层消失上层出现。但是发现当点击上层非button区域时，下层也会响应点击事件，但是点击button区域则不会。这意味着点击事件穿过上层到达下层。对于安卓事件机制一知半解的我无从下手，上网搜了一下发现在上层FrameLayout下增加:

这样的确可以保证上层点击事件不会到达下层，可是这是为什么呢？最初步的猜想是当上层FrameLayout的clickable属性为true时，点击事件已经被上层拦截了。这个和当你点击button时响应onclick()时的原理是不是一样？这就需要从源码分析了。

分析源码前先大致了解一下安卓事件分发机制。

综合上述对安卓事件分发的源码分析知道，当在上层FrameLayout中将clickable设置为true时，其实就是
当点击事件到达上层framelayout时，在onTouchEvent中对事件进行拦截，使得点击事件不会继续向下传递。当然，除了这个方法以外，也可以重写FrameLayout的onInterceptTouchEvent,在将这个函数的返回值为true，也可以实现拦截事件的作用。

㈣ Framework事件机制——手撕Android事件处理的三种方法

Android的事件处理的三种方法：

setOnClickListener，setOnLongClickListener、setOnTouchListener

注意：如果onTouchEvent方法return true，则单击事件和长摁事件不再执行；若onLongClick方法返回true，则单击事件不再处理。

需要定义继承组件的类，重写回调方法Touch方法执行时，先被Activity捕获，DispatchTouchEvent方法处理。return false，交给上层的onTouchEvent方法处理；return super.dispatchTouchEvent（ev），则传递给最外层的View。

View用Dispatch方法处理，return false，由上层的onTouchEvent方法处理。如果返回super.dispatchTouchEvent（ev），则本层的onInterceptTouchEvent拦截，如果拦截true，则拦截，false不拦截，传递给子View的DispatchTouchEvent处理。

常用的回调方法：onKeyDown，onKeyLongPress，onKeyUp，onTouchEvent，onTrackballEvent（轨迹球事件）监听和回调同时存在时，先调用监听。

流程模型图：

Event source 事件源
Event 事件
Event Listener 事件监听器
下面我们来看一下点击事件和触摸事件的监听三要素具体是那部分：

由于点击事件比较简单，系统已经帮我们处理了，并没有找到具体事件是哪个。

View.OnClickListener 单击事件监听器必须实现的接⼝
View.OnCreateContextMenuListener 创建上下⽂菜单事件
View.OnFocusChangeListener 焦点改变事件
View.OnKeyListener 按键事件监听器
View.OnLongClickListener 长按事件监听器
View.OnTouchListener 触摸屏事件监听器

⾸先，事件监听机制中由事件源，事件，事件监听器三类对象组成。
事件监听器处理流程：

在此以OnClickListener单击事件为例使用intent来实现页面的跳转

监听事件处理是事件源与事件监听器分开的而基于回调的事件处理UI组件不但是事件源，而且还是事件监听器，通过组件的相关回调方法处理对应的事件。

Ⅰ. 自定义View类，继承自需要的View UI类。ex ：自定义 MyButton按钮类 extends 基础Button类

Ⅱ. 复写回调函数。ex：public boolean onTouchEvent(MotionEvent event)

每一个事件回调方法都会返回一个boolean值，①.如果返回true：表示该事件已被处理,不再继续向外扩散，②.如果返回false：表示事件继续向外扩散

而说到基于回调就离不开监听机制 。

几乎所有基于回调的事件处理方法都有一个boolean类型的返回值，该返回值用于表示该处理方法是否能完全处理该事件。
如果处理事件的回调方法返回true，表明该处理方法已经完全处理改事件，该事件不会传播出去。
如果处理事件的回调方法返回false，表明该处理方法并未完全处理该事件，该事件会传播出去。
对于基于回调的时间传播而言，某组件上所发生的事件不仅会激发该组件上的回调方法，也会触发该组件所在Activity的回调方法——只要事件能传播到该Activity。

这里是在模拟器里进行的测试，这里按下键盘(而不是点击)，会看到 logcat 中的输出，如下：

View类实现了KeyEvent.Callback接口中的一系列回调函数，因此，基于回调的事件处理机制通过自定义View来实现，自定义View时重写这些事件处理方法即可。

Handler是一个消息分发对象。

Handler是Android系统提供的一套用来更新UI的机制，也是一套消息处理机制，可以通过Handler发消息，也可以通过Handler处理消息。

在下面介绍Handler机制前，首先得了解以下几个概念：

在子线程执行完耗时操作，当Handler发送消息时，将会调用 MessageQueue.enqueueMessage ，向消息队列中添加消息。 当通过 Looper.loop 开启循环后，会不断地从消息池中读取消息，即调用 MessageQueue.next ， 然后调用目标Handler（即发送该消息的Handler）的 dispatchMessage 方法传递消息， 然后返回到Handler所在线程，目标Handler收到消息，调用 handleMessage 方法，接收消息，处理消息。

从上面可以看出，在子线程中创建Handler之前，要调用 Looper.prepare() 方法，Handler创建后，还要调用 Looper.loop() 方法。而前面我们在主线程创建Handler却不要这两个步骤，因为系统帮我们做了。

初始化Looper ：

从上可以看出，不能重复创建Looper，每个线程只能创建一个。创建Looper，并保存在 ThreadLocal 。其中ThreadLocal是线程本地存储区（Thread Local Storage，简称TLS），每个线程都有自己的私有的本地存储区域，不同线程之间彼此不能访问对方的TLS区域。

开启Looper

发送消息 ：

post方法：

send方法：

在子线程中，进行耗时操作，执行完操作后，发送消息，通知主线程更新UI。

本文讲解了三个方面；Android事件机制；基于监听、基于回调以及Handler消息处理。还有许多没有讲解到的知识点，我总结在了整理的一套Android进阶笔记里面；需要学习进阶的同学可以前往获取： Frame Work源码解析手册 、 Android核心技术进阶手册、实战笔记、面试题纲资料

㈤ 请简述什么是android事件处理，并分析两种android事件处理机制的实现过程和区别

UI编程通常都会伴随事件处理，Android也不例外，它提供了两种方式的事件处理：基于回调的事件处理和基于监听器的事件处理。

对于基于监听器的事件处理而言，主要就是为Android界面组件绑定特定的事件监听器；对于基于回调的事件处理而言，主要做法是重写Android组件特定的回调函数，Android大部分界面组件都提供了事件响应的回调函数，我们主要重写它们就行。

一 基于监听器的事件处理

相比于基于回调的事件处理，这是更具“面向对象”性质的事件处理方式。在监听器模型中，主要涉及三类对象：

1）事件源Event Source：产生事件的来源，通常是各种组件，如按钮，窗口等。

2）事件Event：事件封装了界面组件上发生的特定事件的具体信息，如果监听器需要获取界面组件上所发生事件的相关信息，一般通过事件Event对象来传递。

3）事件监听器Event Listener：负责监听事件源发生的事件，并对不同的事件做相应的处理。

基于监听器的事件处理机制是一种委派式Delegation的事件处理方式，事件源将整个事件委托给事件监听器，由监听器对事件进行响应处理。这种处理方式将事件源和事件监听器分离，有利于提供程序的可维护性。

举例：

View类中的OnLongClickListener监听器定义如下：（不需要传递事件）

[java] view plainprint?

public interface OnLongClickListener {

boolean onLongClick(View v);

}

public interface OnLongClickListener {
boolean onLongClick(View v);
}

View类中的OnLongClickListener监听器定义如下：（需要传递事件MotionEvent）

[java] view plainprint?

public interface OnTouchListener {

boolean onTouch(View v, MotionEvent event);

}

public interface OnTouchListener {
boolean onTouch(View v, MotionEvent event);
}

二 基于回调的事件处理

相比基于监听器的事件处理模型，基于回调的事件处理模型要简单些，该模型中，事件源和事件监听器是合一的，也就是说没有独立的事件监听器存在。当用户在GUI组件上触发某事件时，由该组件自身特定的函数负责处理该事件。通常通过重写Override组件类的事件处理函数实现事件的处理。

举例：

View类实现了KeyEvent.Callback接口中的一系列回调函数，因此，基于回调的事件处理机制通过自定义View来实现，自定义View时重写这些事件处理方法即可。

[java] view plainprint?

public interface Callback {

// 几乎所有基于回调的事件处理函数都会返回一个boolean类型值，该返回值用于

// 标识该处理函数是否能完全处理该事件

// 返回true，表明该函数已完全处理该事件，该事件不会传播出去

// 返回false，表明该函数未完全处理该事件，该事件会传播出去

boolean onKeyDown(int keyCode, KeyEvent event);

boolean onKeyLongPress(int keyCode, KeyEvent event);

boolean onKeyUp(int keyCode, KeyEvent event);

boolean onKeyMultiple(int keyCode, int count, KeyEvent event);

}

public interface Callback {
// 几乎所有基于回调的事件处理函数都会返回一个boolean类型值，该返回值用于
// 标识该处理函数是否能完全处理该事件
// 返回true，表明该函数已完全处理该事件，该事件不会传播出去
// 返回false，表明该函数未完全处理该事件，该事件会传播出去
boolean onKeyDown(int keyCode, KeyEvent event);
boolean onKeyLongPress(int keyCode, KeyEvent event);
boolean onKeyUp(int keyCode, KeyEvent event);
boolean onKeyMultiple(int keyCode, int count, KeyEvent event);
}

三 比对

基于监听器的事件模型符合单一职责原则，事件源和事件监听器分开实现；

Android的事件处理机制保证基于监听器的事件处理会优先于基于回调的事件处理被触发；

某些特定情况下，基于回调的事件处理机制会更好的提高程序的内聚性。

四 基于自定义监听器的事件处理流程

在实际项目开发中，我们经常需要自定义监听器来实现自定义业务流程的处理，而且一般都不是基于GUI界面作为事件源的。这里以常见的app自动更新为例进行说明，在自动更新过程中，会存在两个状态：下载中和下载完成，而我们的程序需要在这两个状态做不同的事情，“下载中”需要在UI界面上实时显示软件包下载的进度，“下载完成”后，取消进度条的显示。这里进行一个模拟，重点在说明自定义监听器的事件处理流程。

4.1）定义事件监听器如下：

㈥ Android-View的事件分发及拦截-父控件和子控件都处理触摸事件的方式

比如接着上篇 Android-View的事件分发及拦截机制简单流程先体验再研究(场景？疑问? 具体？待续...） ，小白现在要实现就是子View和父ViewGroup都响应点击事件。

1. 单纯的都只是响应down事件

这个就很简单了 - 直接子View的**public boolean **onTouchEvent(MotionEvent event) 里面直接返回false就行了。也就是子控件响应了一次down后，接下来就交给父ViewGroup了.(子View就啥几把也干不了了）;

2. 响应down和up事件，move啥的

我们知道子View如果onTouch里面返回了true，那么将会处理后续的move，up事件。而不再交给上层父ViewGroup。那父ViewGroup就没办法在Touch里面处理，所以我们只能放到dispatchTouchEvent或者onInterceptTouchEvent中处理这个down，up等事件：

比如dispatchTouchEvent中：

这样的情况就是父ViewGroup先执行点击事件，然后子View再执行。 如果您需要父ViewGroup晚点，可以延时执行啥的。

如果此时，子View的dispatchTouchEvent返回true - 表示拦截，不继续了

那么子View的所有的事件都不会响应了。其实也就是我们的一个事件先传递，touch再处理的树形图：

网络上拔个图来

简单记录下下而已，继续加深理解...这是上一篇的续，还是上一篇....啧啧....后面是官方文档分析来着...

㈦ android的事件处理机制有两种

1.基于监听的事件处理机制，有一个关键就是事件注册。 但是我们在实践的时候并没有自己手动的为某个视图控件注册监听器。
解答： 我们会经常用到 诸如 setOnclickListener()，OnTouchListener()方法等。 从字面意义理解，它为设置...监听器。 但是，它 跟注册还是颇有一些区别的。 我想注册实践监听器，就是将它挂在在一个线程上，也就是说有一个事件监听线程，那么，有事件的视图，就至少是双线程的程序了。 不过很可惜，在去看set..Listener的源码的时候，是看不到它在java源码方面的具体实现的。 也就是说，要么它依赖操作系统实现，要么它依赖jni实现，并且，事件线程由jni管理。 换言之，实现注册监听是由ni实现的。
2.事件源的触发流程：
解答： 学习过操作系统朋友应该知道，操作系统的很多操作都是通过中断来完成。 同理，比如一个点击事件，android手机硬件中，包括了一个触摸屏的硬件，它分为内屏和外屏。 其中负责触发屏幕点击和触摸中断的为内屏。 内屏大概由五个层次构成，具体有什么用不知道，反正我拆过~~~ 从内屏上，当有电容屏感应的时候，会接收到你触摸的位置信息，甚至触摸力度！！！ 这个消息经由系统中断（具有最高优先级，应该是由最高优先级的进程通知）发送给cpu,经由cpu通过进程间的消息机制传递给这个进程（当前正在用户界面运行的进程，这时候只有一个），也就是这个程序运行的内存空间的某个点。（或者说通过广播机制，将这个事件发送给所有的app也是有可能的）。

㈧ Android事件分发机制

Android中对视图的Touch事件进行分发处理。
单手指操作：ACTION_DOWN -> ACTION_MOVE -> ACTION_UP
多手指操作：ACTION_DOWN -> ACTION_POINTER_DOWN -> ACTION_MOVE -> ACTION_POINTER_UP -> ACTION_UP.

（1） dispatchTouchEvent（） ：事件分发

（2） onInterceptTouchEvent（） ：事件拦截

（3） onTouchEvent（） ：事件处理

ViewGroup 的相关事件有三个：onInterceptTouchEvent、dispatchTouchEvent、onTouchEvent。

View 的相关事件只有两个：dispatchTouchEvent、onTouchEvent。

先分析ViewGroup的处理流程：首先得有个结构模型概念：ViewGroup和View组成了一棵树形结构，最顶层为Activity的ViewGroup，下面有若干的ViewGroup节点，每个节点之下又有若干的ViewGroup节点或者View节点，依次类推。如图：

点击事件达到顶级 View(一般是一个 ViewGroup)，会调用 ViewGroup 的 dispatchTouchEvent 方法，如果顶级 ViewGroup 拦截事件即 onInterceptTouchEvent 返回 true，则事件由 ViewGroup 处理，这时如果 ViewGroup 的 mOnTouchListener 被设置，则 onTouch 会被调用，否则 onTouchEvent 会被调用。也就是说如果都提供的话，onTouch 会屏蔽掉 onTouchEvent。在 onTouchEvent 中，如果设置了 mOnClickListenser，则 onClick 会被调用。如果顶级 ViewGroup 不拦截事件，则事件会传递给它所在的点击事件链上的子 View，这时子 View 的 dispatchTouchEvent 会被调用。如此循环。

㈨ Android OkHttp3 ：最简单&粗暴（使用与原理）讲解

注释1：WebSocket是一个接口，它的实现类RealWebSocket，该类完成WebSocket的连接、数据请求与接收功能。

注释1：将RealCall实例添加至Dispatcher中(下文会介绍Dispatcher)。
注释2：通过()获取响应。
注释3：通过封装好的拦截器集合，获取第一个拦截器的任务。
注释4：触发第一个拦截器的任务，该任务就触发一下拦截器的任务，以此类推，原理(Android事件传递机制)如下图：

注释1：把AsyncCall请求对象传递进Dispatcher线程池管理；

注释2：通过()获取响应;

注释1：获取自定义线程池；
注释2：判断正在执行的异步请求数量与请求集合中相同host的数量是否满足，如果满足就添加到执行中的集合中，并添加至线程池中执行请求；如果不满足就添加至待执行请求的集合中，等待执行中的请求完成之后，再执行相同host数量判断满足才添加至线程池中执行请求；
注释3：将请求对象AsyncCall添加进请求执行的集合中；
注释4：将请求对象AsyncCall添加进线程池中执行；
注释5：当不满足执行条件时(注释2)，把请求对象添加至待执行的集合中；
注释6：每当一个请求执行完毕时，就会调用finished()去掉对应集合中的存储对象，并在次判断待执行的集合中是否有满足条件的请求，若满足就添加至执行的集合与线程池中执行，若不满足继续等待下一个请求完成再次判断。
注释7：判断待执行的集合中是否满足可执行的对象。

2.RealConnection与HttpCodec初始化(RealConnection在ConnectInterceptor中通过StreamAllocation的newStream()初始化，而HttpCodec在RealConnection中被初始化)

㈩ Android事件分发与回传机制

[图片上传失败...(image-85aaf7-1630895208631)]

[图片上传失败...(image-8c09b-1630895208631)]

[图片上传失败...(image-25abb8-1630895208631)]

日常处理的部分为RootView下面的ViewGroup和View部分，那么上面的PhoneWindow、DecorView和RootView是做什么用的呢？RootView本身可以作为上下沟通的桥梁使用。

（设计模式-组合模式）

PhoneWindow是Window的实现类，Window是抽象类，DecorView是它的一个内部类。所以，PhoneWindow的大部分消息，都是PhoneWindow通过DecorView传递给下面的View的，同时下面的View传递消息也是通过DecorView回传给PhoneWindow。

事件的传递过程中，主要有三种情况：事件分发（dispatchTouchEvent）、事件拦截（onInterceptTouchEvent）、事件消费（onTouchEvent）。这三种情况均有一个boolean型的返回值来控制事件的传递流程。

为什么只有ViewGroup有事件拦截：因为Activity作为事件分发的开始，拦截了就只能自己处理了；而View作为事件分发的最末端，拦不拦截都需要它处理。中间阶段，拦截可做一些处理。

事件传递的顺序：

Activity -> PhoneWindow -> DecorView -> ViewGroup -> View -> Activity

如果我们点击View1，系统如何传递给View1呢，而不是下面的ViewGroupA或者RootView。很明显，我们需要一种机制来执行消息的分发。而消息分发的最小单位是View，ViewGroup是View的子类，Activity是根布局.

事件消费与否与具体消费无关，仅由返回值决定，true表示消费，false表示不消费。