Android事件分发机制(上) ViewGroup的事件分发

综述

  Android中的事件分发机制也就是View与ViewGroup的对事件的分发与处理。在ViewGroup的内部包含了许多View,而ViewGroup继承自View,所以ViewGroup本身也是一个View。对于事件可以通过ViewGroup下发到它的子View并交由子View进行处理,而ViewGroup本身也能够对事件做出处理。下面就来详细分析一下ViewGroup对时间的分发处理。

MotionEvent

  当手指接触到屏幕以后,所产生的一系列的事件中,都是由以下三种事件类型组成。
  1. ACTION_DOWN: 手指按下屏幕
  2. ACTION_MOVE: 手指在屏幕上移动
  3. ACTION_UP: 手指从屏幕上抬起
  例如一个简单的屏幕触摸动作触发了一系列Touch事件:ACTION_DOWN->ACTION_MOVE->…->ACTION_MOVE->ACTION_UP
  对于Android中的这个事件分发机制,其中的这个事件指的就是MotionEvent。而View的对事件的分发也是对MotionEvent的分发操作。可以通过getRawX和getRawY来获取事件相对于屏幕左上角的横纵坐标。通过getX()和getY()来获取事件相对于当前View左上角的横纵坐标。

三个重要方法

public boolean dispatchTouchEvent(MotionEvent ev)

  这是一个对事件分发的方法。如果一个事件传递给了当前的View,那么当前View一定会调用该方法。对于dispatchTouchEvent的返回类型是boolean类型的,返回结果表示是否消耗了这个事件,如果返回的是true,就表明了这个View已经被消耗,不会再继续向下传递。  

public boolean onInterceptTouchEvent(MotionEvent ev)

  该方法存在于ViewGroup类中,对于View类并无此方法。表示是否拦截某个事件,ViewGroup如果成功拦截某个事件,那么这个事件就不在向下进行传递。对于同一个事件序列当中,当前View若是成功拦截该事件,那么对于后面的一系列事件不会再次调用该方法。返回的结果表示是否拦截当前事件,默认返回false。由于一个View它已经处于最底层,它不会存在子控件,所以无该方法。   

public boolean onTouchEvent(MotionEvent event)

  这个方法被dispatchTouchEvent调用,用来处理事件,对于返回的结果用来表示是否消耗掉当前事件。如果不消耗当前事件的话,那么对于在同一个事件序列当中,当前View就不会再次接收到事件。   

 View事件分发流程图

  对于事件的分发,在这里先通过一个流程图来看一下整个分发过程。

ViewGroup事件分发源码分析

  根据上面的流程图现在就详细的来分析一下ViewGroup事件分发的整个过程。
  手指在触摸屏上滑动所产生的一系列事件,当Activity接收到这些事件通过调用Activity的dispatchTouchEvent方法来进行对事件的分发操作。下面就来看一下Activity的dispatchTouchEvent方法。

public boolean dispatchTouchEvent(MotionEvent ev) {
 if (ev.getAction() == MotionEvent.ACTION_DOWN) {
 onUserInteraction();
 }
 if (getWindow().superDispatchTouchEvent(ev)) {
 return true;
 }
 return onTouchEvent(ev);
}

  通过getWindow().superDispatchTouchEvent(ev)这个方法可以看出来,这个时候Activity又会将事件交由Window处理。Window它是一个抽象类,它的具体实现只有一个PhoneWindow,也就是说这个时候,Activity将事件交由PhoneWindow中的superDispatchTouchEvent方法。现在跟踪进去看一下这个superDispatchTouchEvent代码。

public boolean superDispatchTouchEvent(MotionEvent event) {
 return mDecor.superDispatchTouchEvent(event);
}

  这里面的mDecor它是一个DecorView,DecorView它是一个Activity的顶级View。它是PhoneWindow的一个内部类,继承自FrameLayout。于是在这个时候事件又交由DecorView的superDispatchTouchEvent方法来处理。下面就来看一下这个superDispatchTouchEvent方法。

public boolean superDispatchTouchEvent(MotionEvent event) {
 return super.dispatchTouchEvent(event);
}

  在这个时候就能够很清晰的看到DecorView它调用了父类的dispatchTouchEvent方法。在上面说到DecorView它继承了FrameLayout,而这个FrameLayout又继承自ViewGroup。所以在这个时候事件就开始交给了ViewGroup进行处理了。下面就开始详细看下这个ViewGroup的dispatchTouchEvent方法。由于dispatchTouchEvent代码比较长,在这里就摘取部分代码进行说明。

