Android的事件传递

在Android尤其是手机端的开发中，很多情况下涉及到点击事件，或者说是触摸事件的特殊处理。比如滑动冲突等，因此熟知Android事件传递的流程就显得格外重要。今天老衲就带大家理一理Android事件传递的相关细节。

方法介绍

事件序列

是指当手指接触屏幕至手指离开屏幕是所产生的一系列Down-->Move-->Up事件。

事件传递涉及到三个方法和两个监听（onClick也算，原因在源码分析中可以看到）：

分发事件
//@return True 表示事件被该View处理
public boolean dispatchTouchEvent(MotionEvent ev)

如果事件能够传递到该View（或activity）则该方法一定会被调用。

拦截事件
//@return True 表示事件被该View拦截
public boolean onInterceptTouchEvent(MotionEvent ev)

在上述方法的内部调用，同一事件序列下，该方法只执行一次

处理事件
//@return True 表示事件被该View消耗
public boolean onTouchEvent(MotionEvent event)
子元素用来干预父元素的事件分发过程，ACTION_DOWN除外
public void requestDisallowInterceptTouchEvent
OnTouchListener及OnClickListener
public void onClick(View v)
public boolean onTouch(View v, MotionEvent event)
  1. OnTouchListener内回调的优先级高于onTouchEvent，并且会根据Listener返回值来影响onTouchEvent方法的执行。
  2. OnClickListener回调的执行是在OnTouchEvent方法内，根据UP,DOWN事件的时长来判断是否需要执行click方法（前提是View可以点击）

事件传递的伪代码

@Override
public boolean dispatchTouchEvent(MotionEvent ev) {    
  boolean result = false; 
  //如果View需要拦截该事件，则事件处理交给onTouchEvent   
  if (onInterceptTouchEvent(ev)){        
      result = onTouchEvent(ev);    
  }else{        
      //如果View不需要拦截事件，则事件交给子View来继续该判断。直至事件被消耗
      result = child.dispatchTouchEvent(ev);       
  }    
  return result;
}

事件分发流程的源码分析

事件分发的流程为activity--->window--->View，

Step1. activity-->window

public boolean dispatchTouchEvent(MotionEvent ev) {    
  //空方法，当需要知道用户与设备在互动时调用，可重写
  if (ev.getAction() == MotionEvent.ACTION_DOWN) {        
      onUserInteraction();    
  }    
  //通过window将事件传递给View树来处理，当返回true(View消耗了)则事件传递结束
  if (getWindow().superDispatchTouchEvent(ev)) {        
      return true;    
  }    
  //如果View并未处理，则交给activity的onTouchEvent来处理。
  return onTouchEvent(ev);
}

Step2. window-->view

window是一个抽象类，superDispatchTouchEvent方法的具体实现是在phoneWindow中。

public class PhoneWindow extends Window implements MenuBuilder.Callback {
// This is the top-level view of the window, containing the window decor.
private DecorView mDecor;
// This is the view in which the window contents are placed. It is either
// mDecor itself, or a child of mDecor where the contents go.
private ViewGroup mContentParent;

//直接调用了DecorView的superDispatchTouchEvent方法
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
  return mDecor.superDispatchTouchEvent(event);
}


private void installDecor() {
   if (mDecor == null) {
     mDecor = generateDecor();
     mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);
     mDecor.setIsRootNamespace(true);
   }
   if (mContentParent == null) {
     mContentParent = generateLayout(mDecor);
    }
    //设置title或actionBar以及其他style样式的逻辑
    ...
}

接下来，我们需要看一下DecorView内部的方法实现逻辑。如下代码，它直接又扔给了super的dispatchTouchEvent。

private final class DecorView extends FrameLayout implements RootViewSurfaceTaker {
  ...
  public boolean superDispatchTouchEvent(MotionEvent event) {
    return super.dispatchTouchEvent(event);
  }
 ...
}

这个super就是FrameLayout。我们都知道DecorView其实就是一个FrameLayout，我们在开发过程中写的所以得布局文件，都会被扔到这个FrameLayout中来展示，接下来我们就开始了本文的重中之重，onTouchEvent事件的分析了。

Step3. View内部的源码解析

Step3.1 View的dispatchTouchEvent逻辑

我们首先看一下View内部的事件分发逻辑，相对于ViewGroup，View的事件分发更简单。

