前言
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的時機
ACTION_CANCEL事件是收到前驅事件后，后續事件被父控件攔截的情況下產生，onTouchEvent的事件回傳到父控件只會發生在ACTION_DOWN事件中。 所以當父View攔截到后續事件時才會觸發ACTION_CENCEL,我們正常的流程只有DOWN,UP,MOVE,這三個事件，所以保證ACTION_CENCEL事件不會觸發即可"。
解決自定義View觸發ACTION_CANCEL
結束
漫漫開發之路，我們只是其中的一小部分……只有不斷的學習、進階，才是我們的出路！才跟得上時代的進步！
今年年初我花一個月的時間收錄整理了一套知識體系，如果有想法深入的系統化的去學習的，可以私信我【安卓】，我會把我收錄整理的資料都送給大家，幫助大家更快的進階。
重要的事說三遍，轉發+轉發+轉發，讓更多需要的朋友們都可以看到并且領到！
