android 事件分發機制---簡述

前言：

剛開始接觸事件分發的時候， 很多人都是這樣的
1. 先看網上的流程圖
2. 看源碼
結果：流程圖看懂了， 但是源碼好像關聯不起來， 分析起來很難.

我個人總結的原因:

1. 網上常見的流程圖， 很多都是隻畫了一種事件(ACTION_DOWN)
2. 所謂的事件都是一組出現的， 並不是單個.
3. ViewGroup的dispatchTouchEvent源碼，是幾個事件都合併一切寫的， 所以分析可能起來比較費勁.

一. 事件分發 解決了什麼問題？

佈局嵌套或重疊時， 我們的觸摸屏幕，這個事件到底給誰去執行

二. 事件的分類

需知：事件都是一組出現的， 而不是單個的.

事件分類：

1. 手指觸碰到屏幕 (ACTION_DOWN)
2. 手指在屏幕停留或滑動 (ACTION_MOVE)
3. 手指離開屏幕 (ACTION_UP)
4. 結束這組事件 (ACTION_CANCEL) 非人爲觸碰

常見的事件組：

1. ACTION_DOWN(開始) ---》ACTION_MOVE---》...... ---》ACTION_UP(人爲結束)
2. ACTION_DOWN(開始) ---》ACTION_MOVE---》...... ---》ACTION_CANCEL(非人爲結束)

三. 事件分發的流程

1. ACTION_DOWN 事件的分發， 如上圖：

①：方法全部返回false，會按照黃色箭頭走完， 也即是網上說的“U”型路徑
②：如果onInterceptTouchEvent() 返回true, 則會直接去執行自己的onTouchEvent()， 後面繼續按黃色箭頭走
③：如果onTouchEvent()返回true, 則不會繼續按黃色箭頭走

2. ACTION_MOVE 事件的分發, 如上圖：
影響因素：和ACTION_DOWN事件 在 某個View中onTouchEvent() 中返回值有關
①：返回false, 分發流程 和 ACTION_DOWN事件是一樣的.
②：返回true, 則ACTION_MOVE 會走最短路線找到對應的View, 執行onTouchEvent()，也就是網上說的“L”型路線

3. ACTION_UP 和 ACTION_CANCEL事件的分發, 如上圖：
和ACTION_MOVE 的 分發流程是一樣的，
區別：這是一組事件結束的標記

四. 事件分發 這樣設計有什麼好處呢？

1. 從事件處理的角度--onTouchEvent()： 是從手機最上層的控件， 一層一層往下去處理， 很符合人類的直覺.
2. 事件分發的角度--dispatchTouchEvent()：，父親需要先拿到優先權， 然後才能派發給底下的孩子，不想給我就自己享受， 這個也很符合人類的直覺.
3. 特殊情況： 我的子View 一定要拿到事件，怎麼辦呢？
   系統提供了一個方法：getParent().requestDisallowInterceptTouchEvent(true)