前言
转载请注明，转自【https://www.cnblogs.com/andy-songwei/p/11039252.html】谢谢！
在上一篇文章【【朝花夕拾】Android自定义View篇之（五）Android事件分发机制（上）Touch三个重要方法的处理逻辑】【下文简称（五），请先阅读完（五）再阅读本文】，我们通过示例和log来分析了Android的事件分发机制。这些，我们只是看到了现象，如果要进一步了解事件分发机制，这是不够的，我们还需要透过现象看本质，去研究研究源码。本文将从源码（基于Android API-26）出发，去分析我们上一篇文章中看到的现象，以及其它一些和事件相关的常见问题，如：事件是如何传到View中的、requestDisallowInterceptTouchEvent为什么失效、view设置了focusable=“false”，为什么还能触发点击事件、Touch事件和Click事件谁先谁后等！
本文的主要内容如下：
一、事件的前世今生
前文中研究事件传递是从Activity的dispatchTouchEvent开始的，但是事件的起源肯定不是Activity。因为触摸事件是触摸的硬件，所以很明显事件一定是从底层传过来的。但是，事件是如何传递到View的呢？这一节我们简单了解一下事件传递到Activity的经过。
首先，我们在ViewInner类的dispatchTouchEvent方法中打印调用栈，看看这个方法的调用流程。
//=============ViewInner.java============
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
Log.i("songzheweiwang",Log.getStackTraceString(new Throwable()));
return super.dispatchTouchEvent(event);
}
点击ViewInner区域，得到如下log：
java.lang.Throwable
2 at com.example.demos.customviewdemo.ViewInner.dispatchTouchEvent(ViewInner.java:24)
3 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
4 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
5 at com.example.demos.customviewdemo.ViewGroupMiddle.dispatchTouchEvent(ViewGroupMiddle.java:23)
6 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
7 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
8 at com.example.demos.customviewdemo.ViewGroupOuter.dispatchTouchEvent(ViewGroupOuter.java:23)
9 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
10 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
11 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
12 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
13 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
14 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
15 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
16 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
17 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
18 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
19 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043)
20 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727)
21 at com.android.internal.policy.DecorView.superDispatchTouchEvent(DecorView.java:526)
22 at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1830)
23 at android.app.Activity.dispatchTouchEvent(Activity.java:3410)
24 at com.example.demos.customviewdemo.EventDemoActivity.dispatchTouchEvent(EventDemoActivity.java:37)
25 at android.support.v7.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:68)
26 at com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:475)
27 at android.view.View.dispatchPointerEvent(View.java:12768)
28 at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:5455)
29 at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:5258)
30 at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4766)
31 at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:4819)
32 at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:4785)
33 at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:4934)
34 at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:4793)
35 at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:4991)
36 at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4766)
37 at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:4819)
38 at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:4785)
39 at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:4793)
40 at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4766)
41 at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:7490)
42 at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:7448)
43 at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:7409)
44 at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:7593)
45 at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:199)
46 at android.os.MessageQueue.nativePollOnce(Native Method)
47 at android.os.MessageQueue.next(MessageQueue.java:326)
48 at android.os.Looper.loop(Looper.java:165)
49 at android.app.ActivityThread.main(ActivityThread.java:7477)
50 at java.lang.reflect.Method.invoke(Native Method)
51 at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:500)
52 at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:865)
实际上，Android输入事件的源头是位于/dev/input/下的设备节点，而输入事件的终点是由WMS管理的某个窗口，最终由窗口中的View处理。最初的输入事件为内核生成的原始事件，而最终交付给窗口的则是KeyEvent（键盘）或MotionEvent（鼠标和触摸屏）对象。上述log中（从下往上看），用三种颜色标注了3个阶段：红色部分表示底层活动，这里我们看到了不少熟悉的身影，ZygoteInit，ActivityThread，Native Method等；绿色部分第45行的InputEventReceiver.dispatchInputEvent(）方法，事件通过该方法由Native层进入到Java层，并传递到Activity中，这里我们也看到了不少熟悉的身影，ViewRootImpl，DecorView等；从第24行开始，就是我们前面熟悉的，从Acitivty开始调用dispatchTouchEvent一层层来分发事件。可能读者看到从第20~9行会有疑惑，为什么中间还有这么多过程？如果了解Android的View层次结构的话就会知道，在DecorView和开发者定义的布局（如ViewGroupOuter）之间，隔着很多层ViewGroup，也需要一层层传递，这一点我在本系列第一篇【【朝花夕拾】Android自定义View篇之（一）View绘制流程】【后面简称（一）】的第二节做过讲解，不明白的可以先去看看。
本文的重点是从Activity开始的事件分发，至于前面从底层到Activity的事件流程，咱们这里做一定的了解即可，有兴趣的可以自行研究。
二、事件从Activity到View体系
在上一篇文章的代码示例中，我们的Boss——EventDemoActivity类中有如下代码
//=============Boss:EventDemoActivity.java============
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
Log.i("songzheweiwang", "[EventDemoActivity-->dispatchTouchEvent]ev=" + EventUtil.parseAction(ev.getAction()));
return super.dispatchTouchEvent(ev);
} @Override
public boolean onTouchEvent(MotionEvent event) {
Log.i("songzheweiwang", "[EventDemoActivity-->onTouchEvent]event=" + EventUtil.parseAction(event.getAction()));
return super.onTouchEvent(event);
}
Activity是事件的起点，dispatchTouchEvent又是整个逻辑中最早分发事件的地方。但是Activity并不是View体系中的一员，那它是怎样把事件分发到View体系中的呢？追踪super.dispatchTouchEvent方法，进入到Activity.java的方法中：
//==========================Activity.java=======================
/**
* Called to process touch screen events. You can override this to
* intercept all touch screen events before they are dispatched to the
* window. Be sure to call this implementation for touch screen events
* that should be handled normally.
*
* @param ev The touch screen event.
*
* @return boolean Return true if this event was consumed.
*/
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
如注释中所说，在事件分发到window之前，可以重写这个方法来拦截所有的屏幕事件，如果事件被消费了，这个方法会返回true。这个方法咱们只关注第15~18行。第15行中如果getWindow().superDispatchTouchEvent值为true，表示后续的View体系把事件消费了，那么执行第16行，直接返回true了，后面该Activity的onTouchEvent方法就不再执行了。如果其值为false，则表示事件没有被消费，那该Activity就调用自己的onTouchEvent来消费该事件。这一点，在上一篇文章中多份log都体现了这个结论。当然我们还是需要继续看看getWindow().superDispatchTouchEvent是如何实现的。
其主要代码如下：
//=================Activity.java=================
......
private Window mWindow;
......
public Window getWindow() {
return mWindow;
}
...... //================Window.java================
/**
* ......
* <p>The only existing implementation of this abstract class is
* android.view.PhoneWindow, which you should instantiate when needing a
* Window.
*/
public abstract class Window {
......
public abstract boolean superDispatchTouchEvent(MotionEvent event);
......
}
superDispatchTouchEvent在Window.java中是个抽象方法，需要在实现类中来实现。如注释所说，PhoneWindow是该抽象类唯一存在的实现类，所以我们追踪到PhoneWindow中。
//=============PhoneWindow.java==========
......
// This is the top-level view of the window, containing the window decor.
private DecorView mDecor;
......
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
} //===========DecorView.java==========
......
public boolean superDispatchTouchEvent(MotionEvent event) {
return super.dispatchTouchEvent(event);
}
.... //========ViewGroup.java=======
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
......
}
在本系列第一篇文章【（一）】中，对DecorView做过讲解，如果有看过这篇文章，那么此时看到如上代码，就不会陌生了。DecorView是整个View体系的根view，它是一个ViewGroup，所以事件流程就进入到ViewGroup中的dispatchTouchEvent中了。通过上述流程，Activity就通过dispatchTouchEvent将事件分发到View体系中来了。
如果View体系没有消费掉事件，就会调用Activity自己的onTouchEvent方法，看看其源码。
/**
* Called when a touch screen event was not handled by any of the views
* under it. This is most useful to process touch events that happen
* outside of your window bounds, where there is no view to receive it.
*
* @param event The touch screen event being processed.
*
* @return Return true if you have consumed the event, false if you haven't.
* The default implementation always returns false.
*/
public boolean onTouchEvent(MotionEvent event) {
if (mWindow.shouldCloseOnTouch(this, event)) {
finish();
return true;
}
return false;
}
这里注释说得非常明确了：当它下面的所有view都没有处理掉屏幕触摸事件时，Activity中的这个方法会调用。当触摸事件发生在window边界以外的地方时，这个方法尤为有用，因为这些地方，没有view来接收这个事件。【（五）】的第三点中有个模型图，当触摸白色的Boss区域时，下面三个区域中的view接收不到触摸事件，所以最后只有Activity中的onTouchEvent响应了，【（五）】的第六节中log可以明确这一点。如果您消费了这个事件，返回true；消费不了，则返回false，默认的实现，总是返回false。这一点好理解，Boss嘛，只安排底下的员工干活，自己绝不会动手，就算他们干不了，把事件返回到Boss这里，自己也不会处理的。这里可以改动EventDemoActivity.java中重写的onTouchEvent方法来验证一下：
@Override
public boolean onTouchEvent(MotionEvent event) {
boolean b = super.onTouchEvent(event);
Log.i("songzheweiwang", "[EventDemoActivity-->onTouchEvent]event=" + EventUtil.parseAction(event.getAction())+";b="+b);
return b;
}
最终发现，打印的log中，b值总是false。
到这里，Activity中的两个重要方法就讲完了，后面再来看看事件从Activity分发到View体系后，事件流程是如何在其中一层层分发和处理的。
三、叶子View的事件处理逻辑
控件分为两种：一种是容器类控件，即继承自ViewGroup，如LinearLayout等；一种是叶子View，View的派生类，如TextView，Button等。与之对应，处理事件分发也分为两种情形：一种是ViewGroup处理事件分发；另一种是View处理事件逻辑。ViewGroup会递归遍历子View，如果是叶子View也会调用到View中的dispatchTouchEvent方法。所以，这里咱们先从叶子View处理事件开始分析。
1、叶子View处理事件常见的若干场景
（1）onTouch、onTouchEvent和onClick方法执行顺序问题
我们工作中经常需要为控件设置监听Touch事件和Click事件。这里对【（五）】中的实例代码做一点改动，为ViewInner控件添加触摸事件和点击事件，如下所示：
//===========EventDemoActivity==========
ViewInner mViewInner = findViewById(R.id.viewInner);
mViewInner.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Log.i("songzheweiwang-2", "[EventDemoActivity-->onclick]");
}
});
mViewInner.setOnTouchListener(new View.OnTouchListener() {
@Override
public boolean onTouch(View v, MotionEvent event) {
Log.i("songzheweiwang-2", "[EventDemoActivity-->onTouch]event="+EventUtil.parseAction(event.getAction()));
return false;
}
});
点击ViewInner控件后得到如下log：
1 06-14 01:19:59.246 25518-25518/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_DOWN
2 06-14 01:19:59.246 25518-25518/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
3 06-14 01:19:59.277 25518-25518/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_UP
4 06-14 01:19:59.277 25518-25518/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP
5 06-14 01:19:59.278 25518-25518/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onclick]
我们发现，从执行顺序上看，onTouch > onTouchEvent > onClick，并且onTouch方法执行了两次，onClick在ACTION_UP之后才被执行。
（2）onTouch返回true的场景
另外，我们发现，oTouch是一个boolean型方法，默认返回的是false。如果将其返回值该为true，结果又怎样呢？
1 06-14 01:59:00.487 25760-25760/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_DOWN
2 06-14 01:59:00.492 25760-25760/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_UP
打印log发现，onTouchEvent和onClick方法都没有执行。
（3）控件设置clickable=“false”的场景
在【（五）】中我们讲过，如果控件的clickable属性为false，那么它是无法消费触摸事件的。这里加上Touch和Click事件后，情形如何呢？
1 06-14 02:15:50.279 26161-26161/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_DOWN
2 06-14 02:15:50.279 26161-26161/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
3 06-14 02:15:50.328 26161-26161/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_UP
4 06-14 02:15:50.328 26161-26161/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP
5 06-14 02:15:50.330 26161-26161/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onclick]
这里发现和clickable为true时打印的log一样，也就是说，此时clickable=“false”失效了，这是什么原因呢？
（4）控件设置setEnable(false)时的场景
默认情况下，控件都是enable的，如果给控件执行setEnable(false)，结果会怎样呢？
1 06-14 02:19:56.369 26359-26359/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
2 06-14 02:19:56.401 26359-26359/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP
发现onTouch和onClick都没有执行。为什么？
上面4种场景是工作中经常会碰到的与事件相关的场景，下面我们从源码的角度来分析其原因。
2、View.dispatchTouchEvent方法
View类中用于处理事件分发逻辑的两个主要方法是dispatchTouchEvent和onTouchEvent，前者是事件分发到该控件时最先执行的方法，先分析这个方法。
//=========================View.java==================
/**
* Pass the touch screen motion event down to the target view, or this
* view if it is the target.
* ......
* @return True if the event was handled by the view, false otherwise.
*/
public boolean dispatchTouchEvent(MotionEvent event) {
......
boolean result = false;
......
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;
}
}
......
return result;
}
先看注释：将屏幕动作事件传递给目标view，如果自己就是这个目标则将事件传给自己。如果这个事件被该目标view处理了，会返回true，否则会返回false。当ViewInner被触摸时，会执行到这里。
第11行有个if语句判断，它的作用是为了安全判断当前TouchEvent是否被过滤掉了，比如该控件不在最顶部，被其它控件遮住了等情形。如果被过滤了，该方法就会返回false，事件没有被消费。我们前面的几种场景下，该函数返回的都是true。第16~18行中有多个判断条件，我们来看看这些条件：
//============View.java===========
static class ListenerInfo {
......
private OnTouchListener mOnTouchListener;
......
} /**
* Register a callback to be invoked when a touch event is sent to this view.
* @param l the touch listener to attach to this view
*/
public void setOnTouchListener(OnTouchListener l) {
getListenerInfo().mOnTouchListener = l;
}
前面在EventDemoActivity类中ViewInner调用了该方法，并设置了OnTouchListener，所以li.mOnTouchListener的值这里不是null。(mViewFlags & ENABLED_MASK) == ENABLED表示该view是enable的，默认情况下控件都是enable；li.mOnTouchListener.onTouch(this, event)，就是我们EventDemoActivity中ViewInner的onTouch方法的返回值，默认是返回falsle。所以会跳出该if判断，进入到第21行。由于前面的if条件为false，所以这里result的值还是false，后面那个条件就开始执行onTouchEvent方法了。如果事件被处理了，onTouchEvent会返回true，返回的result值也就为true了，这个事件就完美处理掉了；如果没有处理掉，onTouchEvent就返回false，那返回值result自然就是false了，事件没有被处理掉。所以此时，onTouchEvent方法都是执行了的。如果在onTouch方法中返回了true，那么第16行的判断条件就是true了，此时result被赋值为true，那么第21行的onTouchEvent方法就没有机会执行了，这就是咱们前面说的第（2）种场景“onTouch返回true的场景”了。这种情形下，dispatchTouchEvent返回true，事件也被处理掉了。这里给一个结论：当控件是enable的时候，如果onTouch事件返回true，onTouchEvent和onClick方法均不会执行，且事件仍会被消费。下面，我们再看看onTouchEvent方法的源码。
3、View.onTouchEvent方法
方法很长，这里选取比较关键的代码进行分析。
/**
* Implement this method to handle touch screen motion events.
* ......
* @return True if the event was handled, false otherwise.
*/
public boolean onTouchEvent(MotionEvent event) {
......
final int action = event.getAction();
final boolean clickable = ((viewFlags & CLICKABLE) == CLICKABLE
|| (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)
|| (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE;
if ((viewFlags & ENABLED_MASK) == DISABLED) {
if (action == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) {
setPressed(false);
}
mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN;
// A disabled view that is clickable still consumes the touch
// events, it just doesn't respond to them.
return clickable;
}
......
if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
switch (action) {
case MotionEvent.ACTION_UP:
......
// 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();
}
......
break;
case MotionEvent.ACTION_DOWN:
......
break;
case MotionEvent.ACTION_CANCEL:
......
break;
case MotionEvent.ACTION_MOVE:
......
break;
}
return true;
}
return false;
}
看看注释：实现该方法来处理屏幕触摸事件，如果处理了就返回true，否则返回false。这里需要对比一下dispatchTouchEvent的注释，它的关键字是“pass”，而onTouchEvent的关键字是“handle”，这里可以区别两者的作用。
第9行中的clickable值，前说过，有的控件默认是true，有的则是false。控件的flag为可以一般点击和长按，都表示是可点击的。第12行中，如果控件为disable的，即调用了setEnable(false)时，这里就return了，该方法后面的流程就结束了。如果该控件是可点击的，即clickable的值为true，那onTouchEvent返回的就是true，事件仍然被消费了；反之，控件不可点击，那返回的就是false，事件没有被消费，传递到上一级的onTouchEvent方法中，这一点我们在【（五）】中有讲过。第17、18行的注释也明确说明了：一个可以点击的disable的控件，仍然可以消费触摸事件，只不过它不能回应这些控件。
第22行的第二个条件，tooltip的说明如下：
//=========================View.java====================
1 /**
2 * <p>Indicates this view can display a tooltip on hover or long press.</p>
3 * {@hide}
4 */
5 static final int TOOLTIP = 0x40000000;
这是一种比较特殊的用途，这里不继续深究，我们平时的使用以及这里demo中没有使用该功能。所以咱们这里只考虑第一个条件。
能够走到第22行，说明该控件是enable的。如果该控件是不可点击的，那么这个if语句就跳过去了，返回false，此时前面的dispatchTouchEvent方法返回的也一定是false了，说明该控件没有消费掉事件。相反，如果是可点击的，可以看到，后面一定是会返回true的，那么事件就能被消费了。到这里，结合第19行和dispatchTouchEvent方法，我们可以得到一个结论：如果控件是clickable且没有被过滤的，那么这个控件一定是可以消费掉事件的。在ACTION_UP的时候，会走到第29行。这里我们需要关注一下PerformClick类，其源码如下：
private final class PerformClick implements Runnable {
@Override
public void run() {
performClick();
}
}
而第32行的post方法，本质上就是一个Handler发的post，所以第32、33行是一定要执行performClick()方法的。我们着重看一看这个方法：
//====================View.java================
/**
* Call this view's OnClickListener, if it is defined. Performs all normal
* actions associated with clicking: reporting accessibility event, playing
* a sound, etc.
*
* @return True there was an assigned OnClickListener that was called, false
* otherwise is returned.
*/
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;
}
......
return result;
}
这个方法就是用来执行点击相关的工作的，第13行播放点击音效，第14行响应点击事件等。
//===============View.java=============
static class ListenerInfo {
......
public OnClickListener mOnClickListener;
......
}
......
/**
* Register a callback to be invoked when this view is clicked. If this view is not
* clickable, it becomes clickable.
*
* @param l The callback that will run
*
* @see #setClickable(boolean)
*/
public void setOnClickListener(@Nullable OnClickListener l) {
if (!isClickable()) {
setClickable(true);
}
getListenerInfo().mOnClickListener = l;
}
我们在EventDemoActivity中ViewInner通过该方法设置了OnClickListener，所以EventDemoActivity中的onClick方法在这里就被调用了，此时点击事件就产生了。我们可以看到，点击事件是发生在onTouchEvent方法的ACTION_UP事件中的。这里结合前面讲的onTouch方法，就可以解释场景（1）“onTouch、onTouchEvent和onClick方法执行顺序问题”了：onTouch > onTouchEvent > onClick，并且要在ACTION_UP后才会有onClick。在setOnClickListener方法中第17、18行，我们还可以看到，如果这个控件本身不是clickable的，也会先让它变成clickable的。所以，只要控件调用了setOnClickListener方法，那么之前设置的clickable=“false”就会失效。这里就解释了场景（3）“控件设置clickable=“false”的场景”。此时，我们返回去看看onTouchEvent方法的第19行，就会发现，即使控件是enable的，由于我们设置了点击事件监听，所以这里是返回true的，事件仍然被消费了，再结合前面dispatchTouchEvent的第17行，就能够解释场景（4）“控件设置setEnable(false)时的场景”下，没有执行onTouch和onClick方法，但onTouchEvent方法仍然消费了事件。
这里对关键的源码进行了详细的讲解，且对前面提到的几种常见的现象，从源码角度进行了解释，希望通过这些来加深对View事件分发的认识和理解。关于View中事件的分发，要讲的就是这些了。
四、ViewGroup事件分发处理解析
ViewGroup中处理事件逻辑的方法有两个，分别是dispatchTouchEvent和onInterceptTouchEvent。当一个ViewGroup控件收到上一级传递来的事件时，也是先经过dispatchTouchEvent处理。咱们先看看该方法的源码，该方法很长，这里仅截取了其中关键流程的代码：
//=========================ViewGroup.java========================
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
......
boolean handled = false;
//该判断条件在View的dispatchTouchEvent部分讲过，这个方法用于判断控件是否被遮挡。
if (onFilterTouchEventForSecurity(ev)) {
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// Handle an initial down.
if (actionMasked == MotionEvent.ACTION_DOWN) {
// Throw away all previous state when starting a new touch gesture.
// The framework may have dropped the up or cancel event for the previous gesture
// due to an app switch, ANR, or some other state change.
/**当开始一个新的触摸时，这两句会清除掉以前的状态，
* 清除FLAG_DISALLOW_INTERCEPT设置，
* 代码中还会执行mFirstTouchTarget = null
*/
cancelAndClearTouchTargets(ev);
resetTouchState();
}
// Check for interception.
final boolean intercepted;
/**事件由子View去处理时mFirstTouchTarget会赋值并指向子View。
* mFirstTouchTarget != null表示事件由子View来处理;
* mFirstTouchTarget = null表示事件由自己处理
*/
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
/**FLAG_DISALLOW_INTERCEPT是子View通过requestDisallowInterceptTouchEvent(true)来设置的
* disallowIntercept等同于表示是否调用了该方法。
*/
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
//子View通过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.
//没有找到处理事件的子View，并且这个action不是ACTION_DOWN，所以该View开始拦截触摸事件。
intercepted = true;
}
......
//如果事件没有取消且没有被拦截
if (!canceled && !intercepted) {
......
//寻找能够接收该事件的View
for (int i = childrenCount - 1; i >= 0; i--) {
......
final View child = getAndVerifyPreorderedView(
preorderedList, children, childIndex);
......
/**这两个判断条件分别为1、View可见并且没有播放动画；
* 2、点击事件的坐标在View的范围内。
* 如果其中一个条件不满足，就进行下一次循环。
*/
if (!canViewReceivePointerEvents(child)
|| !isTransformedTouchPointInView(x, y, child, null)) {
ev.setTargetAccessibilityFocus(false);
continue;
}
......
//true表示找到了子View来处理事件，false表示没有子View来处理。
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign))
// Child wants to receive touch within its bounds.
......
//addTouchTarget方法中，会给mFirstTouchTarget赋值。
newTouchTarget = addTouchTarget(child, idBitsToAssign);
......
break;
}
......
}
}
//没有找到可以处理事件的子View，需要自身来处理。
if (mFirstTouchTarget == null) {
// No touch targets so treat this as an ordinary view.
handled = dispatchTransformedTouchEvent(ev, canceled, null,
TouchTarget.ALL_POINTER_IDS);
} else {
......
//这里有一部分源码暂时没有读懂
}
......
}
......
return handled;
}
代码中梳理出了关键的流程，并对几处要点做了一些注释说明，咱们这里再解读一下这段代码：
（1）第11行中，当一个新的事件开始时，即ACTION_DOWN触发时，会进行初始化，清理掉之前的一些状态，这一点很容易理解。
（2）第24~27行对字段mFirstTouchTarget进行了简单的说明，这里不再赘述了，后面几个关键点需要用到这个字段来进行判断。
（3）第28行，如果是ACTION_DOWN事件或者其它事件下找到了处理事件的子View时，会进入到该方法中。
（4）第30~33行，主要是FLAG_DISALLOW_INTERCEPT相关。这里需要简单介绍一下requestDisallowInterceptTouchEvent(boolean disallowIntercept)方法，该方法用于子View请求父View，不让父View拦截，即让父View的onInterceptTouchEvent方法返回true时，失效。在没有调用该方法时，默认其参数为false，即requestDisallowInterceptTouchEvent(false)效果等同于没有调用该方法。FLAG_DISALLOW_INTERCEPT的标志位就是通过该方法来进行设置的。该方法对除ACTION_DOWN之外的事件有效，对ACTION_DOWN事件无效，在第12~20行中讲过，ACTION_DOWN时，会清除之前状态，FLAG_DISALLOW_INTERCEPT标志位也被恢复。这里简单演示一下该方法的使用：
首先在ViewGroupMiddle类中修改onInterceptTouchEvent为以下代码，ViewInner中先不做修改，且为了做对比，要让ViewInner添加clickable=“true”，能够消费事件：
//===========ViewGroupMiddle.java===========
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
Log.i("songzheweiwang-2", "[ViewGroupMiddle-->onInterceptTouchEvent]ev=" + EventUtil.parseAction(ev.getAction()));
switch (ev.getAction()) {
case MotionEvent.ACTION_DOWN:
return false;
default:
return true;
}
}
查看log为：
06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_DOWN
06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->onInterceptTouchEvent]ev=ACTION_DOWN
06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_DOWN
06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_UP
06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->onInterceptTouchEvent]ev=ACTION_UP
06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_CANCEL
06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_CANCEL
ACTION_DOWN没有被拦截，正常传递到了ViewInner中，而其他事件却被拦截了。这里还可以看到，一个完整的事件，如果只有ACTION_DOWN，却没有ACTION_UP，最终会触发ACTION_CANCEL。
现在在ViewInner类的onTouchEvent方法中调用getParent().requestDisallowInterceptTouchEvent(true)方法，如下所示：
//=============ViewInner.java=============
@Override
public boolean onTouchEvent(MotionEvent event) {
Log.i("songzheweiwang-2","[ViewInner-->onTouchEvent]event="+EventUtil.parseAction(event.getAction()));
getParent().requestDisallowInterceptTouchEvent(true);
return super.onTouchEvent(event);
}
之所以要在ViewGroup类中不拦截ACTION_DOWN事件，是因为如果这里拦截了，ViewInner中的方法就不会执行了，第5行的代码也自然起不到效果。得到的log如下：
1 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_DOWN
2 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->onInterceptTouchEvent]ev=ACTION_DOWN
3 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_DOWN
4 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
5 06-12 00:37:24.524 7509-7509/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_UP
6 06-12 00:37:24.524 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_UP
7 06-12 00:37:24.524 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP
可以看到，ACTION_UP事件在ViewInner中正常执行了。所以在第33行的disallowIntercept变量值，在调用该方法且当前事件不是ACTION_DOWN时（因为会清除掉该方法的效果），其值为true，反之则为false。在这里，可以看到，由于调用了该方法，所以在ACTION_UP事件中，ViewGroupMiddle中的onInterceptTouchEvent方法没有执行了。
该方法在日常解决事件冲突时经常会用到，所以这里花了一点篇幅来讲解了一下该方法。
（5）第36行中，调用了onInterceptTouchEvent方法。这个方法我们在【（五）】中提到无数遍了，这里总算看到了它的身影。自然，这里一定要去看看其源码。
//=================ViewGroup.java=============
public boolean onInterceptTouchEvent(MotionEvent ev) {
if (ev.isFromSource(InputDevice.SOURCE_MOUSE)
&& ev.getAction() == MotionEvent.ACTION_DOWN
&& ev.isButtonPressed(MotionEvent.BUTTON_PRIMARY)
&& isOnScrollbarThumb(ev.getX(), ev.getY())) {
return true;
}
return false;
}
What？这么简单？if语句看起来是和鼠标有关系的，貌似和咱们的示例及平时使用没有半毛钱的关系，所以除去这个判断语句，其实就只有第8行的代码了。这里，在【（五）】中讲过，对于重写的onInterceptTouchEvent方法，返回false和返回默认的super.onInterceptTouchEvent，结果是一样的。
（6）第28~46行就确定了是否需要对事件进行拦截了。这里也可以明确看到，onInterceptTouchEvent方法，不一定每次都会被调用了。这里我们在【（五）】中也多次看到这种情形。
（7）第49行中，我们关注后面这个条件，在没有被拦截的情况下才会进入这个if语句内部。它的主要作用就是递归遍历其子view，找到可以接收该事件的view。这里重点需要关注的是第68行的dispatchTransformedTouchEvent方法。这个方法我们在第一节的log中就多次看到过，在ViewGroup中它和dispatchTouchEvent方法总是成对出现的。它的源码如下：
//===============ViewGroup.java==============
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
final boolean handled;
......
//transformedEvent是对event的加工处理
if (child == null) {
handled = super.dispatchTouchEvent(transformedEvent);
} else {
......
handled = child.dispatchTouchEvent(transformedEvent);
}
return handle;
}
这里传入的child参数是有值的，不是null，所以会调用第10行，进行递归。当遍历到叶子View的时候，就跳转到View类中的diapatchTouchEvent方法中了，我们前面已经讲解过了。所以，如果找到了处理事件的view了，handle就是true，该方法返回true，就会跳出for循环，不再需要便利了，否则继续便利。这里面有个addTouchTarget方法，其中会对mFirstTouchTarge进行赋值，说明找到了处理事件的子View，如果没找到，这个值会一直为null。
（8）第79~83行，既然前面没有找到可以处理该事件的子view，那么就只能自己来接手该事件了。第82行，第三个参数传入的是nul，所以该方法体中就会执行第7行。ViewGroup的父类是View，所以会走到View类中，走View处理事件的逻辑了，这里也需要注意，不要混淆父类和父控件了。而如果子View能够处理该事件，那后面当前ViewGroup控件就和这个事件没啥关系了。现在，我们也就能够解释【（五）】中的很多现象了，如：ViewInner无法消费掉事件时，ViewGroupMiddle会回调自身的onTouchEvent方法；如果ViewInner消费了当前的事件，那么本次事件就不会再返回到上级控件了。
（9）最后该方法的返回值仍然是，如果返回true，那么表示事件被消费了，否则返回false。
ViewGroup类中重点需要关注的方法就讲完了，其实主要就是dispatchTouchEvent方法的逻辑。现在我们应该可以理解，在【（五）】在各种现象和结论了吧。
五、参考文章
【Android View 事件分发机制】
【一文读懂Android View事件分发机制】
【Android事件分发机制完全解析，带你从源码的角度彻底理解(上)】
【Android事件分发机制完全解析，带你从源码的角度彻底理解(下)】
结语
Android的View事件传递机制的源码分析，到这里就讲完了，不知道本文中提到的一些场景，是不是也曾经困扰过读者呢？当然，笔者这里只是抓取了主要的关键流程和方法进行了讲解，真实的源码逻辑远远比这要复杂，因为平时会碰到各种不同的情况，比如长按，tip功能的逻辑处理等。总的来说，本文还只不过是登堂入室的开始而已，其中如果有不妥或者不正确的地方，欢迎来拍砖。
