Android事件機制之一：事件傳遞和消費

 關於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的返回值決定的。

 

 測試用例：

EventTest