一步步理解Android事件分发机制

回想一下，通常在Android开发中，我们最常接触到的是什么东西？显然除了Activity以外，就是各种形形色色的控件(即View)了。
与此同时，一个App诞生的起因，终究是根据不同需求完成与用户的各种交互。而所谓的交互，本质就是友好的响应用户的各种操作行为。
所以说，有很多时候，一个控件(View)出现在屏幕当中，通常不会是仅仅为了摆设，而是还要能够负责响应用户的操作。
以最基本的例子而言：现在某一个界面中有一个按钮(Button)，而每当用户点击了该按钮，我们的程序将做出一定回应。
那么，如果我们还原“点击按钮”这一行为，可以视作其根本实际就是：用户的手指 与屏幕上该按钮所处的位置发生了某种接触。
所以简单来说，我们可以将用户每次与屏幕发生接触，视作是一次“触摸事件”。而对于每次“触摸事件”的回应处理，就构成了所谓的“交互”。
由此，也就引出了我们今天在此文里想要弄清楚的一个知识点，即“Android的事件分发机制”。接着，我们就一步一步的来走进它。

为什么需要分发？

在一切开始之前，我们先考虑一个问题。那就是为什么我们发现 关于这个知识点总是被描述为“事件分发”而不是“事件处理”？试想以下情况：

小明注册了一家公司开始了自己的创业之旅。这天，一位客户上门为小明的公司带来了第一单业务。我们可以将“这单业务”视作一次“触摸事件”。
小明乐坏了，赶紧开始着手这单业务。对应来说，我们可以理解为对“触摸事件”的处理。是的，目前为止我们都没发现任何和“分发”相关的东西。
其实，我们不难想象到之所以没有出现任何“分发”相关的东西，是因为现在公司只有小明独自一人，除了自己处理，他别无它选。
对于“分发”这个词本身就是以一定数量作为基础的。比如小明的公司经过发展扩大到了十个人的规模，划分了部门。这天又有新的业务来了。
这个时候小明就有很多选择了，他可以选择自己来处理这单业务；当然也可以选择将业务派发下去让员工来处理。这就是我们所谓的“分发”。

这个案例对应到Android中来说是一样的，如果我们能保证当前屏幕上永远只有唯一的一个View，那么对于“触摸事件”的处理就没什么好说的了。
但显然一个界面中通常都不会只有一个“独苗”，它会涉及到不定量的View(ViewGroup)的组合。这个时候当“事件”发生，就不那么容易处理了。
这其实也是为什么，“Android的事件分发机制”是我们从菜鸟到进阶的过程中绕不开必须掌握的一个知识点。
但实际上也没关系，当我们明白了“小明创业”的这个例子，实际也就已经掌握了关于事件分发最基本的原理。

看事件如何分发？

我们说了所有与用户发生交互的行为都是在手机屏幕，即某个界面中产生的。而Android的界面中的元素，无非就是View与ViewGroup。
与之同时，我们关注的另一个关键点是代表操作行为的“触摸事件”，这对应到英文中来说似乎就是“TouchEvent”。
OK，在我们目前两眼一抹瞎的情况下。不妨试着以“TouchEvent”为关键字，到View与ViewGroup类中去研究研究相关的方法。

最终，我们单独提出以下几个需要我们理解的方法，它们也是事件分发机制的原理所在：

• dispatchTouchEvent
• onTouchEvent
• onInterceptTouchEvent （只存在于ViewGroup）

好的，截止现在我们还不太明白这几个方法的具体作用。只知道如果单独从命名上看，它们似乎分别代表分发、处理和拦截类似的作用。

起源在哪？

从现在开始，我们要正式的一步步研究一个触摸事件的处理过程。我们先来看一个十分基础但具有一定代表性的布局：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:tag="group_a"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <LinearLayout
        android:tag="group_b"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical">

        <Button
            android:tag="view"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content" />

    </LinearLayout>
</LinearLayout>

但如果是这样，我们还是无法研究其事件的分发过程，所以我们自定义两个类分别继承LinearLayout以及Button类。
而我们要做的工作也很简单，就是在我们之前提及的与“事件分发”相关的方法中，分别加上类似如下的日志打印：

Log.d(getTag().toString(),”onTouchEvent”);

然后我们将布局文件中的LinearLayout和Button分别替换成我们自己定义的类，就搞定了。此时，我们运行程序后，对按钮进行点击，得到如下日志：

group_a: dispatchTouchEvent
group_a: onInterceptTouchEvent
group_b: dispatchTouchEvent
group_b: onInterceptTouchEvent
view: dispatchTouchEvent
view: onTouchEvent

