前言
Android的事件分發(fā)機制看了很多文章，背都背出來了，但是一直沒有自己去看源碼追一遍，現(xiàn)在寫下這篇文章記錄下從源碼分析Android的事件分發(fā)機制，如果有哪個地方說的不對的，望大家指出！謝謝！
事件分發(fā)示意圖
解析
本文基于API 26
點擊事件到Activity
詳情可見這一篇，引用大佬的文章 Touch事件如何傳遞到Activity
Activity到PhoneWindow再到DecorView
Activity收集到點擊事件后會調(diào)用到自己的dispatchTouchEvent方法，并且在其中通過調(diào)用window的superDispatchTouchEvent的方法來判斷是否消費該事件，因為window是一個抽象類，他有一個唯一的子類Phonewindow，所以實際上會調(diào)用到PhoneWindow中的superDispatchTouchEvent，而到了PhoneWindow那就是直接調(diào)用DecorView，沒有其他的判斷
- Activity中調(diào)用PhoneWindow的superDispatchTouchEvent方法判斷是否消費該事件
- PhoneWindow直接調(diào)用DecorView中的superDispatchTouchEvent方法
- DecorView到ViewGroup再到View
DecorView繼承自FrameLayou，F(xiàn)rameLayout繼承于ViewGroup,所以DecorView也是ViewGroup的子類，DecorView中的superDispatchTouchEvent調(diào)用父類ViewGroup的dispatchTouchEvent進(jìn)行事件的分發(fā)
- DecorView調(diào)用父類的dispatchTouchEvent方法
- ViewGroup中dispatchTouchEvent進(jìn)行了事件攔截的處理，首先判斷了當(dāng)前是否可以進(jìn)行攔截，然后調(diào)用onInterceptTouchEvent進(jìn)行攔截判斷，如果返回為false，則繼續(xù)向子View進(jìn)行分發(fā)事件（前提是存在子View的情況下，如果不存在，并且攔截為false，則dispatchTouchEvent返回為false，向上級傳遞告訴他們你們自己消費去吧）
- 向子類分發(fā)事件，首先判斷是否存在子View，如果存在子View，則調(diào)用dispatchTransformedTouchEvent方法去篩選，調(diào)用子View的dispatchTouchEvent方法
- 子View中判斷自身的onTouchEvent是否執(zhí)行，如果不執(zhí)行，則返回false，如果執(zhí)行返回true
總結(jié)
事件分發(fā)理解起來比較容易，就是一層一層的關(guān)系，中間任何一個環(huán)節(jié)出現(xiàn)了消費事件的操作，則都不用下發(fā)給下一層了，并且消費過后告訴上一層我已經(jīng)消費了，然后上一層再告訴上上層，直到頂層。
事件cancel的時機
ACTION_CANCEL事件是收到前驅(qū)事件后，后續(xù)事件被父控件攔截的情況下產(chǎn)生，onTouchEvent的事件回傳到父控件只會發(fā)生在ACTION_DOWN事件中。 所以當(dāng)父View攔截到后續(xù)事件時才會觸發(fā)ACTION_CENCEL,我們正常的流程只有DOWN,UP,MOVE,這三個事件，所以保證ACTION_CENCEL事件不會觸發(fā)即可"。
解決自定義View觸發(fā)ACTION_CANCEL
結(jié)束
漫漫開發(fā)之路，我們只是其中的一小部分……只有不斷的學(xué)習(xí)、進(jìn)階，才是我們的出路！才跟得上時代的進(jìn)步！
今年年初我花一個月的時間收錄整理了一套知識體系，如果有想法深入的系統(tǒng)化的去學(xué)習(xí)的，可以私信我【安卓】，我會把我收錄整理的資料都送給大家，幫助大家更快的進(jìn)階。
重要的事說三遍，轉(zhuǎn)發(fā)+轉(zhuǎn)發(fā)+轉(zhuǎn)發(fā)，讓更多需要的朋友們都可以看到并且領(lǐng)到！
