android的事件分发,android事件分发与处理

Android——彻底搞懂事件分发机制

事件分发，总觉得不好理解，感觉非常麻烦，因为它涉及到的东西实在太多了，到底怎么分发与以下因素都有关：在哪个视图层级（Activity、ViewGroup、View），什么事件类型（DOWN、MOVE、UP、CANCEL），在哪个回调方法（dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent），回调方法返回不同的返回值（true、false）。这些因素都会影响事件的分发，如果单纯死记硬背，就算当时背过了，过一段时间也就忘了，所以，真正理解事件分发，才是搞懂事件分发的关键。要理解事件分发，那我们就需要弄清楚，为什么需要事件分发，它具体又是做了什么呢？

我们现在知道，事件是Activity-ViewGroup-View这样层层传递的，每个层级都应该有处理事件的能力，显然，我们需要两个方法，一个用来传递事件，一个用来处理时事件。我们分别定义三个类：MActivity，MViewGroup，MView 来分别模拟Activity，ViewGroup和View，一步一步实现事件分发。

这个需求很简单，我们只是需要最里层View处理事件，假如，不光最里层View可以处理事件，包裹它的ViewGroup也能处理事件，这应该怎么办呢？比如，ViewGroup是可以点击的。

【透镜系列】看穿 触摸事件分发

相关问答

Q1: Android TV 按键焦点事件分发流程详解

DecorView →PhoneWindow →Activity→ViewGroup→view

下面我们根据按键事件的分发流程，抽丝剥茧，逐一分析。

private int processKeyEvent(QueuedInputEvent q)

1、DecorView.java

2、Activity.java

3、ViewGroup.java

4、View.java

通过该方法，接收器receiver的onKeyDown、onKeyUp、onKeyLongPress、onKeyMultiple等方法将被回调。

在上述按键事件的入口中提到的ViewRootImpl中

如果mView.dispatchKeyEvent(event)返回true，则结束事件分发；

如果返回false，则调用如下方法

继续执行后续的焦点导航流程。

焦点导航的总体流程就是：

1、View focused = mView.findFocus();//从视图树的顶层，即DecorView一层一层的递归查找当前获得焦点的view

2、View v = focused.focusSearch(direction);根据导航的方向查找下一个可获取焦点的view

3、v.requestFocus(direction, mTempRect)请求获取焦点

4、v.requestFocus(direction,mTempRect)内部，调用mParent.requestChildFocus(this, focused)逐层递归向上级通知

ViewRootImpl.java

mView即DecorView,从DecorView开始，一层一层的向下递归查找当前获得焦点的view

找到了当前获得焦点的focused,调用该焦点view的focusSearch(direction)方法查找direction方向上下一个将要获取焦点的view。

focused.focusSearch(direction)实际上会调用mParent.focusSearch(this, direction)方法，层层递归，直到调用到DecorView的focusSearch(this, direction)方法。

而DecorView继承ViewGroup，实际上最终会调用到FocusFinder.getInstance().findNextFocus(this, focused, direction)，this 就是DecorView对象。

最终会调用到DecorView父类ViewGroup中的FocusFinder.getInstance().findNextFocus(this, focused, direction);

ViewGroup.java

FocusFinder.java

搜索到下一个获取焦点的view后，调用该view.requestFocus(direction, mTempRect)方法

注意:调用requestFocus(direction, mTempRect)需要区分调用者。

如果是ViewGroup，则会更加焦点获取策略，实现父View和子View之间获取焦点的优先级。

如下是ViewGroup.java 和View.java 中requestFocus方法是实现：

ViewGroup.java

View.java

View获取到焦点后，会调用mParent.requestChildFocus(this, focused)逐层递归向上级通知

ViewGroup.java

Q2: Android View 事件分发机制

Android 事件机制包含系统启动流程、输入管理(InputManager)、系统服务和 UI 的通信(WindowManagerService + ViewRootImpl + Window)、事件分发等一系列的环节。

Android 系统中将输入事件定义为 InputEvent，根据输入事件的类型又分为了 KeyEvent（键盘事件） 和 MotionEvent（屏幕触摸事件）。这些事件统一由系统输入管理器 InputManager 进行分发。

在系统启动的时候，SystemServer 会启动 WindowManagerService，WMS 在启动的时候通过 InputManager 来负责监控键盘消息。

InputManager 负责从硬件接收输入事件，并将事件通过 ViewRootImpl 分发给当前激活的窗口处理，进而分发给 View。

Window 和 InputManagerService 之间通过 InputChannel 来通信，底层通过 socket 进行通信。

Android Touch 事件的基础知识：

KeyEvent 对应了键盘的输入事件；MotionEvent 就是手势事件，鼠标、笔、手指、轨迹球等相关输入设备的事件都属于 MotionEvent。

InputEvent 统一由 InputManager 进行分发，负责与硬件通信并接收输入事件。

system_server 进程启动时会创建 InputManagerService 服务。

system_server 进程启动时同时会启动 WMS，WMS 在启动的时候就会通过 IMS 启动 InputManager 来监控键盘消息。

App 端与服务端建立了双向通信之后，InputManager 就能够将产生的输入事件从底层硬件分发过来，Android 提供了 InputEventReceiver 类，以接收分发这些消息：

Window 和 IMS 之间通过 InputChannel 通信。InputChannel 是一个 pipe，底层通过 socket 进行通信。在 ViewRootImpl.setView() 过程中注册 InputChannel。

Android 事件传递机制是 先分发再处理 ，先由外部的 View 接收，然后依次传递给其内层的 View，再从最内层 View 反向依次向外层传递。

三个方法的关系如下：

分发事件：

应用了树的 深度优先搜索算法 （Depth-First-Search，简称 DFS 算法），每个 ViewGroup 都持有一个 mFirstTouchTarget, 当接收到 ACTION_DOWN 时，通过递归遍历找到 View 树中真正对事件进行消费的 Child，并保存在 mFirstTouchTarget 属性中，依此类推组成一个完整的分发链。在这之后，当接收到同一事件序列的其它事件如 ACTION_MOVE、ACTION_UP 时，则会跳过递归流程，将事件直接分发给下一级的 Child。

ViewGroup 分发事件的主要的任务是找一个 Target，并且用这个 Target 处理事件，主要逻辑如下 ：

为什么倒序查找 TouchTarget?

如果按添加顺序遍历，当 View 重叠时（FrameLayout），先添加的 View 总是能消费事件，而后添加的 View 不可能获取到事件。

拦截事件：

[1] Android 事件分发机制的设计与实现

[2] Android 事件拦截机制的设计与实现

Q3: 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表示不消费。

Q4: Android事件分发机制

dispatchTouchEvent方法：

onInterceptTouchEvent方法：

流程分析：

View的dispatchTouchEvent方法：

View的onTouchEvent方法：

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

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

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

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

综合上述对安卓事件分发的源码分析知道，当在上层FrameLayout中将clickable设置为true时，其实就是

当点击事件到达上层framelayout时，在onTouchEvent中对事件进行拦截，使得点击事件不会继续向下传递。当然，除了这个方法以外，也可以重写FrameLayout的onInterceptTouchEvent,在将这个函数的返回值为true，也可以实现拦截事件的作用。