天天看點

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(上)

其實我一直準備寫一篇關于Android事件分發機制的文章,從我的第一篇部落格開始,就零零散散在好多地方使用到了Android事件分發的知識。也有好多朋友問過我各種問題,比如:onTouch和onTouchEvent有什麼差別,又該如何使用?為什麼給ListView引入了一個滑動菜單的功能,ListView就不能滾動了?為什麼圖檔輪播器裡的圖檔使用Button而不用ImageView?等等……對于這些問題,我并沒有給出非常詳細的回答,因為我知道如果想要徹底搞明白這些問題,掌握Android事件分發機制是必不可少的,而Android事件分發機制絕對不是三言兩語就能說得清的。

在我經過較長時間的籌備之後,終于決定開始寫這樣一篇文章了。目前雖然網上相關的文章也不少,但我覺得沒有哪篇寫得特别詳細的(也許我還沒有找到),多數文章隻是講了講理論,然後配合demo運作了一下結果。而我準備帶着大家從源碼的角度進行分析,相信大家可以更加深刻地了解Android事件分發機制。

閱讀源碼講究由淺入深,循序漸進,是以我們也從簡單的開始,本篇先帶大家探究View的事件分發,下篇再去探究難度更高的ViewGroup的事件分發。

那我們現在就開始吧!比如說你目前有一個非常簡單的項目,隻有一個Activity,并且Activity中隻有一個按鈕。你可能已經知道,如果想要給這個按鈕注冊一個點選事件,隻需要調用:

[java]  view plain copy

  1. button.setOnClickListener(new OnClickListener() {  
  2.     @Override  
  3.     public void onClick(View v) {  
  4.         Log.d("TAG", "onClick execute");  
  5.     }  
  6. });  

這樣在onClick方法裡面寫實作,就可以在按鈕被點選的時候執行。你可能也已經知道,如果想給這個按鈕再添加一個touch事件,隻需要調用: [java]  view plain copy

  1. button.setOnTouchListener(new OnTouchListener() {  
  2.     @Override  
  3.     public boolean onTouch(View v, MotionEvent event) {  
  4.         Log.d("TAG", "onTouch execute, action " + event.getAction());  
  5.         return false;  
  6.     }  
  7. });  

onTouch方法裡能做的事情比onClick要多一些,比如判斷手指按下、擡起、移動等事件。那麼如果我兩個事件都注冊了,哪一個會先執行呢?我們來試一下就知道了,運作程式點選按鈕,列印結果如下:

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

可以看到,onTouch是優先于onClick執行的,并且onTouch執行了兩次,一次是ACTION_DOWN,一次是ACTION_UP(你還可能會有多次ACTION_MOVE的執行,如果你手抖了一下)。是以事件傳遞的順序是先經過onTouch,再傳遞到onClick。

細心的朋友應該可以注意到,onTouch方法是有傳回值的,這裡我們傳回的是false,如果我們嘗試把onTouch方法裡的傳回值改成true,再運作一次,結果如下:

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

我們發現,onClick方法不再執行了!為什麼會這樣呢?你可以先了解成onTouch方法傳回true就認為這個事件被onTouch消費掉了,因而不會再繼續向下傳遞。

如果到現在為止,以上的所有知識點你都是清楚的,那麼說明你對Android事件傳遞的基本用法應該是掌握了。不過别滿足于現狀,讓我們從源碼的角度分析一下,出現上述現象的原理是什麼。

首先你需要知道一點,隻要你觸摸到了任何一個控件,就一定會調用該控件的dispatchTouchEvent方法。那當我們去點選按鈕的時候,就會去調用Button類裡的dispatchTouchEvent方法,可是你會發現Button類裡并沒有這個方法,那麼就到它的父類TextView裡去找一找,你會發現TextView裡也沒有這個方法,那沒辦法了,隻好繼續在TextView的父類View裡找一找,這個時候你終于在View裡找到了這個方法,示意圖如下:

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

