笔记——事件分发机制（四）

《个人平时笔记，看到的同学欢迎指正错误》

1、事件分发机制：整个事件分发是一个U形传递的，递归传递。图解 Android 事件分发机制

一个事件是指一个MotionEvent.ACTION_DOWN事件或MotionEvent.ACTION_MOVE事件或MotionEvent.ACTION_UP事件等，它们合称同一事件序列。

dispatchTouchEvent--->onInterceptTouchEvent--->dispatchTouchEvent--->onTouchEvent

dispatchTouchEvent 返回 false 的含义应该是：事件停止往子View传递和分发，同时开始往父控件回溯（同时回溯后父控件的onTouchEvent开始从下往上回传直到某个onTouchEvent return true消费事件而停止），事件分发机制就像递归，return false 的意义就是递归停止然后开始回溯，回溯到上一层控件的onTouchEvent 。

onTouchEvent return false 就比较简单了，它就是不消费事件，并让事件继续往上一层父控件的方向从下往上流动，直到return true消费事件停止传递。

ViewGroup 和View的这些方法的默认实现就是会让整个事件按照U形完整走完，所以 return super.xxxxxx() 某某方法就会让事件依照U形的方向的完整走完整个事件流动路径），中间不做任何改动，不回溯、不终止，每个环节都走到。

onInterceptTouchEvent拦截只要是return true则是当前控件当前层消费了，即拦截了事件；return false或return super.xxxxxx()同上继续往下传递事件，保证U形路径执行。

事件分发U形图.png

测试消费return true消费事件

测试结果.png

重要注意：某个View一旦开始处理事件，如果它不消耗ACTION_DOWN事件（onTouchEvent返回了false），那么同一事件序列中的其他事件都不会再交给它来处理，并且事件将重新交由它的父元素去处理，即父元素的onTouchEvent会被调用。

1.在onTouchEvent()中B控件onTouchEvent()中MotionEvent.ACTION_DOWN返回return false，则其他事件序列MotionEvent.ACTION_MOVE、MotionEvent.ACTION_UP均不会再接收事件，因为此时控件B已经将事件MotionEvent.ACTION_DOWN处理交给了父容器A;

2.在onTouchEvent()中B控件onTouchEvent()中MotionEvent.ACTION_DOWN返回return true，而其他事件序列MotionEvent.ACTION_MOVE、MotionEvent.ACTION_UP均可以接收事件，而父容器A是不会接收事件了，因为控件B已经消费了事件MotionEvent.ACTION_DOWN;而且假如B控件ACTION_MOVE返回return false，B控件的MotionEvent.ACTION_UP也不受影响仍然能接收该up事件。

3.因此总结，在onTouchEvent()中MotionEvent.ACTION_DOWN的返回值处理是关键；当它返回return true无论后面如何处理，它都是已经处理消费了事件，不会再往上向父容器传递事件。

4.dispatchTouchEvent（）与onInterceptTouchEvent（）依据上图情况可以得到相似结果，只要是ACTION_DOWN都没有接收到事件后面的ACTION_MOVE、ACTION_UP就不会再接收到事件了。并且onInterceptTouchEvent（）比较特殊，当DOWN返回true即拦截事件，而后的事件序列MOVE、UP不会在传递到onInterceptTouchEvent（）而是直接跳过传递到当前view的onTouchEvent（）中。

5.所有ListView,RecycleView,ScrollView等可以滚动，一页显示不了的数据的View都会消费掉onTouchEvent，父View就接收不到了。

假如A包裹B，A为父View，B为子View： View B代码----》： public boolean onTouchEvent(MotionEvent event) {           switch (event.getAction()) {                    case MotionEvent.ACTION_DOWN:                             Log.i(TAG,"----->-----ACTION_DOWN---");                           break;                    case MotionEvent.ACTION_MOVE:                             Log.i(TAG,"----->-----ACTION_MOVE---");                             break;                   case MotionEvent.ACTION_UP:                            Log.i(TAG,"---->------ACTION_UP---");                            break;                    }         return super.onTouchEvent(event); }