// Handle an initial down.
if (actionMasked == MotionEvent.ACTION_DOWN) {
 // Throw away all previous state when starting a new touch gesture.
 // The framework may have dropped the up or cancel event for the previous gesture
 // due to an app switch, ANR, or some other state change.
 cancelAndClearTouchTargets(ev);
 resetTouchState();
}

  从上面代码可以看出,在dispatchTouchEvent中,会对接收的事件进行判断,当接收到的是ACTION_DOWN事件时,便会清空事件分发的目标和状态。然后执行resetTouchState方法重置了触摸状态。下面就来看一下这两个方法。

1. cancelAndClearTouchTargets(ev)

private TouchTarget mFirstTouchTarget;

......

private void cancelAndClearTouchTargets(MotionEvent event) {
 if (mFirstTouchTarget != null) {
 boolean syntheticEvent = false;
 if (event == null) {
  final long now = SystemClock.uptimeMillis();
  event = MotionEvent.obtain(now, now,
   MotionEvent.ACTION_CANCEL, 0.0f, 0.0f, 0);
  event.setSource(InputDevice.SOURCE_TOUCHSCREEN);
  syntheticEvent = true;
 }

 for (TouchTarget target = mFirstTouchTarget; target != null; target = target.next) {
  resetCancelNextUpFlag(target.child);
  dispatchTransformedTouchEvent(event, true, target.child, target.pointerIdBits);
 }
 clearTouchTargets();

 if (syntheticEvent) {
  event.recycle();
 }
 }
}

  在这里先介绍一下mFirstTouchTarget,它是TouchTarget对象,TouchTarget是ViewGroup的一个内部类,TouchTarget采用链表数据结构进行存储View。而在这个方法中主要的作用就是清空mFirstTouchTarget链表并将mFirstTouchTarget设为空。

2. resetTouchState()

private void resetTouchState() {
 clearTouchTargets();
 resetCancelNextUpFlag(this);
 mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;
 mNestedScrollAxes = SCROLL_AXIS_NONE;
}

  在这里介绍一下FLAG_DISALLOW_INTERCEPT标记,这是禁止ViewGroup拦截事件的标记,可以通过requestDisallowInterceptTouchEvent方法来设置这个标记,当设置了这个标记以后,ViewGroup便无法拦截除了ACTION_DOWN以外的其它事件。因为在上面代码中可以看出,当事件为ACTION_DOWN时,会重置FLAG_DISALLOW_INTERCEPT标记。
  那么下面就再次回到dispatchTouchEvent方法中继续看它的源代码。

// Check for interception.
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
 || mFirstTouchTarget != null) {
 final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
 if (!disallowIntercept) {
 intercepted = onInterceptTouchEvent(ev);
 ev.setAction(action); // restore action in case it was changed
 } else {
 intercepted = false;
 }
} else {
 // There are no touch targets and this action is not an initial down
 // so this view group continues to intercept touches.
 intercepted = true;
}

  这段代码主要就是ViewGroup对事件是否需要拦截进行的判断。下面先对mFirstTouchTarget是否为null这两种情况进行说明。当事件没有被拦截时,ViewGroup的子元素成功处理事件后,mFirstTouchTarget会被赋值并且指向其子元素。也就是说这个时候mFirstTouchTarget!=null。可是一旦事件被拦截,mFirstTouchTarget不会被赋值,mFirstTouchTarget也就为null。
  在上面代码中可以看到根据actionMasked==MotionEvent.ACTION_DOWN||mFirstTouchTarget!=null这两个情况进行判断事件是否需要拦截。对于actionMasked==MotionEvent.ACTION_DOWN这个条件很好理解,对于mFirstTouchTarget!=null的两种情况上面已经说明。那么对于一个事件序列,当事件为MotionEvent.ACTION_DOWN时,会重置FLAG_DISALLOW_INTERCEPT,也就是说!disallowIntercept一定为true,必然会执行onInterceptTouchEvent方法,对于onInterceptTouchEvent方法默认返回为false,所以需要ViewGroup拦截事件时,必须重写onInterceptTouchEvent方法,并返回true。这里有一点需要注意,对于一个事件序列,一旦序列中的某一个事件被成功拦截,执行了onInterceptTouchEvent方法,也就是说onInterceptTouchEvent返回值为true,那么该事件之后一系列事件对于条件actionMasked==MotionEvent.ACTION_DOWN||mFirstTouchTarget!=null必然为false,那么这个时候该事件序列剩下的一系列事件将会被拦截,并且不会执行onInterceptTouchEvent方法。于是在这里得出一个结论:对于一个事件序列,当其中某一个事件成功拦截时,那么对于剩下的一系列事件也会被拦截,并且不会再次执行onInterceptTouchEvent方法
  下面再来看一下对于ViewGroup并没有拦截事件是如何进行处理的。

