Android 编程下 Touch 事件的分发和消费机制

Android 中与 Touch 事件相关的方法包括：dispatchTouchEvent(MotionEvent ev)、onInterceptTouchEvent(MotionEvent ev)、onTouchEvent(MotionEvent ev)；能够响应这些方法的控件包括：ViewGroup、View、Activity。方法与控件的对应关系如下表所示：

Touch 事件相关方法方法功能
ViewGroup View Activity
public boolean dispatchTouchEvent(MotionEvent ev) 事件分发 Yes Yes Yes
public boolean onInterceptTouchEvent(MotionEvent ev) 事件拦截 Yes Yes No
public boolean onTouchEvent(MotionEvent ev) 事件响应 Yes Yes Yes

从这张表中我们可以看到 ViewGroup 和 View 对与 Touch 事件相关的三个方法均能响应，而 Activity 对 onInterceptTouchEvent(MotionEvent ev) 也就是事件拦截不进行响应。另外需要注意的是 View 对 dispatchTouchEvent(MotionEvent ev) 和 onInterceptTouchEvent(MotionEvent ev) 的响应的前提是可以向该 View 中添加子 View，如果当前的 View 已经是一个最小的单元 View（比如 TextView），那么就无法向这个最小 View 中添加子 View，也就无法向子 View 进行事件的分发和拦截，所以它没有 dispatchTouchEvent(MotionEvent ev) 和 onInterceptTouchEvent(MotionEvent ev)，只有 onTouchEvent(MotionEvent ev)。

Touch 事件分析

事件分发：public boolean dispatchTouchEvent(MotionEvent ev)

Touch 事件发生时 Activity 的 dispatchTouchEvent(MotionEvent ev) 方法会以隧道方式（从根元素依次往下传递直到最内层子元素或在中间某一元素中由于某一条件停止传递）将事件传递给最外层 View 的 dispatchTouchEvent(MotionEvent ev) 方法，并由该 View 的 dispatchTouchEvent(MotionEvent ev) 方法对事件进行分发。dispatchTouchEvent 的事件分发逻辑如下：

如果 return true，事件会分发给当前 View 并由 dispatchTouchEvent 方法进行消费，同时事件会停止向下传递；
如果 return false，事件分发分为两种情况：
```
如果当前 View 获取的事件直接来自 Activity，则会将事件返回给 Activity 的 onTouchEvent 进行消费；  
如果当前 View 获取的事件来自外层父控件，则会将事件返回给父 View 的 onTouchEvent 进行消费。  
```
如果返回系统默认的 super.dispatchTouchEvent(ev)，事件会自动的分发给当前 View 的 onInterceptTouchEvent 方法。
事件拦截：public boolean onInterceptTouchEvent(MotionEvent ev)

在外层 View 的 dispatchTouchEvent(MotionEvent ev) 方法返回系统默认的 super.dispatchTouchEvent(ev) 情况下，事件会自动的分发给当前 View 的 onInterceptTouchEvent 方法。onInterceptTouchEvent 的事件拦截逻辑如下：

如果 onInterceptTouchEvent 返回 true，则表示将事件进行拦截，并将拦截到的事件交由当前 View 的 onTouchEvent 进行处理；
如果 onInterceptTouchEvent 返回 false，则表示将事件放行，当前 View 上的事件会被传递到子 View 上，再由子 View 的 dispatchTouchEvent 来开始这个事件的分发；
如果 onInterceptTouchEvent 返回 super.onInterceptTouchEvent(ev)，事件默认会被拦截，并将拦截到的事件交由当前 View 的 onTouchEvent 进行处理。
事件响应：public boolean onTouchEvent(MotionEvent ev)

在 dispatchTouchEvent 返回 super.dispatchTouchEvent(ev) 并且 onInterceptTouchEvent 返回 true 或返回 super.onInterceptTouchEvent(ev) 的情况下 onTouchEvent 会被调用。onTouchEvent 的事件响应逻辑如下：

如果事件传递到当前 View 的 onTouchEvent 方法，而该方法返回了 false，那么这个事件会从当前 View 向上传递，并且都是由上层 View 的 onTouchEvent 来接收，如果传递到上面的 onTouchEvent 也返回 false，这个事件就会“消失”，而且接收不到下一次事件。
如果返回了 true 则会接收并消费该事件。
如果返回 super.onTouchEvent(ev) 默认处理事件的逻辑和返回 false 时相同。

到这里，与 Touch 事件相关的三个方法就分析完毕了。下面的内容会通过各种不同的的测试案例来验证上文中三个方法对事件的处理逻辑。

Touch 案例介绍

同样在开始进行案例分析之前，我需要说明测试案例的结构，因为所有的测试都是针对这一个案例来进行的，测试中只是通过修改每个控件中与 Touch 事件相关的三个方法的返回值来体现不同的情况。先来看张图：

Touch 事件案例布局 UI

上面的图为测试案例的布局文件 UI 显示效果，布局文件代码如下：

事件分发机制原理

事件分发机制原理[推荐：★★★★★]

事件分发机制详解

事件分发机制详解[推荐：★★★★★]

MotionEvent

MotionEvent详解[推荐：★★★★★]

View 与ViewGroup关系

http://www.cnblogs.com/hnrainll/archive/2011/11/14/2248564.html

