笔记(四)——事件分发机制

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

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 falsereturn 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;         }     }