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

关注

原创最新推荐文章于 2026-04-04 09:44:38 发布 4.6k 阅读 AI 写同款· GEO 优化 ›

Android事件分发机制最近在学习安卓的事件分发机制，实际上到目前为止还没有写过自定义View，在自定义View中如果需要能够响应手指的点击或者滑动事件就需要处理事件的分发，否则很容易出现冲突。写这篇博客是为了让自己能够更好的消化吸收，同时以后忘了能够很快的捡回来。此篇主要参考。阅读详情

回想一下，通常在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 。。。。 )