android的事件分發機制其實跟實現中的工作流程很相似，比如有一個問題下來，最先知道這個問題的是最高層的領導，領導如果不攔截這個問題就會把問題向下級分發，直到有人把問題處理掉，或者到最后一級都不處理，那么問題就會交給領導處理，領導還處理不了，就會交給領導的領導。。。其實就是一個V字形。
廢話不多說了，進入正題。。。
1、點擊事件的傳遞規則
其實就是MotionEvent的傳遞過程，這里由三個方法來共同完成：dispatchTouchEvent和onInterceptTouchEvent、onTouchEvent。
<b> public boolean dispatchTouchEvent(MotionEvent event) </b>
這個方法用來進行事件的分發，如果事件能傳遞到view，那么view的這個方法一定會被調用，它的返回結果受到當前view的onTouchEvent和下級的dispatchTouchEvent方法的影響，表示是否消耗掉當前事件。
<b> public boolean onInterceptTouchEvent(MotionEvent event) </b>
在上述方法中被調用，用來判斷是否攔截當前事件，如果當前view攔截個某個事件，那么同一個事件序列中，此方法不會被再次調用，返回結果表示是否攔截當前事件。
<b> public boolean onTouchEvent(MotionEvent event) </b>
在dispatchTouchEvent方法中被調用，用來處理點擊事件，返回結果表示是否消耗當前事件，如果不消耗，那么同一個事件序列中，當前view無法再接收到事件。
上述三個方法的關系用如下偽代碼表示：
public boolean dispatchTouchEvent(MotionEvent event) {
boolean consume = false;
if(onIntercepTouchEvent(event)){
consume = onTouchEvent(event);
} else {
consume = child.dispatchTouchEvent(event);
}
return consume;
}
通過上面的偽代碼，可以大致了解點擊事件的傳遞規則：對于一個根viewgroup來說，點擊事件產生后，首先會傳遞給它，這時它的dispatchTouchEvent方法會被調用，如果這個viewgroup的onIntercepTouchEvent方法返回true的話，這個事件就會由它的onTouchEvent方法消耗掉，否則它會將點擊事件傳遞下去。
當一個view需要處理事件時，如果它設置了OnTouchListener，那么OnTouchListener中的onTouch方法會被調用。這時事件如何處理還要看onTouch的返回值，如果返回false,則當前view的onTouchEvent方法會被調用，如果返回true，那么onTouchEvent方法將不會被調用。可以看出，平時我們常用的OnClickListener，其優先級最低，即處于事件傳遞的尾端。
當一個點擊事件產生后，它的傳遞過程遵循如下順序：Activity ->Window ->View，即事件總是先傳遞給Activity，Activity再傳遞給window，最后Window再傳遞給頂級View，頂級View接收事件后，就會按照事件分發機制去分發事件。考慮一種情況，如果一個View的onTouchEvent返回false，那么它的父容器的onTouchEvent將會被調用，依此類推，如果所有的元素都不處理這個事件，那么這個事件將會最終傳遞給Activity處理，即Activity的onTouchEvent方法會調用。這個過程其實也很好理解，我們可以換一種思路，假如點擊事件是一個難題，這個難題最終被上級領導分給一個程序員去處理（這是事件分發過程），結果這個程序員搞不定(onTouchEvent返回了false)，現在該怎么辦呢？難題必須要解決，那只能交給水平更高的上級解決（上級的onTouchEvent被調用），如果上級再搞不定，那只能交給上級的上級去解決，就這樣將難題一層層地向上拋，這是公司內部一種很常見的處理問題的過程。從這個角度來看，View的事件傳遞過程還是很貼近現實的，畢竟程序員也生活在現實中。
關于事件傳遞的機制，這里給出一些結論，根據這些結論可以更好地理解整個傳遞機制，如下所示。
（1）同一個事件序列是指從手指接觸屏幕的那一該走，到手指離開屏幕的那一該結束，在這個過程中所產生的一系列事件，這個事件序列以down事件開始，中間含有數量不定的move事件，最終以up事件結束。
（2）正常情況下，一個事件序列只能被一個View攔截且消耗。這一條的原因可以參考（3），因為一旦一個元素攔截了此事件，那么同一個事件序列內的所有事件都會直接交給它處理，因此同一個事件序列中的事件不能分別由兩個View處理，但是通過特殊手段可以做到，比如一個View將本該自己處理的事件通過onTouchEvent強行傳遞給其他View處理。
（3）某個View一旦決定攔截，那么這一個事件序列都只能由它來處理（如果事件序列能夠傳遞給它的話），并且它的onInterceptTouchEvent不會再被調用。這條也很好理解，就是說當一個View決定攔截一個事件后，那么系統會把同一個事件序列內的其他方法都直接交給它來處理，因此就不用再調用這個View的onInterceptTouchEvent去詢問它是否要攔截了。
（4）某個View一旦開始處理事件，如果它不消耗ACTION_DOWN事件（onTouchEvent返回了false），那么同一個序列中的其他事件都不會再交給它來處理，并且事件將重新交由它的父元素去處理，并且事件將重新交由它的父元素處理，即父元素的onTouchEvent會被調用。也就是事件一旦交給一個View處理，那么它就必須消耗掉，否則同一事件序列中剩下的事件就不再交給它來處理了，這就好比上級交給程序員一件事，如果這件事沒有處理好，短期內上級就不敢再把事件交給這個程序員做了，二者是類似的道理。
（5）如果View不消耗除ACTION_DOWN以外的其他事件，那么這個點擊事件會消失，此時父元素的onTouchEvent并不會被調用，并且當前View可以持續收到后續的事件，最終這些消失的點擊事件會傳遞給Activity處理。
（6）ViewGroup默認不攔截任何事件。Android源碼中ViewGroup的onInterceptTouchEvent方法默認返回false。
（7）View沒有onIntercepTouchEvent方法，一旦有點擊事件傳遞給它，那么它的onTouchEvent方法默認返回false。
（8）View的onTouchEvent默認都會消耗事件（返回true），除非它是不可點擊的（clickable和longClickable同時為false）。View的longClickable屬性默認都為false，clickable屬性要分情況，比如Button的clickable屬性默認為true，而TextView的clickable屬性默認為false。
（9）View的enable屬性不影響onTouchEvent的默認返回值。哪怕一個View是disable狀態的，只要它的clickable或者longClickable有一個為true，那么它的onTouchEvent就返回true。
（10）onClick會發生的前提是當前View是可點擊的，并且它收到了down和up的事件。
（11）事件傳遞過程是由外向內的，即事件總先傳遞給父元素，然后再由父元素分發給子View，通過requestDisallowInterceptTouchEvent方法可以在子元素中干預父元素的事件分發過程，但是ACTION_DOWN事件除外。