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

2020 年 3 月 27 日
筆記

——》个人平时笔记，看到的同学欢迎指正错误，文中多处摘录于各大博主精华、书籍

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

image

一个事件是指：一个ACTION_DOWN事件或ACTION_MOVE事件或ACTION_UP事件等。它们合称同一个事件序列。事件是分开执行传递的，在顺利的条件下ACTION_DOWN、ACTION_MOVE、ACTION_UP事件分别按这个顺序，依次跑完U行事件流程。

对于ACTION_DOWN事件有以下特性 (1)、dispatchTouchEvent返回 false 的含义应该是事件停止往子View传递和分发，并往上层父控件的onTouchEvent 回溯，之后上层父控件的onTouchEvent开始从下往上回传，直到某个更上一层的onTouchEvent return true消费事件而终止传递。其中如果是activity的话，dispatchTouchEvent return false | ture都是消费；最内部底层view的dispatchTouchEvent return super.dispatchTouchEvent()则会将事件传递给当前view的onTouchEvent 。 (2)、onTouchEvent返回false | super就比较简单了，它就是不消费事件，并让事件继续从下往上向一层父控件的方向传递，直到return true消费掉事件终止传递。 (3)、ViewGroup 和View的这些方法的super.xxxx()默认实现就是会让整个事件按照U形完整走完。中间不做任何改动，不回溯、不终止，每个环节都走到 dispatchTouchEvent—>onInterceptTouchEvent—>dispatchTouchEvent—>onTouchEvent。 (4)、onInterceptTouchEvent拦截方法，类似一个开关，当return true时该事件则被当前控件消费了，拦截该事件，不再往下传递了；而return false或return super.xxxxxx()不会拦截事件，继续往下传递事件，保证U形路径畅通。

down事件流程1

down事件流程2

重要注意： (1)、如果一个View或ViewGroup的onTouchEvent不消耗ACTION_DOWN事件返回了false，那么它就不会再接收同一事件序列中的ACTION_MOVE、ACTION_UP等事件，并且将整个事件交给它的上一层父元素去处理。如果返回true就消费事件终止传递。 (2)、dispatchTouchEvent（）与onInterceptTouchEvent（）依据上图情况可以得到相似结果。如果ACTION_DOWN都没有接收到，同一事件序列的ACTION_MOVE、ACTION_UP就不会再被接收了。但是onInterceptTouchEvent（）比较特殊，当拦截事件ACTION_DOWN返回true时，同一事件序列ACTION_MOVE、ACTION_UP并不会再传递到onInterceptTouchEvent（），而是直接跳过onInterceptTouchEvent（），直接传递到当前view的onTouchEvent（）中。反之onInterceptTouchEvent（）不拦截事件ACTION_DOWN，后面的ACTION_MOVE、ACTION_UP才能交由它处理。

2、所有ListView、RecycleView、ScrollView等可以滚动的控件，当一页显示不完数据时都会消费掉onTouchEvent，所以父View的onTouchEvent就接收不到事件了。

小结：dispatchTouchEvent（），onInterceptTouchEvent（），onTouchEvent（）所示最后打印输出所知Down、Move、UP都是一个一个对应执行。但是要是ACTION_DOWN都没有接收到事件，后面的ACTION_MOVE、ACTION_UP事件序列就也不能接收到。

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

绘制及分发的顺序流程： Activity->Window(PhoneWindow实体类)->ViewRoot(ViewRootImpl)->DecorView->ViewGroup——》View（最底部转折点）——》ViewGroup->DecorView->ViewRoot(ViewRootImpl)->Window(PhoneWindow实体类)->Activity

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

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

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

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

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

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

image

（6）、ViewGroup默认不拦截任何事件。Android源码中ViewGroup的onInterceptTouchEvent方法默认返回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是可点击的，并且它收到了ACTION_DOWN和ACTION_UP的事件。优先级：onTouchListener > onTouchEvent > OnClickListener

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

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

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

image

5、解决滑动冲突的方式：外部拦截法和内部拦截法参考-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: {                    //参数true，使父ViewGroup不拦截                   parent.requestDisallowInterceptTouchEvent(true);                   break;              }              case MotionEvent.ACTION_MOVE: {                   int deltaX = x -mLastX;                   int deltaY = y -mLastY;                   if (父容器需要此类点击事件)) {                      //参数false，让父ViewGroup拦截事件                           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) {             //因为子view需要事件，父ViewGroup的down都不拦截，让这一系列事件往下传递             return false;         } else {             return true;         }     }