一口气吃不成一个胖子，我们这里首先只关注一点，那就是：当我们点击按钮后，最先被触发的是“group_a“也就是最外层layout的dispatchTouchEvent方法。这个道理其实并不难理解，就像“小明创业”一样，如果一单业务来临，自然应该先由最高级别的“小明”知会。

也就是说，当一个“触摸事件”产生，将最先传送到最顶层View。这看上去合情合理，但我们又不难想到，如果谈到“最顶层”的话：
那么，我们所有的View，即我们整个布局文件，它实际也有一个载体，那就是它的宿主Activity。因为你一定记得”setContenView(R.layout.xxx)”。
那么，我们想象一下，“触摸事件”会不会最先被传送到Activity呢？打开Activity的源码我们惊喜的发现：它也包含dispatchTouchEvent和OnTouchEvent方法。OK，我们接着要做的，自然就是在我们的Activity类中覆写这两个方法，也加上日志打印，再次运行测试得到如下日志：

MainActivity: dispatchTouchEvent
group_a: dispatchTouchEvent
group_a: onInterceptTouchEvent
group_b: dispatchTouchEvent
group_b: onInterceptTouchEvent
view: dispatchTouchEvent
view: onTouchEvent

通过日志，我们不难发现，正如我们推测的一样，当触摸事件产生，的确是最先传递给Activity的。
这个时候，又要提到“小明”了。没错，当有业务来临，肯定是先到达“公司”层面，然后才是最高负责人“小明”。

打开Activity类的dispatchTouchEvent源码如下：

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

我们关注的重点放在下面一行代码上。由此，我们发现Activity接收到触摸事件后，是通过其所属的Window来分发事件的。

if (getWindow().superDispatchTouchEvent(ev))

Window自身是一个抽象类，而其superDispatchTouchEvent也是一个抽象方法。其唯一实现存在PhoneWindow类中。
而在PhoneWindow当中，superDispatchTouchEvent的实现是这样的：

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

也就是，这时候事件的分发会传递到mDecor，即Android视图结构中所谓的“DecorView”当中，而DecorView自身本就是FrameLayout。
所以，这个时候事件分发的本质就很简单了，它回归到了FrameLayout，即ViewGroup的事件分发。

P.S: DecorView涉及到了Android的UI界面架构的知识。我们通常可以最简单的理解为一个Activiy就是一个界面。

但其实随着对Android越来越熟悉，我们也可以很容易猜测到，实际上肯定不仅仅如此。那么我们可以这样简单理解：

• Activity会附属在PhoneWindow上；这其中会首先包裹一个DecorView（翻译就是装饰视图），它本身是一个FrameLayout。
  （所以，我们其实可以理解为，DecorView才是我们界面中真正位于最顶层的父View）
• 而同时，通常来说，DecorView中会有两个子View，分别是：TitleView及ContentView。
• 其中，TitleView简单来说就是我们平时所说的ActionBar(TitleBar)的那一列。而ContentView我们就熟悉了：“setContenView(R.layout.xxx)”

好了，话到这里，我们先对我们目前的收获进行总结，很简单：
当一个“触摸事件”产生，会首先传递到当前Activity。Activity会通过其所属Window，找到其中DecorView，从而开始逐级向下分发事件。

继续传递

回忆我们点击按钮时，所产生的输出日志：

MainActivity: dispatchTouchEvent
group_a: dispatchTouchEvent
group_a: onInterceptTouchEvent
group_b: dispatchTouchEvent
group_b: onInterceptTouchEvent
view: dispatchTouchEvent
view: onTouchEvent

我们发现，经由MainActivity进行传递，最终会首先到达该Activity的ContentView，即我们定义的布局文件中的最外层LinearLayou上。
这之后发生的事，我们通过日志观察的现象似乎是：事件在继续向下传递，直到最后到达了最里的Button，才通过onTouchEvent进行了处理。
所以，我们大胆猜测：一个“触摸事件”发生，会逐级dispatchTouchEvent，直至到达最底层的View，然后通过onTouchEvent进行处理。
这看上去是说得通的，但唯一的缺陷就在于，onInterceptTouchEvent 这个名字透露着拦截事件的方法，似乎并没有得到什么发挥？

那么，我们干脆直接打开ViewGroup中onInterceptTouchEvent的源码：

    public boolean onInterceptTouchEvent(MotionEvent ev) {
        return false;
    }

我们发现源码特别简单，唯一值得注意的是，该方法有一个布尔型的返回值，并且默认的返回值是false。
秉承着一贯的“手贱主义”的思想，我们将我们自定义的LinearLayou类中的onInterceptTouchEvent返回值修改为true。然后再次测试：

MainActivity: dispatchTouchEvent
group_a: dispatchTouchEvent
group_a: onInterceptTouchEvent
group_a: onTouchEvent

