淺談事件分發

@[toc]

何爲事件分發

• 基礎知識

事件：MotionEvent(點擊事件)

事件列：從手指接觸屏幕至手指離開屏幕的這個過程所產生的一系列事件，通常狀況下，點擊事件都是從DOWN事件開始，UP事件結束，中間經歷若干個MOVE事件。

事件類型： 手指按下 -->產生DOWN事件 手指滑動 -->產生MOVE事件 手指擡起 -->產生UP事件

• 定義理解：通常來講，事件分發就是將點擊事件分發（能夠理解爲傳遞）到一個view去處理該事件。

ACTION_DOWN事件怎麼傳遞和處理的

看了很多文章，po一張比較好理解的圖：基於ACTION_DOWN事件走向。 來源Kelin

先對這圖作一些基本說明：

• true---該控件或activity消費事件，事件再也不被傳遞。
• false---該控件或actiivty不消費事件，事件被繼續傳遞。
• super---調用該方法的父類實現，在方法中可修改返回值。
• dispatchTouchEvent()---事件首先到達的方法。用於分發點擊事件，通常不會重寫這個方法。
• onInterceptTouchEvent()---判斷是否攔截該事件，用來攔截事件。
• onTouchEvent()---判斷是否消費該事件，用來處理事件。

上圖很明顯地表示了系統默認的對於down事件的傳遞方式。咱們能夠觀察到這些事件在三個對象間進行傳遞，分別是activity，viewgroup，view。 總結： activity層的dispatchTouchEvent()---調用--->activity層父類的dispatchTouchEvent()(默認實現是調用viewgroup層的dispatchTouchEvent())---調用--->super的默認實現 viewgroup層onInterceptTouchEvent()---調用--->【默認返回false】super的默認實現view層dispatchTouchEvent()---調用--->super的默認實現view層的onTouchEvent()

在這以後，如圖，默認狀況下，view層和Viewgroup都不進行消費，那麼就會一路傳給了activity層的onTouchEvent()進行消費。 因而出現了相似U型的流程走向。

po另一張圖，來源仍是 Kelin

注：右上角的橫線代表返回值 咱們能夠很清楚地看到整個的流程，有幾點總結一下

1.只有viewgroup纔有 onInterceptTouchEvent()方法。

2.當viewgroup層的 onInterceptTouchEvent()返回值爲true，代表該viewgroup想要處理這個事件，那麼這個事件便會傳遞給其onTouchEvent()進行處理。

3.若是onTouchEvent()或者dispatchTouchEvent()不想處理事件，返回false，則拋給上級的onTouchEvent()進行處理。

4.另外，調用優先級： onTouchListener的onTouch>View的onTouch>onClickListener 當一個view須要處理事件時，若是它設置了onTouchListener，那麼onTouchEvent()中的onTouch()會被回調。若是該方法返回值爲true,那麼當前view的onTouchEvent()將不會被調用，返回false纔會調用到view的onTouchEvent()。這個時候再onTouchEvent()中設置的onClickListener()纔會被調用。

ACTION_MOVE和ACTION_UP事件怎麼傳遞和處理的

詳細可參考博客中的參考圖片及相關說明。此處再也不贅述，只作總結。

• 總結
  • 1.當一個view決定攔截一個事件後，系統會把同一個事件系列內的全部事件都交給他處理，此時不須要再調用攔截器詢問是否須要攔截。所以同一個事件系列中的事件通常也只由一個view進行處理。
  • 2.在DOWN事件發生時，若是某個view的onTouchEvent()被調用，可是返回了false[即不想處理]，那麼該事件系列後續的事件也再也不傳遞給他，乃是傳給其父類viewgroup的onTouchEvent()。這一點的話很像是上級交給程序員一個任務，他沒完成，交給他的上級完成。那麼短期內他的上級就不會交給他相關任務了。 這個時候咱們可能會發現，其實事件分發的機制能夠用領導交給下級任務這種職場常見模式進行分析，或許這樣會更加容易理解。
  • 3.在哪一個對象的onTouchEvent()進行消費，那麼後續的事件都會給其進行處理。

事件分發是第一次接觸的東西，源碼和實例等等尚未進行研究。如有錯誤之處，還望各位不吝賜教。