一般我們處理事件,都是針對(duì)某一個(gè)View來處理了,要么是添加onTouchListener監(jiān)聽器,要么繼承View然后重寫View#onTouchEvent,

甚至不用重寫,只要使用Widget自己的監(jiān)聽函數(shù) ,或者GestureDetector就OK了.

但是理解Android事件模型,對(duì)于理解GestureDetector,及Android事件的交互,寫出具有出色的交互的應(yīng)用.

都是必經(jīng)之路.

一:ViewGroup與View的事件模型

我們都知道Android界面實(shí)際是一棵View的樹.枝干是ViewGroup.

ViewGroup繼承自View,但是又是管理View的容器.那么ViewGroup與View的事件關(guān)系是怎么樣的呢?

這需要從另一個(gè)重要的ViewGroup中的方法,如下說起:

1public boolean onInterceptTouchEvent(MotionEvent ev) {

2 return false;

3}

它的默認(rèn)實(shí)現(xiàn)很簡(jiǎn)單,就是把事件交給子View去處理.自己不攔截.

Intercept就是攔截的意思.

此方法的注釋,對(duì)于ViewGroup與View的事件模型說得很清楚,

主要是以下幾點(diǎn):

(1) 如果此方法返回false,說明此ViewGroup暫時(shí)(只是暫時(shí))對(duì)于觸控事件不感興趣.

但是不知道后面的事件它感不感興趣.所以后續(xù)事件還會(huì)一直傳遞到此方法中來,供此方法判斷.

(2) 如果此方法返回true了.那么說明此方法對(duì)應(yīng)的ViewGroup開始對(duì)于此事件(或者手勢(shì))感興趣了.

那么后續(xù)事件就會(huì)直接給此方法對(duì)應(yīng)的ViewGroup的onTouchEvent方法來處理事件了.

(3) 如果此方法一開始返回false,說不感興趣這個(gè)時(shí)候事件發(fā)給了目錄View.

現(xiàn)在又返回true,說感興趣了.那么目錄View就會(huì)收到一個(gè)action為ACTION_CANCEL的事件.

跟此方法返回true時(shí)的事件是同一個(gè)事件 ,只是action變了.

(4) ViewGroup會(huì)在這里接收觸控開始的事件.

規(guī)則就是上面這些 ,那么是誰在后面處理這些規(guī)則呢?

就是ViewGroup.它在disptachTouchEvent方法中,進(jìn)行了一系列的處理來實(shí)現(xiàn)這種模型.

public boolean dispatchTouchEvent(MotionEvent ev)

對(duì)于單獨(dú)的View本身來說,它也有一個(gè)簡(jiǎn)單的事件派發(fā)模型.通過以下代碼就可以很明白的看出來了:

View#dispatchTouchEvent(MotionEvent event):

1ListenerInfo li = mListenerInfo;

2if (li != null && li.mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED

3 && li.mOnTouchListener.onTouch(this, event)) {

4 return true;

5}

6

7if (onTouchEvent(event)) {

8 return true;

9}

二: Activity與View的事件模型

事件先到Activity中,然后Activity調(diào)用:

01/**

02 * Called to process touch screen events. You can override this to

03 * intercept all touch screen events before they are dispatched to the

04 * window. Be sure to call this implementation for touch screen events

05 * that should be handled normally.

06 *

07 * @param ev The touch screen event.

08 *

09 * @return boolean Return true if this event was consumed.

10 */

11 public boolean dispatchTouchEvent(MotionEvent ev) {

12 if (ev.getAction() == MotionEvent.ACTION_DOWN) {

13 onUserInteraction();

14 }

15 if (getWindow().superDispatchTouchEvent(ev)) {

16 return true;

17 }

18 return onTouchEvent(ev);

19 }

來分發(fā)事件, 這里的邏輯是:

先讓用戶界面窗口處理:getWindow().superDispatchTouchEvent(ev)

如果窗口沒有處理這個(gè)事件.

那就交給Activity自己處理.return onTouchEvent(ev)

這個(gè)Window跟View層級(jí)是怎么交互的呢?

我們找到了Window的實(shí)現(xiàn)類:PhoneWindow(com.android.internal.policy.impl.PhoneWindow)

1@Override

2 public boolean superDispatchTouchEvent(MotionEvent event) {

3 return mDecor.superDispatchTouchEvent(event);

4 }

這個(gè)mDecor就是用戶界面的根View了.

private final class DecorView extends FrameLayout

(com.android.internal.policy.impl.PhoneWindow.DecorView)

原來窗口將事件交給根View來進(jìn)行事件派發(fā)的.

mDecor調(diào)用自己的superDispatchTouchEvent(event)

然后將事件派發(fā)的任務(wù)交給了自己的dispatchTouchEvent

1public boolean superDispatchTouchEvent(MotionEvent event) {

2 return super.dispatchTouchEvent(event);

3}

這里調(diào)用的super.dispatchTouchEvent 就是ViewGroup的聲明的dispatchTouchEvent的了.