.1.0 View及ViewGroup类关系
Android View和ViewGroup从组成架构上看，似乎ViewGroup在View之上，View需要继承ViewGroup，但实际上不是这样的。 View是基类，ViewGroup是它的子类。这就证明了一点，View代表了用户界面组件的一块可绘制的空间块。每一个View在屏幕上占据一个长方形区域。在这个区域内，这个VIEW对象负责图形绘制和事件处理。View是小控件widgets和ViewGroup的父类。ViewGroup又是 Layout的基类。

image

从上面两图的对比中，可以看出，实际上ViewGroup是View的子类，因此，View的行为特征ViewGroup也具备，但同时因为 ViewGroup是Layout的祖先，所以具备了其它一些特点,View所未具有的。通常创建一个View，不论是通过XML还是通过代码创建。对任何一个View及这个View的子类Widget，需要关注如下几个方面：
【1】设置属性，如长、宽、着色等。这些属性的设置通常可以用代码实现，也可以用XML文件。并用这些属性在运行时候也可以通常方法进行修改。
ID 属性，Android对每个UI元素的ID名称要求唯一，但也不绝对。同时在不同的Layout中是可以相同的元素名称的。给一个UI元素指定ID，有一个好处就是可以在代码中找得到。

image

Tags，同ID不同，这个不用来搜索View,类似于对View的一些描述性数据保存。
Animation，对任何一个View，可以使用动画对象进行操作。注意，如果View有子的话，子同样具备这个animation功能
Position, Size, padding and margins，对任一个View来说，表达这个View通常是宽和高。也可以设置padding和margins。不是所有的View都设置margins。

image

Orientatiion，对ViewGroup的子类Layout来说，设置Orienatation，可用来决定子类的位置
FillModel，出现这种情况主要是默认情况，某些元素不能完全占满父区域的空间，这时除非子VIEW已经设置具体和DPI，否则话需要告诉父控件，你所选择填充空间方式，如Fill-parent或者Wrap-content等。
Gravity，Gravity与Orientation是不同，Gravaity与Word文档中左对齐，右对齐类似。缺省是左上对齐。
Weight,这个在两个控制同时分配剩余空间，需要设置layout-weight决定两者谁的占比。
【2】请求焦点，可以通过函数实现焦点转换。不同的焦点可以实现不同的背景变换等功能。焦点在Android里分为几种情况，一种是可以获取焦点，另外一种是不能获取焦点，第三种是可获取焦点，但当前正取触摸状态下。
【3】设置事件监听者，所有的View都会在本身发生变化将自身的信息广播出去。比喻点击、焦点失去得到等。通常一个事件来到，Android会将事件传递到相应的View，然后View将事件传递到相应的Listeners。这时View需要获取焦点，如果需要重新绘制View的话，需要调用 invalidate(0或者reqeustLayout重新绘制整个界面。
【4】设置显示与隐藏，还可以对其内容设置scrolling。
2.1.1 View、Window、Activity、Dispay之间的关系
这些都是组成Android 系统显示的关键元素。我们首先来了解Dispay。Dispay代表了硬件显示屏幕信息。

image

通过这些函数可以了解一个屏幕的宽、高及分辨率还有是横屏还坚屏等一些基本情况，透过这些函数，我们开发应用时可以方便的得到当前安装我这个应用的屏幕的大小，以便调整应用使用户得到更好的用户体验。接下来我们看其它三者之间的关系，我想大家虽然看了前面的View的介绍和SDK中关系UI的基本介绍之后还是对Android图形窗口十分困惑，看API也是，有WindowMangaer接口和Window类，但是在说明文档中，并未提到如何用这些。但实际上这里面要去看到Android核心，Android核心底层GDI是SKIA，同chrome是一样的GDI，但是GUI是不一样的。这里面 Android实现的是C/S模式。如下图所示

image

从上图，我们可以理出大致的显示过程如下：
【1】ActivityManagerService创建Activity线程，激活一个activity
【2】系统调用Instrumentation.newActivity创建一个activity
【3】Activity创建后，attach到一个新创建的phonewindow中。这样Activity获取一个唯一的WindowManager服务的实例
【4】Activity创建过程中使用setcontentView设置用用户UI，这些VIEW被加入到PhoneWindow的ContentParent中。
【5】Activity线程继续执行，当执行到Activity.makeVisible是将根view DecoView加入到WindowManger中，WindowManger实全会为每个DecoView创建对应的ViewRoot
【6】每个ViewRoot拥有一个Surface，每个Surface将会调用底层库创建图形绘制的内存空间。这个底层库就是SurfaceFlinger。SurfaceFlinger同时也负责将个View绘制的图形合到一块（按照Z轴）显示到用户屏幕。
【7】如果用户直接在Canvas上绘制，实际上它直接操作Surface。但对每个View的变更，它是要通知到ViewRoot，然后 ViewRoot获取Canvas。如果绘制完成，surfaceFlinger得到通知，合并Surface成一个Surface到设备屏幕。
从上面的图形输出过程分析，我们可以知道真正显示图形的实际上跟Activity没有关系，完全由WindowManager来决定。 WindowManager是一个系统服务，因此可以直接调用这个服务来创建界面，并且更绝的是Dialog、Menu也是有WindowManager 来管理的。另外一个我们也可以看到，最底层都是Surface来，因此，常见开发游戏的人都推荐你使用SurfaceView来创建界面。

Android中View的机制图