final int childrenCount = mChildrenCount;
if (newTouchTarget == null && childrenCount != 0) {
 final float x = ev.getX(actionIndex);
 final float y = ev.getY(actionIndex);
 // Find a child that can receive the event.
 // Scan children from front to back.
 final ArrayList<View> preorderedList = buildOrderedChildList();
 final boolean customOrder = preorderedList == null
  && isChildrenDrawingOrderEnabled();
 final View[] children = mChildren;
 for (int i = childrenCount - 1; i >= 0; i--) {
 final int childIndex = customOrder
  ? getChildDrawingOrder(childrenCount, i) : i;
 final View child = (preorderedList == null)
  ? children[childIndex] : preorderedList.get(childIndex);

 // If there is a view that has accessibility focus we want it
 // to get the event first and if not handled we will perform a
 // normal dispatch. We may do a double iteration but this is
 // safer given the timeframe.
 if (childWithAccessibilityFocus != null) {
  if (childWithAccessibilityFocus != child) {
  continue;
  }
  childWithAccessibilityFocus = null;
  i = childrenCount - 1;
 }

 if (!canViewReceivePointerEvents(child)
  || !isTransformedTouchPointInView(x, y, child, null)) {
  ev.setTargetAccessibilityFocus(false);
  continue;
 }

 newTouchTarget = getTouchTarget(child);
 if (newTouchTarget != null) {
  // Child is already receiving touch within its bounds.
  // Give it the new pointer in addition to the ones it is handling.
  newTouchTarget.pointerIdBits |= idBitsToAssign;
  break;
 }

 resetCancelNextUpFlag(child);
 if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
  // Child wants to receive touch within its bounds.
  mLastTouchDownTime = ev.getDownTime();
  if (preorderedList != null) {
  // childIndex points into presorted list, find original index
  for (int j = 0; j < childrenCount; j++) {
   if (children[childIndex] == mChildren[j]) {
   mLastTouchDownIndex = j;
   break;
   }
  }
  } else {
  mLastTouchDownIndex = childIndex;
  }
  mLastTouchDownX = ev.getX();
  mLastTouchDownY = ev.getY();
  newTouchTarget = addTouchTarget(child, idBitsToAssign);
  alreadyDispatchedToNewTouchTarget = true;
  break;
 }

 // The accessibility focus didn't handle the event, so clear
 // the flag and do a normal dispatch to all children.
 ev.setTargetAccessibilityFocus(false);
 }
 if (preorderedList != null) preorderedList.clear();
}

  对于这段代码虽然说比较长,但是在这里面的逻辑去不是很复杂。首先获取当前ViewGroup中的子View和ViewGroup的数量。然后对该ViewGroup中的元素进行逐步遍历。在获取到ViewGroup中的子元素后,判断该元素是否能够接收触摸事件。子元素若是能够接收触摸事件,并且该触摸坐标在子元素的可视范围内的话,便继续向下执行。否则就continue。对于衡量子元素能否接收到触摸事件的标准有两个:子元素是否在播放动画和点击事件的坐标是否在子元素的区域内。
  一旦子View接收到了触摸事件,然后便开始调用dispatchTransformedTouchEvent方法对事件进行分发处理。对于dispatchTransformedTouchEvent方法代码比较多,现在只关注下面这五行代码。从下面5行代码中可以看出,这时候会调用子View的dispatchTouchEvent,也就是在这个时候ViewGroup已经完成了事件分发的整个过程。

if (child == null) {
 handled = super.dispatchTouchEvent(event);
} else {
 handled = child.dispatchTouchEvent(event);
}

  当子元素的dispatchTouchEvent返回为true的时候,也就是子View对事件处理成功。这时候便会通过addTouchTarget方法对mFirstTouchTarget进行赋值。
  如果dispatchTouchEvent返回了false,或者说当前的ViewGroup没有子元素的话,那么这个时候便会调用如下代码。

