關於Android中的事件機制，用到的地方還是很多的，並且這個知識點還真有點復雜。
在寫這篇文章前，網上看了不少博文，有的寫的感覺挺不錯的。只是當時感覺好像理解了，事后又很容易忘。現在自己也系統整理下吧。
Android中的事件在表現形式上有很多，如onTach、onClick和onLongClick等，在具體微觀上的表現形勢有action_down、action_move和action_up等。
無論哪種事件表現類型，首先都是基於事件的傳遞模型。其實Android中的事件傳遞有點類似於JS中事件傳遞模型。都是基於先捕獲然后冒泡的形式。
在捕獲階段，事件先由外部的View接收，然后傳遞給其內層的View，依次傳遞到更夠接收此事件的最小View單元，完成事件捕獲過程；
在冒泡階段，事件則從事件源的最小View單元開始，依次向外冒泡，將事件對層傳遞。
事件的捕獲和冒泡是整個事件的傳遞流程，但是在實際的傳遞過程中，Android中則表現的相對復雜。
主要表現在可以控制每層事件是否繼續傳遞（由事件分發和事件攔截協同進行），以及事件的具體消費（由事件消響應進行，但需要注意的是，事件分發自身也具有事件消費能力）。
也就是本文提及的事件分發、攔截和響應。
Android中不同的控件所具有的事件分發、攔截和響應稍有不同，主要表現在Activity本身不具有事件攔截，不是ViewGroup的最小view單元不具有事件分發和事件攔截（因為它沒有自己的子View）。
具體對應關系如下圖所示：
對於控制Android中的事件傳遞和消費機制，最主要需要注意的就是這幾個方法的返回值了。
事件分發：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的返回值決定的。
測試用例：