从源码角度剖析Android事件分发机制（一）

开头

一直都想要系统的学习一下 android 的事件分发机制，结果由于个人原因，一拖再拖，我实在是觉得脸红了，趁着公司最近不忙，就写了这篇博客，当然我的能力有限，在分析源码的过程中难免会有疏漏和错误，还请不吝指正，非常感谢！

入门

先从最简单的说起吧。新建一个项目，整个项目只有一个 Activity，我们在布局文件中有一个Button 按钮，现在我们给按钮添加触摸监听和点击监听。

public class MainActivity extends AppCompatActivity implements View.OnTouchListener, View.OnClickListener {    private static final String TAG = "MainActivity";    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        Button button = (Button) findViewById(R.id.btn);        RelativeLayout relativeLayout = (RelativeLayout) findViewById(R.id.layout);        button.setOnTouchListener(this);        button.setOnClickListener(this);        relativeLayout.setOnTouchListener(this);        relativeLayout.setOnClickListener(this);    }    /**     * Action.Down = 0;     * Action.Up = 1;     * Action.Move = 2;     */    @Override    public boolean onTouch(View v, MotionEvent event) {        Log.d(TAG, "OnTouchListener-Action " + event.getAction() + " ==TouchListener-Id" + v.getId());        return false;    }   @Override    public void onClick(View v) {        Log.d(TAG,  "ClickListener-Id == " + v.getId());    }}

看看布局文件

<RelativeLayout    android:id="@+id/layout"    xmlns:android="http://schemas.android.com/apk/res/android"    android:layout_width="match_parent"    android:layout_height="match_parent">    <Button        android:id="@+id/btn"        android:layout_width="wrap_content"        android:layout_height="wrap_content"        android:text="Hello World!"/></RelativeLayout>

下面就是上面项目的运行结果。

上图可以看到，当我们点击 Button 的时候，先响应的是 Button 的触摸 ACTION_DOWN 事件（ ACTION_DOWN 的常量值为 0 ），然后响应的是触摸的 ACTION_UP 事件（ ACTION_UP 的常量值为 1 ），最后才响应的 Button 的点击事件。同样当我们点击外层的 RelativeLayout 也是同样的结果。

接下来我们将重写的 onTouch 方法的返回值改成 true。我们再来看一下结果如何。

你会惊奇的发现，不管是 Button 还是 RelativeLayout，他们的点击事件都没有被调用了。这说明了什么？

我们在 onTouch() 方法中返回 false，调用关系如下：

ACTION_DOWN → ACTION_UP → onClick()

我们在 onTouch() 方法中返回 true，调用关系如下：

ACTION_DOWN → ACTION_UP

说明我们这里的点击事件被 onTouch() 事件给拦截掉了。通常这里我们叫做“消费”，说明事件传递到 onTouch() 方法这里的时候，因为 onTouch() 方法返回了 true，所以这里的本应该继续传递到 onClick() 方法中的事件就被消费了。

到这里，如果能够理解，就说明事件分发机制你已经掌握了一点了，但是我们不能满足于这点东西，要知其然而知其所以然，所以我们去看看源码，看源码到底是怎么玩的。

下面我给出几个方法的执行顺序，这里暂时不讨论为什么这些方法是按这个顺序执行的，我们先解决眼前的问题，至于执行顺序，后面我们通过案例来验证执行顺序的正确性。

View 的事件分发

这里先说明事件的执行过程。下面我们通过源码来看看它的执行过程是不是和下面所说的一样。

1. dispatchTouchEvent()2. onTouchListener  --> onTouch() 方法3. onTouchEvent()4. onClickListener --> onClick() 方法

首先你要知道，当我们触摸到一个控件的时候，最先调用的应该是控件的 dispatchTouchEvent() 这个方法，所以在上面的例子中，我们去找 Button 中的 dispatchTouchEvent() 方法，你会发现 Button 中并没有这个方法，然后我们去它的父类 TextView 中找，你发现还是找不到，那行，我们接着跟到 View 这个类中，果然不出所料，找到了 dispatchTouchEvent() 方法。

