以前寫 android ,對事件的處理沒有太深入,只是簡單的 onTouchEvent 就 ok 了,現在寫的 UI ,很多自訂群組件,父 view 和子view 都需要接收事件,然後處理。如果不弄明白它的事件傳遞機制,很難擁有好的使用者體驗。
Touchevent 中,傳回值是 true ,則說明消耗掉了這個事件,傳回值是 false ,則沒有消耗掉,會繼續傳遞下去,這個是最基本的。
在 View 中跟 Touch 相關的事件有 dispatchTouchEvent , interceptTouchEvnet , onTouchEvent 三種。 dispatchTouchEvent是負責分發事件的,事件從 activity 傳遞出來之後,最先到達的就是最頂層 view 的 dispatchTouchEvent ,然後它進行分發,如果返回false ,則交給這個 view 的 interceptTouchEvent 方法來決定是否要攔截這個事件,如果 interceptTouchEvent
返回 true ,也就是攔截掉了,則交給它的 onTouchEvent 來處理,如果 interceptTouchEvent 返回 false ,那麼就傳遞給子 view ,由子 view 的dispatchTouchEvent 再來開始這個事件的分發。
如果事件傳遞到某一層的子 view 的 onTouchEvent 上了,這個方法返回了 false ,那麼這個事件會從這個 view 往上傳遞,都是onTouchEvent 來接收。而如果傳遞到最上面的 onTouchEvent 也返回 false 的話,這個事件就會“消失”,而且接收不到下一次事件。(我說的一次事件指的是 down 到 up 之間的一系列事件)
我畫了個圖,見附件。
總結一下,如果這一次事件沒有人消耗掉,則系統不會給你下一次事件,因為他會認為你這次的事件阻塞了,沒必要給下一次。onTouchEvent如果不消耗的話,會從子view傳遞到父view。
又一個例子:
需求:要做一個完全通過flip手勢來切換的介面。在最上層用一個ViewFlipper作為容器,並檢測flip手勢操作。
難題:ViewFlipper的flip手勢檢測需要的MotionEvent會被各種子View的觸摸檢測給攔截了。比如介面上有一個Button,則當手指按下Button(還沒有抬起)然後flip出Button,則最上層的flip手勢檢測無效。
原因:android對Touch Event的分發邏輯是View從上層分發到下層(dispatchTouchEvent函數),然後下層優先開始處理Event(先mOnTouchListener,再onTouchEvent)並向上返回處理情況(boolean值),若返回true,則上層不再處理。
於是我們首先想到,要保證flip手勢檢測,需要把所有的Touch Event都傳到上層去。
然而在分發邏輯之外還有一個邏輯,android估計是為了保證每個觸操作只能由一個View來進行完整響應,對ACTION_DOWN事件有個額外的邏輯:如果某個View在處理ACTION_DOWN事件時返回false(即該View未處理此事件),那麼後續產生的其它事件將直接忽略掉這個View(不過LongPress又有另外的獨立邏輯)。舉例來說就是,如果你處理ACTION_DOWN時返回了false,那麼你這個View將得不到ACTION_MOVE或ACTION_DOWN等等這些後續事件了。
於是難題出現了,你若把Touch Event都想辦法給傳到上層了(只能通過返回false來傳到上層),那麼下層的各種子View就不能處理後續事件了。
解決方案:
開始僅著眼於Touch Event處理完後的回傳過程,想了N久不得,畢竟我想實現的是一個需要打破android事件處理邏輯的效果(就是一個連續性操作,只有不滿足上層要求時,才輪到下層處理)。然後突然想到事件的分發過程,便豁然開朗:
覆寫最上層的View的dispatchTouchEvent函數,代碼如下:
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
if (_flipDetector.onTouchEvent(event)) {
event.setAction(MotionEvent.ACTION_CANCEL);
}
return super.dispatchTouchEvent(event);
}
於是效果實現。也就是在分發之前便進行手勢檢測處理,若檢測成功,則取消下層的一切處理過程。