PS一句：最終還是選擇CSDN來整理發表這幾年的知識點，該文章平行遷移到CSDN。因為CSDN也支持MarkDown語法了，牛逼啊！ 【工匠若水?[http://blog.csdn.net/yanbober](http://blog.csdn.net/yanbober)】 Notice：閱讀完該篇之后如果想繼續深入閱讀Android觸摸屏事件派發機制詳解與源碼分析下一篇請點擊[《Android觸摸屏事件派發機制詳解與源碼分析二(ViewGroup篇)》](http://blog.csdn.net/yanbober/article/details/45912661)查看。 ### 1 背景 最近在簡書和微博還有Q群看見很多人說Android自定義控件（View/ViewGroup）如何學習？為啥那么難？其實答案很簡單：“基礎不牢，地動山搖。” 不扯蛋了，進入正題。就算你不自定義控件，你也必須要了解Android控件的觸摸屏事件傳遞機制（之所以說觸摸屏是因為該系列以觸摸屏的事件機制分析為主，對于類似TV設備等的物理事件機制的分析雷同但有區別。哈哈，誰讓我之前是做Android TV BOX的，悲催！），只有這樣才能將你的控件事件運用的如魚得水。接下來的控件觸摸屏事件傳遞機制分析依據Android 5.1.1源碼（API 22）。 ### 2 基礎實例現象 #### 2-1 例子 從一個例子分析說起吧。如下是一個很簡單不過的Android實例：?  ~~~ <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:gravity="center" android:layout_width="fill_parent" android:layout_height="fill_parent" android:id="@+id/mylayout"> <Button android:id="@+id/my_btn" android:layout_width="match_parent" android:layout_height="wrap_content" android:text="click test"/> </LinearLayout> ~~~ ~~~ public class ListenerActivity extends Activity implements View.OnTouchListener, View.OnClickListener { private LinearLayout mLayout; private Button mButton; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); mLayout = (LinearLayout) this.findViewById(R.id.mylayout); mButton = (Button) this.findViewById(R.id.my_btn); mLayout.setOnTouchListener(this); mButton.setOnTouchListener(this); mLayout.setOnClickListener(this); mButton.setOnClickListener(this); } @Override public boolean onTouch(View v, MotionEvent event) { Log.i(null, "OnTouchListener--onTouch-- action="+event.getAction()+" --"+v); return false; } @Override public void onClick(View v) { Log.i(null, "OnClickListener--onClick--"+v); } } ~~~ #### 2-2 現象 如上代碼很簡單，但凡學過幾天Android的人都能看懂吧。Activity中有一個LinearLayout（ViewGroup的子類，ViewGroup是View的子類）布局，布局中包含一個按鈕（View的子類）；然后分別對這兩個控件設置了Touch與Click的監聽事件，具體運行結果如下： 1. 當穩穩的點擊Button時打印如下：?  1. 當穩穩的點擊除過Button以外的其他地方時打印如下：?  1. 當收指點擊Button時按在Button上晃動了一下松開后的打印如下：?  機智的你看完這個結果指定知道為啥吧？? 我們看下onTouch和onClick，從參數都能看出來onTouch比onClick強大靈活，畢竟多了一個event參數。這樣onTouch里就可以處理ACTION_DOWN、ACTION_UP、ACTION_MOVE等等的各種觸摸。現在來分析下上面的打印結果；在1中，當我們點擊Button時會先觸發onTouch事件（之所以打印action為0,1各一次是因為按下抬起兩個觸摸動作被觸發）然后才觸發onClick事件；在2中也同理類似1；在3中會發現onTouch被多次調運后才調運onClick，是因為手指晃動了，所以觸發了ACTION_DOWN->ACTION_MOVE…->ACTION_UP。 如果你眼睛比較尖你會看見onTouch會有一個返回值，而且在上面返回了false。你可能會疑惑這個返回值有啥效果？那就驗證一下吧，我們將上面的onTouch返回值改為ture。如下： ~~~ @Override public boolean onTouch(View v, MotionEvent event) { Log.i(null, "OnTouchListener--onTouch-- action="+event.getAction()+" --"+v); return true; } ~~~ 再次點擊Button結果如下：?  ? 看見了吧，如果onTouch返回true則onClick不會被調運了。 #### 2-3 總結結論 好了，經過這個簡單的實例驗證你可以總結發現： 1. Android控件的Listener事件觸發順序是先觸發onTouch，其次onClick。 1. 如果控件的onTouch返回true將會阻止事件繼續傳遞，返回false事件會繼續傳遞。 對于伸手黨碼農來說其實到這足矣應付常規的App事件監聽處理使用開發了，但是對于復雜的事件監聽處理或者想自定義控件的碼農來說這才是剛剛開始，只是個熱身。既然這樣那就繼續嘍。。。 ### 3 Android 5.1.1(API 22) View觸摸屏事件傳遞源碼分析 #### 3-1 寫在前面的話 其實Android源碼無論哪個版本對于觸摸屏事件的傳遞機制都類似，這里只是選用了目前最新版本的源碼來分析而已。分析Android View事件傳遞機制之前有必要先看下源碼的一些關系，如下是幾個繼承關系圖：?  ?  怎么樣？看了官方這個繼承圖是不是明白了上面例子中說的LinearLayout是ViewGroup的子類，ViewGroup是View的子類，Button是View的子類關系呢？其實，在Android中所有的控件無非都是ViewGroup或者View的子類，說高尚點就是所有控件都是View的子類。 這里通過繼承關系是說明一切控件都是View，同時View與ViewGroup又存在一些區別，所以該模塊才只單單先分析View觸摸屏事件傳遞機制。 #### 3-2 從View的dispatchTouchEvent方法說起 在Android中你只要觸摸控件首先都會觸發控件的dispatchTouchEvent方法（其實這個方法一般都沒在具體的控件類中，而在他的父類View中），所以我們先來看下View的dispatchTouchEvent方法，如下： ~~~ public boolean dispatchTouchEvent(MotionEvent event) { // If the event should be handled by accessibility focus first. if (event.isTargetAccessibilityFocus()) { // We don't have focus or no virtual descendant has it, do not handle the event. if (!isAccessibilityFocusedViewOrHost()) { return false; } // We have focus and got the event, then use normal event dispatch. event.setTargetAccessibilityFocus(false); } boolean result = false; if (mInputEventConsistencyVerifier != null) { mInputEventConsistencyVerifier.onTouchEvent(event, 0); } final int actionMasked = event.getActionMasked(); if (actionMasked == MotionEvent.ACTION_DOWN) { // Defensive cleanup for new gesture stopNestedScroll(); } if (onFilterTouchEventForSecurity(event)) { //noinspection SimplifiableIfStatement ListenerInfo li = mListenerInfo; if (li != null && li.mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED && li.mOnTouchListener.onTouch(this, event)) { result = true; } if (!result && onTouchEvent(event)) { result = true; } } if (!result && mInputEventConsistencyVerifier != null) { mInputEventConsistencyVerifier.onUnhandledEvent(event, 0); } // Clean up after nested scrolls if this is the end of a gesture; // also cancel it if we tried an ACTION_DOWN but we didn't want the rest // of the gesture. if (actionMasked == MotionEvent.ACTION_UP || actionMasked == MotionEvent.ACTION_CANCEL || (actionMasked == MotionEvent.ACTION_DOWN && !result)) { stopNestedScroll(); } return result; } ~~~ dispatchTouchEvent的代碼有點長，咱們看重點就可以。前面都是設置一些標記和處理input與手勢等傳遞，到24行的 `if (onFilterTouchEventForSecurity(event))`語句判斷當前View是否沒被遮住等，接著26行定義ListenerInfo局部變量，ListenerInfo是View的靜態 內部類，用來定義一堆關于View的XXXListener等方法；接著`if (li != null && li.mOnTouchListener != null && (mViewFlags & ENABLED_MASK) ==?` `ENABLED && li.mOnTouchListener.onTouch(this, event))`語句就是重點，首先li對象自然不會為null，li.mOnTouchListener呢？你會發現ListenerInfo 的mOnTouchListener成員是在哪兒賦值的呢？怎么確認他是不是null呢？通過在View類里搜索可以看到： ~~~ /** * Register a callback to be invoked when a touch event is sent to this view. * @param l the touch listener to attach to this view */ public void setOnTouchListener(OnTouchListener l) { getListenerInfo().mOnTouchListener = l; } ~~~ li.mOnTouchListener是不是null取決于控件（View）是否設置setOnTouchListener監聽，在上面的實例中我們是設置過Button的 setOnTouchListener方法的，所以也不為null；接著通過位與運算確定控件（View）是不是ENABLED 的，默認控件都是ENABLED 的； 接著判斷onTouch的返回值是不是true。通過如上判斷之后如果都為true則設置默認為false的result為true，那么接下來的 `if (!result && onTouchEvent(event))`就不會執行，最終dispatchTouchEvent也會返回true。而如果 `if (li != null && li.mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED && li.mOnTouchListener.onTouch(this, event))` 語句有一個為false則`if (!result && onTouchEvent(event))`就會執行，如果onTouchEvent(event)返回false則dispatchTouchEvent返回false， 否則返回true。 這下再看前面的實例部分明白了吧？控件觸摸就會調運dispatchTouchEvent方法，而在dispatchTouchEvent中先執行的是onTouch方法，所以驗證了實例結論總結中的onTouch優先于onClick執行道理。如果控件是ENABLE且在onTouch方法里返回了true則dispatchTouchEvent方法也返回true，不會再繼續往下執行；反之，onTouch返回false則會繼續向下執行onTouchEvent方法，且dispatchTouchEvent的返回值與onTouchEvent返回值相同。 所以依據這個結論和上面實例打印結果你指定已經大膽猜測認為onClick一定與onTouchEvent有關系？是不是呢？先告訴你，是的。下面我們會分析。 #### 3-2-1 總結結論 在View的觸摸屏傳遞機制中通過分析dispatchTouchEvent方法源碼我們會得出如下基本結論： 1. 觸摸控件（View）首先執行dispatchTouchEvent方法。 1. 在dispatchTouchEvent方法中先執行onTouch方法，后執行onClick方法（onClick方法在onTouchEvent中執行，下面會分析）。 1. 如果控件（View）的onTouch返回false或者mOnTouchListener為null（控件沒有設置setOnTouchListener方法）或者控件不是enable的情況下會調運onTouchEvent，dispatchTouchEvent返回值與onTouchEvent返回一樣。 1. 如果控件不是enable的設置了onTouch方法也不會執行，只能通過重寫控件的onTouchEvent方法處理（上面已經處理分析了），dispatchTouchEvent返回值與onTouchEvent返回一樣。 1. 如果控件（View）是enable且onTouch返回true情況下，dispatchTouchEvent直接返回true，不會調用onTouchEvent方法。 上面說了onClick一定與onTouchEvent有關系，那么接下來就分析分析dispatchTouchEvent方法中的onTouchEvent方法。 #### 3-3 繼續說說View的dispatchTouchEvent方法中調運的onTouchEvent方法 上面說了dispatchTouchEvent方法中如果onTouch返回false或者mOnTouchListener為null（控件沒有設置setOnTouchListener方法）或者控件不是enable的情況下會調運onTouchEvent，所以接著看就知道了，如下： ~~~ public boolean onTouchEvent(MotionEvent event) { final float x = event.getX(); final float y = event.getY(); final int viewFlags = mViewFlags; if ((viewFlags & ENABLED_MASK) == DISABLED) { if (event.getAction() == MotionEvent.ACTION_UP && (mPrivateFlags & PFLAG_PRESSED) != 0) { setPressed(false); } // A disabled view that is clickable still consumes the touch // events, it just doesn't respond to them. return (((viewFlags & CLICKABLE) == CLICKABLE || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)); } if (mTouchDelegate != null) { if (mTouchDelegate.onTouchEvent(event)) { return true; } } if (((viewFlags & CLICKABLE) == CLICKABLE || (viewFlags & LONG_CLICKABLE) == LONG_CLICKABLE)) { switch (event.getAction()) { case MotionEvent.ACTION_UP: boolean prepressed = (mPrivateFlags & PFLAG_PREPRESSED) != 0; if ((mPrivateFlags & PFLAG_PRESSED) != 0 || prepressed) { // take focus if we don't have it already and we should in // touch mode. boolean focusTaken = false; if (isFocusable() && isFocusableInTouchMode() && !isFocused()) { focusTaken = requestFocus(); } if (prepressed) { // The button is being released before we actually // showed it as pressed. Make it show the pressed // state now (before scheduling the click) to ensure // the user sees it. setPressed(true, x, y); } if (!mHasPerformedLongPress) { // This is a tap, so remove the longpress check removeLongPressCallback(); // Only perform take click actions if we were in the pressed state if (!focusTaken) { // Use a Runnable and post this rather than calling // performClick directly. This lets other visual state // of the view update before click actions start. if (mPerformClick == null) { mPerformClick = new PerformClick(); } if (!post(mPerformClick)) { performClick(); } } } if (mUnsetPressedState == null) { mUnsetPressedState = new UnsetPressedState(); } if (prepressed) { postDelayed(mUnsetPressedState, ViewConfiguration.getPressedStateDuration()); } else if (!post(mUnsetPressedState)) { // If the post failed, unpress right now mUnsetPressedState.run(); } removeTapCallback(); } break; case MotionEvent.ACTION_DOWN: mHasPerformedLongPress = false; if (performButtonActionOnTouchDown(event)) { break; } // Walk up the hierarchy to determine if we're inside a scrolling container. boolean isInScrollingContainer = isInScrollingContainer(); // For views inside a scrolling container, delay the pressed feedback for // a short period in case this is a scroll. if (isInScrollingContainer) { mPrivateFlags |= PFLAG_PREPRESSED; if (mPendingCheckForTap == null) { mPendingCheckForTap = new CheckForTap(); } mPendingCheckForTap.x = event.getX(); mPendingCheckForTap.y = event.getY(); postDelayed(mPendingCheckForTap, ViewConfiguration.getTapTimeout()); } else { // Not inside a scrolling container, so show the feedback right away setPressed(true, x, y); checkForLongClick(0); } break; case MotionEvent.ACTION_CANCEL: setPressed(false); removeTapCallback(); removeLongPressCallback(); break; case MotionEvent.ACTION_MOVE: drawableHotspotChanged(x, y); // Be lenient about moving outside of buttons if (!pointInView(x, y, mTouchSlop)) { // Outside button removeTapCallback(); if ((mPrivateFlags & PFLAG_PRESSED) != 0) { // Remove any future long press/tap checks removeLongPressCallback(); setPressed(false); } } break; } return true; } return false; } ~~~ 我勒個去！一個方法比一個方法代碼多。好吧，那咱們繼續只挑重點來說明唄。 首先地6到14行可以看出，如果控件（View）是disenable狀態，同時是可以clickable的則onTouchEvent直接消費事件返回true，反之如果控件（View）是disenable狀態，同時是disclickable的則onTouchEvent直接false。多說一句，關于控件的enable或者clickable屬性可以通過java或者xml直接設置，每個view都有這些屬性。 接著22行可以看見，如果一個控件是enable且disclickable則onTouchEvent直接返回false了；反之，如果一個控件是enable且clickable則繼續進入過于一個event的switch判斷中，然后最終onTouchEvent都返回了true。switch的ACTION_DOWN與ACTION_MOVE都進行了一些必要的設置與置位，接著到手抬起來ACTION_UP時你會發現，首先判斷了是否按下過，同時是不是可以得到焦點，然后嘗試獲取焦點，然后判斷如果不是longPressed則通過post在UI Thread中執行一個PerformClick的Runnable，也就是performClick方法。具體如下： ~~~ public boolean performClick() { final boolean result; final ListenerInfo li = mListenerInfo; if (li != null && li.mOnClickListener != null) { playSoundEffect(SoundEffectConstants.CLICK); li.mOnClickListener.onClick(this); result = true; } else { result = false; } sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED); return result; } ~~~ 這個方法也是先定義一個ListenerInfo的變量然后賦值，接著判斷li.mOnClickListener是不是為null，決定執行不執行onClick。你指定現在已經很 機智了，和onTouch一樣，搜一下mOnClickListener在哪賦值的唄，結果發現： ~~~ public void setOnClickListener(OnClickListener l) { if (!isClickable()) { setClickable(true); } getListenerInfo().mOnClickListener = l; } ~~~ 看見了吧！控件只要監聽了onClick方法則mOnClickListener就不為null，而且有意思的是如果調運setOnClickListener方法設置監聽且控件是 disclickable的情況下默認會幫設置為clickable。 我勒個去！！！驚訝吧！！！猜的沒錯onClick就在onTouchEvent中執行的，而且是在onTouchEvent的ACTION_UP事件中執行的。 #### 3-3-1 總結結論 1. onTouchEvent方法中會在ACTION_UP分支中觸發onClick的監聽。 1. 當dispatchTouchEvent在進行事件分發的時候，只有前一個action返回true，才會觸發下一個action。 到此上面例子中關于Button點擊的各種打印的真實原因都找到了可靠的證據，也就是說View的觸摸屏事件傳遞機制其實也就這么回事。 ### 4 透過源碼繼續進階實例驗證 其實上面分析完View的觸摸傳遞機制之后已經足夠用了。如下的實例驗證可以說是加深閱讀源碼的理解，還有一個主要作用就是為將來自定義控件打下堅實基礎。因為自定義控件中時常會與這幾個方法打交道。 #### 4-1 例子 我們自定義一個Button（Button實質繼承自View），如下： ~~~ public class TestButton extends Button { public TestButton(Context context, AttributeSet attrs) { super(context, attrs); } @Override public boolean dispatchTouchEvent(MotionEvent event) { Log.i(null, "dispatchTouchEvent-- action=" + event.getAction()); return super.dispatchTouchEvent(event); } @Override public boolean onTouchEvent(MotionEvent event) { Log.i(null, "onTouchEvent-- action="+event.getAction()); return super.onTouchEvent(event); } } ~~~ 其他代碼如下： ~~~ <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:gravity="center" android:layout_width="fill_parent" android:layout_height="fill_parent" android:id="@+id/mylayout"> <com.zzci.light.TestButton android:id="@+id/my_btn" android:layout_width="match_parent" android:layout_height="wrap_content" android:text="click test"/> </LinearLayout> ~~~ ~~~ public class ListenerActivity extends Activity implements View.OnTouchListener, View.OnClickListener { private LinearLayout mLayout; private TestButton mButton; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); mLayout = (LinearLayout) this.findViewById(R.id.mylayout); mButton = (TestButton) this.findViewById(R.id.my_btn); mLayout.setOnTouchListener(this); mButton.setOnTouchListener(this); mLayout.setOnClickListener(this); mButton.setOnClickListener(this); } @Override public boolean onTouch(View v, MotionEvent event) { Log.i(null, "OnTouchListener--onTouch-- action="+event.getAction()+" --"+v); return false; } @Override public void onClick(View v) { Log.i(null, "OnClickListener--onClick--"+v); } } ~~~ 其實這段代碼只是對上面例子中的Button換為了自定義Button而已。 #### 4-2 現象分析 #### 4-2-1 點擊Button（手抽筋了一下）  可以發現，如上打印完全符合源碼分析結果，dispatchTouchEvent方法先派發down事件，完事調運onTouch，完事調運onTouchEvent返回true，同時dispatchTouchEvent返回true，然后dispatchTouchEvent繼續派發move或者up事件，循環，直到onTouchEvent處理up事件時調運onClick事件，完事返回true，同時dispatchTouchEvent返回true；一次完整的View事件派發流程結束。 #### 4-2-2 簡單修改onTouchEvent返回值為true 將TestButton類的onTouchEvent方法修改如下，其他和基礎代碼保持不變： ~~~ @Override public boolean onTouchEvent(MotionEvent event) { Log.i(null, "onTouchEvent-- action="+event.getAction()); return true; } ~~~ 點擊Button打印如下：?  可以發現，當自定義了控件（View）的onTouchEvent直接返回true而不調運super方法時，事件派發機制如同4.2.1類似，只是最后up事件沒有觸發onClick而已（因為沒有調用super）。 所以可想而知，如果TestButton類的onTouchEvent修改為如下： ~~~ @Override public boolean onTouchEvent(MotionEvent event) { Log.i(null, "onTouchEvent-- action="+event.getAction()); super.onTouchEvent(event); return true; } ~~~ 點擊Button如下：?  整個派發機制和4.2.1完全類似。 #### 4-2-3 簡單修改onTouchEvent返回值為false 將TestButton類的onTouchEvent方法修改如下，其他和基礎代碼保持不變： ~~~ @Override public boolean onTouchEvent(MotionEvent event) { Log.i(null, "onTouchEvent-- action="+event.getAction()); return false; } ~~~ 點擊Button如下：?  ? 你會發現如果onTouchEvent返回false（也即dispatchTouchEvent一旦返回false將不再繼續派發其他action，立即停止派發），這里只派發了down事件。至于后面觸發了LinearLayout的touch與click事件我們這里不做關注，下一篇博客會詳細解釋為啥（其實你可以想下的，LinearLayout是ViewGroup的子類，你懂的），這里你只用知道View的onTouchEvent返回false會阻止繼續派發事件。 同理修改如下： ~~~ @Override public boolean onTouchEvent(MotionEvent event) { Log.i(null, "onTouchEvent-- action="+event.getAction()); super.onTouchEvent(event); return false; } ~~~ 點擊Button如下：?  #### 4-2-4 簡單修改dispatchTouchEvent返回值為true 將TestButton類的dispatchTouchEvent方法修改如下，其他和基礎代碼保持不變： ~~~ @Override public boolean dispatchTouchEvent(MotionEvent event) { Log.i(null, "dispatchTouchEvent-- action=" + event.getAction()); return true; } ~~~ 點擊Button如下：?  你會發現如果dispatchTouchEvent直接返回true且不調運super任何事件都得不到觸發。 繼續修改如下呢？? 將TestButton類的dispatchTouchEvent方法修改如下，其他和基礎代碼保持不變： ~~~ @Override public boolean dispatchTouchEvent(MotionEvent event) { Log.i(null, "dispatchTouchEvent-- action=" + event.getAction()); super.dispatchTouchEvent(event); return true; } ~~~ 點擊Button如下：?  可以發現所有事件都可以得到正常派發，和4.2.1類似。 #### 4-2-5 簡單修改dispatchTouchEvent返回值為false 將TestButton類的dispatchTouchEvent方法修改如下，其他和基礎代碼保持不變： ~~~ @Override public boolean dispatchTouchEvent(MotionEvent event) { Log.i(null, "dispatchTouchEvent-- action=" + event.getAction()); return false; } ~~~ 點擊Button如下：?  你會發現事件不進行任何繼續觸發，關于點擊Button觸發了LinearLayout的事件暫時不用關注，下篇詳解。 繼續修改如下呢？? 將TestButton類的dispatchTouchEvent方法修改如下，其他和基礎代碼保持不變： ~~~ @Override public boolean dispatchTouchEvent(MotionEvent event) { Log.i(null, "dispatchTouchEvent-- action=" + event.getAction()); super.dispatchTouchEvent(event); return false; } ~~~ 點擊Button如下：?  ? 你會發現結果和4.2.3的第二部分結果一樣，也就是說如果dispatchTouchEvent返回false事件將不再繼續派發下一次。 #### 4-2-6 簡單修改dispatchTouchEvent與onTouchEvent返回值 修改dispatchTouchEvent返回值為true，onTouchEvent為false： 將TestButton類的dispatchTouchEvent方法和onTouchEvent方法修改如下，其他和基礎代碼保持不變： ~~~ @Override public boolean dispatchTouchEvent(MotionEvent event) { Log.i(null, "dispatchTouchEvent-- action=" + event.getAction()); super.dispatchTouchEvent(event); return true; } @Override public boolean onTouchEvent(MotionEvent event) { Log.i(null, "onTouchEvent-- action=" + event.getAction()); super.onTouchEvent(event); return false; } ~~~ 點擊Button如下：?  修改dispatchTouchEvent返回值為false，onTouchEvent為true： 將TestButton類的dispatchTouchEvent方法和onTouchEvent方法修改如下，其他和基礎代碼保持不變： ~~~ @Override public boolean dispatchTouchEvent(MotionEvent event) { Log.i(null, "dispatchTouchEvent-- action=" + event.getAction()); super.dispatchTouchEvent(event); return false; } @Override public boolean onTouchEvent(MotionEvent event) { Log.i(null, "onTouchEvent-- action=" + event.getAction()); super.onTouchEvent(event); return true; } ~~~ 點擊Button如下：?  由此對比得出結論，dispatchTouchEvent事件派發是傳遞的，如果返回值為false將停止下次事件派發，如果返回true將繼續下次派發。譬如，當前派發down事件，如果返回true則繼續派發up，如果返回false派發完down就停止了。 #### 4-1 總結 這個例子組合了很多種情況的值去驗證上面源碼的分析，同時也為自定義控件打下了基礎。仔細理解這個例子對于View的事件傳遞就差不多了。 ### 5 總結View觸摸屏事件傳遞機制 上面例子也測試了，源碼也分析了，總得有個最終結論方便平時寫代碼作為參考依據呀，不能每次都再去分析一遍源碼，那得多蛋疼呢！ 綜合得出Android View的觸摸屏事件傳遞機制有如下特征： 1. 觸摸控件（View）首先執行dispatchTouchEvent方法。 1. 在dispatchTouchEvent方法中先執行onTouch方法，后執行onClick方法（onClick方法在onTouchEvent中執行，下面會分析）。 1. 如果控件（View）的onTouch返回false或者mOnTouchListener為null（控件沒有設置setOnTouchListener方法）或者控件不是enable的情況下會調運onTouchEvent，dispatchTouchEvent返回值與onTouchEvent返回一樣。 1. 如果控件不是enable的設置了onTouch方法也不會執行，只能通過重寫控件的onTouchEvent方法處理（上面已經處理分析了），dispatchTouchEvent返回值與onTouchEvent返回一樣。 1. 如果控件（View）是enable且onTouch返回true情況下，dispatchTouchEvent直接返回true，不會調用onTouchEvent方法。 1. 當dispatchTouchEvent在進行事件分發的時候，只有前一個action返回true，才會觸發下一個action（也就是說dispatchTouchEvent返回true才會進行下一次action派發）。 【工匠若水?[http://blog.csdn.net/yanbober](http://blog.csdn.net/yanbober)】 關于上面的疑惑還有ViewGroup事件派發機制你可以繼續閱讀下一篇博客[《Android觸摸屏事件派發機制詳解與源碼分析二(ViewGroup篇)》](http://blog.csdn.net/yanbober/article/details/45912661)，以便繼續分析View之外的ViewGroup事件傳遞機制。