下面贴一下 View 中的 dispatchTouchEvent() 的部分源码。（View.class 10016行）

 if (onFilterTouchEventForSecurity(event)) {      if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {           result = true;       }       //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;       }   }

我这里看的是 6.0 的源码，内容有点多，所以我就只贴了主要部分过来了，其他的部分我们不需要关系，只需要关心上面的一小段代码就足够了。

那我们接下来看 if 判断中的四个条件

li != null li.mOnTouchListener != null(mViewFlags & ENABLED_MASK) == ENABLEDli.mOnTouchListener.onTouch(this, event)

ListenerInfo getListenerInfo() {      if (mListenerInfo != null) {          return mListenerInfo;      }      mListenerInfo = new ListenerInfo();      return mListenerInfo;  }

ListenerInfo 是一个 View 的内部类，上面代码中把 mListenerInfo 赋值给了 li， 根据上面的源码片段可知 li != null 这个条件是成立的。 
第二个条件根据上面的源码我们也可以断定是成立的。

我们在 View 中找到了这段代码。

就是把我们在 MainActivity 中调用的 setOnTouchListener(this) 给 mOnTouchListener 赋值。

那么我们接下来看第三个条件，这个条件你可能看不懂，不过没关系，这个条件是判断按钮是否可以点击，显然是成立的。(如果这里按钮是不可用的，那么 (mViewFlags & ENABLED_MASK) == ENABLED 这里就直接为 false 了，if 判断中的后面的条件就能不会继续执行下去了。)
也就是说我们的重头戏就是最后一个条件了。

li.mOnTouchListener.onTouch(this, event)

会不会觉得很熟悉？ 其实这里的方法就是我们 MainActivity 中设置监听器的回调方法，还记得我们返回的是什么么？默认是返回 false。

1、这里先看默认的情况：返回 false
返回 false 那么这个 if 条件就不成立，接着走下面的 if 条件。

if (!result && onTouchEvent(event)) {     result = true;}

result 默认值为 false， !result 即为 true， 第一个条件成立。下面进入判断第二个条件 onTouchEvent(event)

2、onTouch() 方法返回 true 的情况
那么 result 为 true， !result 即为 false， 那么这个 if 后面的条件便不会执行了。

说到这里我们就可以得出部分结论了

1. 如果OnTouchListener的onTouch方法返回了true， 那么 View 里面的 onTouchEvent() 就不会被调用了。执行顺序： dispatchTouchEvent → onTouchListener → return false →  onTouchEvent2. 如果 View 或者 View 的子类属性 enabled 被设置为 false（也就是不可用），则：OnTouchListener 里面的 onTouch() 方法不会被执行，但是会执行 onTouchEvent(event)；

同样通过上面的源码，我们也隐晦的知道了一条重要的信息：如果当 onTouch() 方法返回 true 的时候，我们的结论是控件的 onClick() 方法不会被执行了，而此时恰好源码中的 View 的onTouchEvent() 方法不会被执行，这正好说明了我们的 onClick() 方法是在 View 的 onTouchEvent的方法处理的。所以我们去 onTouchEvent() 方法中瞧瞧。

 public boolean onTouchEvent(MotionEvent event) {        final float x = event.getX();        final float y = event.getY();        final int viewFlags = mViewFlags;        final int action = event.getAction();        if ((viewFlags & ENABLED_MASK) == DISABLED) {            if (action == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) {                setPressed(false);            }            // A disabled view that is clickable still consumes the touch            // events, it just doesn't respond to them.            return (((viewFlags & CLICKABLE) == CLICKABLE                    || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)                    || (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE);        }        if (mTouchDelegate != null) {            if (mTouchDelegate.onTouchEvent(event)) {                return true;            }        }        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();                                }                            }                        }                        if (mUnsetPressedState == null) {                            mUnsetPressedState = new UnsetPressedState();                        }                        if (prepressed) {                            postDelayed(mUnsetPressedState,                                    ViewConfiguration.getPressedStateDuration());                        } else if (!post(mUnsetPressedState)) {                            // If the post failed, unpress right now                            mUnsetPressedState.run();                        }                        removeTapCallback();                    }                    mIgnoreNextUpEvent = false;                    break;                case MotionEvent.ACTION_DOWN:                    mHasPerformedLongPress = false;                    if (performButtonActionOnTouchDown(event)) {                        break;                    }                    // Walk up the hierarchy to determine if we're inside a scrolling container.                    boolean isInScrollingContainer = isInScrollingContainer();                    // For views inside a scrolling container, delay the pressed feedback for                    // a short period in case this is a scroll.                    if (isInScrollingContainer) {                        mPrivateFlags |= PFLAG_PREPRESSED;                        if (mPendingCheckForTap == null) {                            mPendingCheckForTap = new CheckForTap();                        }                        mPendingCheckForTap.x = event.getX();                        mPendingCheckForTap.y = event.getY();                        postDelayed(mPendingCheckForTap, ViewConfiguration.getTapTimeout());                    } else {                        // Not inside a scrolling container, so show the feedback right away                        setPressed(true, x, y);                        checkForLongClick(0, x, y);                    }                    break;                case MotionEvent.ACTION_CANCEL:                    setPressed(false);                    removeTapCallback();                    removeLongPressCallback();                    mInContextButtonPress = false;                    mHasPerformedLongPress = false;                    mIgnoreNextUpEvent = false;                    break;                case MotionEvent.ACTION_MOVE:                    drawableHotspotChanged(x, y);                    // Be lenient about moving outside of buttons                    if (!pointInView(x, y, mTouchSlop)) {                        // Outside button                        removeTapCallback();                        if ((mPrivateFlags & PFLAG_PRESSED) != 0) {                            // Remove any future long press/tap checks                            removeLongPressCallback();                            setPressed(false);                        }                    }                    break;            }            return true;        }        return false;    }

这个里面的代码就比 dispatchTouchEvent() 方法中的代码多太多了，不过没关系，有很多我们都不需要去关心，只挑重点看。

首先的第一个 if 是判断按钮是否可用，这里条件为 false，所以不进入，直接往下走，到第二个 if 的时候，我们直接跳过第二个 if， 看第三个if， 根据条件来看，是判断按钮是否可点击的情况，毫无疑问满足这个 if 语句，直接进入，看 switch 语句。

之前说 onTouch() 方法返回 false 的时候，执行顺序是 Action_Down → Action_Up → onClick() ，所以跟 onClick() 方法有联系的一定是 Action_Up 这个子句，所以不用管其他，直接看 Action_Up 这个 case。功夫不负有心人，你发现它最后调用了 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;    }

li 我们上面就知道了是不为空的，那么 mOnClickListener 是否为空呢？ 我们看看它是在哪里赋值的。

public void setOnClickListener(@Nullable OnClickListener l) {        if (!isClickable()) {            setClickable(true);        }        getListenerInfo().mOnClickListener = l;    }

和 OnTouchListener 一样，只要我们给控件注册了事件，那么这个 mOnClickListener 就一定不为空。调用 perfromClick() 方法的同时，在其中回调 onClick() 方法。说到这里，就一切真相大白了。整个 View 的事件分发机制就是这样。

总结

不过还有几点问题需要注意：

如果你够细心，你会发现 onTouchEvent() 方法的末尾系统帮你执行了 return true， 这里可能你就有点不理解了？我们辛辛苦苦在前面将 onTouch() 方法的返回值改成了 false， onTouchEvent() 方法才得以执行，早知道你要返回 true ，那又何必多此一举呢？ 如果你真的这么想，那你就太天真了。其实它这么做只是为了保证

在 onTouch 方法返回 false 的前提下，onTouchEvent() 中的 Case Action_Up: 子句能顺利执行下去，你要知道，Action Event 的执行顺序是 Down → 多个Move → Up，如果想要他们顺利执行完，必须每个子句中都保证返回 true，那么下一个动作才能顺利执行，不如我们的点击响应是 Down → Up， 如果 Down 分支语句执行完成之后，不能返回 true，那么 Up 分支的代码将不会执行。

举个例子，我自定义一个Button，重写父类的 OnTouchEvent() 方法。down， up， move 中全部返回 true ，结果如下：

此时我把 down 分支语句中的返回值改成 false，那么执行结果为：

最后总结出一幅图，大致就是下面的这个样子。可能描述的不太准备，不过大致就是这个样子！

总结

1. onTouch 和 onTouchEvent 这两个方法我们从源码中可以看出，onTouch 方法优先于 onTouchEvent 方法执行。因为 onTouch 的条件判断在 onTouchEvent 条件判断的前面。如果在 onTouch 方法中返回了 true， 那么 onTouchEvent 方法将不再执行。

2. 另外注意在上面的四个条件中，注意一个条件 (mViewFlags & ENABLED_MASK) == ENABLED，如果控件被设置成了 false，那么 onTouch() 将永远都得不到执行。