if (mFirstTouchTarget == null) {
 // No touch targets so treat this as an ordinary view.
 handled = dispatchTransformedTouchEvent(ev, canceled, null,
  TouchTarget.ALL_POINTER_IDS);
}

  在这里调用dispatchTransformedTouchEvent方法,并将child参数设为null。也就是执行了super.dispatchTouchEvent(event)方法。由于ViewGroup继承自View,所以这个时候又将事件交由父类的dispatchTouchEvent进行处理。对于父类View是如何通过dispatchTouchEvent对事件进行处理的,在下篇文章中会进行详细说明。
  到这里对于ViewGroup的事件分发已经讲完了,在这一路下来,不难发现对于dispatchTouchEvent有一个boolean类型返回值。对于这个返回值,当返回true的时候表示当前事件处理成功,若是返回false,一般来说是因为在事件处理onTouchEvent返回了false,这时候变会交由它的父控件进行处理,以此类推,若是一直处理失败,则最终会交由Activity的onTouchEvent方法进行处理。

总结

  在这里从宏观上再看一下这个ViewGroup对事件的分发,当ViewGroup接收一个事件序列以后,首先会判断是否拦截该事件,若是拦截该事件,则通过调用父类View的dispatchTouchEvent来处理这个事件。若是不去拦截这一事件,便将该事件下发到子View当中。若果说ViewGroup没有子View,或者说子View对事件处理失败,则将该事件有交由该ViewGroup处理,若是该ViewGroup对事件依然处理失败,最终则会将事件交由Activity进行处理。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

时间: 2017-01-13

Android View的事件分发机制