然後我們來看一下View中dispatchTouchEvent方法的源碼:

[java]  view plain copy

  1. public boolean dispatchTouchEvent(MotionEvent event) {  
  2.     if (mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED &&  
  3.             mOnTouchListener.onTouch(this, event)) {  
  4.         return true;  
  5.     }  
  6.     return onTouchEvent(event);  
  7. }  

這個方法非常的簡潔,隻有短短幾行代碼!我們可以看到,在這個方法内,首先是進行了一個判斷,如果mOnTouchListener != null,(mViewFlags & ENABLED_MASK) == ENABLED和mOnTouchListener.onTouch(this, event)這三個條件都為真,就傳回true,否則就去執行onTouchEvent(event)方法并傳回。

先看一下第一個條件,mOnTouchListener這個變量是在哪裡指派的呢?我們尋找之後在View裡發現了如下方法:

[java]  view plain copy

  1. public void setOnTouchListener(OnTouchListener l) {  
  2.     mOnTouchListener = l;  
  3. }  

Bingo!找到了,mOnTouchListener正是在setOnTouchListener方法裡指派的,也就是說隻要我們給控件注冊了touch事件,mOnTouchListener就一定被指派了。

第二個條件(mViewFlags & ENABLED_MASK) == ENABLED是判斷目前點選的控件是否是enable的,按鈕預設都是enable的,是以這個條件恒定為true。

第三個條件就比較關鍵了,mOnTouchListener.onTouch(this, event),其實也就是去回調控件注冊touch事件時的onTouch方法。也就是說如果我們在onTouch方法裡傳回true,就會讓這三個條件全部成立,進而整個方法直接傳回true。如果我們在onTouch方法裡傳回false,就會再去執行onTouchEvent(event)方法。

現在我們可以結合前面的例子來分析一下了,首先在dispatchTouchEvent中最先執行的就是onTouch方法,是以onTouch肯定是要優先于onClick執行的,也是印證了剛剛的列印結果。而如果在onTouch方法裡傳回了true,就會讓dispatchTouchEvent方法直接傳回true,不會再繼續往下執行。而列印結果也證明了如果onTouch傳回true,onClick就不會再執行了。

根據以上源碼的分析,從原理上解釋了我們前面例子的運作結果。而上面的分析還透漏出了一個重要的資訊,那就是onClick的調用肯定是在onTouchEvent(event)方法中的!那我們馬上來看下onTouchEvent的源碼,如下所示:

[java]  view plain copy

  1. public boolean onTouchEvent(MotionEvent event) {  
  2.     final int viewFlags = mViewFlags;  
  3.     if ((viewFlags & ENABLED_MASK) == DISABLED) {  
  4.         // A disabled view that is clickable still consumes the touch  
  5.         // events, it just doesn't respond to them.  
  6.         return (((viewFlags & CLICKABLE) == CLICKABLE ||  
  7.                 (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE));  
  8.     }  
  9.     if (mTouchDelegate != null) {  
  10.         if (mTouchDelegate.onTouchEvent(event)) {  
  11.             return true;  
  12.         }  
  13.     }  
  14.     if (((viewFlags & CLICKABLE) == CLICKABLE ||  
  15.             (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)) {  
  16.         switch (event.getAction()) {  
  17.             case MotionEvent.ACTION_UP:  
  18.                 boolean prepressed = (mPrivateFlags & PREPRESSED) != 0;  
  19.                 if ((mPrivateFlags & PRESSED) != 0 || prepressed) {  
  20.                     // take focus if we don't have it already and we should in  
  21.                     // touch mode.  
  22.                     boolean focusTaken = false;  
  23.                     if (isFocusable() && isFocusableInTouchMode() && !isFocused()) {  
  24.                         focusTaken = requestFocus();  
  25.                     }  
  26.                     if (!mHasPerformedLongPress) {  
  27.                         // This is a tap, so remove the longpress check  
  28.                         removeLongPressCallback();  
  29.                         // Only perform take click actions if we were in the pressed state  
  30.                         if (!focusTaken) {  
  31.                             // Use a Runnable and post this rather than calling  
  32.                             // performClick directly. This lets other visual state  
  33.                             // of the view update before click actions start.  
  34.                             if (mPerformClick == null) {  
  35.                                 mPerformClick = new PerformClick();  
  36.                             }  
  37.                             if (!post(mPerformClick)) {  
  38.                                 performClick();  
  39.                             }  
  40.                         }  
  41.                     }  
  42.                     if (mUnsetPressedState == null) {  
  43.                         mUnsetPressedState = new UnsetPressedState();  
  44.                     }  
  45.                     if (prepressed) {  
  46.                         mPrivateFlags |= PRESSED;  
  47.                         refreshDrawableState();  
  48.                         postDelayed(mUnsetPressedState,  
  49.                                 ViewConfiguration.getPressedStateDuration());  
  50.                     } else if (!post(mUnsetPressedState)) {  
  51.                         // If the post failed, unpress right now  
  52.                         mUnsetPressedState.run();  
  53.                     }  
  54.                     removeTapCallback();  
  55.                 }  
  56.                 break;  
  57.             case MotionEvent.ACTION_DOWN:  
  58.                 if (mPendingCheckForTap == null) {  
  59.                     mPendingCheckForTap = new CheckForTap();  
  60.                 }  
  61.                 mPrivateFlags |= PREPRESSED;  
  62.                 mHasPerformedLongPress = false;  
  63.                 postDelayed(mPendingCheckForTap, ViewConfiguration.getTapTimeout());  
  64.                 break;  
  65.             case MotionEvent.ACTION_CANCEL:  
  66.                 mPrivateFlags &= ~PRESSED;  
  67.                 refreshDrawableState();  
  68.                 removeTapCallback();  
  69.                 break;  
  70.             case MotionEvent.ACTION_MOVE:  
  71.                 final int x = (int) event.getX();  
  72.                 final int y = (int) event.getY();  
  73.                 // Be lenient about moving outside of buttons  
  74.                 int slop = mTouchSlop;  
  75.                 if ((x < 0 - slop) || (x >= getWidth() + slop) ||  
  76.                         (y < 0 - slop) || (y >= getHeight() + slop)) {  
  77.                     // Outside button  
  78.                     removeTapCallback();  
  79.                     if ((mPrivateFlags & PRESSED) != 0) {  
  80.                         // Remove any future long press/tap checks  
  81.                         removeLongPressCallback();  
  82.                         // Need to switch from pressed to not pressed  
  83.                         mPrivateFlags &= ~PRESSED;  
  84.                         refreshDrawableState();  
  85.                     }  
  86.                 }  
  87.                 break;  
  88.         }  
  89.         return true;  
  90.     }  
  91.     return false;  
  92. }  

相較于剛才的dispatchTouchEvent方法,onTouchEvent方法複雜了很多,不過沒關系,我們隻挑重點看就可以了。

首先在第14行我們可以看出,如果該控件是可以點選的就會進入到第16行的switch判斷中去,而如果目前的事件是擡起手指,則會進入到MotionEvent.ACTION_UP這個case當中。在經過種種判斷之後,會執行到第38行的performClick()方法,那我們進入到這個方法裡瞧一瞧:

[java]  view plain copy

  1. public boolean performClick() {  
  2.     sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED);  
  3.     if (mOnClickListener != null) {  
  4.         playSoundEffect(SoundEffectConstants.CLICK);  
  5.         mOnClickListener.onClick(this);  
  6.         return true;  
  7.     }  
  8.     return false;  
  9. }  

可以看到,隻要mOnClickListener不是null,就會去調用它的onClick方法,那 mOnClickListener又是在哪裡指派的呢?經過尋找後找到如下方法: [java]  view plain copy

  1. public void setOnClickListener(OnClickListener l) {  
  2.     if (!isClickable()) {  
  3.         setClickable(true);  
  4.     }  
  5.     mOnClickListener = l;  
  6. }  

一切都是那麼清楚了!當我們通過調用setOnClickListener方法來給控件注冊一個點選事件時,就會給 mOnClickListener指派。然後每當控件被點選時,都會在performClick()方法裡回調被點選控件的onClick方法。

這樣View的整個事件分發的流程就讓我們搞清楚了!不過别高興的太早,現在還沒結束,還有一個很重要的知識點需要說明,就是touch事件的層級傳遞。我們都知道如果給一個控件注冊了touch事件,每次點選它的時候都會觸發一系列的ACTION_DOWN,ACTION_MOVE,ACTION_UP等事件。這裡需要注意,如果你在執行ACTION_DOWN的時候傳回了false,後面一系列其它的action就不會再得到執行了。簡單的說,就是當dispatchTouchEvent在進行事件分發的時候,隻有前一個action傳回true,才會觸發後一個action。

說到這裡,很多的朋友肯定要有巨大的疑問了。這不是在自相沖突嗎?前面的例子中,明明在onTouch事件裡面傳回了false,ACTION_DOWN和ACTION_UP不是都得到執行了嗎?其實你隻是被假象所迷惑了,讓我們仔細分析一下,在前面的例子當中,我們到底傳回的是什麼。

參考着我們前面分析的源碼,首先在onTouch事件裡傳回了false,就一定會進入到onTouchEvent方法中,然後我們來看一下onTouchEvent方法的細節。由于我們點選了按鈕,就會進入到第14行這個if判斷的内部,然後你會發現,不管目前的action是什麼,最終都一定會走到第89行,傳回一個true。

是不是有一種被欺騙的感覺?明明在onTouch事件裡傳回了false,系統還是在onTouchEvent方法中幫你傳回了true。就因為這個原因,才使得前面的例子中ACTION_UP可以得到執行。

那我們可以換一個控件,将按鈕替換成ImageView,然後給它也注冊一個touch事件,并傳回false。如下所示:

[java]  view plain copy

  1. imageView.setOnTouchListener(new OnTouchListener() {  
  2.     @Override  
  3.     public boolean onTouch(View v, MotionEvent event) {  
  4.         Log.d("TAG", "onTouch execute, action " + event.getAction());  
  5.         return false;  
  6.     }  
  7. });  

運作一下程式,點選ImageView,你會發現結果如下:

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

在ACTION_DOWN執行完後,後面的一系列action都不會得到執行了。這又是為什麼呢?因為ImageView和按鈕不同,它是預設不可點選的,是以在onTouchEvent的第14行判斷時無法進入到if的内部,直接跳到第91行傳回了false,也就導緻後面其它的action都無法執行了。

好了,關于View的事件分發,我想講的東西全都在這裡了。現在我們再來回顧一下開篇時提到的那三個問題,相信每個人都會有更深一層的了解。

1. onTouch和onTouchEvent有什麼差別,又該如何使用?

從源碼中可以看出,這兩個方法都是在View的dispatchTouchEvent中調用的,onTouch優先于onTouchEvent執行。如果在onTouch方法中通過傳回true将事件消費掉,onTouchEvent将不會再執行。

另外需要注意的是,onTouch能夠得到執行需要兩個前提條件,第一mOnTouchListener的值不能為空,第二目前點選的控件必須是enable的。是以如果你有一個控件是非enable的,那麼給它注冊onTouch事件将永遠得不到執行。對于這一類控件,如果我們想要監聽它的touch事件,就必須通過在該控件中重寫onTouchEvent方法來實作。

2. 為什麼給ListView引入了一個滑動菜單的功能,ListView就不能滾動了?

如果你閱讀了Android滑動架構完全解析,教你如何一分鐘實作滑動菜單特效 這篇文章,你應該會知道滑動菜單的功能是通過給ListView注冊了一個touch事件來實作的。如果你在onTouch方法裡處理完了滑動邏輯後傳回true,那麼ListView本身的滾動事件就被屏蔽了,自然也就無法滑動(原理同前面例子中按鈕不能點選),是以解決辦法就是在onTouch方法裡傳回false。

3. 為什麼圖檔輪播器裡的圖檔使用Button而不用ImageView?

提這個問題的朋友是看過了Android實作圖檔滾動控件,含頁簽功能,讓你的應用像淘寶一樣炫起來 這篇文章。當時我在圖檔輪播器裡使用Button,主要就是因為Button是可點選的,而ImageView是不可點選的。如果想要使用ImageView,可以有兩種改法。第一,在ImageView的onTouch方法裡傳回true,這樣可以保證ACTION_DOWN之後的其它action都能得到執行,才能實作圖檔滾動的效果。第二,在布局檔案裡面給ImageView增加一個android:clickable="true"的屬性,這樣ImageView變成可點選的之後,即使在onTouch裡傳回了false,ACTION_DOWN之後的其它action也是可以得到執行的。

今天的講解就到這裡了,相信大家現在對Android事件分發機制又有了進一步的認識,在後面的文章中我會再帶大家一起探究Android中ViewGroup的事件分發機制,感興趣的朋友請繼續閱讀 。

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(下)

記得在前面的文章中,我帶大家一起從源碼的角度分析了Android中View的事件分發機制,相信閱讀過的朋友對View的事件分發已經有比較深刻的了解了。

還未閱讀過的朋友,請先參考 Android事件分發機制完全解析,帶你從源碼的角度徹底了解(上) 。

那麼今天我們将繼續上次未完成的話題,從源碼的角度分析ViewGruop的事件分發。

首先我們來探讨一下,什麼是ViewGroup?它和普通的View有什麼差別?

顧名思義,ViewGroup就是一組View的集合,它包含很多的子View和子VewGroup,是Android中所有布局的父類或間接父類,像LinearLayout、RelativeLayout等都是繼承自ViewGroup的。但ViewGroup實際上也是一個View,隻不過比起View,它多了可以包含子View和定義布局參數的功能。ViewGroup繼承結構示意圖如下所示:

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

可以看到,我們平時項目裡經常用到的各種布局,全都屬于ViewGroup的子類。

簡單介紹完了ViewGroup,我們現在通過一個Demo來示範一下Android中VewGroup的事件分發流程吧。

首先我們來自定義一個布局,命名為MyLayout,繼承自LinearLayout,如下所示:

[java]  view plain copy

  1. public class MyLayout extends LinearLayout {  
  2.     public MyLayout(Context context, AttributeSet attrs) {  
  3.         super(context, attrs);  
  4.     }  
  5. }  

然後,打開主布局檔案activity_main.xml,在其中加入我們自定義的布局:

[html]  view plain copy

  1. <com.example.viewgrouptouchevent.MyLayout xmlns:android="http://schemas.android.com/apk/res/android"  
  2.     xmlns:tools="http://schemas.android.com/tools"  
  3.     android:id="@+id/my_layout"  
  4.     android:layout_width="match_parent"  
  5.     android:layout_height="match_parent"  
  6.     android:orientation="vertical" >  
  7.     <Button  
  8.         android:id="@+id/button1"  
  9.         android:layout_width="match_parent"  
  10.         android:layout_height="wrap_content"  
  11.         android:text="Button1" />  
  12.     <Button  
  13.         android:id="@+id/button2"  
  14.         android:layout_width="match_parent"  
  15.         android:layout_height="wrap_content"  
  16.         android:text="Button2" />  
  17. </com.example.viewgrouptouchevent.MyLayout>  

可以看到,我們在MyLayout中添加了兩個按鈕,接着在MainActivity中為這兩個按鈕和MyLayout都注冊了監聽事件: [java]  view plain copy

  1. myLayout.setOnTouchListener(new OnTouchListener() {  
  2.     @Override  
  3.     public boolean onTouch(View v, MotionEvent event) {  
  4.         Log.d("TAG", "myLayout on touch");  
  5.         return false;  
  6.     }  
  7. });  
  8. button1.setOnClickListener(new OnClickListener() {  
  9.     @Override  
  10.     public void onClick(View v) {  
  11.         Log.d("TAG", "You clicked button1");  
  12.     }  
  13. });  
  14. button2.setOnClickListener(new OnClickListener() {  
  15.     @Override  
  16.     public void onClick(View v) {  
  17.         Log.d("TAG", "You clicked button2");  
  18.     }  
  19. });  

我們在MyLayout的onTouch方法,和Button1、Button2的onClick方法中都列印了一句話。現在運作一下項目,效果圖如下所示:

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

分别點選一下Button1、Button2和空白區域,列印結果如下所示:

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

你會發現,當點選按鈕的時候,MyLayout注冊的onTouch方法并不會執行,隻有點選空白區域的時候才會執行該方法。你可以先了解成Button的onClick方法将事件消費掉了,是以事件不會再繼續向下傳遞。

那就說明Android中的touch事件是先傳遞到View,再傳遞到ViewGroup的?現在下結論還未免過早了,讓我們再來做一個實驗。

查閱文檔可以看到,ViewGroup中有一個onInterceptTouchEvent方法,我們來看一下這個方法的源碼:

[java]  view plain copy

  1. public boolean onInterceptTouchEvent(MotionEvent ev) {  
  2.     return false;  
  3. }  

如果不看源碼你還真可能被這注釋吓到了,這麼長的英文注釋看得頭都大了。可是源碼竟然如此簡單!隻有一行代碼,傳回了一個false!

好吧,既然是布爾型的傳回,那麼隻有兩種可能,我們在MyLayout中重寫這個方法,然後傳回一個true試試,代碼如下所示:

[java]  view plain copy

  1. public class MyLayout extends LinearLayout {  
  2.     public MyLayout(Context context, AttributeSet attrs) {  
  3.         super(context, attrs);  
  4.     }  
  5.     @Override  
  6.     public boolean onInterceptTouchEvent(MotionEvent ev) {  
  7.         return true;  
  8.     }  
  9. }  

現在再次運作項目,然後分别Button1、Button2和空白區域,列印結果如下所示:

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

你會發現,不管你點選哪裡,永遠都隻會觸發MyLayout的touch事件了,按鈕的點選事件完全被屏蔽掉了!這是為什麼呢?如果Android中的touch事件是先傳遞到View,再傳遞到ViewGroup的,那麼MyLayout又怎麼可能屏蔽掉Button的點選事件呢?

看來隻有通過閱讀源碼,搞清楚Android中ViewGroup的事件分發機制,才能解決我們心中的疑惑了,不過這裡我想先跟你透露一句,Android中touch事件的傳遞,絕對是先傳遞到ViewGroup,再傳遞到View的。記得在Android事件分發機制完全解析,帶你從源碼的角度徹底了解(上) 中我有說明過,隻要你觸摸了任何控件,就一定會調用該控件的dispatchTouchEvent方法。這個說法沒錯,隻不過還不完整而已。實際情況是,當你點選了某個控件,首先會去調用該控件所在布局的dispatchTouchEvent方法,然後在布局的dispatchTouchEvent方法中找到被點選的相應控件,再去調用該控件的dispatchTouchEvent方法。如果我們點選了MyLayout中的按鈕,會先去調用MyLayout的dispatchTouchEvent方法,可是你會發現MyLayout中并沒有這個方法。那就再到它的父類LinearLayout中找一找,發現也沒有這個方法。那隻好繼續再找LinearLayout的父類ViewGroup,你終于在ViewGroup中看到了這個方法,按鈕的dispatchTouchEvent方法就是在這裡調用的。修改後的示意圖如下所示:

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

那還等什麼?快去看一看ViewGroup中的dispatchTouchEvent方法的源碼吧!代碼如下所示:

[java]  view plain copy

  1. public boolean dispatchTouchEvent(MotionEvent ev) {  
  2.     final int action = ev.getAction();  
  3.     final float xf = ev.getX();  
  4.     final float yf = ev.getY();  
  5.     final float scrolledXFloat = xf + mScrollX;  
  6.     final float scrolledYFloat = yf + mScrollY;  
  7.     final Rect frame = mTempRect;  
  8.     boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;  
  9.     if (action == MotionEvent.ACTION_DOWN) {  
  10.         if (mMotionTarget != null) {  
  11.             mMotionTarget = null;  
  12.         }  
  13.         if (disallowIntercept || !onInterceptTouchEvent(ev)) {  
  14.             ev.setAction(MotionEvent.ACTION_DOWN);  
  15.             final int scrolledXInt = (int) scrolledXFloat;  
  16.             final int scrolledYInt = (int) scrolledYFloat;  
  17.             final View[] children = mChildren;  
  18.             final int count = mChildrenCount;  
  19.             for (int i = count - 1; i >= 0; i--) {  
  20.                 final View child = children[i];  
  21.                 if ((child.mViewFlags & VISIBILITY_MASK) == VISIBLE  
  22.                         || child.getAnimation() != null) {  
  23.                     child.getHitRect(frame);  
  24.                     if (frame.contains(scrolledXInt, scrolledYInt)) {  
  25.                         final float xc = scrolledXFloat - child.mLeft;  
  26.                         final float yc = scrolledYFloat - child.mTop;  
  27.                         ev.setLocation(xc, yc);  
  28.                         child.mPrivateFlags &= ~CANCEL_NEXT_UP_EVENT;  
  29.                         if (child.dispatchTouchEvent(ev))  {  
  30.                             mMotionTarget = child;  
  31.                             return true;  
  32.                         }  
  33.                     }  
  34.                 }  
  35.             }  
  36.         }  
  37.     }  
  38.     boolean isUpOrCancel = (action == MotionEvent.ACTION_UP) ||  
  39.             (action == MotionEvent.ACTION_CANCEL);  
  40.     if (isUpOrCancel) {  
  41.         mGroupFlags &= ~FLAG_DISALLOW_INTERCEPT;  
  42.     }  
  43.     final View target = mMotionTarget;  
  44.     if (target == null) {  
  45.         ev.setLocation(xf, yf);  
  46.         if ((mPrivateFlags & CANCEL_NEXT_UP_EVENT) != 0) {  
  47.             ev.setAction(MotionEvent.ACTION_CANCEL);  
  48.             mPrivateFlags &= ~CANCEL_NEXT_UP_EVENT;  
  49.         }  
  50.         return super.dispatchTouchEvent(ev);  
  51.     }  
  52.     if (!disallowIntercept && onInterceptTouchEvent(ev)) {  
  53.         final float xc = scrolledXFloat - (float) target.mLeft;  
  54.         final float yc = scrolledYFloat - (float) target.mTop;  
  55.         mPrivateFlags &= ~CANCEL_NEXT_UP_EVENT;  
  56.         ev.setAction(MotionEvent.ACTION_CANCEL);  
  57.         ev.setLocation(xc, yc);  
  58.         if (!target.dispatchTouchEvent(ev)) {  
  59.         }  
  60.         mMotionTarget = null;  
  61.         return true;  
  62.     }  
  63.     if (isUpOrCancel) {  
  64.         mMotionTarget = null;  
  65.     }  
  66.     final float xc = scrolledXFloat - (float) target.mLeft;  
  67.     final float yc = scrolledYFloat - (float) target.mTop;  
  68.     ev.setLocation(xc, yc);  
  69.     if ((target.mPrivateFlags & CANCEL_NEXT_UP_EVENT) != 0) {  
  70.         ev.setAction(MotionEvent.ACTION_CANCEL);  
  71.         target.mPrivateFlags &= ~CANCEL_NEXT_UP_EVENT;  
  72.         mMotionTarget = null;  
  73.     }  
  74.     return target.dispatchTouchEvent(ev);  
  75. }  

這個方法代碼比較長,我們隻挑重點看。首先在第13行可以看到一個條件判斷,如果 disallowIntercept和!onInterceptTouchEvent(ev)兩者有一個為true,就會進入到這個條件判斷中。disallowIntercept是指是否禁用掉事件攔截的功能,預設是false,也可以通過調用requestDisallowInterceptTouchEvent方法對這個值進行修改。那麼當第一個值為false的時候就會完全依賴第二個值來決定是否可以進入到條件判斷的内部,第二個值是什麼呢?竟然就是對onInterceptTouchEvent方法的傳回值取反!也就是說如果我們在onInterceptTouchEvent方法中傳回false,就會讓第二個值為true,進而進入到條件判斷的内部,如果我們在onInterceptTouchEvent方法中傳回true,就會讓第二個值為false,進而跳出了這個條件判斷。

這個時候你就可以思考一下了,由于我們剛剛在MyLayout中重寫了onInterceptTouchEvent方法,讓這個方法傳回true,導緻所有按鈕的點選事件都被屏蔽了,那我們就完全有理由相信,按鈕點選事件的處理就是在第13行條件判斷的内部進行的!

那我們重點來看下條件判斷的内部是怎麼實作的。在第19行通過一個for循環,周遊了目前ViewGroup下的所有子View,然後在第24行判斷目前周遊的View是不是正在點選的View,如果是的話就會進入到該條件判斷的内部,然後在第29行調用了該View的dispatchTouchEvent,之後的流程就和 Android事件分發機制完全解析,帶你從源碼的角度徹底了解(上) 中講解的是一樣的了。我們也是以證明了,按鈕點選事件的處理确實就是在這裡進行的。

然後需要注意一下,調用子View的dispatchTouchEvent後是有傳回值的。我們已經知道,如果一個控件是可點選的,那麼點選該控件時,dispatchTouchEvent的傳回值必定是true。是以會導緻第29行的條件判斷成立,于是在第31行給ViewGroup的dispatchTouchEvent方法直接傳回了true。這樣就導緻後面的代碼無法執行到了,也是印證了我們前面的Demo列印的結果,如果按鈕的點選事件得到執行,就會把MyLayout的touch事件攔截掉。

那如果我們點選的不是按鈕,而是空白區域呢?這種情況就一定不會在第31行傳回true了,而是會繼續執行後面的代碼。那我們繼續往後看,在第44行,如果target等于null,就會進入到該條件判斷内部,這裡一般情況下target都會是null,是以會在第50行調用super.dispatchTouchEvent(ev)。這句代碼會調用到哪裡呢?當然是View中的dispatchTouchEvent方法了,因為ViewGroup的父類就是View。之後的處理邏輯又和前面所說的是一樣的了,也是以MyLayout中注冊的onTouch方法會得到執行。之後的代碼在一般情況下是走不到的了,我們也就不再繼續往下分析。

再看一下整個ViewGroup事件分發過程的流程圖吧,相信可以幫助大家更好地去了解:

Android事件分發機制完全解析,帶你從源碼的角度徹底了解(全)

現在整個ViewGroup的事件分發流程的分析也就到此結束了,我們最後再來簡單梳理一下吧。

1. Android事件分發是先傳遞到ViewGroup,再由ViewGroup傳遞到View的。

2. 在ViewGroup中可以通過onInterceptTouchEvent方法對事件傳遞進行攔截,onInterceptTouchEvent方法傳回true代表不允許事件繼續向子View傳遞,傳回false代表不對事件進行攔截,預設傳回false。

3. 子View中如果将傳遞的事件消費掉,ViewGroup中将無法接收到任何事件。

好了,Android事件分發機制完全解析到此全部結束,結合上下兩篇,相信大家對事件分發的了解已經非常深刻了。