前言
前幾篇文章咱們從源碼的層面分析了事件分發機制…不過感覺有些時候還是需要記一些筆記般的內容，簡單快捷的回憶對應的內容。
正文
佈局嵌套層級：ViewGroupA中嵌套ViewGroupB，然後ViewGroupB嵌套ViewGroupC,ViewGroupC中包含ViewD。
基於此，咱們分情況記錄一些情況：
一、C的onInterceptTouchEvent()返回true，onTouchEvent()返回false
現象： DOWN走到C的onTouchEvent()，然後逐層回調父View的onTouchEvent()，並且後續MOVE、UP將不再回調。
解讀：
DOWN一路下來，因爲沒有任何onTouchEvent()返回true，那麼意味着這條分發鏈上沒有任何View消費事件，也就意味着mFirstTouchTarget爲null，因此後續的MOVE、UP事件就不會再重新分發。
二、C的onInterceptTouchEvent()返回false，onTouchEvent()返回true
現象： DOWN一直傳到D，然後調D的onTouchEvent()，C的onTouchEvent()。找到消費事件的C，後續事件正常按ABC的順序調用
解讀： 因爲不存在任何View攔截，所以事件會一直傳遞至D。然後逐層倒序回調onTouchEvent()來確定是否有子View消費。而此時我們的C返回了true，所以着mFirstTouchTarget不爲null，後續事件就交由C去消費。
三、C的dispatchTouchEvent()直接返回true，且不主動調用super
現象： 正常回調AB、但永遠只會回調C的dispatchTouchEvent()
解讀： 父View通過子View的dispatchTouchEvent()的返回值來決定分發權。一旦返回true，意味着找到了消費此事件的View。因爲我們直接返回了true，所以這個對於父View來說mFirstTouchTarget已經確認。後續事件直接分發到此View。
但是因爲我們我們直接true，且不掉super那意味着onTouchEvent()沒有時機執行…
尾聲
當然可能會有小夥伴說，還有一些情況呢？但其實萬變不離其宗，你都會唱、跳、RAP了還差打籃球嗎？j你太美就哦了。
最近在看View的繪製體系，不出意外國慶會開始陸續連載~