我们发现日志打印已经发生了改变，通过日志我们观察到的是：事件传递到group_a后不再向下传递了，直接通过group_a的onTouchEvent进行处理。
这一现象其实是合理的，它告诉了我们：onInterceptTouchEvent的返回结果将决定事件是否被拦截在当前View层面。返回true则拦截；否则继续传递。
而onInterceptTouchEvent的返回结果之所以能实现上述效果，可以在ViewGroup类中的dispatchTouchEvent方法里找到答案。
ViewGroup当中的dispatchTouchEvent源码很多，也很复杂，我们很难去读个透彻。但通过部分关键代码，我们可以知道它的原理是如下：
ViewGroup里，dispatchTouchEvent里会调用到onInterceptTouchEvent方法，并通过判断其返回结果决定下一步操作：

• 如果onInterceptTouchEvent返回true，则会调用onTouchEvent方法处理触摸事件。
• 如果onInterceptTouchEvent返回false，则会通过child.dispatchTouchEvent的形式向下分发事件。

到现在，看上去我们基本已经对事件的整个分发流程都触碰到了。但我们想象这样一种情况：
小明的公司接收了一单新的业务，并分发给了底下的小王去做。但这时候的问题可能是：
小王收到通知后发现自己完成不了。或者说小王给出了一套方案，但他对该方案的信心并不足。
这样的问题应该怎么解决，很显然，小王应该“报告老板”。这单业务最后的处理方案可能还是得您来拿。

这对应到我们的程序中，应该如何来实现呢？我们发现，onTouchEvent这个方法也有一个布尔型的返回值。
现在，我们试着将我们之前自定义的Button类里的onTouchEvent的返回值修改为固定返回false。再次运行程序测试：

MainActivity: dispatchTouchEvent
group_a: dispatchTouchEvent
group_a: onInterceptTouchEvent
group_b: dispatchTouchEvent
group_b: onInterceptTouchEvent
view: dispatchTouchEvent
view: onTouchEvent
group_b: onTouchEvent
group_a: onTouchEvent

我们发现，事件在经过button类里onTouchEvent处理后， 又回传到上层目录继续处理了。
由此我们可以知道：onTouchEvent的返回值也是另一种“拦截”，不同的是之前我们说的是拦截事件继续向下传递。
而这里，是在表明，这个事件“我”是否能够完全处理。如果能，则返回true,那么事件经过“我”处理后就结束了。否则返回false，再让父View去处理。

好了，这里我们先总结一下到目前为止，我们掌握到的关于事件分发机制的流程：

• 当一个触摸事件产生，会首先传递到其所属Activity。Activity将负责将事件向下进行分发。
• 该触摸事件将逐级的依次向下传递，直到传递至最底层View，然后进行处理。
• ViewGroup在向下传递事件的时候，通过onInterceptTouchEvent的返回值来判断是否拦截事件。
• 如果确定拦截事件，那么此次一系列的触摸事件都会通过该ViewGroup的onTouchEvent方法进行处理，并不再向下传递
• onTouchEvent的返回结果决定了事件在此次处理之后，是否需要回传到上一级的View。

好了，我们继续看。我们肯定也注意到了，说了这么多，但我们之前关于事件分发的重点，都是放在上一层View向下层View分发事件的过程。
也就是说，之前我们的重点是在分析ViewGroup的dispatchTouchEvent方法，我们说了该方法会判断是否拦截事件，而决定是否继续向下传递事件。
当就拿我们此文中的例子来说，当事件最终传递到button类当中。我们不难想象到，这时dispatchTouchEvent的工作肯定与之前有所不同。
因为Button自身只是一个View，它不会存在所谓的子视图。也就说，这个时候事件你肯定要做出处理了，那么还分发个什么劲呢？

要得到这个问题的答案，最好的方式当然就是打开View类里的dispatchTouchEvent方法的源码看看，这里我们只截取我们关心的代码部分：

        if (onFilterTouchEventForSecurity(event)) {
            //noinspection SimplifiableIfStatement
            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;
            }
        }

我们看到，首先会获取一个ListenerInfo类型的变量。该类型实际就是封装了各种类型的Listener。随后会开启第一次判断：
如果此对象不为空，mOnTouchListener不为空，且(mViewFlags & ENABLED_MASK) ==ENABLED，则会执行mOnTouchListener。
这其中(mViewFlags & ENABLED_MASK) ==ENABLED是判断控件状态是否是ENABLE的，默认情况肯定是的。
mOnTouchListener看着有些眼熟，如果我们查看源码，你就更眼熟了，因为我们发现它是通过如下代码进行赋值的：

    public void setOnTouchListener(OnTouchListener l) {
        getListenerInfo().mOnTouchListener = l;
    }

