Android的事件传递

作者: 老衲法号能吃 | 来源:发表于2016-10-09 23:04 被阅读250次

在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)

OnTouchListener内回调的优先级高于onTouchEvent，并且会根据Listener返回值来影响onTouchEvent方法的执行。
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内的事件分发逻辑非常清晰：

OnTouchListener是否存在，如果存在则执行onTouch方法
执行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的事件分发就已经介绍完了。老衲也要苦逼的开始找工作了。祝大家工作顺利。

Android的事件传递

方法介绍

事件序列

分发事件

拦截事件

处理事件

子元素用来干预父元素的事件分发过程，ACTION_DOWN除外

OnTouchListener及OnClickListener

事件传递的伪代码

事件分发流程的源码分析

Step1. activity-->window

Step2. window-->view

Step3. View内部的源码解析

Step3.1 View的dispatchTouchEvent逻辑

Step3.2 ViewGroup的dispatchTouchEvent逻辑

Step3.2.1 ViewGroup内部的拦截逻辑

Step3.2.2ViewGroup内部的事件分发逻辑

Step4. onTouchEvent事件的处理逻辑

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

情景1

情景2

情景3

3.1

3.2

情景4

4.1 只拦截，不处理

4.1 拦截并处理

情景5

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

安卓

Android技术知识

Android开发

android实用技术

首页投稿（暂停使用，暂停投稿）

安卓资源收集