ViewGroup A代码----》：由以下测试dispatchTouchEvent（），onInterceptTouchEvent（），onTouchEvent（）所示最后打印输出所知Down、Move、UP都是一个一个对应执行。但是要是ACTION_DOWN都没有接收到事件，后面的ACTION_MOVE、ACTION_UP事件序列就也不能接收到。

ViewGroup A.png

ViewGroup A.png

ViewGroup A.png

2、《Android开发艺术探索》中提到:

分发的顺序流程： Activity->Window(PhoneWindow实体类)->DecorView->ViewGroup->>View->>ViewGroup->DecorView->Window(PhoneWindow实体类)->Activity

关于事件传递的机制，这里给出一些结论，根据这些结论可以更好地理解整个传递机制，如下所示。

（1）同一个事件序列是指从手指接触屏幕的那一刻起，到手指离开屏幕的那一刻结束，在这个过程中所产生的一系列事件，这个事件序列以down事件开始，中间含有数量不定的move事件，最终以up事件结束。

（2）正常情况下，一个事件序列只能被一个View拦截且消耗。这一条的原因可以参考（3），因为一旦一个元素拦截了某此事件，那么同一个事件序列内的所有事件都会直接交给它处理，因此同一个事件序列中的事件不能分别由两个View同时处理，但是通过特殊手段可以做到，比如一个View将本该自己处理的事件通过onTouchEvent强行传递给其他View处理。

（3）某个View一旦决定拦截（拦截ACTION_DOWN返回true），那么这一个事件序列都只能由它来处理（如果事件序列能够传递给它的话），并且它的onInterceptTouchEvent不会再被调用。这条也很好理解，就是说当一个View决定拦截一个事件后，那么系统会把同一个事件序列内的其他方法都直接交给它来处理，因此就不用再调用这个View的onInterceptTouchEvent去询问它是否要拦截了。

（4）某个View一旦开始处理事件，如果它不消耗ACTION_DOWN事件（onTouchEvent返回了false），那么同一事件序列中的其他事件都不会再交给它来处理，并且事件将重新交由它的父元素去处理，即父元素的onTouchEvent会被调用。意思就是事件一旦交给一个View处理，那么它就必须消耗掉，否则同一事件序列中剩下的事件就不再交给它来处理了，这就好比上级交给程序员一件事，如果这件事没有处理好，短期内上级就不敢再把事情交给这个程序员做了，二者是类似的道理。

（5）如果View不消耗除ACTION_DOWN以外的其他事件，那么这个点击事件会消失，此时父元素的onTouchEvent并不会被调用，并且当前View可以持续收到后续的事件，最终这些消失的点击事件会传递给Activity处理。（特别记下）

activity_dispatchtouchevent.png

（6）ViewGroup默认不拦截任何事件。Android源码中ViewGroup的onInterceptTouch-Event方法默认返回false。

（7）View没有onInterceptTouchEvent方法，一旦有点击事件传递给它，那么它的onTouchEvent方法就会被调用。

（8）View的onTouchEvent默认都会消耗事件（返回true），除非它是不可点击的（clickable 和longClickable同时为false）。View的longClickable属性默认都为false，clickable属性要分情况，比如Button的clickable属性默认为true，而TextView的clickable属性默认为false。

（9）View的enable属性不影响onTouchEvent的默认返回值。哪怕一个View是disable状态的，只要它的clickable或者longClickable有一个为true，那么它的onTouchEvent就返回true。

比如Button是可点击的，TextView是不可点击的。通过setClickable和setLongClickable可以分别改变View的CLICKABLE和LONG_CLICKABLE属性。另外，setOnClickListener会自动将View的CLICKABLE设为true，setOnLongClickListener则会自动将View的LONG_CLICKABLE设为true，这一点从源码中可以看出来。 public void setOnClickListener(OnClickListener l) {         if (!isClickable()) {                 setClickable(true);         }         getListenerInfo().mOnClickListener = l;     }     public void setOnLongClickListener(OnLongClickListener l) {         if (!isLongClickable()) {                 setLongClickable(true);         }        getListenerInfo().mOnLongClickListener = l; }

（10）onClick会发生的前提是当前View是可点击的，并且它收到了down和up的事件。优先级：onTouchListener > onTouchEvent > OnClickListener

