動作序列的三個事件

TouchEvent 分三種事件:down、move、up。

其中move事件在一個操作中（這裡說的一個操作就是使用者與螢幕的互動，即由down到up的動作序列）可能會發生多次。 
但是，我們認為一個動作序列會包含以上三種事件，因此，在事件處理中就是要處理好這個過程，而最重要的就是down事件，這是一個動作序列的起始，沒有down談不上後面的事件了。 
所以，我們把消耗down事件的類當做是這個動作序列的最終載體。

如果Down事件不歸你處理，那這個動作序列的move，up也不歸你處理。

他們的觸發順序會是這樣：

ACTION_DOWN->ACTION_MOVE->ACTION_MOVE->ACTION_MOVE...->ACTION_MOVE->ACTION_UP

 

從父到子的訊息分發流程

Android 訊息佇列的分發流程是

Activity  ->  ViewGroup1  -> ViewGroup1的直接子ViewGroup –> ××××××  -> 葉子View

 

 

訊息和處理的一一對應

一個訊息，預設訊息都只需要一個控制元件來處理。中間訊息途徑的都只是起中轉的效果，不做處理。處理完成直接返回了，不會通知中間步驟。

如果一個訊息想改成多個控制元件都處理，則需要修改這裡的邏輯

 

 

 

訊息處理流程，從子到父

如果訊息處理一直返回的是 false。

則一直是從子到父的依次處理。處理到沒有可以處理的人了，或者返回了true到此為止。

比如：

如果一個Activity呼叫一個View，那麼首先執行的是View中的onTouchEvent(MotionEvent event)，如果返回false，

再執行Activity中的onTouchEvent(MotionEvent event)，

否則不執行Activity中的onTouchEvent(MotionEvent event)；

但是如果是觸控螢幕的標題欄的時候，執行的是Activity中onTouchEvent(MotionEvent event)。

 

Android 事件分發處理策略

Activity與View控制元件的分發流程有所區別，首先我們介紹 ViewGroup 的分發流程

 

Android ViewGroup分發處理原則

• 預設情況，一個訊息最後只需要一個人處理，其它訊息途徑者都只是幹了中轉的效果。
• 訊息傳遞途徑三級處理機制：
  • 接受上級訊息（dispatchTouchEvent），
  • 決策向下級分發還是自身處理（onInterceptTouchEvent），
  • 自身處理邏輯（onTouchEvent、onTouch 、onClick 、onLongClick 等）
• View內部自身處理邏輯先後順序,依次是:（注：在return不為true的情況下）
  • onTouchEvent
  • onClick
  • onLongClick
• OnTouchListener onTouch onTouchEvent 的區別
  • 首先執行OnTouchListener()中的onTouch,然後執行重寫的onTouchEvent(MotionEvent event)。（注：在return不為true的情況下）
  • onTouch() is used by users of the View to get touch events while onTouchEvent() is used by derived classes of the View to get touch events.
  • 更詳細的可以看  http://blog.csdn.net/ddna/article/details/5451722
• 訊息處理中， return true 表示訊息被完整地處理完成了，後面不用再用其他事件處理了。

 

View，ViewGroup 的分發處理邏輯

 

dispatchTouchEvent	接受上級傳遞過來的訊息  抽象物件的對外呼叫介面。  對外部來說，只知道這個介面，不知道其他。相當於企業門衛，郵遞員是把信給門衛的。  1、返回值：false   不接受動作序列中的後續事件  我們一般遇到事件有3種，分別是：Down、move、up False表示不接受動作序列中的後續事件，因此本次後續操作不起作用， 如：down後返回false，則move和up都不會被接受，只能接受下個動作。 2、返回值：true    繼續接受動作序列中的後續事件，如move、up   其中如果呼叫了Super.dispatchTouchEvent。 這樣就會繼續呼叫onInterceptTouchEvent事件。  如果返回值是 Super.dispatchTouchEvent ，意味著由onInterceptTouchEvent決定事件流向， Super.dispatchTouchEvent 的返回值就是系統預設的，系統預設最終只有一個控制元件處理這個訊息。  如果需要多個控制元件同時處理，則一定需要返回true，並呼叫Super.dispatchTouchEvent
onInterceptTouchEvent	抽象物件對內的介面。  相當其企業的內勤，負責分發信件。  不過要注意的是，一旦動作序列的down事件知道了該如何分發，下次就會繞過它  返回值：true 自己處理，不需要繼續下傳  事件會傳遞到自己的onTouchEvent() Down事件在onInterceptTouchEvent()後返回true，則傳遞到onTouchEvent， 當其返回true時，動作序列的後續事件不會再通過onInterceptTouchEvent了,而是在dispatchTouchEvent中直接傳遞於onTouchEvent。  返回值：false  自己無法完全處理，或者不能處理，繼續下傳 傳遞到下一個view的dispatchTouchEvent() onInterceptTouchEvent返回false應該傳給下個子view的dispatchTouchEvent，但是，點選的葉子節點view，因此不存在子view而直接傳給自己的onTouchEvent onInterceptTouchEvent要做的就是確定事件傳遞到哪個子view，如果返回false，又沒有子view處理（因為根本就沒有點選到子view），就自己處理了,而自己在onTouchEvent處理的後續事件就不必經過onInterceptTouchEvent了，它是判斷傳遞給子view的，都不是子view處理，就不用經過了。
onTouchEvent 實現View.OnClickListener 的onClick 實現View.OnLongClickListener 的 onLongClick 實現View.OnTouchClickListener 的 onTouch	具體幹事的  這裡有個先後順序。  如果先工作的把這件事情結束了，就不會繼續傳遞下去了。  如果我們在一個View中同時覆寫了onClick、onLongClick及onTouchEvent的話，onTouchEvent是最先捕捉到ACTION_DOWN和ACTION_UP事件的，其次才可能觸發onClick或者onLongClick。  返回值 true和false在其中起著標誌事件是否被消耗，  如果消耗了就不再傳遞給其他控制元件了。  如果沒有消耗則還會傳遞給其他控制元件，觸發其他控制元件的事件處理函式。

 

參考資料

Android onTouchEvent, onClick及onLongClick的呼叫機制 
http://blog.csdn.net/ddna/article/details/5451722

 

android 事件處理 
http://blog.csdn.net/leesidong/article/details/6973261

 

Android FrameWork——Touch事件派發過程詳解 
http://blog.csdn.net/stonecao/article/details/6759189

 

Android中Touch事件的處理邏輯 
http://www.oschina.net/question/163910_27289