接着看代码，我们发现如果li.mOnTouchListener.onTouch(this, event)执行的结果也为true，那么result也将被设置为true。
假设该方法的执行结果返回是false，那么以上代码将继续进行，从而开始第二轮判断，于是onTouchEvent方法得以执行。

OK，对于这里的代码，我觉得有两点是值得一说的。第一是，我们首先可以明白如下的结论：

• 假如我们为某个View设置了OnTouchListener，那么listener会先于onTouchEvent执行。同时：
• 如果listener的onTouch方法返回true，那么onTouchEvent将不再执行。

第二点是，我们看到对于View来说：假设onTouchEvent的返回值为false，那么dispatchTouchEvent也会返回false。
这实际上就构成了整个“onTouchEvent返回值可以决定事件是否回传”的原因。这是因为：
ViewGroup在通过child.dispatchTouchEvent向下分发事件时，会通过该返回值来判断子视图是否具备处理事件的能力。
如果返回为false，就会继续遍历子视图，直至遍历到有一个具备事件处理能力的子视图为止。
如果没有一个具备处理能力的子视图，那么ViewGroup就会自己通过onTouchEvent来解决了。

到了这里，我们实际上已经对整个Android事件的分发机制有了不错的了解了。但我们肯定会想到一个问题：
那就是，以Button来说，我们通常是通过setOnClickListener的方式来对其设置点击事件监听的。
但很显然，我们目前为止研究过的代码中，还没有出现任何与之相关的东西。在View类中，我们剩下没有看过代码的，就是onTouchEvent了：

        if (((viewFlags & CLICKABLE) == CLICKABLE ||
                (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE) ||
                (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE) {
            switch (action) {
                case MotionEvent.ACTION_UP:
                    boolean prepressed = (mPrivateFlags & PFLAG_PREPRESSED) != 0;
                    if ((mPrivateFlags & PFLAG_PRESSED) != 0 || prepressed) {
                        // take focus if we don't have it already and we should in
                        // touch mode.
                        boolean focusTaken = false;
                        if (isFocusable() && isFocusableInTouchMode() && !isFocused()) {
                            focusTaken = requestFocus();
                        }

                        if (prepressed) {
                            // The button is being released before we actually
                            // showed it as pressed.  Make it show the pressed
                            // state now (before scheduling the click) to ensure
                            // the user sees it.
                            setPressed(true, x, y);
                       }

                        if (!mHasPerformedLongPress && !mIgnoreNextUpEvent) {
                            // This is a tap, so remove the longpress check
                            removeLongPressCallback();

                            // Only perform take click actions if we were in the pressed state
                            if (!focusTaken) {
                                // Use a Runnable and post this rather than calling
                                // performClick directly. This lets other visual state
                                // of the view update before click actions start.
                                if (mPerformClick == null) {
                                    mPerformClick = new PerformClick();
                                }
                                if (!post(mPerformClick)) {
                                    performClick();
                                }
                            }
                        }

以上代码是我们关心的原因所在，我们看到经过一系列的判断后，会进入到一个名为performClick的方法调用，打开该方法的源码：

    public boolean performClick() {
        final boolean result;
        final ListenerInfo li = mListenerInfo;
        if (li != null && li.mOnClickListener != null) {
            playSoundEffect(SoundEffectConstants.CLICK);
            li.mOnClickListener.onClick(this);
            result = true;
        } else {
            result = false;
        }

        sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED);
        return result;
    }

综合以上两段代码，我们可以得出以下结论：

• onClickListener会在onTouchEvent方法中，ACTION为UP的时候得以执行。
• 但注意前提条件是，控件是可点击(长按)的；并且mOnClickListener不为空。

最后的总结与比喻

最后，我们仍旧以“小明创业“的例子来总结我们所学到的关于Android的事件分发的相关知识。

• 公司(Activity)接收了一项新的业务(触摸事件)。
• 该业务会最先到达公司的最高层小明手上(最顶层View)。
• 小明研究了以下此次业务，此时可以分为两种情况：
  1、小明认为此业务难度不大，于是决定将业务分配给部门经理小王(dispatch-event)。
  2、小明认为此次业务至关重要，决定自己处理(intercept-event & onTouchEvent)。
• 假设业务分配给了经理小王，此时小王与小明一样，同样有两种选择：即自己拦截处理或者继续向下布置。
• 业务最终终将被分配到某个员工的手中，它会负责处理(onTouchEvent)。
• 但该员工接收到任务后，也可以判断自己是否能够完成，如果觉得不能完成，
  或者还需要上级审核，可以选择回报给上级(onTouchEvent返回false)
• 员工处理该任务的方式也许有多种，例如A(OnTouchListener)、B（onTouchEvent）、C（OnClickListener） 等等。
  (它们的优先级顺序是 A > B > C 。。。。 )