Android Touch事件傳遞機制講解

在講正題之前我們講一段有關任務傳遞的小故事，拋磚迎玉下：

話說一家軟件公司，來一個任務，分派給了開發經理去完成：

開發經理拿到，看了一下，感覺好簡單，於是

開發經理：分派給了開發組長

開發組長：分派給了自己組員（程序員）

程序員：分派給了自己帶的實習生。

實習生：好苦逼，無法分派，怎麼辦啊？只能自己干了

但是實習生能不能做好，有兩種情況了。

情況一：

實習生：經過一段時間的研究，琢磨，熬夜，奮斗，死敲，皇天不負有心人啊，完成了。

後來又來一個類似的任務，也按著這樣傳遞下去了（開發經理->開發組長->程序員->實習生），又有實習生完成了。

情況二：

實習生：經過一段時間的研究，琢磨，就是毫無頭緒，無法完成，只能求教師傅（程序員）了。

程序員：啊，我怎麼沒留意就給實習生搞了，這任務好難啊，自己研究下，也沒有頭緒，沒辦法只能請求組長了。

開發組長：這任務不難啊，怎麼我底下的人都不會了，沒辦法，只能自己搞了，經過，一段時間，完成了，感想，以後要是又有跟這個很類似的任務，我就自己弄了，不給他們弄了。

後來又來一個類似的任務，傳遞是這樣的

開發經理：分派給開發組長

開發組長：啊，又是跟著上一個很類似的任務，我自己弄吧，沒過多久也完成了！

PS:以上就是一個任務傳遞的過程。上級一開始總會想把任務分派給自己的下屬去弄，然後任務一步一步去傳遞下去，最後由一個人去完成他，當然傳遞下 去，最底下人不會，也會一步一步的回滾，又他上級去完成，如果又有一個類似的任務，那個節點不會的人就不會再傳遞給他，給他也不會弄。當然實現中，這些任 務的傳遞也可能被分派人去攔截，比如說，開發組長本打算分派給程序員，突然他不想傳遞了，就半路攔截了下來。

而在我們android Touch事件傳遞機制跟這個很類似，思想差不多，有句話說，設計來源於生活。跟Touch事件有關的處理方法主要由三個：

//分派事件
public boolean dispatchTouchEvent(MotionEvent ev)
//攔截事件 
public boolean onInterceptTouchEvent(MotionEvent ev)
//處理事件
public boolean onTouchEvent(MotionEvent event)

用他們的時候，我們只需要重寫一下，即可操作，這三個方法主要在三種類被調用，那三種類呢？

基類 例子類 擁有的方法 繼承Activity（activity類） MainActivity（因項目而異）

dispatchTouchEvent,onTouchEvent

繼承ViewGroup（View容器） RelativeLayout，FrameLayout，LinearLayout,AbsoluteLayout,ListView,ScrollView…

dispatchTouchEvent,onInterceptTouchEvent,onTouchEvent

繼承View（View控件） Button,EditText,TextView,ImageView….

dispatchTouchEvent,onTouchEvent

而這三個方法的含義是什麼呢？

事件 含義

dispatchTouchEvent

用來分派事件。
其中調用了onInterceptTouchEvent()和onTouchEvent()，一般不重寫該方法

onInterceptTouchEvent

用來攔截事件。
ViewGroup類中的源碼實現就是{return false;}表示不攔截該事件，
事件將向下傳遞（傳遞給其子View）；
若手動重寫該方法，使其返回true則表示攔截，事件將終止向下傳遞，
事件由當前ViewGroup類來處理，就是調用該類的onTouchEvent()方法

onTouchEvent

用來處理事件。
返回true則表示該View能處理該事件，事件將終止向上傳遞（傳遞給其父View）；
返回false表示不能處理，則把事件傳遞給其父View的onTouchEvent()方法來處理

根據上面的小故事，我們用代碼去實現一下：

我新建了四個類：MainActivity（開發經理），FirstFrameLayout（開發組長），SecondRelativeLayout（程序員），ThirdTextView（實習生）

