Android进阶知识（十）：View的事件分发机制

Android进阶知识（十）：View的事件分发机制

  这一篇章中，笔者将介绍View的事件分发机制，需要提及的是，View的事件分发机制是View事件体系中极其重要的一点。以下对View的事件分发机制的解析，都是基于源代码的基础上进行的总结与分析，若有兴趣的读者可以通过《Android开发艺术探索》一书阅读任玉刚老师是如何通过源码来解释以下内容的，笔者就不完全照搬了。

一、点击事件的传递规则

  此处以点击事件的传递规则作为View事件分发机制的介绍，点击事件的传递规则分析的对象是MotionEvent，即点击事件。所谓的点击事件的事件分发，其实就是对MotionEvent事件的分发过程，即当一个MotionEvent产生后，系统需要把这个事件传递给具体View，这个传递过程就是事件分发过程。
  点击事件的分发过程由三个很重要的方法来共同完成：dispatchTouchEvent、onInterceptTouchEvent和onTouchEvent。

1. dispatchTouchEvent(MotionEvent ev)

  用来进行事件的分发。如果事件能够传递给当前View，那么此方法一定会被调用，返回结果受当前View的onTouchEvent和下级View的dispatchTouchEvent方法的影响，表示是否消耗当前事件。

2. onInterceptTouchEvent(MotionEvent event)

  在上述方法内部调用，用来判断是否拦截某个事件，如果当前View拦截了某个事件，那么在同一个事件序列当中，此方法不会被再次调用，返回结果表示是否拦截当前事件。

3. onTouchEvent(Motion event)

  在dispatchTouchEvent方法中调用，用来处理点击事件，返回结果表示是否消耗当前事件，如果不消耗，则在同一事件序列中，当前View无法再次接收到事件。

  这三个方法的关系可以用如下的伪代码来表示。

public boolean dispatchTouchEvent(MotionEvent ev) {
    boolean consume = false;  // 事件是否被消费
    if (onInterceptTouchEvent(ev)) {
        consume = onTouchEvent(ev);  // 拦截，调用自身的onTouchEvent方法
    } else {
        consume = child.dispatchTouchEvent(ev);  // 不拦截，调用子View的dispatchTouchEvent方法
    }
    return consume;
}

  点击事件的传递规则：如果顶级ViewGroup拦截事件即onInterceptTouchEvent返回true，则事件由ViewGroup处理，这时如果ViewGroup的mOnTouchListener被设置，则onTouch会被调用，onTouch返回true则onTouchEvent不会被调用，反之则会被调用，在onTouchEvent方法中，如果设置了OnClickListener，则可以通过performClick()调用onClick；如果ViewGroup不拦截事件，则当前事件传递给其子元素，直到事件被处理。
  从上述中可以看到，onTouch、onTouchEvent以及onClick的优先级关系为：onTouch>onTouchEvent>onClick。以上点击事件的传递规则用流程图可以表示为如下所示。

  对于上图，需要提出的一点是，当onTouchEvent或者返回false，即事件不消费时，后续的流程需要根据所处理的事件进行分类，具体情况可以参照后面的结论4和结论5。
  当一个点击事件产生之后，其传递过程遵循如下顺序：Activity->Window->View，即事件总是先传递给Activity，Activity再传递给Window，最后Window再传递给顶级View。顶级View接收到事件后，就会按照事件分发机制去分发事件。

二、事件传递机制结论

  为了更好的理解整个事件分发传递机制，根据源码可以得出对于down事件，View事件分发流程如下图所示（这里不设置onTouchListener和onClickListener，仅仅以onTouchEvent来讨论）。

  值得一提的是，Activity的dispatchTouchEvent源码如下所示。事件一开始交给了Activity所附属的Window进行分发，返回true则事件结束，否则交给Activity的onToucEvent处理。

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

  从以上对down事件的View事件分发流程图可以得到如下结论。