（11）事件传递过程是由外向内的，即事件总是先传递给父元素，然后再由父元素分发给子View，通过requestDisallowInterceptTouchEvent方法可以在子元素中干预父元素的事件分发过程，但是ACTION_DOWN事件除外。（若要干预ACTION_DOW的话也只能改父viewGroup为拦截状态返回true，如果这样的话子view本身就接收不到任何事件序列了，就更谈不上requestDisallowInterceptTouchEvent能够干预父元素事件了）（有解释说因为down事件方法里，会清除所有的标志位——View的事件分发机制和滑动冲突解决方案）

3、下图理解（图解 Android 事件分发机制一文中）：事件为U型传递，ViewGroup2消费事件，则消费ACTION_DOWN返回true，事件分发到此为止；ViewGroup2既然能消费事件，则它的下层子View的onTouchEvent的ACTION_DOWN必定是不消费返回false的，而返回了false则后面子View的ACTION_MOVE和ACTION_UP等事件序列就不再被接收了，直接分发至父ViewGroup2，所以才有这样的蓝色箭头走向

我们在ViewGroup 2 的onTouchEvent 返回true消费这次事件 红色的箭头代表ACTION_DOWN 事件的流向 蓝色的箭头代表ACTION_MOVE 和 ACTION_UP 事件的流向

ontouchevent.png

4、解决滑动冲突的方式：外部拦截法和内部拦截法    参考-View的事件分发机制和滑动冲突解决方案

外部拦截法：是指点击事情都先经过父容器的拦截处理，如果父容器需要此事件就拦截，如果不需要此事件就不拦截，这样就可以解决滑动冲突的问题，这种方法比较符合点击事件的分发机制。外部拦截法需要重写父容器的onInterceptTouchEvent方法，在内部做相应的拦截即可。

ACTION_UP事件，这里必须要返回false，假设事件交由子元素处理，如果父容器在ACTION_UP时返回了true，就会导致子元素无法接收到ACTION_UP事件，这个时候子元素中的onClick事件就无法触发，但是父容器比较特殊，一旦它开始拦截任何一个事件，那么后续的事件都会交给它来处理，而ACTION_UP作为最后一个事件也必定可以传递给父容器，即便父容器的onInterceptTouchEvent方法在ACTION_UP时返回了false。

父ViewGroup伪代码如下： public boolean onInterceptTouchEvent(MotionEvent event) {         boolean intercepted = false;         int x = (int) event.getX();         int y = (int) event.getY();         switch (event.getAction()) {     case MotionEvent.ACTION_DOWN: {                 intercepted = false;                 break;         }         case MotionEvent.ACTION_MOVE: {                 if (父容器需要当前点击事件) {                         intercepted = true;                 } else {                         intercepted = false;                 }                 break;         }         case MotionEvent.ACTION_UP: {                 intercepted = false;                 break;         }         default:                 break;         }         mLastXIntercept = x;         mLastYIntercept = y;         return intercepted;     }

内部拦截法：是指父容器不拦截任何事件，所有的事件都传递给子元素，如果子元素需要此事件就直接消耗掉，否则就交由父容器进行处理，这种方法和Android中的事件分发机制不一致，需要配合requestDisallowInterceptTouchEvent方法才能正常工作。

子View伪代码如下： public boolean dispatchTouchEvent(MotionEvent event) {         int x = (int) event.getX();         int y = (int) event.getY();         switch (event.getAction()) {         case MotionEvent.ACTION_DOWN: {                 parent.requestDisallowInterceptTouchEvent(true);                 break;         }         case MotionEvent.ACTION_MOVE: {                 int deltaX = x -mLastX;                 int deltaY = y -mLastY;                 if (父容器需要此类点击事件)) {                         parent.requestDisallowInterceptTouchEvent(false);                 }                 break;   }         case MotionEvent.ACTION_UP: {                 break;         }         default:                 break;         }         mLastX = x;         mLastY = y;         return super.dispatchTouchEvent(event);     } 父ViewGroup伪代码： @Override   public boolean onInterceptTouchEvent(MotionEvent event) {       int action = event.getAction();       if (action == MotionEvent.ACTION_DOWN) {           return false;       } else {           return true;       }   }