public boolean dispatchTouchEvent(MotionEvent event) {  
  // 焦点处理
  // 滑动处理

  if (onFilterTouchEventForSecurity(event)) {    
    ... 
    //View监听的处理，如果有onTouchListener，则执行onTouch事件，
    //然后，根据onTouch事件的返回结果来判断是否要执行View的onTouchEvent事件。
    ListenerInfo li = mListenerInfo;    
    if (li != null && li.mOnTouchListener != null&& (mViewFlags & ENABLED_MASK) == ENABLED
      && li.mOnTouchListener.onTouch(this, event)) {        
      result = true;    
    }    
    if (!result && onTouchEvent(event)) {        
      result = true;    
    }
}

View内的事件分发逻辑非常清晰：

  1. OnTouchListener是否存在，如果存在则执行onTouch方法
  2. 执行onTouchEvent方法。

其他就是一些焦点和滑动情况下的特殊处理。本文不做深究。

Step3.2 ViewGroup的dispatchTouchEvent逻辑

接下来，我们来看下ViewGroup内部的事件分发逻辑

Step3.2.1 ViewGroup内部的拦截逻辑
// 事件传递队列(View的嵌套队列)中首个消耗事件序列的目标（View）
private TouchTarget mFirstTouchTarget;

public boolean dispatchTouchEvent(MotionEvent ev) {
  //焦点处理

  //新的点击序列的初始化
  if (actionMasked == MotionEvent.ACTION_DOWN) {     
    //当开始一个新的touch事件序列时，先丢弃之前事件产生的状态
    //因为app的切换，ANR或者其他状态的改变会导致Android丢掉之前手势产生的UP及CANCLE事件
    cancelAndClearTouchTargets(ev);    
    resetTouchState();
  }

  //检查拦截设置
  final boolean intercepted;
  // 重点1. 
  if (actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null) {    
    //重点2. 
    final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;    
    if (!disallowIntercept) {        
      //根据onInterceptTouchEvent的返回值确定是否拦截该事件序列
      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;
  }
}

重点1：“或” 的判断逻辑，前半部分用来标识事件类型(DOWN,MOVE或者UP)，后半部分是用来判断之前是否有接收了该事件序列中的View，如果任意为true，则接下来该ViewGroup的onInterceptTouchEvent方法不会再被调用，该事件序列中剩余的事件都交给mFirstTouchTarget处理。

重点2：之前提到过，子View可以通过requestDisallowInterceptTouchEvent影响父View的事件分发。当FLAG_DISALLOW_INTERCEPT被子View修改以后，父View将只会拦截DOWN事件，而不会拦截其他事件。至于原因可以在resetTouchState方法中找到。

Step3.2.2ViewGroup内部的事件分发逻辑
//最近一次处理事件的View的索引
int mLastTouchDownIndex

//子View个数
final int childrenCount = mChildrenCount;
if (newTouchTarget == null && childrenCount != 0) {    
  //获取事件坐标
  final float x = ev.getX(actionIndex);    
  final float y = ev.getY(actionIndex);    
  // 找到一个能接受事件的子View
  // 从外向内扫描子View，根据Z轴以及绘制的顺序生成的View的list
  final ArrayList<View> preorderedList = buildTouchDispatchChildList();    
  final boolean customOrder = preorderedList == null && isChildrenDrawingOrderEnabled();    
  final View[] children = mChildren;    
  for (int i = childrenCount - 1; i >= 0; i--) {      
    //根据绘制的顺序获取index并得到View  
    final int childIndex = getAndVerifyPreorderedIndex(childrenCount, i, customOrder);        
    final View child = getAndVerifyPreorderedView(preorderedList, children, childIndex);        
    ...    
    //判断是否可以接收事件
    //1.View可见
    //2.坐标在View的区域内
    if (!canViewReceivePointerEvents(child)|| !isTransformedTouchPointInView(x, y, child, null)) {  
        ev.setTargetAccessibilityFocus(false);            
        continue;        
    }        
    ...       
    //重点
    if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {            
      // 子View希望接收在它范围内的事件
      mLastTouchDownTime = ev.getDownTime();            
      if (preorderedList != null) {                
        //根据childindex找到View集合中的原始索引下标    
        for (int j = 0; j < childrenCount; j++) {                    
          if (children[childIndex] == mChildren[j]) {
            mLastTouchDownIndex = j;                       
            break;                    
          }                
        }            
    } else {                
      mLastTouchDownIndex = childIndex;            
    }            
    ...    
  }        
  //事件没有被能够获取到焦点的对象处理，清除flag，然后分发到所有的子View
  ev.setTargetAccessibilityFocus(false);    
  }    
//清理预排序的View集合
if (preorderedList != null) 
  preorderedList.clear();
}

上述代码标注重点的位置，它的具体实现如下，有子View则调用子View的dispatchTouchEvent，没有则调用父类的的dispatchTouchEvent方法，如果子View依然是一个ViewGroup则递归，直至最后的View为止。

private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel, View child, int desiredPointerIdBits) {     
  // CANCLE事件的特殊处理
  ...
  // 执行必要的转换和分发
  if (child == null) {    
      handled = super.dispatchTouchEvent(transformedEvent);
  } else {    
      final float offsetX = mScrollX - child.mLeft;    
      final float offsetY = mScrollY - child.mTop;    
      transformedEvent.offsetLocation(offsetX, offsetY);    
      if (! child.hasIdentityMatrix()) {        
          transformedEvent.transform(child.getInverseMatrix());    
      }    
      handled = child.dispatchTouchEvent(transformedEvent);
  }
 ...
}

我们在一开始分析了View和ViewGroup的dispatchTouchEvent方法，里面都有调用onTouchEvent事件的逻辑，根据该方法的调用结果来确定该事件是否被消耗，一旦被消耗，则dispatchTransformedTouchEvent的返回值为true，此时，ViewGourp的dispatchTouchEvent会调出遍历子view的for循环，进入下一事件的分发过程。

Step4. onTouchEvent事件的处理逻辑

public boolean onTouchEvent(MotionEvent event) {
  //获取事件的坐标及ACTION
  ...
  if ((viewFlags & ENABLED_MASK) == DISABLED) {    
  //一个可点击的disabled的View依然可以消耗事件，只是不会做出响应
  return (((viewFlags & CLICKABLE) == CLICKABLE 
        || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE) 
        || (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE);
  }
  //重点1.
  if (((viewFlags & CLICKABLE) == CLICKABLE 
      || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE) 
      || (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE) 
    {    
      switch (action) {        
        case MotionEvent.ACTION_UP:
          //如果View可以获取焦点，则首先让该View获取焦点
          //这个View的按下状态即将被释放，修改样式（selector）及动画
          if (!post(mPerformClick)) {    
            //重点2，执行点击事件
            performClick();
          }
          break;
        case MotionEvent.ACTION_DOWN:
          ...
          //重点3
          checkForLongClick(0, x, y);
          break;


}

重点1 ： 只要View的CLICKABLE或者LONG_CLICKABLE任意一个属性为true，那就会消耗该事件

重点2 ： 在onTouchEvent方法会间接调用OnClickListener方法的回调。

public boolean performClick() {    
  final boolean result;    
  final ListenerInfo li = mListenerInfo;    
  if (li != null && li.mOnClickListener != null) {     
    ...      
    //如果执行了点击事件，则表示该事件被消耗了。
    li.mOnClickListener.onClick(this);        
    result = true;    
  } else {        
    result = false;    
  }    
  ...
  return result;
}

重点3 ： 在ACTION_DOWN的判断逻辑里会进行长按的校验，如果判断不是长按事件则会调用UP分支的performClick方法

事件传递所涉及方法的执行顺序

以下日志只涉及DOWN和UP两种事件

情景1

多层嵌套，无任何拦截，子View不处理事件

//activity分发开始
MainActivity---->dispatchTouchEvent start
//各层View尝试拦截
GrandParentView--->onInterceptTouchEvent
ParentView--->onInterceptTouchEvent
//如果有Listener则先执行监听的回调
OnTouchListener---->处理事件
//最终执行onTouchEvent
MyImageView--->onTouchEvent
//--------------------------------事件回传
MyImageView--->dispatchTouchEvent
ParentView--->onTouchEvent
ParentView--->dispatchTouchEvent
GrandParentView--->onTouchEvent
GrandParentView--->dispatchTouchEvent
//回传到activity然后结束
MainActivity---->onTouchEvent
MainActivity---->dispatchTouchEvent end
//该事件序列的剩余事件无需再次层层传递，直接在activity中处理
MainActivity---->dispatchTouchEvent start
MainActivity---->onTouchEventfalse
MainActivity---->dispatchTouchEvent end

此情境下情况下，首先从activity开始，由外到内传递给View的onTouchEvent，然后再由内到外传递给activity的onTouchEvent，最终消耗掉此事件。这里的事件是指DOWN事件，因为没有子View来处理该DOWN事件，所以最终由activity出面处理，那么接下来的事件序列也没有必要继续向内传递了，可以直接在activity中处理了。

举个栗子，CTO吩咐技术总监一个任务，技术总监交代给你，但是你没有完成又扔给总监，总监也没完成又扔给CTO，此时接下来的任务CTO就会自己去处理而不是交给下级。

情景2

多层嵌套，无任何拦截，子View处理事件

//activity分发开始
MainActivity---->dispatchTouchEvent start
//各层View尝试拦截
GrandParentView--->onInterceptTouchEvent
ParentView--->onInterceptTouchEvent
//监听处理
OnTouchListener---->处理事件
//事件最终被消耗
MyImageView--->onTouchEvent
//回调各层级的dispatchTouchEvent
MyImageView--->dispatchTouchEvent
ParentView--->dispatchTouchEvent
GrandParentView--->dispatchTouchEvent
MainActivity---->dispatchTouchEvent end
//开始UP事件的分发
MainActivity---->dispatchTouchEvent start
GrandParentView--->onInterceptTouchEvent
ParentView--->onInterceptTouchEvent
OnTouchListener---->处理事件
MyImageView--->onTouchEvent
MyImageView--->dispatchTouchEvent
ParentView--->dispatchTouchEvent
GrandParentView--->dispatchTouchEvent
MainActivity---->dispatchTouchEvent end

相较于上种情况，本次的事件传递多了UP事件的传递。

再举个栗子，CTO吩咐技术总监一个任务，技术总监交代给你，你完美的完成了，接下来的任务CTO会继续交托给你执行。

情景3

多层嵌套，无拦截，但是dispatchTouchEvent与onTouchEvent声明的行为不一致（返回结果不同）

一般来说，我们会在dispatchTouchEvent方法中声明说事件序列由该View处理，而在onTouchEvent中确定是否真正处理了该事件序列，所以基本来说他们是一致的，但是假如不一致，那么就会出现如下执行顺序

3.1

声明要处理，但是实际上没有处理，则该事件会被吞噬

dispatch true onTouchEvent false

MainActivity---->dispatchTouchEvent start : 
GrandParentView--->onInterceptTouchEvent
ParentView--->onInterceptTouchEvent
ParentView--->onTouchEvent
ParentView--->dispatchTouchEvent
GrandParentView--->dispatchTouchEvent
MainActivity---->dispatchTouchEvent end :
3.2

声明不处理，但是实际上处理了，则该事件会当做没人处理回传给activity中,并且后续的事件也不会再向下传递了。

MainActivity---->dispatchTouchEvent start : 
GrandParentView--->onInterceptTouchEvent
ParentView--->onInterceptTouchEvent
ParentView--->onTouchEvent
ParentView--->dispatchTouchEventtrue
GrandParentView--->onTouchEvent
GrandParentView--->dispatchTouchEvent
MainActivity---->onTouchEvent
MainActivity---->dispatchTouchEvent end : 
MainActivity---->dispatchTouchEvent start : 
MainActivity---->onTouchEvent
MainActivity---->dispatchTouchEvent end :
情景4

多层嵌套，有拦截

4.1 只拦截，不处理
MainActivity---->dispatchTouchEvent start :
GrandParentView--->onInterceptTouchEvent
GrandParentView--->onTouchEvent
GrandParentView--->dispatchTouchEvent
MainActivity---->onTouchEvent
MainActivity---->dispatchTouchEvent end :
MainActivity---->dispatchTouchEvent start : 
MainActivity---->onTouchEvent
MainActivity---->dispatchTouchEvent end :

只拦截，不处理的话，则事件最终仍会返回给activity处理

4.1 拦截并处理
MainActivity---->dispatchTouchEvent start : 
GrandParentView--->onInterceptTouchEvent
GrandParentView--->onTouchEvent
GrandParentView--->dispatchTouchEvent
MainActivity---->dispatchTouchEvent end : 
MainActivity---->dispatchTouchEvent start : 
GrandParentView--->onTouchEvent
GrandParentView--->dispatchTouchEvent
MainActivity---->dispatchTouchEvent end :

此时和最内层View处理事件的逻辑一样。

情景5

涉及OnClickListener的处理

当给一个View设置OnClickListener时，onClick回调方法会在最后一步执行，它的优先级是最低的，此处就不写打印日志了。因为此处日志与情景1类似，只是在最后一步执行onClick方法而已，需要注意的是onClick回调能够执行的前提是，View的dispatchTouchEvent方法返回true，onTouchEvent无所谓，否则无法接收点击事件回调，至于原因在源码中也可以找到。

至此，Android的事件分发就已经介绍完了。老衲也要苦逼的开始找工作了。祝大家工作顺利。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 204,684评论 6赞 478
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 87,143评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 151,214评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,788评论 1赞 277
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,796评论 5赞 368
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,665评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,027评论 3赞 399
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,679评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 41,346评论 1赞 299
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,664评论 2赞 321
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,766评论 1赞 331
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,412评论 4赞 321
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,015评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,974评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,073评论 2赞 350
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,501评论 2赞 343

推荐阅读更多精彩内容