后期更新了連載：每日一問：談?wù)劵瑒記_突你是怎樣處理的
寫在前面
轉(zhuǎn)眼間 面試系列 已經(jīng)到了第九期了蒋畜，由于文章將會持續(xù)更新询微，導(dǎo)致標(biāo)題難看性炫隶，所以以后的標(biāo)題將更正為本文類似的格式洞辣。
好了叉存，話不多說码俩，還是直入主題吧。
面試場景
講講 Android 的事件分發(fā)機制歼捏？
基本會遵從 Activity => ViewGroup => View 的順序進(jìn)行事件分發(fā)稿存，然后通過調(diào)用 onTouchEvent() 方法進(jìn)行事件的處理。我們在項目中一般會對 MotionEvent.ACTION_DOWN瞳秽，MotionEvent.ACTION_UP挠铲，MotionEvent.ACTION_MOVE，MotionEvent.ACTION_CANCEL 分情況進(jìn)行操作寂诱。
有去查看源碼中的事件攔截方法嗎拂苹？或者說在進(jìn)行事件分發(fā)的時候如何讓正常的分發(fā)方式進(jìn)行攔截？
我知道有個攔截事件的方法叫...叫痰洒，onInterceptEvent()瓢棒？應(yīng)該是，不過由于平時項目較多丘喻，確實沒時間去關(guān)注太多源碼脯宿。
厄，那你覺得在一個列表中泉粉，同時對父 View 和子 View 設(shè)置點擊方法连霉，優(yōu)先響應(yīng)哪個榴芳？為什么會這樣？
肯定是優(yōu)先響應(yīng)子 View 的跺撼，至于為什么這樣窟感，平時知道這個結(jié)論，所以沒去太深入研究歉井，但我相信我簡單看一下源碼是肯定知道的柿祈。
先發(fā)表點扯淡
我們可能經(jīng)常會遇到上面的這種情況，面試官希望了解我們知識的深入情況哩至，或者說是平時學(xué)習(xí)欲望到底怎樣躏嚎。可很不幸的是菩貌，我搞 模擬面試 以來卢佣，80% 的小伙伴都屬于開發(fā)能力不錯，可對類似事件分發(fā)這樣的基礎(chǔ)問題一概不知箭阶。究其原因虚茶，除去忙以外，大多數(shù)小伙伴還是覺得平時開發(fā)也用不上什么尾膊，即使用到了媳危，直接 Google 一下便能得到正確答案荞彼。
這大概就是很多人不會自定義 View 的原因吧冈敛，大多數(shù)效果在 GitHub 上都是現(xiàn)成的了，即使不太一樣鸣皂，也可以簡單改改完事抓谴。
可很遺憾的是，我模擬面試那額外的 20% 的人寞缝，總拿到了令大多數(shù)人羨慕嫉妒恨的 offer癌压，這不是沒有原因的【Ｂ剑可能別人就平時的開發(fā)中保持了更多的一點求知欲滩届，就學(xué)到了很多至關(guān)重要的細(xì)節(jié)知識。
正文
還是不能偏題被啼，其實這樣的一個面試問題帜消，確實是一個較為普遍的問題，我相信同類型的文章浓体，網(wǎng)上一搜也是比比皆是泡挺，而且簡單看一下關(guān)注度就能知道有多少人倒在了這種源碼類型的面試上。
一般情況下命浴，事件列都是從用戶按下（ACTION_DOWN）的那一刻產(chǎn)生的娄猫，不得不提到贱除，三個非常重要的與事件相關(guān)的方法。
- dispatchTouchEvent()
- onTouchEvent()
- onInterceptTouchEvent()
Activity 的事件分發(fā)機制
從英文單詞中已經(jīng)很明顯的知道媳溺，dispatchTouchEvent() 是負(fù)責(zé)事件分發(fā)的月幌。當(dāng)點擊事件產(chǎn)生后，事件首先會傳遞給當(dāng)前的 Activity褂删，這會調(diào)用 Activity 的 dispatchTouchEvent() 方法飞醉，我們來看看源碼中是怎么處理的。
注意截圖中屯阀，我增加了一些注釋缅帘，便于我們更加方便的理解，由于我們一般產(chǎn)生點擊事件都是 MotionEvent.ACTION_DOWN难衰，所以一般都會調(diào)用到 onUserInteraction() 這個方法钦无。我們不妨來看看都做了什么。
很遺憾盖袭，這個方法實現(xiàn)是空的失暂，不過我們可以從注釋和其他途徑可以了解到，該方法主要的作用是實現(xiàn)屏保功能鳄虱，并且當(dāng)此 Activity 在棧頂?shù)臅r候弟塞，觸屏點擊 Home、Back拙已、Recent 鍵等都會觸發(fā)這個方法决记。
再來看看第二個 if 語句，getWindow().superDispatchTouchEvent()倍踪，getWindow() 明顯是獲取 Window系宫，由于 Window 是一個抽象類，所以我們能拿到其子類 PhoneWindow建车，我們直接看看 PhoneWindows.superDispatchTouchEvent() 到底做了什么操作扩借。
直接調(diào)用了 DecorView 的 superDispatchTrackballEvent() 方法。DecorView 繼承于 FrameLayout缤至，作為頂層 View潮罪，是所有界面的父類。而 FrameLayout 作為 ViewGroup 的子類领斥，所以直接調(diào)用了 ViewGroup 的 dispatchTouchEvent()嫉到。
ViewGroup 的事件分發(fā)機制
我們通過查看 ViewGroup 的 dispatchTouchEvent() 可以發(fā)現(xiàn)。
注意其中紅框里面的代碼戒突，看注釋也能知道屯碴，定義了一個 boolean 值變量 intercept 來表示是否要攔截事件。
其中采用到了 onInterceptTouchEvent(ev) 對 intercept 進(jìn)行賦值膊存。大多數(shù)情況下导而，onInterceptTouchEvent() 返回值為 false忱叭，但我們完全可以通過重寫 onInterceptTouchEvent(ev) 來改變它的返回值，不妨繼續(xù)往下看今艺，我們后面對這個 intercept 做了什么處理韵丑。
暫時忽略 判斷的 canceled，該值同樣大多數(shù)時候都返回 false虚缎，所以當(dāng)我們沒有重寫 onInterceptTouchEvent() 并使它的返回值為 true 時撵彻，一般情況下都是可以進(jìn)入到該方法的。
繼續(xù)閱讀源碼可以發(fā)現(xiàn)实牡，里面做了一個 For 循環(huán)陌僵，通過倒序遍歷 ViewGroup 下面的所有子 View，然后一個一個判斷點擊位置是否是該子 View 的布局區(qū)域创坞，當(dāng)然還有一些其他的碗短，由于篇幅原因，這里就不細(xì)講了题涨。
View 的事件分發(fā)機制
ViewGroup 說到底還是一個 View偎谁，所以我們不得不繼續(xù)看看 View 的 dispatchTouchEvent()。
截圖中的代碼是有刪減的纲堵，我們重點看看沒有刪減的代碼巡雨。
紅框中的三個條件，第一個我就不用說了席函。
(mViewFlags & ENABLED_MASK) == ENABLED
該條件是判斷當(dāng)前點擊的控件是否為 enable铐望，但由于基本 View 都是 enable 的，所以這個條件基本都返回 true向挖。mOnTouchListener.onTouch(this, event)
即我們調(diào)用setOnTouchListener()時必須覆蓋的方法onTouch()的返回值蝌以。
從上述的分析炕舵，終于知道「onTouch() 方法優(yōu)先級高于 onTouchEvent(event) 方法」是怎么來的了吧何之。
再來看看 onTouchEvent()
從上面的代碼可以明顯地看到，只要 View 的 CLICKABLE 和 LONG_CLICKABLE 有一個為 true咽筋，那么 onTouchEvent() 就會返回 true 消耗這個事件溶推。CLICKABLE 和 LONG_CLICKABLE 代表 View 可以被點擊和長按點擊，我們通常都會采用 setOnClickListener() 和 setOnLongClickListener() 做設(shè)置奸攻。接著在 ACTION_UP 事件中會調(diào)用 performClick() 方法蒜危，我們看看都做了什么。
從截圖中可以看到睹耐，如果 mOnClickListener 不為空辐赞，那么它的 onClick() 方法就會調(diào)用。
總結(jié)
本來寫到這就結(jié)束了硝训，但回顧一遍還是打算給大家稍微總結(jié)一下响委。
需要總結(jié)的小點：
1新思、Android 事件分發(fā)總是遵循 Activity => ViewGroup => View 的傳遞順序；
2赘风、onTouch()執(zhí)行總優(yōu)先于onClick()
原本想用文字總結(jié)的夹囚，結(jié)果發(fā)現(xiàn)簡書上還有這樣一篇神文：Android事件分發(fā)機制詳解：史上最全面、最易懂邀窃，所以直接引用一下其中的圖片荸哟。
-
Activity 的事件分發(fā)示意圖
-
ViewGroup 事件分發(fā)示意圖
-
View 的事件分發(fā)示意圖
-
事件分發(fā)工作流程總結(jié)
