【朝花夕拾】Android自定义View篇之（六）Android事件分发机制（中）从源码分析事件分发机制
前言html
转载请注明，转自【https://www.cnblogs.com/andy-songwei/p/11039252.html】谢谢！java
在上一篇文章【【朝花夕拾】Android自定义View篇之（五）Android事件分发机制（上）Touch三个重要方法的处理逻辑】【下文简称（五），请先阅读完（五）再阅读本文】，咱们经过示例和log来分析了Android的事件分发机制。这些，咱们只是看到了现象，若是要进一步了解事件分发机制，这是不够的，咱们还须要透过现象看本质，去研究研究源码。本文将从源码（基于Android API-26）出发，去分析咱们上一篇文章中看到的现象，以及其它一些和事件相关的常见问题，如：事件是如何传到View中的、requestDisallowInterceptTouchEvent为何失效、view设置了focusable=“false”，为何还能触发点击事件、Touch事件和Click事件谁先谁后等！android
本文的主要内容以下：安全
1、事件的前世此生app
前文中研究事件传递是从Activity的dispatchTouchEvent开始的，可是事件的起源确定不是Activity。由于触摸事件是触摸的硬件，因此很明显事件必定是从底层传过来的。可是，事件是如何传递到View的呢？这一节咱们简单了解一下事件传递到Activity的通过。ide
首先，咱们在ViewInner类的dispatchTouchEvent方法中打印调用栈，看看这个方法的调用流程。函数
1 //=============ViewInner.java============ 2 @Override 3 public boolean dispatchTouchEvent(MotionEvent event) { 4 Log.i("songzheweiwang",Log.getStackTraceString(new Throwable())); 5 return super.dispatchTouchEvent(event); 6 }
点击ViewInner区域，获得以下log：
oop
1 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的事件流程，我们这里作必定的了解便可，有兴趣的能够自行研究。布局
2、事件从Activity到View体系
在上一篇文章的代码示例中，咱们的Boss——EventDemoActivity类中有以下代码
1 //=============Boss:EventDemoActivity.java============ 2 @Override 3 public boolean dispatchTouchEvent(MotionEvent ev) { 4 Log.i("songzheweiwang", "[EventDemoActivity-->dispatchTouchEvent]ev=" + EventUtil.parseAction(ev.getAction())); 5 return super.dispatchTouchEvent(ev); 6 } 7 8 @Override 9 public boolean onTouchEvent(MotionEvent event) { 10 Log.i("songzheweiwang", "[EventDemoActivity-->onTouchEvent]event=" + EventUtil.parseAction(event.getAction())); 11 return super.onTouchEvent(event); 12 }
Activity是事件的起点，dispatchTouchEvent又是整个逻辑中最先分发事件的地方。可是Activity并非View体系中的一员，那它是怎样把事件分发到View体系中的呢？追踪super.dispatchTouchEvent方法，进入到Activity.java的方法中：
1 //==========================Activity.java======================= 2 /** 3 * Called to process touch screen events. You can override this to 4 * intercept all touch screen events before they are dispatched to the 5 * window. Be sure to call this implementation for touch screen events 6 * that should be handled normally. 7 * 8 * @param ev The touch screen event. 9 * 10 * @return boolean Return true if this event was consumed. 11 */ 12 public boolean dispatchTouchEvent(MotionEvent ev) { 13 if (ev.getAction() == MotionEvent.ACTION_DOWN) { 14 onUserInteraction(); 15 } 16 if (getWindow().superDispatchTouchEvent(ev)) { 17 return true; 18 } 19 return onTouchEvent(ev); 20 }
如注释中所说，在事件分发到window以前，能够重写这个方法来拦截全部的屏幕事件，若是事件被消费了，这个方法会返回true。这个方法我们只关注第15~18行。第15行中若是getWindow().superDispatchTouchEvent值为true，表示后续的View体系把事件消费了，那么执行第16行，直接返回true了，后面该Activity的onTouchEvent方法就再也不执行了。若是其值为false，则表示事件没有被消费，那该Activity就调用本身的onTouchEvent来消费该事件。这一点，在上一篇文章中多份log都体现了这个结论。固然咱们仍是须要继续看看getWindow().superDispatchTouchEvent是如何实现的。
其主要代码以下：
1 //=================Activity.java================= 2 ...... 3 private Window mWindow; 4 ...... 5 public Window getWindow() { 6 return mWindow; 7 } 8 ...... 9 10 //================Window.java================ 11 /** 12 * ...... 13 * <p>The only existing implementation of this abstract class is 14 * android.view.PhoneWindow, which you should instantiate when needing a 15 * Window. 16 */ 17 public abstract class Window { 18 ...... 19 public abstract boolean superDispatchTouchEvent(MotionEvent event); 20 ...... 21 }
superDispatchTouchEvent在Window.java中是个抽象方法，须要在实现类中来实现。如注释所说，PhoneWindow是该抽象类惟一存在的实现类，因此咱们追踪到PhoneWindow中。
1 //=============PhoneWindow.java========== 2 ...... 3 // This is the top-level view of the window, containing the window decor. 4 private DecorView mDecor; 5 ...... 6 @Override 7 public boolean superDispatchTouchEvent(MotionEvent event) { 8 return mDecor.superDispatchTouchEvent(event); 9 } 10 11 //===========DecorView.java========== 12 ...... 13 public boolean superDispatchTouchEvent(MotionEvent event) { 14 return super.dispatchTouchEvent(event); 15 } 16 .... 17 18 //========ViewGroup.java======= 19 @Override 20 public boolean dispatchTouchEvent(MotionEvent ev) { 21 ...... 22 }
在本系列第一篇文章【（一）】中，对DecorView作过讲解，若是有看过这篇文章，那么此时看到如上代码，就不会陌生了。DecorView是整个View体系的根view，它是一个ViewGroup，因此事件流程就进入到ViewGroup中的dispatchTouchEvent中了。经过上述流程，Activity就经过dispatchTouchEvent将事件分发到View体系中来了。
若是View体系没有消费掉事件，就会调用Activity本身的onTouchEvent方法，看看其源码。
1 /** 2 * Called when a touch screen event was not handled by any of the views 3 * under it. This is most useful to process touch events that happen 4 * outside of your window bounds, where there is no view to receive it. 5 * 6 * @param event The touch screen event being processed. 7 * 8 * @return Return true if you have consumed the event, false if you haven't. 9 * The default implementation always returns false. 10 */ 11 public boolean onTouchEvent(MotionEvent event) { 12 if (mWindow.shouldCloseOnTouch(this, event)) { 13 finish(); 14 return true; 15 } 16 return false; 17 }
这里注释说得很是明确了：当它下面的全部view都没有处理掉屏幕触摸事件时，Activity中的这个方法会调用。当触摸事件发生在window边界之外的地方时，这个方法尤其有用，由于这些地方，没有view来接收这个事件。【（五）】的第三点中有个模型图，当触摸白色的Boss区域时，下面三个区域中的view接收不到触摸事件，因此最后只有Activity中的onTouchEvent响应了，【（五）】的第六节中log能够明确这一点。若是您消费了这个事件，返回true；消费不了，则返回false，默认的实现，老是返回false。这一点好理解，Boss嘛，只安排底下的员工干活，本身毫不会动手，就算他们干不了，把事件返回到Boss这里，本身也不会处理的。这里能够改动EventDemoActivity.java中重写的onTouchEvent方法来验证一下：
1 @Override 2 public boolean onTouchEvent(MotionEvent event) { 3 boolean b = super.onTouchEvent(event); 4 Log.i("songzheweiwang", "[EventDemoActivity-->onTouchEvent]event=" + EventUtil.parseAction(event.getAction())+";b="+b); 5 return b; 6 }
最终发现，打印的log中，b值老是false。
到这里，Activity中的两个重要方法就讲完了，后面再来看看事件从Activity分发到View体系后，事件流程是如何在其中一层层分发和处理的。
3、叶子View的事件处理逻辑
控件分为两种：一种是容器类控件，即继承自ViewGroup，如LinearLayout等；一种是叶子View，View的派生类，如TextView，Button等。与之对应，处理事件分发也分为两种情形：一种是ViewGroup处理事件分发；另外一种是View处理事件逻辑。ViewGroup会递归遍历子View，若是是叶子View也会调用到View中的dispatchTouchEvent方法。因此，这里我们先从叶子View处理事件开始分析。
一、叶子View处理事件常见的若干场景
（1）onTouch、onTouchEvent和onClick方法执行顺序问题
咱们工做中常常须要为控件设置监听Touch事件和Click事件。这里对【（五）】中的实例代码作一点改动，为ViewInner控件添加触摸事件和点击事件，以下所示：
1 //===========EventDemoActivity========== 2 ViewInner mViewInner = findViewById(R.id.viewInner); 3 mViewInner.setOnClickListener(new View.OnClickListener() { 4 @Override 5 public void onClick(View v) { 6 Log.i("songzheweiwang-2", "[EventDemoActivity-->onclick]"); 7 } 8 }); 9 mViewInner.setOnTouchListener(new View.OnTouchListener() { 10 @Override 11 public boolean onTouch(View v, MotionEvent event) { 12 Log.i("songzheweiwang-2", "[EventDemoActivity-->onTouch]event="+EventUtil.parseAction(event.getAction())); 13 return false; 14 } 15 });
点击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种场景是工做中常常会碰到的与事件相关的场景，下面咱们从源码的角度来分析其缘由。
二、View.dispatchTouchEvent方法
View类中用于处理事件分发逻辑的两个主要方法是dispatchTouchEvent和onTouchEvent，前者是事件分发到该控件时最早执行的方法，先分析这个方法。
1 //=========================View.java================== 2 /** 3 * Pass the touch screen motion event down to the target view, or this 4 * view if it is the target. 5 * ...... 6 * @return True if the event was handled by the view, false otherwise. 7 */ 8 public boolean dispatchTouchEvent(MotionEvent event) { 9 ...... 10 boolean result = false; 11 ...... 12 if (onFilterTouchEventForSecurity(event)) { 13 ...... 14 //noinspection SimplifiableIfStatement 15 ListenerInfo li = mListenerInfo; 16 if (li != null && li.mOnTouchListener != null 17 && (mViewFlags & ENABLED_MASK) == ENABLED 18 && li.mOnTouchListener.onTouch(this, event)) { 19 result = true; 20 } 21 if (!result && onTouchEvent(event)) { 22 result = true; 23 } 24 } 25 ...... 26 return result; 27 }
先看注释：将屏幕动做事件传递给目标view，若是本身就是这个目标则将事件传给本身。若是这个事件被该目标view处理了，会返回true，不然会返回false。当ViewInner被触摸时，会执行到这里。
第11行有个if语句判断，它的做用是为了安全判断当前TouchEvent是否被过滤掉了，好比该控件不在最顶部，被其它控件遮住了等情形。若是被过滤了，该方法就会返回false，事件没有被消费。咱们前面的几种场景下，该函数返回的都是true。第16~18行中有多个判断条件，咱们来看看这些条件：
1 //============View.java=========== 2 static class ListenerInfo { 3 ...... 4 private OnTouchListener mOnTouchListener; 5 ...... 6 } 7 8 /** 9 * Register a callback to be invoked when a touch event is sent to this view. 10 * @param l the touch listener to attach to this view 11 */ 12 public void setOnTouchListener(OnTouchListener l) { 13 getListenerInfo().mOnTouchListener = l; 14 }
前面在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方法的源码。
三、View.onTouchEvent方法
方法很长，这里选取比较关键的代码进行分析。
1 /** 2 * Implement this method to handle touch screen motion events. 3 * ...... 4 * @return True if the event was handled, false otherwise. 5 */ 6 public boolean onTouchEvent(MotionEvent event) { 7 ...... 8 final int action = event.getAction(); 9 final boolean clickable = ((viewFlags & CLICKABLE) == CLICKABLE 10 || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE) 11 || (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE; 12 if ((viewFlags & ENABLED_MASK) == DISABLED) { 13 if (action == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) { 14 setPressed(false); 15 } 16 mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN; 17 // A disabled view that is clickable still consumes the touch 18 // events, it just doesn't respond to them. 19 return clickable; 20 } 21 ...... 22 if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) { 23 switch (action) { 24 case MotionEvent.ACTION_UP: 25 ...... 26 // Use a Runnable and post this rather than calling 27 // performClick directly. This lets other visual state 28 // of the view update before click actions start. 29 if (mPerformClick == null) { 30 mPerformClick = new PerformClick(); 31 } 32 if (!post(mPerformClick)) { 33 performClick(); 34 } 35 ...... 36 break; 37 case MotionEvent.ACTION_DOWN: 38 ...... 39 break; 40 case MotionEvent.ACTION_CANCEL: 41 ...... 42 break; 43 case MotionEvent.ACTION_MOVE: 44 ...... 45 break; 46 } 47 return true; 48 } 49 return false; 50 }
看看注释：实现该方法来处理屏幕触摸事件，若是处理了就返回true，不然返回false。这里须要对比一下dispatchTouchEvent的注释，它的关键字是“pass”，而onTouchEvent的关键字是“handle”，这里能够区别二者的做用。
第9行中的clickable值，前说过，有的控件默认是true，有的则是false。控件的flag为能够通常点击和长按，都表示是可点击的。第12行中，若是控件为disable的，即调用了setEnable(false)时，这里就return了，该方法后面的流程就结束了。若是该控件是可点击的，即clickable的值为true，那onTouchEvent返回的就是true，事件仍然被消费了；反之，控件不可点击，那返回的就是false，事件没有被消费，传递到上一级的onTouchEvent方法中，这一点咱们在【（五）】中有讲过。第1七、18行的注释也明确说明了：一个能够点击的disable的控件，仍然能够消费触摸事件，只不过它不能回应这些控件。
第22行的第二个条件，tooltip的说明以下：
1 //=========================View.java==================== 2 1 /** 3 2 * <p>Indicates this view can display a tooltip on hover or long press.</p> 4 3 * {@hide} 5 4 */ 6 5 static final int TOOLTIP = 0x40000000;
这是一种比较特殊的用途，这里不继续深究，咱们平时的使用以及这里demo中没有使用该功能。因此我们这里只考虑第一个条件。
可以走到第22行，说明该控件是enable的。若是该控件是不可点击的，那么这个if语句就跳过去了，返回false，此时前面的dispatchTouchEvent方法返回的也必定是false了，说明该控件没有消费掉事件。相反，若是是可点击的，能够看到，后面必定是会返回true的，那么事件就能被消费了。到这里，结合第19行和dispatchTouchEvent方法，咱们能够获得一个结论：若是控件是clickable且没有被过滤的，那么这个控件必定是能够消费掉事件的。在ACTION_UP的时候，会走到第29行。这里咱们须要关注一下PerformClick类，其源码以下：
1 private final class PerformClick implements Runnable { 2 @Override 3 public void run() { 4 performClick(); 5 } 6 }
而第32行的post方法，本质上就是一个Handler发的post，因此第3二、33行是必定要执行performClick()方法的。咱们着重看一看这个方法：
1 //====================View.java================ 2 /** 3 * Call this view's OnClickListener, if it is defined. Performs all normal 4 * actions associated with clicking: reporting accessibility event, playing 5 * a sound, etc. 6 * 7 * @return True there was an assigned OnClickListener that was called, false 8 * otherwise is returned. 9 */ 10 public boolean performClick() { 11 final boolean result; 12 final ListenerInfo li = mListenerInfo; 13 if (li != null && li.mOnClickListener != null) { 14 playSoundEffect(SoundEffectConstants.CLICK); 15 li.mOnClickListener.onClick(this); 16 result = true; 17 } else { 18 result = false; 19 } 20 ...... 21 return result; 22 }
这个方法就是用来执行点击相关的工做的，第13行播放点击音效，第14行响应点击事件等。
1 //===============View.java============= 2 static class ListenerInfo { 3 ...... 4 public OnClickListener mOnClickListener; 5 ...... 6 } 7 ...... 8 /** 9 * Register a callback to be invoked when this view is clicked. If this view is not 10 * clickable, it becomes clickable. 11 * 12 * @param l The callback that will run 13 * 14 * @see #setClickable(boolean) 15 */ 16 public void setOnClickListener(@Nullable OnClickListener l) { 17 if (!isClickable()) { 18 setClickable(true); 19 } 20 getListenerInfo().mOnClickListener = l; 21 }
咱们在EventDemoActivity中ViewInner经过该方法设置了OnClickListener，因此EventDemoActivity中的onClick方法在这里就被调用了，此时点击事件就产生了。咱们能够看到，点击事件是发生在onTouchEvent方法的ACTION_UP事件中的。这里结合前面讲的onTouch方法，就能够解释场景（1）“onTouch、onTouchEvent和onClick方法执行顺序问题”了：onTouch > onTouchEvent > onClick，而且要在ACTION_UP后才会有onClick。在setOnClickListener方法中第1七、18行，咱们还能够看到，若是这个控件自己不是clickable的，也会先让它变成clickable的。因此，只要控件调用了setOnClickListener方法，那么以前设置的clickable=“false”就会失效。这里就解释了场景（3）“控件设置clickable=“false”的场景”。此时，咱们返回去看看onTouchEvent方法的第19行，就会发现，即便控件是enable的，因为咱们设置了点击事件监听，因此这里是返回true的，事件仍然被消费了，再结合前面dispatchTouchEvent的第17行，就可以解释场景（4）“控件设置setEnable(false)时的场景”下，没有执行onTouch和onClick方法，但onTouchEvent方法仍然消费了事件。
这里对关键的源码进行了详细的讲解，且对前面提到的几种常见的现象，从源码角度进行了解释，但愿经过这些来加深对View事件分发的认识和理解。关于View中事件的分发，要讲的就是这些了。
4、ViewGroup事件分发处理解析
ViewGroup中处理事件逻辑的方法有两个，分别是dispatchTouchEvent和onInterceptTouchEvent。当一个ViewGroup控件收到上一级传递来的事件时，也是先通过dispatchTouchEvent处理。我们先看看该方法的源码，该方法很长，这里仅截取了其中关键流程的代码：
1 //=========================ViewGroup.java======================== 2 @Override 3 public boolean dispatchTouchEvent(MotionEvent ev) { 4 ...... 5 boolean handled = false; 6 //该判断条件在View的dispatchTouchEvent部分讲过，这个方法用于判断控件是否被遮挡。 7 if (onFilterTouchEventForSecurity(ev)) { 8 final int action = ev.getAction(); 9 final int actionMasked = action & MotionEvent.ACTION_MASK; 10 // Handle an initial down. 11 if (actionMasked == MotionEvent.ACTION_DOWN) { 12 // Throw away all previous state when starting a new touch gesture. 13 // The framework may have dropped the up or cancel event for the previous gesture 14 // due to an app switch, ANR, or some other state change. 15 /**当开始一个新的触摸时，这两句会清除掉之前的状态， 16 * 清除FLAG_DISALLOW_INTERCEPT设置， 17 * 代码中还会执行mFirstTouchTarget = null 18 */ 19 cancelAndClearTouchTargets(ev); 20 resetTouchState(); 21 } 22 // Check for interception. 23 final boolean intercepted; 24 /**事件由子View去处理时mFirstTouchTarget会赋值并指向子View。 25 * mFirstTouchTarget != null表示事件由子View来处理; 26 * mFirstTouchTarget = null表示事件由本身处理 27 */ 28 if (actionMasked == MotionEvent.ACTION_DOWN 29 || mFirstTouchTarget != null) { 30 /**FLAG_DISALLOW_INTERCEPT是子View经过requestDisallowInterceptTouchEvent(true)来设置的 31 * disallowIntercept等同于表示是否调用了该方法。 32 */ 33 final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0; 34 if (!disallowIntercept) { 35 //子View经过onInterceptTouchEvent来判断是否须要拦截。 36 intercepted = onInterceptTouchEvent(ev); 37 ev.setAction(action); // restore action in case it was changed 38 } else { 39 intercepted = false; 40 } 41 } else { 42 // There are no touch targets and this action is not an initial down 43 // so this view group continues to intercept touches. 44 //没有找处处理事件的子View，而且这个action不是ACTION_DOWN，因此该View开始拦截触摸事件。 45 intercepted = true; 46 } 47 ...... 48 //若是事件没有取消且没有被拦截 49 if (!canceled && !intercepted) { 50 ...... 51 //寻找可以接收该事件的View 52 for (int i = childrenCount - 1; i >= 0; i--) { 53 ...... 54 final View child = getAndVerifyPreorderedView( 55 preorderedList, children, childIndex); 56 ...... 57 /**这两个判断条件分别为一、View可见而且没有播放动画； 58 * 二、点击事件的坐标在View的范围内。 59 * 若是其中一个条件不知足，就进行下一次循环。 60 */ 61 if (!canViewReceivePointerEvents(child) 62 || !isTransformedTouchPointInView(x, y, child, null)) { 63 ev.setTargetAccessibilityFocus(false); 64 continue; 65 } 66 ...... 67 //true表示找到了子View来处理事件，false表示没有子View来处理。 68 if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) 69 // Child wants to receive touch within its bounds. 70 ...... 71 //addTouchTarget方法中，会给mFirstTouchTarget赋值。 72 newTouchTarget = addTouchTarget(child, idBitsToAssign); 73 ...... 74 break; 75 } 76 ...... 77 } 78 } 79 //没有找到能够处理事件的子View，须要自身来处理。 80 if (mFirstTouchTarget == null) { 81 // No touch targets so treat this as an ordinary view. 82 handled = dispatchTransformedTouchEvent(ev, canceled, null, 83 TouchTarget.ALL_POINTER_IDS); 84 } else { 85 ...... 86 //这里有一部分源码暂时没有读懂 87 } 88 ...... 89 } 90 ...... 91 return handled; 92 }
代码中梳理出了关键的流程，并对几处要点作了一些注释说明，我们这里再解读一下这段代码：
（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”，可以消费事件：
1 //===========ViewGroupMiddle.java=========== 2 @Override 3 public boolean onInterceptTouchEvent(MotionEvent ev) { 4 Log.i("songzheweiwang-2", "[ViewGroupMiddle-->onInterceptTouchEvent]ev=" + EventUtil.parseAction(ev.getAction())); 5 switch (ev.getAction()) { 6 case MotionEvent.ACTION_DOWN: 7 return false; 8 default: 9 return true; 10 } 11 }
查看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)方法，以下所示：
1 //=============ViewInner.java============= 2 @Override 3 public boolean onTouchEvent(MotionEvent event) { 4 Log.i("songzheweiwang-2","[ViewInner-->onTouchEvent]event="+EventUtil.parseAction(event.getAction())); 5 getParent().requestDisallowInterceptTouchEvent(true); 6 return super.onTouchEvent(event); 7 }
之因此要在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方法。这个方法咱们在【（五）】中提到无数遍了，这里总算看到了它的身影。天然，这里必定要去看看其源码。
1 //=================ViewGroup.java============= 2 public boolean onInterceptTouchEvent(MotionEvent ev) { 3 if (ev.isFromSource(InputDevice.SOURCE_MOUSE) 4 && ev.getAction() == MotionEvent.ACTION_DOWN 5 && ev.isButtonPressed(MotionEvent.BUTTON_PRIMARY) 6 && isOnScrollbarThumb(ev.getX(), ev.getY())) { 7 return true; 8 } 9 return false; 10 }
What？这么简单？if语句看起来是和鼠标有关系的，貌似和我们的示例及平时使用没有半毛钱的关系，因此除去这个判断语句，其实就只有第8行的代码了。这里，在【（五）】中讲过，对于重写的onInterceptTouchEvent方法，返回false和返回默认的super.onInterceptTouchEvent，结果是同样的。
（6）第28~46行就肯定了是否须要对事件进行拦截了。这里也能够明确看到，onInterceptTouchEvent方法，不必定每次都会被调用了。这里咱们在【（五）】中也屡次看到这种情形。
（7）第49行中，咱们关注后面这个条件，在没有被拦截的状况下才会进入这个if语句内部。它的主要做用就是递归遍历其子view，找到能够接收该事件的view。这里重点须要关注的是第68行的dispatchTransformedTouchEvent方法。这个方法咱们在第一节的log中就屡次看到过，在ViewGroup中它和dispatchTouchEvent方法老是成对出现的。它的源码以下：
1 //===============ViewGroup.java============== 2 private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel, 3 View child, int desiredPointerIdBits) { 4 final boolean handled; 5 ...... 6 //transformedEvent是对event的加工处理 7 if (child == null) { 8 handled = super.dispatchTouchEvent(transformedEvent); 9 } else { 10 ...... 11 handled = child.dispatchTouchEvent(transformedEvent); 12 } 13 return handle; 14 }
这里传入的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方法的逻辑。如今咱们应该能够理解，在【（五）】在各类现象和结论了吧。
5、参考文章
【Android事件分发机制彻底解析，带你从源码的角度完全理解(上)】
【Android事件分发机制彻底解析，带你从源码的角度完全理解(下)】
结语
Android的View事件传递机制的源码分析，到这里就讲完了，不知道本文中提到的一些场景，是否是也曾经困扰过读者呢？固然，笔者这里只是抓取了主要的关键流程和方法进行了讲解，真实的源码逻辑远远比这要复杂，由于平时会碰到各类不一样的状况，好比长按，tip功能的逻辑处理等。总的来讲，本文还只不过是登堂入室的开始而已，其中若是有不妥或者不正确的地方，欢迎来拍砖。
原文出处：https://www.cnblogs.com/andy-songwei/p/11039252.html
- 1. Android事件分发机制源码解析(一)-View的事件分发机制
- 2. 基于源码分析 Android View 事件分发机制
- 3. Android事件分发机制源码解析(二)-ViewGroup的事件分发机制
- 4. Android自定义View的事件分发机制（一）
- 5. 浅谈Android View事件分发机制
- 6. [Android] View和ViewGroup事件分发机制
- 7. 浅谈android view事件分发机制
- 8. Android View的事件分发机制
- 9. Android View 事件分发机制
- 10. Android事件分发机制——View(一)
- 更多相关文章...
- • 自定义TypeHandler - MyBatis教程
- • SVN分支 - SVN 教程
- • 漫谈MySQL的锁机制
- • 再有人问你分布式事务，把这篇扔给他
-
每一个你不满意的现在，都有一个你没有努力的曾经。