点击屏幕的事件传递是：
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;
在哪个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处理并结束传递。
https://blog.csdn.net/wangzici/article/details/78143428
dispatchTouchEvent小结
true时,dispatchTouchEvent自己消费事件，不走onInterceptTouchEvent/onTouchEvent,同时也没有返回上层
false时,dispatchTouchEvent不分发事件，直接返回上层容器，让上层容器自己处理，同时也不走onInterceptTouchEvent/onTouchEvent
super.dispatchTouchEvent(ev) 才会分发事件,去走onInterceptTouchEvent方法