1. 同一个事件序列是指从手指接触屏幕的那一刻起，到手指离开屏幕的那一刻结束

  在手指接触到离开屏幕的这一过程中，其所产生的一系列事件序列以down事件开始，中间含有数量不定的move事件，最终以up事件结束。

2. 正常情况下，一个事件序列只能被一个View拦截且消耗

  一旦一个元素拦截了某此事件，那么同一个事件序列内的所有事件都会直接交给它处理，因此同一事件序列中的事件不能分别由两个View同时处理。从源码上去理解的话就是，某View拦截了Down事件，那么该View的上级ViewGroup会持有指向该View的TouchTarget。

3. 某个View一旦决定拦截，那么这一个事件序列都只能由它来处理（如果事件序列能够传递给它的话），并且它的onInterceptTouchEvent不会再被调用

  值得一提的是，这里提到的View指的是ViewGroup，因为最底层的View是没有onInterceptTouchEvent方法的。这个结论可以从源码上去理解，如图为ViewGroup的dispatchTouchEvent的部分源码。其中，mFirstTouchTarget指向拦截事件的子元素，如果该值为null，即ViewGroup拦截事件，从中可以看出当Down事件时ViewGroup选择了拦截事件，则后续事件则不会在调用方法判断。

// 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;
}

4. 某个View一旦开始处理事件，如果它不消耗ACTION_DOWN事件，那么同一事件序列中的其他事件都不会再交给它来处理，并且事件将重新交由它的父元素去处理，即父元素的onTouchEvent会被调用

  这一结论可以参照上面提到的流程图。其原因在于由于View不消耗Down事件，因此顶层ViewGroup并不会持有指向View的TouchTarget对象。用动画表示如下。

5. 如果View不消耗除ACTION_DOWN以外的其他事件，那么这个点击事件就会消失，此时父元素的onTouchEvent并不会被调用，并且当前View可以持续收到后续的事件，最终这些消失的点击事件会传递给Activity处理

  这一结论的原因在于，该View消耗了Down事件，那么该View的上级ViewGroup会持有指向该View的TouchTarget对象，因此后续事件都会直接交付给该View。但是由于后续事件不消耗，在Activity的dispatchTouchEvent则会调用Activity的onTouchEvent方法（见上方源码）。
  需要注意的是，这一结论的前提是，在ViewGroup中事件默认不拦截。

6. ViewGroup默认不拦截任何事件

  Android源码中ViewGroup的onInterceptTouchEvent方法默认返回false。

7. View没有onInterceptTouchEvent方法，一旦有点击事件传递给它，那么它的onTouchEvent方法就会被调用

8. View的onTouchEvent默认都会消耗事件（返回true），除非它是不可点击的（clickable和longClickable同时为false）

  View的longClickable属性默认都为false，clickable属性视情况而定。

9. View的enable属性不影响onTouchEvent的默认返回值

  一个View哪怕是disable状态，只要其clickable或者longClickable有一个为true，那么它的onTouchEvent就会返回true。

10. onClick会发生的前提是当前View是可点击的，并且它收到了down和up的事件

11. 事件传递过程是由外向内，即事件总是先传递给父元素，然后再由父元素分发给子View

  这里值得一提的是，通过requestDisallowInterceptTouchEvent方法可以在子元素中干预父元素的事件分发过程，但是ACTION_DOWN事件除外。这也是解决滑动冲突的一种方式（具体使用方式见：Android进阶知识（十一）：View的滑动冲突
）。
  之所以ACTION_DOWN事件除外，原因在于对于一个事件序列，ViewGroup在分发事件时，如果是事件的开始即ACTION_DOWN事件，那么将进行初始化，这导致了标志为FLAG_DISALLOW_INTERCEPT的重置。而requestDisallowInterceptTouchEvent方法恰恰就是对该标志位的设置。

  以上就是对View事件分发机制的结论，如果不是很多的读者，建议还是看看源码，毕竟源码才是王道，其他都是胡扯。

参考资料：《Android开发艺术探索》