点击事件透传机制

点击屏幕的事件传递是:

  • Activity将事件交给 所属的Window,如果返回true,整个事件循环就结束了,返回false意味着事件没人处理,所有view的onTouchevent ,都反回了false,那么Activity的onTouchevent就会被调用。

  • window会将事件传递给decorView(viewgroup)
    window可以控制顶级View的外观和行为策略,window的唯一实现是phonewindow,phonewindow将事件扔给了decorView,

  • decorView
    ((ViewGruop)getWindow().getDecorView.findViewById(android.R.id.content)).getChildAt(0), 可以获取Activity所设置的View。

首先事件会调用ViewGroup的dispatchTouchEvent方法,如果顶级ViewGroup拦截事件即onInterceptTouchEvent 返回true ,则事件由ViewGroup处理,这时如果ViewGroup 的mOnTouchListener 被设置,则onTouch会被调用,否则onTouchEvent会被调用。也就是说,如果提供的话,onTouch 会屏蔽掉 onTouchEvent 。在OnTouchEvent中如果设置了mOnClickListener,则onClick会被调用,通过顶级ViewGroup不拦截事件,则事件会传递个他所在的点击事件链子上的子View,这事子View的dispatchTouchEnent会被调用,到此为止事件已经将事件传递了下一层View

最后一个最小view单元不具有事件分发和事件拦截(因为它没有自己的子View)

先捕获然后冒泡的形式:

在捕获阶段,事件先由外部的View接收,然后传递给其内层的View,依次传递到能够接收此事件的最小View单元,完成事件捕获过程;

在冒泡阶段,事件则从事件源的最小View单元开始,依次向外冒泡,将事件对层传递。

事件的捕获和冒泡是整个事件的传递流程,但是在实际的传递过程中,Android中则表现的相对复杂。

主要表现在可以控制每层事件是否继续传递(由事件分发和事件拦截协同进行),以及事件的具体消费(由事件消响应进行,但需要注意的是,事件分发自身也具有事件消费能力)。

也就是本文提及的事件分发、拦截和响应。

Android中不同的控件所具有的事件分发、拦截和响应稍有不同,主要表现在Activity本身不具有事件拦截,不是ViewGroup的最小view单元不具有事件分发和事件拦截(因为它没有自己的子View)。


事件分发:**public boolean dispatchTouchEvent(MotionEvent ev)**
当有监听到事件时,首先由Activity的捕获到,进入事件分发处理流程。无论是Activity还是View,如前文所说,事件分发自身也具有消费能力,
如果事件分发返回true,表示该事件在本层不再进行分发且已经在事件分发自身中被消费了。至此,事件已经完结。如果你不想Activity中的任何控件具有任何的事件消费能力,
最简答的方法可以重写此Activity的dispatchTouchEvent方法,直接返回true就ok。
如果事件分发返回 false,表明事件在本层不再继续进行分发,并交由上层控件的onTouchEvent方法进行消费。
当然了,如果本层控件已经是Activity,那么事件将被系统消费或处理。
如果事件分发返回系统默认的 super.dispatchTouchEvent(ev),事件将分发给本层的事件拦截onInterceptTouchEvent 方法进行处理
(如果本层控件是Activity,由于其没有事件拦截,因此将直接将事件传递到子View,并交给子View的事件分发进行处理)。

事件拦截:**public boolean onInterceptTouchEvent(MotionEvent ev)**
如果 onInterceptTouchEvent 返回 true,则表示将事件进行拦截,并将拦截到的事件交由本层控件 的 onTouchEvent 进行处理;
如果返回结果是false:则表示不对事件进行拦截,事件得以成功分发到子View。并由子View的dispatchTouchEvent进行处理。
如果返回super.onInterceptTouchEvent(ev),事件默认不会被拦截,交由子View的dispatchTouchEvent进行处理。

事件响应:public boolean onTouchEvent(MotionEvent ev)
如果onTouchEvent返回true,表示onTouchEvent处理完事件后消费了此次事件。此时事件终结,将不会进行后续的冒泡。
如果onTouchEvent返回false,事件在onTouchEvent中处理后继续向上层View冒泡,且由上层View的onTouchEvent进行处理。
如果返回super.onTouchEvent(ev),则默认处理的逻辑和返回false时相同。
总结:从以上过程中可以看出,dispatchTouchEvent无论返回true还是false,事件都不再进行分发,
只有当其返回super.dispatchTouchEvent(ev),才表明其具有向下层分发的愿望,
但是是否能够分发成功,则需要经过事件拦截onInterceptTouchEvent的审核。事件是否具有冒泡特是由onTouchEvent的返回值决定的。

总结:
ViewGroup在接受到上级传下来的事件时,如果是一系列Touch事件的开始(ACTION_DOWN),ViewGroup会先看看自己需不需要拦截这个事件(onInterceptTouchEvent,ViewGroup的默认实现直接返回false表示不拦截),接着ViewGroup遍历自己所有的View。找到当前点击的那个View,马上调用目标View的dispatchTouchEvent。如果目标View的dispatchTouchEvent返回false,那么认为目标View只是在那个位置而已,它并不想接受这个事件,只想安安静静的做一个View(我静静地看着你们装*)。

view 的onTouchEvent

 if (((viewFlags & CLICKABLE) == CLICKABLE ||
                (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)) {
...
...
return true;
}
return false;

点击事件透传机制_第1张图片

你可能感兴趣的:(技术知识)