一.Android View框架提供了3个对事件的主要操作概念. 1.事件的分发机制,dispatchTouchEvent.主要是parent根据触摸事件的产生位置,以及child是否愿意负责处理该系列事件等状态,向其child分发事件的机制. 2.事件的拦截机制,onInterceptTouchEvent.主要是parent根据它内部的状态.或者child的状态,来把事件拦截下来,阻止其进一步传递到child的机制. 3.事件的处理机制,onTouchEvent.主要是事件序列的接受者(可以是

android事件分发机制的实现原理

android中的事件处理,以及解决滑动冲突问题都离不开事件分发机制,android中的事件流,即MotionEvent都会经历一个从分发,拦截到处理的一个过程.即dispatchTouchEvent(),onInterceptEvent()到onTouchEvent()的一个过程,在dispatchTouchEvent()负责了事件的分发过程,在dispatchTouchEvent()中会调用onInterceptEvent()与onTouchEvent(),如果onInterceptEven

Android View事件分发机制详解

准备了一阵子,一直想写一篇事件分发的文章总结一下,这个知识点实在是太重要了. 一个应用的布局是丰富的,有TextView,ImageView,Button等,这些子View的外层还有ViewGroup,如RelativeLayout,LinearLayout.作为一个开发者,我们会思考,当点击一个按钮,Android系统是怎样确定我点的就是按钮而不是TextView的?然后还正确的响应了按钮的点击事件.内部经过了一系列什么过程呢? 先铺垫一些知识能更加清晰的理解事件分发机制: 1. 通过setC

Android View 事件分发机制详解

Android开发,触控无处不在.对于一些 不咋看源码的同学来说,多少对这块都会有一些疑惑.View事件的分发机制,不仅在做业务需求中会碰到这些问题,在一些面试笔试题中也常有人问,可谓是老生常谈了.我以前也看过很多人写的这方面的文章,不是说的太啰嗦就是太模糊,还有一些在细节上写的也有争议,故再次重新整理一下这块内容,十分钟让你搞明白View事件的分发机制. 说白了这些触控的事件分发机制就是弄清楚三个方法,dispatchTouchEvent(),OnInterceptTouchEvent(),o

Android View事件分发和消费源码简单理解

Android View事件分发和消费源码简单理解 前言: 开发过程中觉得View事件这块是特别烧脑的,看了好久,才自认为看明白.中间上网查了下singwhatiwanna粉丝的读书笔记,有种茅塞顿开的感觉. 很重要的学习方法:化繁为简,只抓重点. 源码一坨,不要指望每一行代码都看懂.首先是没必要,其次大量非关键代码会让你模糊真正重要的部分. 以下也只是学姐的学习成果,各位同学要想理解深刻,还需要自己亲自去看源码. 2.源码分析 由于源码实在太长,而且也不容易看懂,学姐这里就不贴出来了,因为没必

Android事件分发机制的详解

Android事件分发机制 我们只考虑最重要的四个触摸事件,即:DOWN,MOVE,UP和CANCEL.一个手势(gesture)是一个事件列,以一个DOWN事件开始(当用户触摸屏幕时产生),后跟0个或多个MOVE事件(当用户四处移动手指时产生),最后跟一个单独的UP或CANCEL事件(当用户手指离开屏幕或者系统告诉你手势(gesture)由于其他原因结束时产生).当我们说到"手势剩余部分"时指的是手势后续的MOVE事件和最后的UP或CANCEL事件. 在这里我也不考虑多点触摸手势(我

Android 事件分发详解及示例代码

事件分发是Android中非常重要的机制,是用户与界面交互的基础.这篇文章将通过示例打印出的Log,绘制出事件分发的流程图,让大家更容易的去理解Android的事件分发机制. 一.必要的基础知识 1.相关方法 Android中与事件分发相关的方法主要包括dispatchTouchEvent.onInterceptTouchEvent.onTouchEvent三个方法,而事件分发一般会经过三种容器,分别为Activity.ViewGroup.View.下表对这三种容器分别拥有的事件分发相关方法进行

Android事件分发机制(下) View的事件处理

综述 在上篇文章Android中的事件分发机制(上)--ViewGroup的事件分发中,对ViewGroup的事件分发进行了详细的分析.在文章的最后ViewGroup的dispatchTouchEvent方法调用dispatchTransformedTouchEvent方法成功将事件传递给ViewGroup的子View.并交由子View进行处理.那么现在就来分析一下子View接收到事件以后是如何处理的. View的事件处理 对于这里描述的View,它是ViewGroup的父类,并不包含任何的子元

Android Touch事件分发深入了解

本文带着大家深入学习触摸事件的分发,具体内容如下 1. 触摸动作及事件序列 (1)触摸事件的动作 触摸动作一共有三种:ACTION_DOWN.ACTION_MOVE.ACTION_UP.当用户手指接触屏幕时,便产生一个动作为ACTION_DOWN的触摸事件,此时若用户的手指立即离开屏幕,会产生一个动作为ACTION_UP的触摸事件:若用户手指接触屏幕后继续滑动,当滑动距离超过了系统中预定义的距离常数,则产生一个动作为ACTION_MOVE的触摸事件,系统中预定义的用来判断用户手指在屏幕上的滑动是

谈谈对Android View事件分发机制的理解

最近因为项目中用到类似一个LinearLayout中水平布局中,有一个TextView和Button,然后对该LinearLayout布局设置点击事件,点击TextView能够触发该点击事件,然而奇怪的是点击Button却不能触发.然后google到了解决办法(重写Button,然后重写其中的ontouchEvent方法,且返回值为false),但是不知道原因,这两天看了几位大神的博客,然后自己总结下. public class MyButton extends Button { private

30分钟搞清楚Android Touch事件分发机制

Touch事件分发中只有两个主角:ViewGroup和View.Activity的Touch事件事实上是调用它内部的ViewGroup的Touch事件,可以直接当成ViewGroup处理. View在ViewGroup内,ViewGroup也可以在其他ViewGroup内,这时候把内部的ViewGroup当成View来分析. ViewGroup的相关事件有三个:onInterceptTouchEvent.dispatchTouchEvent.onTouchEvent.View的相关事件只有两个:

解析Android点击事件分发机制

开头说说初衷 网上关于点击事件分发的文章一搜一大堆,标题一看,不是"30分钟让你弄明白XXX"就是"这是讲解XXX最好的文章",满怀憧憬与信心,忍不住兴奋的点进去一看,发现不是代码就全是图,我基本上看完了所有相关的文章,结果硬是看了三个小时也没搞懂.所以最后还是决定自己去试一试,看一看点击事件分发到底是怎么个流程,我写的肯定不会比其他文章好多少,但是呢,带着一个初学者的心,去分析这个东西,自己能弄明白的同时,也让想学习这个的人看了之后有些许收获,那就足够了. 运行的

Android从源码的角度彻底理解事件分发机制的解析(上)

其实我一直准备写一篇关于Android事件分发机制的文章,从我的第一篇博客开始,就零零散散在好多地方使用到了Android事件分发的知识.也有好多朋友问过我各种问题,比如:onTouch和onTouchEvent有什么区别,又该如何使用?为什么给ListView引入了一个滑动菜单的功能,ListView就不能滚动了?为什么图片轮播器里的图片使用Button而不用ImageView?等等--对于这些问题,我并没有给出非常详细的回答,因为我知道如果想要彻底搞明白这些问题,掌握Android事件分发机