Activity对点击事件的分发过程
点击事件用MotionEvent
来表示,当一个点击操作发生的时候,事件最先传递给当前Activity
,由Activity
的dispatchTouchEvent
来进行事件的派发,具体的工作是由Activity内部的window来完成的,window会将事件传递给decor view
,decor view
一般都是当前界面的底层容器,通过Activity.getWindow.getDecorView()
获得,我们可以先从Activity
的dispatchTouchEvent
的源码看起:
public boolean dispatchTouchEvent(MotionEvent ev) { |
先分析下上面的代码,首先事件交给Activity
的dispatchTouchEvent
进行分发,然后在通过getWindow().superDispatchTouchEvent(ev)
把事件分发给activity
所依附的window
,如果返回true
那就结束了,如果返回false的话就没人处理,那么Activity的onTouchEvent
就会被调用。
接下来我们看下getWindow().superDispatchTouchEvent(ev)
里面window是如何将事件传递给ViewGroup的,通过源码我们知道,window是一个抽象类,而window的superdispatchTouchEvent(ev)方法也是抽象的
,因此我们必须找到window的实现类
public abstract boolean superDispatchTouchEvent(MotionEvent event); |
那么window的实现类是什么呢?就是phonewindow
,这点源码中有一段注释就说明了
/** |
上面的意思大概就是window
类控制顶级的View的外观和行为机制,他的唯一实现是android.policy.PhoneWinodw
。
由于Window的唯一实现是PhoneWindow,那我们看一下PhoneWindow是如何处理点击事件的
|
我们接下来再进入mDecor.superDispatchTouchEvent(event);
方法中
public boolean superDispatchTouchEvent(MotionEvent event) { |
此处调用了super.dispatchTouchEvent(event);
那就要看看这个Decorview
的父类是谁了,看下面源码:
public class DecorView extends FrameLayout implements RootViewSurfaceTaker, WindowCallbacks { |
很明显DecorView
继承自FrameLayou
,所以最终事件会传递给ViewGroup
的dispatchTouchEvent
。不过上面只是分析了事件从Activity
传递到ViewGroup
的过程,但这不是我们的重点,重点是事件到了ViewGroup
以后应该如何传递,从这里开始,事件已经传递到顶级ViewGroup
了,接下来就开始分析具体的事件传递了。
顶级ViewGroup对事件的分发过程
点击事件达到顶级ViewGroup
以后,会调用ViewGroup
的dispatchTouchEvent
方法
|
由于这个方法比较长,下面进行分段说明。先看下面一段
// Check for interception. |
很显然,它描述的是ViewGroup是否拦截点击事件这个逻辑。
从上面代码我们可以看出,ViewGroup在如下两种情况下会判断是否要拦截当前事件:
事件类型为ACTION_DOWN
mFirstTouchTarget!=null
ACTION_DOWN
事件好理解,那么mFirstTouchTarget!=null
是什么意思呢?下面就开始分析下:
当ViewGroup不拦截事件时intercepted = onInterceptTouchEvent(ev);
中的onInterceptTouchEvent
返回false
,那下面分发给子类并通过mFirstTouchTarget
来标记处理事件的view的那段代码就会执行, mFirstTouchTarget
会被赋值并指向子元素,也就是说,当ViewGroup不拦截事件并将事件交由子元素处理时mFirstTouchTarget != null
。
反过来,一旦事件由当前ViewGroup拦截时intercepted
就为true,那if (!canceled && !intercepted)
就不成立,那么mFirstTouchTarget就不会被赋值为子元素,那 mFirstTouchTarget != null
就不成立。那么当ACTION_MOVE和ACTION_UP
事件到来时,由于actionMasked == MotionEvent.ACTION_DOWN || mFirstTouchTarget != null
这个条件为false,将导致ViewGroup
的onInterceptTouchEvent
不会再被调用,那也就是说同一序列中的其他事件都会默认交给此ViewGroup去处理了。
当然,这里有一种特殊情况,就是上面代码中final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0
这个判断,如果disallowIntercept
为false那就走父类拦截方法,如果为true那就不走父类拦截方法,这个mGroupFlags & FLAG_DISALLOW_INTERCEPT
是否等于0,有以下两个地方决定
第一个地方是每次DOWN
事件来的时候都会执行的下面的一段代码
private void resetTouchState() { |
还有就是子类调用requestDisallowInterceptTouchEvent(true)
告诉父类不拦截事件,requestDisallowInterceptTouchEvent(false)
允许父类拦截事件
|
通过上面两段代码我们知道
mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT
执行完后再执行mGroupFlags & FLAG_DISALLOW_INTERCEPT
一定为0mGroupFlags |= FLAG_DISALLOW_INTERCEPT
执行后再执行mGroupFlags & FLAG_DISALLOW_INTERCEPT
一定不为0
为什么呢?
我们都知道
protected static final int FLAG_DISALLOW_INTERCEPT = 0x80000; |
FLAG_DISALLOW_INTERCEPT的值为0x80000,化成二进制,就是1000000000000000000 |
此处我只分析这一种另一种自己分析
有了上面的分析我们可以知道:ViewGroup在事件分发时,如果是ACTION_DOWN
就会执行mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT
使其 final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0
中的disallowIntercept
为false
,也就是当DOWN
事件来的时候ViewGroup总是会调用自己的onInterceptTouchEvent
方法询问自己是否拦截事件,而在子类设置了requestDisallowInterceptTouchEvent(true)
后final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0
中的disallowIntercept为true,那当除了DOWN
的其他事件都不会被父类拦截了
结论:
当ViewGroup决定拦截事件后,那么后续的点击事件将默认交给它处理并不会再调用它的onInterceptTouchEvent
方法,FLAG_DISALLOW_INTERCEPT
标志位的作用是让ViewGroup不再拦截事件,当然前提是ViewGroup不拦截ACTION_DOWN事件,通过上面的分析我们还可以得到:
- 第一点:
onInterceptTouchEvent
不是每次事件都会调用,如果我们想提前处理所有的点击事件,要选择dispatchTouchEvent
方法,只有这个方法能保证每次都会调用,当然前提是事件能够传递到当前的ViewGroup; - 另一点:
FLAG_DISALLOW_INTERCEPT
标志位的作用可以解决一些滑动冲突。
ViewGroup分发子元素事件
接下来我们再看下ViewGroup不拦截事件的时候,事件会向下分发由他的子View进行处理:
final View[] children = mChildren; |
上面的代码逻辑还是比较清晰的,首先遍历的是ViewGroup的所有子元素,然后判断子元素是否能接受这个点击事件主要是两点来衡量,子元素是否在播动画和点击是按的坐标是否落在子元素的区域内,如果某子元素满足这两个条件,那么事件就会传递给他处理,可以看到,dispatchTransformedTouchEvent
实际上调用的就是子元素的dispatchTouchEvent
方法,在他的内部有下面的一段代码,
if (child == null) { |
而在上面的代码dispatchTransformedTouchEvent
中child传递的不是null,因此他会直接调用子元素的dispatchTouchEvent
方法,这样事件就交由子元素处理了,这就从而完成这一轮事件分发。
如果子元素的dispatchTouchEvent
返回true,这时我们暂时不考虑事件在子元素的怎么分发的,那么mFirstTouchTarget
就会被赋值同时跳出for循环:
newTouchTarget = addTouchTarget(child, idBitsToAssign); |
这几行代码就完成了mFirstTouchTarget
的赋值并且并终止对子元素的遍历,如果子元素的dispatchTouchEvent
返回false,ViewGroup就会把事件分给下一个子元素(如果还有下一个子元素的话)
其实mFirstTouchTarget
真正的赋值过程是在addTouchTarget
方法内部完成的,从下面的addTouchTarget
的内部结构就可以看出,mFirstTouchTarget
其实是一种单链表的结构,mFirstTouchTarget
是否被赋值,将直接影响到ViewGroup对事件的拦截机制,如果mFirstTouchTarget
为null,那么ViewGroup就默认拦截下同一序列中所有的点击事件
private TouchTarget addTouchTarget(@NonNull View child, int pointerIdBits) { |
如果遍历所有的子元素后事件都没有被合适的处理,这包含两种情况,第一是Viewgroup没有子元素,第二是子元素处理了点击事件,但是在dispatchTouchEvent
中返回false,这一般是因为子元素在onTouchEvent
返回了false,这两种情况下,ViewGroup会自己处理点击事件,看代码:
// Dispatch to touch targets. |
注意上面这段话,这里的第三个参数child为null,从上面的分析我们可用知道,他会调用supe.dispatchTouchEvent(event)
,很显然,这里就转到了View的dispatchTouchEvent
方法,就是点击事件开始给View处理了,下面开始分析View对点击事件的处理
View对点击事件的处理过程
View对点击事件的处理过程稍微简单一些,这里注意,这里的View不包含ViewGroup,先看他的dispatchTouchEvent
方法
public boolean dispatchTouchEvent(MotionEvent event) { |
View点击事件的处理就比较简单了,因为他只是一个View,他没有子元素所以无法向下传递,所以只能自己处理点击事件,从上面的源码可以看出View对点击事件的处理过程,首选会判断你有没有设置onTouchListener
,如果onTouchListener
中的onTouch
为true,那么onTouchEvent
就不会被调用,可见onTouchListener
的优先级高于onTouchEvent
,这样做的好处就是方便在外界通过设置onTouchListener
来处理点击事件。
接着我们再来分析下onTouchEvent
的实现
public boolean onTouchEvent(MotionEvent event) { |
先看当View处于不可用的状态下点击事件的处理过程,如下,很显然,不可用状态下的View照样会消耗点击事件,尽管他看起来不可用:
if ((viewFlags & ENABLED_MASK) == DISABLED) { |
接着,如果View设置有代理,那么还会执行TouchDelegate
的onTouchEvent
方法,这个看起来和onTouchListener
类似,这里就不深究了
if (mTouchDelegate != null) { |
下面再看一下onTouchEvent
中点击事件的具体处理,如下所示:
if (((viewFlags & CLICKABLE) == CLICKABLE || |
从上面的代码来看,只要View的CLICKABLE和LONG_CLICKABLE有一个为true,那么他就会消耗这个事件,即onTouchEvent返回true,不管他是不是DISABLE状态,然后就是当ACTION_UP事件发生时,会触发performClick
方法,如果View设置了onClickListener
,那么performClick
方法内部就会调用他的onClick方法
public boolean performClick() { |
View的LONG_CLICKABLE属性默认为false,而CLICKABLE属性是否为什么和具体的View有关,确切的说是可点击的View其CLICKABLE为true,不可点击的为false,比如button是可点击的,textview是不可点击的,通过setClickable
和setLongClickable
可以分别改变View的CLICKABLE和LONG_CLICKABLE属性值,另外,setOnClickListener会自动的将View的CLICKABLE设为true,setOnLongClickListener也会自动将LONG_CLICKABLE属性设为true,这点我们看源码:
public void setOnClickListener(@Nullable OnClickListener l) { |
到这里,点击事件的分发机制源码就分析完成了
总结
所谓点击事件的事件分发,其实就是对MotionEvent
事件的分发过程,即当一个MotionEvent
产生了以后,系统需要把这个事件传递给一个具体的View,而这个传递的过程就是分发过程。点击事件的分发过程由三个很重要的方法来共同完成:dispatchTouchEvent
,onInterceptTouchEvent
和onTouchEvent
- puhlic boolean dispatchTouchEvent(MotionEvent ev)
用来进行事件的分发。如果事件能够传递给当前View,那么此方法一定会被调用,返回结果受当前View的onTouchEvent
和下级View的dispatchTouchEvent
方法的影响,表示是否消耗当前事件。
- public boolean onInterceptTouchEven(MotionEvent event)
在dispatchTouchEvent
方法内部调用,用来判断是否拦截某个事件,如果当前ViewGroup拦截了某个事件,那么在同一个事件序列当中,此方法不会被再次调用,返回结果表示是否拦截当前事件。
- public boolean onTouchEvent(MotionEvent event)
在dispatchTouchEvent
方法中调用,用来处理点击事件,返回结果表示是否消耗当前事件,如果不消耗,则在同一个事件序列中,当前View无法再次接收到事件。
对于一个根ViewGroup
来说,点击事件产生以后,首先传递给ViewGroup
,这时它的dispatchTouchEvent就会被调用,如果这个ViewGroup的onIntereptTouchEvent
方法返回true就表示它要控截当前事件,接着事件就会交给这个ViewGroup
处理,则他的onTouchEvent
方法就会被调用;如果这个ViewGroup的onIntereptTouchEvent
方法返回false
就表示不需要拦截当前事件,这时当前事件就会继续传递给它的子元素,接着子元素的dispatchTouchEvent
方法就会被调用,如此反复直到事件被最终处理。
当一个View需要处理事件时,如果它设置了OnTouchListener
,那么OnTouchListener
中的onTouch
方法会被回调。这时事件如何处理还要看onTouch的返回值,如果返回false
,那当前的View的方法onTouchEvent
会被调用;如果返回true
,那么onTouchEvent
方法将不会被调用。由此可见,给View设置的OnTouchListener
优先级比onTouchEvent
要高,在onTouchEvent
方法中,如果当前设置的有OnClickListener
,那么它的onClick
方法会被调用。可以看出,平时我们常用的OnClickListener
,其优先级最低,即处于事件尾端。
当一个点击事件产生后,它的传递过程遵循如下顺序:Activity-->Window-->View
,即事件总是先传递给Activity
,Activity
再传递给Window
,最后Window
再传递给顶级ViewGroup
。顶级ViewGroup
接收到事件后,就会按照事件分发机制去分发事件。考虑一种情况,如果一个View的onTouchEvent
返回false
,那么它的父容器的onTouchEvent
将会被调用,依此类推,如果所有的元素都不处理这个事件,那么这个事件将会最终传递给Activity
处理,即Activity
的onTouchEvent
方法会被调用。
关于事件传递的机制,这里先给出一些结论,具体分析上文已经结合源码进行了讲解
(1)同一个事件序列是指从手指接触屏幕的那一刻起,到手指离开屏慕的那一刻结束,在这个过程中会产生产生的一系列事件,这个事件序列以
down
事件开始,中间含有数量不定的move
事件,最后以up
事件结束(2)正常情况下,一个事件序列只能被一个View拦截且消耗。这一条的原因可以参考(3),因为一旦一个元素拦截了某此事件,那么同一个事件序列内的所有事件都会直接交给它处理,因此同一个事件序列中的事件不能分别由两个View同时处理,但是通过特殊手段可以做到,比如一个View将本该自己处理的事件通过onTouchEvent强行传递给其他View处理。
(3)某个View一旦决定拦截,那么这一个事件序列都只能由它来处理(如果事件序列能够传递给它的话),并且它的onInterceprTouchEvent不会再被调用。这条也很好理解,就是说当一个View决定拦截一个事件后,那么系统会把同一个事件序列内的其他方法都直接交给它来处理,因此就不用再调用这个View的onInterceptTouchEvent去询问它是否要拦截了。
(4)某个View一旦开始处理事件,如果它不消耗ACTON_DOWN事件(onTouchEvent返回了false),那么同一事件序列中的其他事件都不会再交给它来处理,并且事件将重新交由它的父元素去处理,即父元素的onTouchEvent会被调用。意思就是事件一旦交给一个View处理,那么它就必须消耗掉,否则同一事件序列中剩下的事件就不再交给它来处理了,这就好比上级交给程序员一件事,如果这件事没有处理好,短期内上级就不敢再把事情交给这个程序员做了,二者是类似的道理。
(5)如果View不消耗除ACTION_DOWN以外的其他事件,那么这个点击事件会消失,此时父元素的onTouchEvent并不会被调用,并且当前View可以持续收到后续的事件,最终这些消失的点击事件会传递给Activity处理。
(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。
(10)onclick会发生的前提实际当前的View是可点击的,并且他收到了down和up的事件
(11)事件传递过程是由外到内的,理解就是事件总是先传递给父元素,然后再由父元素分发给子View,子View可以通过requestDisallowInterptTouchEvent方法干预父ViewGroup的事件分发过程,但是ACTION_DOWN除外。