在界面的層次關系如下圖：

我就好比我們前面的故事情況一，情況二那麼模擬下：

情況一

首先我們按照上面的故事情況一那樣，任務一級一級傳遞下去（將viewgroup的類的onInterceptTouchEvent都返回 false），然後事件就會一直傳遞到，ThirdTextview，最後，我們把它的onTouchEvent返回ture（含義是實習生處理成功 了）。我們點擊藍色區域。我們看下日志。

情況二

首先我們還是一級級傳遞下去（將viewgroup的類的onInterceptTouchEvent都返回false），然後是傳遞到 ThirdTextview，我們將它的onTouchEvent返回false（含義是實習生處理失敗了），再講 SecondRelativeLayout的onTouchEvent返回false（含義是程序員處理失敗了），最後講 FirstFrameLayout的onTouchEvent返回true（含義是組長處理成功了）。我們點擊藍色區域。我們看下日志，如下圖。

注：上面兩種情況的日志圖，紅色框代表第一個任務，黃色框代表第二個類似的任務。根據上圖日志，我們畫下傳遞圖：

情況一事件傳遞圖：

情況二事件傳遞圖：

http://blog.csdn.net/hyp712/article/details/8777835

（情況二的流程圖，有點問題，，請參考上面鏈接！問題是：在第二次傳遞類似的事件（move、up）的時候，不再走onInterceptTouchEvent（）函數，而是直接分發時間到onTouchEvent（）函數中去！！！）

 

從上面兩張事件傳遞圖我們的出來一些結論：

1.事件是先有dispatchTouchEvent分派給下一級

2.要經過onInterceptTouchEvent是否需要攔截，不攔截傳遞給下一級，最終傳遞給view控件，

3.onTouchEvent方法中，在處理事件中，如果返回True，則表示能處理，傳遞將會終止。反著，不能，如果不能的話，這會返回上一級的onTouchEvent方法中，如果還是false，會一直到到上一層的onTouchEvent方法中。

好奇的我們會發現一個問題：圖二中的黃色線，沒有像紅色線那樣，先傳遞到最底層，然後再回滾回去，這是為什麼呢？

答：就如我們故事中，他都知道了，底下人都不會去做了，那麼他干嘛還分派給他呢，他就會自己做了，直接給onTouchEvent ，這就是事件傳遞中的“記憶”功能。我們是手指點擊藍色區域，Touch事件有兩個，第一個ACTION_DOWN，第二個ACTION_UP，第一個 ACTION_DOWN事件向下傳遞到某View，它把事件繼續傳遞交給它的子View，它會記錄該事件是否被它下面的View給處理成功了，（怎麼能知 道呢？如果該事件會再次被向上傳遞到我這裡來由我的onTouchEvent來處理，那就說明下面的View都沒能成功處理該事件）；當第二個 ACTION_UP事件向下傳遞到該View，該View的dispatchTouchEvent方法機會判斷，若上次的事件由下面的view成功處理 了，那麼這次的事件就繼續交給下面的來處理，若上次的事件沒有被下面的處理成功，那麼這次的事件就不會向下傳遞了，該View直接調用自己的 onTouchEvent方法來處理該事件。

PS：關於這“記憶”功能的信息只在一系列事件完成之前有效，也就是從ACTION_DOWN事件開始，直到後續事件 ACTION_MOVE，ACTION_UP結束後，“記憶”的信息就會清除。也就是說如果某View處理ACTION_DOWN事件失敗了 （onTouchEvent()返回false），那麼後續的ACTION_MOVE,ACTION_UP等事件就不會再傳遞到該View了，由其父 View自己來處理。在下一次發生ACTION_DOWN事件的時候，還是會傳遞到該View的。

補充說明：

-》若在向下傳遞的過程中被攔截了，即onInterceptTouchEvent方法返回true，則事件將停止向下傳遞，直接由當前的onTouchEvent方法來處理，若處理成功則OK，若處理不成功，則事件會向上傳遞。

謝謝收看。