Android事件分發機制

前言

 Android的事件分發機制看了不少文章，背都背出來了，可是一直沒有本身去看源碼追一遍，如今寫下這篇文章記錄下從源碼分析Android的事件分發機制，若是有哪一個地方說的不對的，望你們指出！謝謝！

事件分發示意圖

解析

本文基於API 26

點擊事件到Activity

詳情可見這一篇，引用大佬的文章 Touch事件如何傳遞到Activity

Activity到PhoneWindow再到DecorView

 Activity收集到點擊事件後會調用到本身的dispatchTouchEvent方法，而且在其中經過調用window的superDispatchTouchEvent的方法來判斷是否消費該事件，由於window是一個抽象類，他有一個惟一的子類Phonewindow，因此實際上會調用到PhoneWindow中的superDispatchTouchEvent，而到了PhoneWindow那就是直接調用DecorView，沒有其餘的判斷

• Activity中調用PhoneWindow的superDispatchTouchEvent方法判斷是否消費該事件

  

• PhoneWindow直接調用DecorView中的superDispatchTouchEvent方法

  

DecorView到ViewGroup再到View

 DecorView繼承自FrameLayou，FrameLayout繼承於ViewGroup,因此DecorView也是ViewGroup的子類，DecorView中的superDispatchTouchEvent調用父類ViewGroup的dispatchTouchEvent進行事件的分發

• DecorView調用父類的dispatchTouchEvent方法

  

   ViewGroup中dispatchTouchEvent進行了事件攔截的處理，首先判斷了當前是否能夠進行攔截，而後調用onInterceptTouchEvent進行攔截判斷，若是返回爲false，則繼續向子View進行分發事件（前提是存在子View的狀況下，若是不存在，而且攔截爲false，則dispatchTouchEvent返回爲false，向上級傳遞告訴他們大家本身消費去吧）

  

  

• 向子類分發事件，首先判斷是否存在子View，若是存在子View，則調用dispatchTransformedTouchEvent方法去篩選，調用子View的dispatchTouchEvent方法

  

  

  

• 子View中判斷自身的onTouchEvent是否執行，若是不執行，則返回false，若是執行返回true

總結

 事件分發理解起來比較容易，就是一層一層的關係，中間任何一個環節出現了消費事件的操做，則都不用下發給下一層了，而且消費事後告訴上一層我已經消費了，而後上一層再告訴上上層，直到頂層。

事件cancel的時機

 文章剛發出來就被羣裏的大佬提醒了一點，何時會cancel，個人天，我還懵逼中，而後我正在查，又一位大佬把答案發出來了，感謝兩位！  另外加上一篇博客，裏面也說了:"：ACTION_CANCEL事件是收到前驅事件後，後續事件被父控件攔截的狀況下產生，onTouchEvent的事件回傳到父控件只會發生在ACTION_DOWN事件中。 因此當父View攔截到後續事件時纔會觸發ACTION_CENCEL,咱們正常的流程只有DOWN,UP,MOVE,這三個事件，因此保證ACTION_CENCEL事件不會觸發便可"。

解決自定義View觸發ACTION_CANCEL