轉載請注明出處：http://blog.csdn.net/guolin_blog/article/details/9097463
其實我一直準備寫一篇關于Android事件分發(fā)機制的文章，從我的第一篇博客開始燕耿，就零零散散在好多地方使用到了Android事件分發(fā)的知識中符。也有好多朋友問過我各種問題，比如：onTouch和onTouchEvent有什么區(qū)別誉帅，又該如何使用淀散？為什么給ListView引入了一個滑動菜單的功能，ListView就不能滾動了蚜锨？為什么圖片輪播器里的圖片使用Button而不用ImageView档插？等等……對于這些問題，我并沒有給出非常詳細的回答亚再，因為我知道如果想要徹底搞明白這些問題郭膛，掌握Android事件分發(fā)機制是必不可少的，而Android事件分發(fā)機制絕對不是三言兩語就能說得清的氛悬。
在我經(jīng)過較長時間的籌備之后则剃，終于決定開始寫這樣一篇文章了。目前雖然網(wǎng)上相關的文章也不少圆雁，但我覺得沒有哪篇寫得特別詳細的(也許我還沒有找到)忍级，多數(shù)文章只是講了講理論帆谍，然后配合demo運行了一下結果伪朽。而我準備帶著大家從源碼的角度進行分析，相信大家可以更加深刻地理解Android事件分發(fā)機制汛蝙。
閱讀源碼講究由淺入深烈涮，循序漸進，因此我們也從簡單的開始窖剑，本篇先帶大家探究View的事件分發(fā)坚洽，下篇再去探究難度更高的ViewGroup的事件分發(fā)。
那我們現(xiàn)在就開始吧西土！比如說你當前有一個非常簡單的項目讶舰，只有一個Activity，并且Activity中只有一個按鈕需了。你可能已經(jīng)知道跳昼，如果想要給這個按鈕注冊一個點擊事件，只需要調用：
[java]view plaincopy
button.setOnClickListener(newOnClickListener()?{
@Override
publicvoidonClick(View?v)?{
Log.d("TAG","onClick?execute");
}
});
這樣在onClick方法里面寫實現(xiàn)肋乍，就可以在按鈕被點擊的時候執(zhí)行鹅颊。你可能也已經(jīng)知道，如果想給這個按鈕再添加一個touch事件墓造，只需要調用：
[java]view plaincopy
button.setOnTouchListener(newOnTouchListener()?{
@Override
publicbooleanonTouch(View?v,?MotionEvent?event)?{
Log.d("TAG","onTouch?execute,?action?"+?event.getAction());
returnfalse;
}
});
onTouch方法里能做的事情比onClick要多一些堪伍，比如判斷手指按下锚烦、抬起、移動等事件帝雇。那么如果我兩個事件都注冊了涮俄，哪一個會先執(zhí)行呢？我們來試一下就知道了尸闸，運行程序點擊按鈕禽拔，打印結果如下：
可以看到，onTouch是優(yōu)先于onClick執(zhí)行的室叉，并且onTouch執(zhí)行了兩次睹栖，一次是ACTION_DOWN，一次是ACTION_UP(你還可能會有多次ACTION_MOVE的執(zhí)行茧痕，如果你手抖了一下)野来。因此事件傳遞的順序是先經(jīng)過onTouch，再傳遞到onClick踪旷。
細心的朋友應該可以注意到曼氛，onTouch方法是有返回值的，這里我們返回的是false令野，如果我們嘗試把onTouch方法里的返回值改成true舀患，再運行一次，結果如下：
我們發(fā)現(xiàn)气破，onClick方法不再執(zhí)行了聊浅！為什么會這樣呢？你可以先理解成onTouch方法返回true就認為這個事件被onTouch消費掉了现使，因而不會再繼續(xù)向下傳遞低匙。
如果到現(xiàn)在為止，以上的所有知識點你都是清楚的碳锈，那么說明你對Android事件傳遞的基本用法應該是掌握了顽冶。不過別滿足于現(xiàn)狀，讓我們從源碼的角度分析一下售碳，出現(xiàn)上述現(xiàn)象的原理是什么强重。
首先你需要知道一點，只要你觸摸到了任何一個控件贸人，就一定會調用該控件的dispatchTouchEvent方法间景。那當我們去點擊按鈕的時候，就會去調用Button類里的dispatchTouchEvent方法灸姊，可是你會發(fā)現(xiàn)Button類里并沒有這個方法拱燃，那么就到它的父類TextView里去找一找，你會發(fā)現(xiàn)TextView里也沒有這個方法力惯，那沒辦法了碗誉，只好繼續(xù)在TextView的父類View里找一找召嘶，這個時候你終于在View里找到了這個方法，示意圖如下：
然后我們來看一下View中dispatchTouchEvent方法的源碼：
[java]view plaincopy
publicbooleandispatchTouchEvent(MotionEvent?event)?{
if(mOnTouchListener?!=null&&?(mViewFlags?&?ENABLED_MASK)?==?ENABLED?&&
mOnTouchListener.onTouch(this,?event))?{
returntrue;
}
returnonTouchEvent(event);
}
這個方法非常的簡潔哮缺，只有短短幾行代碼弄跌！我們可以看到，在這個方法內尝苇，首先是進行了一個判斷铛只，如果mOnTouchListener != null，(mViewFlags & ENABLED_MASK) == ENABLED和mOnTouchListener.onTouch(this, event)這三個條件都為真糠溜，就返回true淳玩，否則就去執(zhí)行onTouchEvent(event)方法并返回。
先看一下第一個條件非竿，mOnTouchListener這個變量是在哪里賦值的呢蜕着？我們尋找之后在View里發(fā)現(xiàn)了如下方法：
[java]view plaincopy
publicvoidsetOnTouchListener(OnTouchListener?l)?{
mOnTouchListener?=?l;
}
Bingo！找到了红柱，mOnTouchListener正是在setOnTouchListener方法里賦值的承匣，也就是說只要我們給控件注冊了touch事件，mOnTouchListener就一定被賦值了锤悄。
第二個條件(mViewFlags & ENABLED_MASK) == ENABLED是判斷當前點擊的控件是否是enable的韧骗，按鈕默認都是enable的，因此這個條件恒定為true零聚。
第三個條件就比較關鍵了袍暴，mOnTouchListener.onTouch(this, event)，其實也就是去回調控件注冊touch事件時的onTouch方法握牧。也就是說如果我們在onTouch方法里返回true容诬，就會讓這三個條件全部成立娩梨，從而整個方法直接返回true沿腰。如果我們在onTouch方法里返回false，就會再去執(zhí)行onTouchEvent(event)方法狈定。
現(xiàn)在我們可以結合前面的例子來分析一下了颂龙，首先在dispatchTouchEvent中最先執(zhí)行的就是onTouch方法，因此onTouch肯定是要優(yōu)先于onClick執(zhí)行的纽什，也是印證了剛剛的打印結果措嵌。而如果在onTouch方法里返回了true，就會讓dispatchTouchEvent方法直接返回true芦缰，不會再繼續(xù)往下執(zhí)行企巢。而打印結果也證實了如果onTouch返回true，onClick就不會再執(zhí)行了让蕾。
根據(jù)以上源碼的分析浪规，從原理上解釋了我們前面例子的運行結果或听。而上面的分析還透漏出了一個重要的信息，那就是onClick的調用肯定是在onTouchEvent(event)方法中的笋婿！那我們馬上來看下onTouchEvent的源碼誉裆，如下所示：
[java]view plaincopy
publicbooleanonTouchEvent(MotionEvent?event)?{
finalintviewFlags?=?mViewFlags;
if((viewFlags?&?ENABLED_MASK)?==?DISABLED)?{
//?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))?{
returntrue;
}
}
if(((viewFlags?&?CLICKABLE)?==?CLICKABLE?||
(viewFlags?&?LONG_CLICKABLE)?==?LONG_CLICKABLE))?{
switch(event.getAction())?{
caseMotionEvent.ACTION_UP:
booleanprepressed?=?(mPrivateFlags?&?PREPRESSED)?!=0;
if((mPrivateFlags?&?PRESSED)?!=0||?prepressed)?{
//?take?focus?if?we?don't?have?it?already?and?we?should?in
//?touch?mode.
booleanfocusTaken?=false;
if(isFocusable()?&&?isFocusableInTouchMode()?&&?!isFocused())?{
focusTaken?=?requestFocus();
}
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?=newPerformClick();
}
if(!post(mPerformClick))?{
performClick();
}
}
}
if(mUnsetPressedState?==null)?{
mUnsetPressedState?=newUnsetPressedState();
}
if(prepressed)?{
mPrivateFlags?|=?PRESSED;
refreshDrawableState();
postDelayed(mUnsetPressedState,
ViewConfiguration.getPressedStateDuration());
}elseif(!post(mUnsetPressedState))?{
//?If?the?post?failed,?unpress?right?now
mUnsetPressedState.run();
}
removeTapCallback();
}
break;
caseMotionEvent.ACTION_DOWN:
if(mPendingCheckForTap?==null)?{
mPendingCheckForTap?=newCheckForTap();
}
mPrivateFlags?|=?PREPRESSED;
mHasPerformedLongPress?=false;
postDelayed(mPendingCheckForTap,?ViewConfiguration.getTapTimeout());
break;
caseMotionEvent.ACTION_CANCEL:
mPrivateFlags?&=?~PRESSED;
refreshDrawableState();
removeTapCallback();
break;
caseMotionEvent.ACTION_MOVE:
finalintx?=?(int)?event.getX();
finalinty?=?(int)?event.getY();
//?Be?lenient?about?moving?outside?of?buttons
intslop?=?mTouchSlop;
if((x?<0-?slop)?||?(x?>=?getWidth()?+?slop)?||
(y?<0-?slop)?||?(y?>=?getHeight()?+?slop))?{
//?Outside?button
removeTapCallback();
if((mPrivateFlags?&?PRESSED)?!=0)?{
//?Remove?any?future?long?press/tap?checks
removeLongPressCallback();
//?Need?to?switch?from?pressed?to?not?pressed
mPrivateFlags?&=?~PRESSED;
refreshDrawableState();
}
}
break;
}
returntrue;
}
returnfalse;
}
相較于剛才的dispatchTouchEvent方法，onTouchEvent方法復雜了很多缸濒，不過沒關系足丢，我們只挑重點看就可以了。
首先在第14行我們可以看出庇配，如果該控件是可以點擊的就會進入到第16行的switch判斷中去斩跌，而如果當前的事件是抬起手指，則會進入到MotionEvent.ACTION_UP這個case當中捞慌。在經(jīng)過種種判斷之后滔驶，會執(zhí)行到第38行的performClick()方法，那我們進入到這個方法里瞧一瞧：
[java]view plaincopy
publicbooleanperformClick()?{
sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED);
if(mOnClickListener?!=null)?{
playSoundEffect(SoundEffectConstants.CLICK);
mOnClickListener.onClick(this);
returntrue;
}
returnfalse;
}
可以看到卿闹，只要mOnClickListener不是null揭糕，就會去調用它的onClick方法，那mOnClickListener又是在哪里賦值的呢锻霎？經(jīng)過尋找后找到如下方法：
[java]view plaincopy
publicvoidsetOnClickListener(OnClickListener?l)?{
if(!isClickable())?{
setClickable(true);
}
mOnClickListener?=?l;
}
一切都是那么清楚了著角！當我們通過調用setOnClickListener方法來給控件注冊一個點擊事件時，就會給mOnClickListener賦值旋恼。然后每當控件被點擊時吏口，都會在performClick()方法里回調被點擊控件的onClick方法。
這樣View的整個事件分發(fā)的流程就讓我們搞清楚了冰更！不過別高興的太早产徊，現(xiàn)在還沒結束，還有一個很重要的知識點需要說明蜀细，就是touch事件的層級傳遞舟铜。我們都知道如果給一個控件注冊了touch事件，每次點擊它的時候都會觸發(fā)一系列的ACTION_DOWN奠衔，ACTION_MOVE谆刨，ACTION_UP等事件。這里需要注意归斤，如果你在執(zhí)行ACTION_DOWN的時候返回了false痊夭，后面一系列其它的action就不會再得到執(zhí)行了。簡單的說脏里，就是當dispatchTouchEvent在進行事件分發(fā)的時候她我，只有前一個action返回true，才會觸發(fā)后一個action。
說到這里番舆，很多的朋友肯定要有巨大的疑問了根吁。這不是在自相矛盾嗎？前面的例子中合蔽，明明在onTouch事件里面返回了false击敌，ACTION_DOWN和ACTION_UP不是都得到執(zhí)行了嗎？其實你只是被假象所迷惑了拴事，讓我們仔細分析一下沃斤，在前面的例子當中，我們到底返回的是什么刃宵。
參考著我們前面分析的源碼衡瓶，首先在onTouch事件里返回了false，就一定會進入到onTouchEvent方法中牲证，然后我們來看一下onTouchEvent方法的細節(jié)哮针。由于我們點擊了按鈕，就會進入到第14行這個if判斷的內部坦袍，然后你會發(fā)現(xiàn)十厢，不管當前的action是什么，最終都一定會走到第89行捂齐，返回一個true蛮放。
是不是有一種被欺騙的感覺？明明在onTouch事件里返回了false奠宜，系統(tǒng)還是在onTouchEvent方法中幫你返回了true包颁。就因為這個原因，才使得前面的例子中ACTION_UP可以得到執(zhí)行压真。
那我們可以換一個控件娩嚼，將按鈕替換成ImageView，然后給它也注冊一個touch事件滴肿，并返回false岳悟。如下所示：
[java]view plaincopy
imageView.setOnTouchListener(newOnTouchListener()?{
@Override
publicbooleanonTouch(View?v,?MotionEvent?event)?{
Log.d("TAG","onTouch?execute,?action?"+?event.getAction());
returnfalse;
}
});
運行一下程序，點擊ImageView嘴高，你會發(fā)現(xiàn)結果如下：
在ACTION_DOWN執(zhí)行完后竿音，后面的一系列action都不會得到執(zhí)行了。這又是為什么呢拴驮？因為ImageView和按鈕不同，它是默認不可點擊的柴信，因此在onTouchEvent的第14行判斷時無法進入到if的內部套啤，直接跳到第91行返回了false，也就導致后面其它的action都無法執(zhí)行了。
好了潜沦，關于View的事件分發(fā)萄涯，我想講的東西全都在這里了。現(xiàn)在我們再來回顧一下開篇時提到的那三個問題唆鸡，相信每個人都會有更深一層的理解涝影。
1.?onTouch和onTouchEvent有什么區(qū)別，又該如何使用争占？
從源碼中可以看出燃逻，這兩個方法都是在View的dispatchTouchEvent中調用的，onTouch優(yōu)先于onTouchEvent執(zhí)行臂痕。如果在onTouch方法中通過返回true將事件消費掉伯襟，onTouchEvent將不會再執(zhí)行。
另外需要注意的是握童，onTouch能夠得到執(zhí)行需要兩個前提條件姆怪，第一mOnTouchListener的值不能為空，第二當前點擊的控件必須是enable的澡绩。因此如果你有一個控件是非enable的稽揭，那么給它注冊onTouch事件將永遠得不到執(zhí)行。對于這一類控件肥卡，如果我們想要監(jiān)聽它的touch事件淀衣，就必須通過在該控件中重寫onTouchEvent方法來實現(xiàn)。
2.?為什么給ListView引入了一個滑動菜單的功能召调，ListView就不能滾動了膨桥？
如果你閱讀了Android滑動框架完全解析，教你如何一分鐘實現(xiàn)滑動菜單特效這篇文章唠叛，你應該會知道滑動菜單的功能是通過給ListView注冊了一個touch事件來實現(xiàn)的只嚣。如果你在onTouch方法里處理完了滑動邏輯后返回true，那么ListView本身的滾動事件就被屏蔽了艺沼，自然也就無法滑動(原理同前面例子中按鈕不能點擊)册舞，因此解決辦法就是在onTouch方法里返回false。
3.?為什么圖片輪播器里的圖片使用Button而不用ImageView障般？
提這個問題的朋友是看過了Android實現(xiàn)圖片滾動控件调鲸，含頁簽功能，讓你的應用像淘寶一樣炫起來這篇文章挽荡。當時我在圖片輪播器里使用Button藐石，主要就是因為Button是可點擊的，而ImageView是不可點擊的定拟。如果想要使用ImageView于微，可以有兩種改法。第一，在ImageView的onTouch方法里返回true株依，這樣可以保證ACTION_DOWN之后的其它action都能得到執(zhí)行驱证，才能實現(xiàn)圖片滾動的效果。第二恋腕，在布局文件里面給ImageView增加一個android:clickable="true"的屬性抹锄，這樣ImageView變成可點擊的之后，即使在onTouch里返回了false荠藤，ACTION_DOWN之后的其它action也是可以得到執(zhí)行的伙单。
今天的講解就到這里了，相信大家現(xiàn)在對Android事件分發(fā)機制又有了進一步的認識商源，在后面的文章中我會再帶大家一起探究Android中ViewGroup的事件分發(fā)機制车份，感興趣的朋友請繼續(xù)閱讀Android事件分發(fā)機制完全解析，帶你從源碼的角度徹底理解(下)牡彻。
