android点击事件透传,点击事件透传机制

点击屏幕的事件传递是：

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

笔记2

在哪个View的onTouchEvent 返回true，那么ACTION_MOVE和ACTION_UP的事件从上往下传到这个View后就不再往下传递了，而直接传给自己的onTouchEvent 并结束本次事件传递过程。

对于ACTION_MOVE、ACTION_UP总结：ACTION_DOWN事件在哪个控件消费了(return true)， 那么ACTION_MOVE和ACTION_UP就会从上往下(通过dispatchTouchEvent)做事件分发往下传，就只会传到这个控件，不会继续往下传，如果ACTION_DOWN事件是在dispatchTouchEvent消费，那么事件到此为止停止传递，如果ACTION_DOWN事件是在onTouchEvent消费的，那么会把ACTION_MOVE或ACTION_UP事件传给该控件的onTouchEvent处理并结束传递。

touchevent true

dispatchTouchEvent小结

true时,dispatchTouchEvent自己消费事件，不走onInterceptTouchEvent/onTouchEvent,同时也没有返回上层

false时,dispatchTouchEvent不分发事件，直接返回上层容器，让上层容器自己处理，同时也不走onInterceptTouchEvent/onTouchEvent

super.dispatchTouchEvent(ev) 才会分发事件,去走onInterceptTouchEvent方法