前言
轉載請注明，轉自【https://www.cnblogs.com/andy-songwei/p/11039252.html】謝謝！
在上一篇文章【【朝花夕拾】Android自定義View篇之（五）Android事件分發機制（上）Touch三個重要方法的處理邏輯】【下文簡稱（五），請先閱讀完（五）再閱讀本文】，我們通過示例和log來分析了Android的事件分發機制。這些，我們只是看到了現象，如果要進一步了解事件分發機制，這是不夠的，我們還需要透過現象看本質，去研究研究源碼。本文將從源碼（基於Android API-26）出發，去分析我們上一篇文章中看到的現象，以及其它一些和事件相關的常見問題，如：事件是如何傳到View中的、requestDisallowInterceptTouchEvent為什么失效、view設置了focusable=“false”，為什么還能觸發點擊事件、Touch事件和Click事件誰先誰后等！
本文的主要內容如下：
一、事件的前世今生
前文中研究事件傳遞是從Activity的dispatchTouchEvent開始的，但是事件的起源肯定不是Activity。因為觸摸事件是觸摸的硬件，所以很明顯事件一定是從底層傳過來的。但是，事件是如何傳遞到View的呢？這一節我們簡單了解一下事件傳遞到Activity的經過。
首先，我們在ViewInner類的dispatchTouchEvent方法中打印調用棧，看看這個方法的調用流程。
1 //=============ViewInner.java============ 2 @Override 3 public boolean dispatchTouchEvent(MotionEvent event) { 4 Log.i("songzheweiwang",Log.getStackTraceString(new Throwable())); 5 return super.dispatchTouchEvent(event); 6 }
點擊ViewInner區域，得到如下log：
1 java.lang.Throwable 2 at com.example.demos.customviewdemo.ViewInner.dispatchTouchEvent(ViewInner.java:24) 3 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043) 4 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727) 5 at com.example.demos.customviewdemo.ViewGroupMiddle.dispatchTouchEvent(ViewGroupMiddle.java:23) 6 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043) 7 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727) 8 at com.example.demos.customviewdemo.ViewGroupOuter.dispatchTouchEvent(ViewGroupOuter.java:23) 9 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043) 10 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727) 11 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043) 12 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727) 13 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043) 14 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727) 15 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043) 16 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727) 17 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043) 18 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727) 19 at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3043) 20 at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2727) 21 at com.android.internal.policy.DecorView.superDispatchTouchEvent(DecorView.java:526) 22 at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1830) 23 at android.app.Activity.dispatchTouchEvent(Activity.java:3410) 24 at com.example.demos.customviewdemo.EventDemoActivity.dispatchTouchEvent(EventDemoActivity.java:37) 25 at android.support.v7.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:68) 26 at com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:475) 27 at android.view.View.dispatchPointerEvent(View.java:12768) 28 at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:5455) 29 at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:5258) 30 at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4766) 31 at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:4819) 32 at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:4785) 33 at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:4934) 34 at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:4793) 35 at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:4991) 36 at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4766) 37 at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:4819) 38 at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:4785) 39 at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:4793) 40 at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:4766) 41 at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:7490) 42 at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:7448) 43 at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:7409) 44 at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:7593) 45 at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:199) 46 at android.os.MessageQueue.nativePollOnce(Native Method) 47 at android.os.MessageQueue.next(MessageQueue.java:326) 48 at android.os.Looper.loop(Looper.java:165) 49 at android.app.ActivityThread.main(ActivityThread.java:7477) 50 at java.lang.reflect.Method.invoke(Native Method) 51 at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:500) 52 at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:865)
實際上，Android輸入事件的源頭是位於/dev/input/下的設備節點，而輸入事件的終點是由WMS管理的某個窗口，最終由窗口中的View處理。最初的輸入事件為內核生成的原始事件，而最終交付給窗口的則是KeyEvent（鍵盤）或MotionEvent（鼠標和觸摸屏）對象。上述log中（從下往上看），用三種顏色標注了3個階段：紅色部分表示底層活動，這里我們看到了不少熟悉的身影，ZygoteInit，ActivityThread，Native Method等；綠色部分第45行的InputEventReceiver.dispatchInputEvent(）方法，事件通過該方法由Native層進入到Java層，並傳遞到Activity中，這里我們也看到了不少熟悉的身影，ViewRootImpl，DecorView等；從第24行開始，就是我們前面熟悉的，從Acitivty開始調用dispatchTouchEvent一層層來分發事件。可能讀者看到從第20~9行會有疑惑，為什么中間還有這么多過程？如果了解Android的View層次結構的話就會知道，在DecorView和開發者定義的布局（如ViewGroupOuter）之間，隔着很多層ViewGroup，也需要一層層傳遞，這一點我在本系列第一篇【【朝花夕拾】Android自定義View篇之（一）View繪制流程】【后面簡稱（一）】的第二節做過講解，不明白的可以先去看看。
本文的重點是從Activity開始的事件分發，至於前面從底層到Activity的事件流程，咱們這里做一定的了解即可，有興趣的可以自行研究。
二、事件從Activity到View體系
在上一篇文章的代碼示例中，我們的Boss——EventDemoActivity類中有如下代碼
1 //=============Boss:EventDemoActivity.java============ 2 @Override 3 public boolean dispatchTouchEvent(MotionEvent ev) { 4 Log.i("songzheweiwang", "[EventDemoActivity-->dispatchTouchEvent]ev=" + EventUtil.parseAction(ev.getAction())); 5 return super.dispatchTouchEvent(ev); 6 } 7 8 @Override 9 public boolean onTouchEvent(MotionEvent event) { 10 Log.i("songzheweiwang", "[EventDemoActivity-->onTouchEvent]event=" + EventUtil.parseAction(event.getAction())); 11 return super.onTouchEvent(event); 12 }
Activity是事件的起點，dispatchTouchEvent又是整個邏輯中最早分發事件的地方。但是Activity並不是View體系中的一員，那它是怎樣把事件分發到View體系中的呢？追蹤super.dispatchTouchEvent方法，進入到Activity.java的方法中：
1 //==========================Activity.java======================= 2 /** 3 * Called to process touch screen events. You can override this to 4 * intercept all touch screen events before they are dispatched to the 5 * window. Be sure to call this implementation for touch screen events 6 * that should be handled normally. 7 * 8 * @param ev The touch screen event. 9 * 10 * @return boolean Return true if this event was consumed. 11 */ 12 public boolean dispatchTouchEvent(MotionEvent ev) { 13 if (ev.getAction() == MotionEvent.ACTION_DOWN) { 14 onUserInteraction(); 15 } 16 if (getWindow().superDispatchTouchEvent(ev)) { 17 return true; 18 } 19 return onTouchEvent(ev); 20 }
如注釋中所說，在事件分發到window之前，可以重寫這個方法來攔截所有的屏幕事件，如果事件被消費了，這個方法會返回true。這個方法咱們只關注第15~18行。第15行中如果getWindow().superDispatchTouchEvent值為true，表示后續的View體系把事件消費了，那么執行第16行，直接返回true了，后面該Activity的onTouchEvent方法就不再執行了。如果其值為false，則表示事件沒有被消費，那該Activity就調用自己的onTouchEvent來消費該事件。這一點，在上一篇文章中多份log都體現了這個結論。當然我們還是需要繼續看看getWindow().superDispatchTouchEvent是如何實現的。
其主要代碼如下：
1 //=================Activity.java================= 2 ...... 3 private Window mWindow; 4 ...... 5 public Window getWindow() { 6 return mWindow; 7 } 8 ...... 9 10 //================Window.java================ 11 /** 12 * ...... 13 * <p>The only existing implementation of this abstract class is 14 * android.view.PhoneWindow, which you should instantiate when needing a 15 * Window. 16 */ 17 public abstract class Window { 18 ...... 19 public abstract boolean superDispatchTouchEvent(MotionEvent event); 20 ...... 21 }
superDispatchTouchEvent在Window.java中是個抽象方法，需要在實現類中來實現。如注釋所說，PhoneWindow是該抽象類唯一存在的實現類，所以我們追蹤到PhoneWindow中。
1 //=============PhoneWindow.java========== 2 ...... 3 // This is the top-level view of the window, containing the window decor. 4 private DecorView mDecor; 5 ...... 6 @Override 7 public boolean superDispatchTouchEvent(MotionEvent event) { 8 return mDecor.superDispatchTouchEvent(event); 9 } 10 11 //===========DecorView.java========== 12 ...... 13 public boolean superDispatchTouchEvent(MotionEvent event) { 14 return super.dispatchTouchEvent(event); 15 } 16 .... 17 18 //========ViewGroup.java======= 19 @Override 20 public boolean dispatchTouchEvent(MotionEvent ev) { 21 ...... 22 }
在本系列第一篇文章【（一）】中，對DecorView做過講解，如果有看過這篇文章，那么此時看到如上代碼，就不會陌生了。DecorView是整個View體系的根view，它是一個ViewGroup，所以事件流程就進入到ViewGroup中的dispatchTouchEvent中了。通過上述流程，Activity就通過dispatchTouchEvent將事件分發到View體系中來了。
如果View體系沒有消費掉事件，就會調用Activity自己的onTouchEvent方法，看看其源碼。
1 /** 2 * Called when a touch screen event was not handled by any of the views 3 * under it. This is most useful to process touch events that happen 4 * outside of your window bounds, where there is no view to receive it. 5 * 6 * @param event The touch screen event being processed. 7 * 8 * @return Return true if you have consumed the event, false if you haven't. 9 * The default implementation always returns false. 10 */ 11 public boolean onTouchEvent(MotionEvent event) { 12 if (mWindow.shouldCloseOnTouch(this, event)) { 13 finish(); 14 return true; 15 } 16 return false; 17 }
這里注釋說得非常明確了：當它下面的所有view都沒有處理掉屏幕觸摸事件時，Activity中的這個方法會調用。當觸摸事件發生在window邊界以外的地方時，這個方法尤為有用，因為這些地方，沒有view來接收這個事件。【（五）】的第三點中有個模型圖，當觸摸白色的Boss區域時，下面三個區域中的view接收不到觸摸事件，所以最后只有Activity中的onTouchEvent響應了，【（五）】的第六節中log可以明確這一點。如果您消費了這個事件，返回true；消費不了，則返回false，默認的實現，總是返回false。這一點好理解，Boss嘛，只安排底下的員工干活，自己絕不會動手，就算他們干不了，把事件返回到Boss這里，自己也不會處理的。這里可以改動EventDemoActivity.java中重寫的onTouchEvent方法來驗證一下：
1 @Override 2 public boolean onTouchEvent(MotionEvent event) { 3 boolean b = super.onTouchEvent(event); 4 Log.i("songzheweiwang", "[EventDemoActivity-->onTouchEvent]event=" + EventUtil.parseAction(event.getAction())+";b="+b); 5 return b; 6 }
最終發現，打印的log中，b值總是false。
到這里，Activity中的兩個重要方法就講完了，后面再來看看事件從Activity分發到View體系后，事件流程是如何在其中一層層分發和處理的。
三、葉子View的事件處理邏輯
控件分為兩種：一種是容器類控件，即繼承自ViewGroup，如LinearLayout等；一種是葉子View，View的派生類，如TextView，Button等。與之對應，處理事件分發也分為兩種情形：一種是ViewGroup處理事件分發；另一種是View處理事件邏輯。ViewGroup會遞歸遍歷子View，如果是葉子View也會調用到View中的dispatchTouchEvent方法。所以，這里咱們先從葉子View處理事件開始分析。
1、葉子View處理事件常見的若干場景
（1）onTouch、onTouchEvent和onClick方法執行順序問題
我們工作中經常需要為控件設置監聽Touch事件和Click事件。這里對【（五）】中的實例代碼做一點改動，為ViewInner控件添加觸摸事件和點擊事件，如下所示：
1 //===========EventDemoActivity========== 2 ViewInner mViewInner = findViewById(R.id.viewInner); 3 mViewInner.setOnClickListener(new View.OnClickListener() { 4 @Override 5 public void onClick(View v) { 6 Log.i("songzheweiwang-2", "[EventDemoActivity-->onclick]"); 7 } 8 }); 9 mViewInner.setOnTouchListener(new View.OnTouchListener() { 10 @Override 11 public boolean onTouch(View v, MotionEvent event) { 12 Log.i("songzheweiwang-2", "[EventDemoActivity-->onTouch]event="+EventUtil.parseAction(event.getAction())); 13 return false; 14 } 15 });
點擊ViewInner控件后得到如下log：
1 06-14 01:19:59.246 25518-25518/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_DOWN 2 06-14 01:19:59.246 25518-25518/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN 3 06-14 01:19:59.277 25518-25518/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_UP 4 06-14 01:19:59.277 25518-25518/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP 5 06-14 01:19:59.278 25518-25518/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onclick]
我們發現，從執行順序上看，onTouch > onTouchEvent > onClick，並且onTouch方法執行了兩次，onClick在ACTION_UP之后才被執行。
（2）onTouch返回true的場景
另外，我們發現，oTouch是一個boolean型方法，默認返回的是false。如果將其返回值該為true，結果又怎樣呢？
1 06-14 01:59:00.487 25760-25760/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_DOWN
2 06-14 01:59:00.492 25760-25760/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_UP
打印log發現，onTouchEvent和onClick方法都沒有執行。
（3）控件設置clickable=“false”的場景
在【（五）】中我們講過，如果控件的clickable屬性為false，那么它是無法消費觸摸事件的。這里加上Touch和Click事件后，情形如何呢？
1 06-14 02:15:50.279 26161-26161/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_DOWN 2 06-14 02:15:50.279 26161-26161/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN 3 06-14 02:15:50.328 26161-26161/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onTouch]event=ACTION_UP 4 06-14 02:15:50.328 26161-26161/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP 5 06-14 02:15:50.330 26161-26161/com.example.demos I/songzheweiwang-2: [EventDemoActivity-->onclick]
這里發現和clickable為true時打印的log一樣，也就是說，此時clickable=“false”失效了，這是什么原因呢？
（4）控件設置setEnable(false)時的場景
默認情況下，控件都是enable的，如果給控件執行setEnable(false)，結果會怎樣呢？
1 06-14 02:19:56.369 26359-26359/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN
2 06-14 02:19:56.401 26359-26359/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP
發現onTouch和onClick都沒有執行。為什么？
上面4種場景是工作中經常會碰到的與事件相關的場景，下面我們從源碼的角度來分析其原因。
2、View.dispatchTouchEvent方法
View類中用於處理事件分發邏輯的兩個主要方法是dispatchTouchEvent和onTouchEvent，前者是事件分發到該控件時最先執行的方法，先分析這個方法。
1 //=========================View.java================== 2 /** 3 * Pass the touch screen motion event down to the target view, or this 4 * view if it is the target. 5 * ...... 6 * @return True if the event was handled by the view, false otherwise. 7 */ 8 public boolean dispatchTouchEvent(MotionEvent event) { 9 ...... 10 boolean result = false; 11 ...... 12 if (onFilterTouchEventForSecurity(event)) { 13 ...... 14 //noinspection SimplifiableIfStatement 15 ListenerInfo li = mListenerInfo; 16 if (li != null && li.mOnTouchListener != null 17 && (mViewFlags & ENABLED_MASK) == ENABLED 18 && li.mOnTouchListener.onTouch(this, event)) { 19 result = true; 20 } 21 if (!result && onTouchEvent(event)) { 22 result = true; 23 } 24 } 25 ...... 26 return result; 27 }
先看注釋：將屏幕動作事件傳遞給目標view，如果自己就是這個目標則將事件傳給自己。如果這個事件被該目標view處理了，會返回true，否則會返回false。當ViewInner被觸摸時，會執行到這里。
第11行有個if語句判斷，它的作用是為了安全判斷當前TouchEvent是否被過濾掉了，比如該控件不在最頂部，被其它控件遮住了等情形。如果被過濾了，該方法就會返回false，事件沒有被消費。我們前面的幾種場景下，該函數返回的都是true。第16~18行中有多個判斷條件，我們來看看這些條件：
1 //============View.java=========== 2 static class ListenerInfo { 3 ...... 4 private OnTouchListener mOnTouchListener; 5 ...... 6 } 7 8 /** 9 * Register a callback to be invoked when a touch event is sent to this view. 10 * @param l the touch listener to attach to this view 11 */ 12 public void setOnTouchListener(OnTouchListener l) { 13 getListenerInfo().mOnTouchListener = l; 14 }
前面在EventDemoActivity類中ViewInner調用了該方法，並設置了OnTouchListener，所以li.mOnTouchListener的值這里不是null。(mViewFlags & ENABLED_MASK) == ENABLED表示該view是enable的，默認情況下控件都是enable；li.mOnTouchListener.onTouch(this, event)，就是我們EventDemoActivity中ViewInner的onTouch方法的返回值，默認是返回falsle。所以會跳出該if判斷，進入到第21行。由於前面的if條件為false，所以這里result的值還是false，后面那個條件就開始執行onTouchEvent方法了。如果事件被處理了，onTouchEvent會返回true，返回的result值也就為true了，這個事件就完美處理掉了；如果沒有處理掉，onTouchEvent就返回false，那返回值result自然就是false了，事件沒有被處理掉。所以此時，onTouchEvent方法都是執行了的。如果在onTouch方法中返回了true，那么第16行的判斷條件就是true了，此時result被賦值為true，那么第21行的onTouchEvent方法就沒有機會執行了，這就是咱們前面說的第（2）種場景“onTouch返回true的場景”了。這種情形下，dispatchTouchEvent返回true，事件也被處理掉了。這里給一個結論：當控件是enable的時候，如果onTouch事件返回true，onTouchEvent和onClick方法均不會執行，且事件仍會被消費。下面，我們再看看onTouchEvent方法的源碼。
3、View.onTouchEvent方法
方法很長，這里選取比較關鍵的代碼進行分析。
1 /** 2 * Implement this method to handle touch screen motion events. 3 * ...... 4 * @return True if the event was handled, false otherwise. 5 */ 6 public boolean onTouchEvent(MotionEvent event) { 7 ...... 8 final int action = event.getAction(); 9 final boolean clickable = ((viewFlags & CLICKABLE) == CLICKABLE 10 || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE) 11 || (viewFlags & CONTEXT_CLICKABLE) == CONTEXT_CLICKABLE; 12 if ((viewFlags & ENABLED_MASK) == DISABLED) { 13 if (action == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) { 14 setPressed(false); 15 } 16 mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN; 17 // A disabled view that is clickable still consumes the touch 18 // events, it just doesn't respond to them. 19 return clickable; 20 } 21 ...... 22 if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) { 23 switch (action) { 24 case MotionEvent.ACTION_UP: 25 ...... 26 // Use a Runnable and post this rather than calling 27 // performClick directly. This lets other visual state 28 // of the view update before click actions start. 29 if (mPerformClick == null) { 30 mPerformClick = new PerformClick(); 31 } 32 if (!post(mPerformClick)) { 33 performClick(); 34 } 35 ...... 36 break; 37 case MotionEvent.ACTION_DOWN: 38 ...... 39 break; 40 case MotionEvent.ACTION_CANCEL: 41 ...... 42 break; 43 case MotionEvent.ACTION_MOVE: 44 ...... 45 break; 46 } 47 return true; 48 } 49 return false; 50 }
看看注釋：實現該方法來處理屏幕觸摸事件，如果處理了就返回true，否則返回false。這里需要對比一下dispatchTouchEvent的注釋，它的關鍵字是“pass”，而onTouchEvent的關鍵字是“handle”，這里可以區別兩者的作用。
第9行中的clickable值，前說過，有的控件默認是true，有的則是false。控件的flag為可以一般點擊和長按，都表示是可點擊的。第12行中，如果控件為disable的，即調用了setEnable(false)時，這里就return了，該方法后面的流程就結束了。如果該控件是可點擊的，即clickable的值為true，那onTouchEvent返回的就是true，事件仍然被消費了；反之，控件不可點擊，那返回的就是false，事件沒有被消費，傳遞到上一級的onTouchEvent方法中，這一點我們在【（五）】中有講過。第17、18行的注釋也明確說明了：一個可以點擊的disable的控件，仍然可以消費觸摸事件，只不過它不能回應這些控件。
第22行的第二個條件，tooltip的說明如下：
1 //=========================View.java==================== 2 1 /** 3 2 * <p>Indicates this view can display a tooltip on hover or long press.</p> 4 3 * {@hide} 5 4 */ 6 5 static final int TOOLTIP = 0x40000000;
這是一種比較特殊的用途，這里不繼續深究，我們平時的使用以及這里demo中沒有使用該功能。所以咱們這里只考慮第一個條件。
能夠走到第22行，說明該控件是enable的。如果該控件是不可點擊的，那么這個if語句就跳過去了，返回false，此時前面的dispatchTouchEvent方法返回的也一定是false了，說明該控件沒有消費掉事件。相反，如果是可點擊的，可以看到，后面一定是會返回true的，那么事件就能被消費了。到這里，結合第19行和dispatchTouchEvent方法，我們可以得到一個結論：如果控件是clickable且沒有被過濾的，那么這個控件一定是可以消費掉事件的。在ACTION_UP的時候，會走到第29行。這里我們需要關注一下PerformClick類，其源碼如下：
1 private final class PerformClick implements Runnable { 2 @Override 3 public void run() { 4 performClick(); 5 } 6 }
而第32行的post方法，本質上就是一個Handler發的post，所以第32、33行是一定要執行performClick()方法的。我們着重看一看這個方法：
1 //====================View.java================ 2 /** 3 * Call this view's OnClickListener, if it is defined. Performs all normal 4 * actions associated with clicking: reporting accessibility event, playing 5 * a sound, etc. 6 * 7 * @return True there was an assigned OnClickListener that was called, false 8 * otherwise is returned. 9 */ 10 public boolean performClick() { 11 final boolean result; 12 final ListenerInfo li = mListenerInfo; 13 if (li != null && li.mOnClickListener != null) { 14 playSoundEffect(SoundEffectConstants.CLICK); 15 li.mOnClickListener.onClick(this); 16 result = true; 17 } else { 18 result = false; 19 } 20 ...... 21 return result; 22 }
這個方法就是用來執行點擊相關的工作的，第13行播放點擊音效，第14行響應點擊事件等。
1 //===============View.java============= 2 static class ListenerInfo { 3 ...... 4 public OnClickListener mOnClickListener; 5 ...... 6 } 7 ...... 8 /** 9 * Register a callback to be invoked when this view is clicked. If this view is not 10 * clickable, it becomes clickable. 11 * 12 * @param l The callback that will run 13 * 14 * @see #setClickable(boolean) 15 */ 16 public void setOnClickListener(@Nullable OnClickListener l) { 17 if (!isClickable()) { 18 setClickable(true); 19 } 20 getListenerInfo().mOnClickListener = l; 21 }
我們在EventDemoActivity中ViewInner通過該方法設置了OnClickListener，所以EventDemoActivity中的onClick方法在這里就被調用了，此時點擊事件就產生了。我們可以看到，點擊事件是發生在onTouchEvent方法的ACTION_UP事件中的。這里結合前面講的onTouch方法，就可以解釋場景（1）“onTouch、onTouchEvent和onClick方法執行順序問題”了：onTouch > onTouchEvent > onClick，並且要在ACTION_UP后才會有onClick。在setOnClickListener方法中第17、18行，我們還可以看到，如果這個控件本身不是clickable的，也會先讓它變成clickable的。所以，只要控件調用了setOnClickListener方法，那么之前設置的clickable=“false”就會失效。這里就解釋了場景（3）“控件設置clickable=“false”的場景”。此時，我們返回去看看onTouchEvent方法的第19行，就會發現，即使控件是enable的，由於我們設置了點擊事件監聽，所以這里是返回true的，事件仍然被消費了，再結合前面dispatchTouchEvent的第17行，就能夠解釋場景（4）“控件設置setEnable(false)時的場景”下，沒有執行onTouch和onClick方法，但onTouchEvent方法仍然消費了事件。
這里對關鍵的源碼進行了詳細的講解，且對前面提到的幾種常見的現象，從源碼角度進行了解釋，希望通過這些來加深對View事件分發的認識和理解。關於View中事件的分發，要講的就是這些了。
四、ViewGroup事件分發處理解析
ViewGroup中處理事件邏輯的方法有兩個，分別是dispatchTouchEvent和onInterceptTouchEvent。當一個ViewGroup控件收到上一級傳遞來的事件時，也是先經過dispatchTouchEvent處理。咱們先看看該方法的源碼，該方法很長，這里僅截取了其中關鍵流程的代碼：
1 //=========================ViewGroup.java======================== 2 @Override 3 public boolean dispatchTouchEvent(MotionEvent ev) { 4 ...... 5 boolean handled = false; 6 //該判斷條件在View的dispatchTouchEvent部分講過，這個方法用於判斷控件是否被遮擋。 7 if (onFilterTouchEventForSecurity(ev)) { 8 final int action = ev.getAction(); 9 final int actionMasked = action & MotionEvent.ACTION_MASK; 10 // Handle an initial down. 11 if (actionMasked == MotionEvent.ACTION_DOWN) { 12 // Throw away all previous state when starting a new touch gesture. 13 // The framework may have dropped the up or cancel event for the previous gesture 14 // due to an app switch, ANR, or some other state change. 15 /**當開始一個新的觸摸時，這兩句會清除掉以前的狀態， 16 * 清除FLAG_DISALLOW_INTERCEPT設置， 17 * 代碼中還會執行mFirstTouchTarget = null 18 */ 19 cancelAndClearTouchTargets(ev); 20 resetTouchState(); 21 } 22 // Check for interception. 23 final boolean intercepted; 24 /**事件由子View去處理時mFirstTouchTarget會賦值並指向子View。 25 * mFirstTouchTarget != null表示事件由子View來處理; 26 * mFirstTouchTarget = null表示事件由自己處理 27 */ 28 if (actionMasked == MotionEvent.ACTION_DOWN 29 || mFirstTouchTarget != null) { 30 /**FLAG_DISALLOW_INTERCEPT是子View通過requestDisallowInterceptTouchEvent(true)來設置的 31 * disallowIntercept等同於表示是否調用了該方法。 32 */ 33 final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0; 34 if (!disallowIntercept) { 35 //子View通過onInterceptTouchEvent來判斷是否需要攔截。 36 intercepted = onInterceptTouchEvent(ev); 37 ev.setAction(action); // restore action in case it was changed 38 } else { 39 intercepted = false; 40 } 41 } else { 42 // There are no touch targets and this action is not an initial down 43 // so this view group continues to intercept touches. 44 //沒有找到處理事件的子View，並且這個action不是ACTION_DOWN，所以該View開始攔截觸摸事件。 45 intercepted = true; 46 } 47 ...... 48 //如果事件沒有取消且沒有被攔截 49 if (!canceled && !intercepted) { 50 ...... 51 //尋找能夠接收該事件的View 52 for (int i = childrenCount - 1; i >= 0; i--) { 53 ...... 54 final View child = getAndVerifyPreorderedView( 55 preorderedList, children, childIndex); 56 ...... 57 /**這兩個判斷條件分別為1、View可見並且沒有播放動畫； 58 * 2、點擊事件的坐標在View的范圍內。 59 * 如果其中一個條件不滿足，就進行下一次循環。 60 */ 61 if (!canViewReceivePointerEvents(child) 62 || !isTransformedTouchPointInView(x, y, child, null)) { 63 ev.setTargetAccessibilityFocus(false); 64 continue; 65 } 66 ...... 67 //true表示找到了子View來處理事件，false表示沒有子View來處理。 68 if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) 69 // Child wants to receive touch within its bounds. 70 ...... 71 //addTouchTarget方法中，會給mFirstTouchTarget賦值。 72 newTouchTarget = addTouchTarget(child, idBitsToAssign); 73 ...... 74 break; 75 } 76 ...... 77 } 78 } 79 //沒有找到可以處理事件的子View，需要自身來處理。 80 if (mFirstTouchTarget == null) { 81 // No touch targets so treat this as an ordinary view. 82 handled = dispatchTransformedTouchEvent(ev, canceled, null, 83 TouchTarget.ALL_POINTER_IDS); 84 } else { 85 ...... 86 //這里有一部分源碼暫時沒有讀懂 87 } 88 ...... 89 } 90 ...... 91 return handled; 92 }
代碼中梳理出了關鍵的流程，並對幾處要點做了一些注釋說明，咱們這里再解讀一下這段代碼：
（1）第11行中，當一個新的事件開始時，即ACTION_DOWN觸發時，會進行初始化，清理掉之前的一些狀態，這一點很容易理解。
（2）第24~27行對字段mFirstTouchTarget進行了簡單的說明，這里不再贅述了，后面幾個關鍵點需要用到這個字段來進行判斷。
（3）第28行，如果是ACTION_DOWN事件或者其它事件下找到了處理事件的子View時，會進入到該方法中。
（4）第30~33行，主要是FLAG_DISALLOW_INTERCEPT相關。這里需要簡單介紹一下requestDisallowInterceptTouchEvent(boolean disallowIntercept)方法，該方法用於子View請求父View，不讓父View攔截，即讓父View的onInterceptTouchEvent方法返回true時，失效。在沒有調用該方法時，默認其參數為false，即requestDisallowInterceptTouchEvent(false)效果等同於沒有調用該方法。FLAG_DISALLOW_INTERCEPT的標志位就是通過該方法來進行設置的。該方法對除ACTION_DOWN之外的事件有效，對ACTION_DOWN事件無效，在第12~20行中講過，ACTION_DOWN時，會清除之前狀態，FLAG_DISALLOW_INTERCEPT標志位也被恢復。這里簡單演示一下該方法的使用：
首先在ViewGroupMiddle類中修改onInterceptTouchEvent為以下代碼，ViewInner中先不做修改，且為了做對比，要讓ViewInner添加clickable=“true”，能夠消費事件：
1 //===========ViewGroupMiddle.java=========== 2 @Override 3 public boolean onInterceptTouchEvent(MotionEvent ev) { 4 Log.i("songzheweiwang-2", "[ViewGroupMiddle-->onInterceptTouchEvent]ev=" + EventUtil.parseAction(ev.getAction())); 5 switch (ev.getAction()) { 6 case MotionEvent.ACTION_DOWN: 7 return false; 8 default: 9 return true; 10 } 11 }
查看log為：
06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_DOWN 06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->onInterceptTouchEvent]ev=ACTION_DOWN 06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_DOWN 06-12 00:21:27.800 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN 06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_UP 06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->onInterceptTouchEvent]ev=ACTION_UP 06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_CANCEL 06-12 00:21:27.832 6906-6906/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_CANCEL
ACTION_DOWN沒有被攔截，正常傳遞到了ViewInner中，而其他事件卻被攔截了。這里還可以看到，一個完整的事件，如果只有ACTION_DOWN，卻沒有ACTION_UP，最終會觸發ACTION_CANCEL。
現在在ViewInner類的onTouchEvent方法中調用getParent().requestDisallowInterceptTouchEvent(true)方法，如下所示：
1 //=============ViewInner.java============= 2 @Override 3 public boolean onTouchEvent(MotionEvent event) { 4 Log.i("songzheweiwang-2","[ViewInner-->onTouchEvent]event="+EventUtil.parseAction(event.getAction())); 5 getParent().requestDisallowInterceptTouchEvent(true); 6 return super.onTouchEvent(event); 7 }
之所以要在ViewGroup類中不攔截ACTION_DOWN事件，是因為如果這里攔截了，ViewInner中的方法就不會執行了，第5行的代碼也自然起不到效果。得到的log如下：
1 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_DOWN 2 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->onInterceptTouchEvent]ev=ACTION_DOWN 3 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_DOWN 4 06-12 00:37:24.505 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_DOWN 5 06-12 00:37:24.524 7509-7509/com.example.demos I/songzheweiwang-2: [ViewGroupMiddle-->dispatchTouchEvent]ev=ACTION_UP 6 06-12 00:37:24.524 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->dispatchTouchEvent]event=ACTION_UP 7 06-12 00:37:24.524 7509-7509/com.example.demos I/songzheweiwang-2: [ViewInner-->onTouchEvent]event=ACTION_UP
可以看到，ACTION_UP事件在ViewInner中正常執行了。所以在第33行的disallowIntercept變量值，在調用該方法且當前事件不是ACTION_DOWN時（因為會清除掉該方法的效果），其值為true，反之則為false。在這里，可以看到，由於調用了該方法，所以在ACTION_UP事件中，ViewGroupMiddle中的onInterceptTouchEvent方法沒有執行了。
該方法在日常解決事件沖突時經常會用到，所以這里花了一點篇幅來講解了一下該方法。
（5）第36行中，調用了onInterceptTouchEvent方法。這個方法我們在【（五）】中提到無數遍了，這里總算看到了它的身影。自然，這里一定要去看看其源碼。
1 //=================ViewGroup.java============= 2 public boolean onInterceptTouchEvent(MotionEvent ev) { 3 if (ev.isFromSource(InputDevice.SOURCE_MOUSE) 4 && ev.getAction() == MotionEvent.ACTION_DOWN 5 && ev.isButtonPressed(MotionEvent.BUTTON_PRIMARY) 6 && isOnScrollbarThumb(ev.getX(), ev.getY())) { 7 return true; 8 } 9 return false; 10 }
What？這么簡單？if語句看起來是和鼠標有關系的，貌似和咱們的示例及平時使用沒有半毛錢的關系，所以除去這個判斷語句，其實就只有第8行的代碼了。這里，在【（五）】中講過，對於重寫的onInterceptTouchEvent方法，返回false和返回默認的super.onInterceptTouchEvent，結果是一樣的。
（6）第28~46行就確定了是否需要對事件進行攔截了。這里也可以明確看到，onInterceptTouchEvent方法，不一定每次都會被調用了。這里我們在【（五）】中也多次看到這種情形。
（7）第49行中，我們關注后面這個條件，在沒有被攔截的情況下才會進入這個if語句內部。它的主要作用就是遞歸遍歷其子view，找到可以接收該事件的view。這里重點需要關注的是第68行的dispatchTransformedTouchEvent方法。這個方法我們在第一節的log中就多次看到過，在ViewGroup中它和dispatchTouchEvent方法總是成對出現的。它的源碼如下：
1 //===============ViewGroup.java============== 2 private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel, 3 View child, int desiredPointerIdBits) { 4 final boolean handled; 5 ...... 6 //transformedEvent是對event的加工處理 7 if (child == null) { 8 handled = super.dispatchTouchEvent(transformedEvent); 9 } else { 10 ...... 11 handled = child.dispatchTouchEvent(transformedEvent); 12 } 13 return handle; 14 }
這里傳入的child參數是有值的，不是null，所以會調用第10行，進行遞歸。當遍歷到葉子View的時候，就跳轉到View類中的diapatchTouchEvent方法中了，我們前面已經講解過了。所以，如果找到了處理事件的view了，handle就是true，該方法返回true，就會跳出for循環，不再需要便利了，否則繼續便利。這里面有個addTouchTarget方法，其中會對mFirstTouchTarge進行賦值，說明找到了處理事件的子View，如果沒找到，這個值會一直為null。
（8）第79~83行，既然前面沒有找到可以處理該事件的子view，那么就只能自己來接手該事件了。第82行，第三個參數傳入的是nul，所以該方法體中就會執行第7行。ViewGroup的父類是View，所以會走到View類中，走View處理事件的邏輯了，這里也需要注意，不要混淆父類和父控件了。而如果子View能夠處理該事件，那后面當前ViewGroup控件就和這個事件沒啥關系了。現在，我們也就能夠解釋【（五）】中的很多現象了，如：ViewInner無法消費掉事件時，ViewGroupMiddle會回調自身的onTouchEvent方法；如果ViewInner消費了當前的事件，那么本次事件就不會再返回到上級控件了。
（9）最后該方法的返回值仍然是，如果返回true，那么表示事件被消費了，否則返回false。
ViewGroup類中重點需要關注的方法就講完了，其實主要就是dispatchTouchEvent方法的邏輯。現在我們應該可以理解，在【（五）】在各種現象和結論了吧。
五、參考文章
【Android事件分發機制完全解析，帶你從源碼的角度徹底理解(上)】
【Android事件分發機制完全解析，帶你從源碼的角度徹底理解(下)】
結語
Android的View事件傳遞機制的源碼分析，到這里就講完了，不知道本文中提到的一些場景，是不是也曾經困擾過讀者呢？當然，筆者這里只是抓取了主要的關鍵流程和方法進行了講解，真實的源碼邏輯遠遠比這要復雜，因為平時會碰到各種不同的情況，比如長按，tip功能的邏輯處理等。總的來說，本文還只不過是登堂入室的開始而已，其中如果有不妥或者不正確的地方，歡迎來拍磚。