Android onTouchEvent, onClick及onLongClick的調(diào)
加入技術(shù)交流群
針對屏幕上的一個View控件，Android如何區(qū)分應(yīng)當(dāng)觸發(fā)onTouchEvent，還是onClick，亦或是onLongClick事件?
本文引用地址：http://www.ex-cimer.com/article/201609/303429.htm在Android中，一次用戶操作可以被不同的View按次序分別處理，并將完全響應(yīng)了用戶一次UI操作稱之為消費(fèi)了該事件(consume)，那么Android是按什么次序?qū)⑹录鬟f的呢?又在什么情況下判定為消費(fèi)了該事件?
搞清楚這些問題對于編寫出能正確響應(yīng)UI操作的代碼是很重要的，尤其當(dāng)屏幕上的不同View需要針對此次UI操作做出各種不同響應(yīng)的時(shí)候更是如此，一個典型例子就是用戶在桌面上放置了一個Widget，那么當(dāng)用戶針對widget做各種操作時(shí)，桌面本身有的時(shí)候要對用戶的操作做出響應(yīng)，有時(shí)忽略。只有搞清楚事件觸發(fā)和傳遞的機(jī)制才有可能保證在界面布局非常復(fù)雜的情況下，UI控件仍然能正確響應(yīng)用戶操作。
1. onTouchEvent
onTouchEvent中要處理的最常用的3個事件就是：ACTION_DOWN、ACTION_MOVE、ACTION_UP。
這三個事件標(biāo)識出了最基本的用戶觸摸屏幕的操作，含義也很清楚。雖然大家天天都在用它們，但是有一點(diǎn)請留意，ACTION_DOWN事件作為起始事件，它的重要性是要超過ACTION_MOVE和ACTION_UP的，如果發(fā)生了ACTION_MOVE或者ACTION_UP，那么一定曾經(jīng)發(fā)生了ACTION_DOWN。
從Android的源代碼中能看到基于這種不同重要性的理解而實(shí)現(xiàn)的一些交互機(jī)制，SDK中也有明確的提及，例如在ViewGroup的onInterceptTouchEvent方法中，如果在ACTION_DOWN事件中返回了true，那么后續(xù)的事件將直接發(fā)給onTouchEvent，而不是繼續(xù)發(fā)給onInterceptTouchEvent。
2. onClick、onLongClick與onTouchEvent
曾經(jīng)看過一篇帖子提到，如果在View中處理了onTouchEvent，那么就不用再處理onClick了，因?yàn)锳ndroid只會觸發(fā)其中一個方法。這個理解是不太正確的，針對某個view，用戶完成了一次觸碰操作，顯然從傳感器上得到的信號是手指按下和抬起兩個操作，我們可以理解為一次Click，也可以理解為發(fā)生了一次ACTION_DOWN和ACTION_UP，那么Android是如何理解和處理的呢?
在Android中，onClick、onLongClick的觸發(fā)是和ACTION_DOWN及ACTION_UP相關(guān)的，在時(shí)序上，如果我們在一個View中同時(shí)覆寫了onClick、onLongClick及onTouchEvent的話，onTouchEvent是最先捕捉到ACTION_DOWN和ACTION_UP事件的，其次才可能觸發(fā)onClick或者onLongClick。主要的邏輯在View.java中的onTouchEvent方法中實(shí)現(xiàn)的：
case MotionEvent.ACTION_DOWN:
mPrivateFlags |= PRESSED;
refreshDrawableState();
if ((mViewFlags LONG_CLICKABLE) == LONG_CLICKABLE) {
postCheckForLongClick();
}
break;
case MotionEvent.ACTION_UP:
if ((mPrivateFlags PRESSED) != 0) {
boolean focusTaken = false;
if (isFocusable() isFocusableInTouchMode() !isFocused()) {
focusTaken = requestFocus();
}
if (!mHasPerformedLongPress) {
if (mPendingCheckForLongPress != null) {
removeCallbacks(mPendingCheckForLongPress);
}
if (!focusTaken) {
performClick();
}
}
…
break;
可以看到，Click的觸發(fā)是在系統(tǒng)捕捉到ACTION_UP后發(fā)生并由performClick()執(zhí)行的，performClick里會調(diào)用先前注冊的監(jiān)聽器的onClick()方法：
public boolean performClick() {
…
if (mOnClickListener != null) {
playSoundEffect(SoundEffectConstants.CLICK);
mOnClickListener.onClick(this);
return true;
}
return false;
}
LongClick的觸發(fā)則是從ACTION_DOWN開始，由postCheckForLongClick()方法完成：
private void postCheckForLongClick() {
mHasPerformedLongPress = false;
if (mPendingCheckForLongPress == null) {
mPendingCheckForLongPress = new CheckForLongPress();
}
mPendingCheckForLongPress.rememberWindowAttachCount();
postDelayed(mPendingCheckForLongPress, ViewConfiguration.getLongPressTimeout());
}
可以看到，在ACTION_DOWN事件被捕捉后，系統(tǒng)會開始觸發(fā)一個postDelayed操作，delay的時(shí)間在Eclair2.1上為500ms，500ms后會觸發(fā)CheckForLongPress線程的執(zhí)行：
class CheckForLongPress implements Runnable {
…
public void run() {
if (isPressed() (mParent != null)
mOriginalWindowAttachCount == mWindowAttachCount) {
if (performLongClick()) {
mHasPerformedLongPress = true;
}
}
}
…
}
如果各種條件都滿足，那么在CheckForLongPress中執(zhí)行performLongClick()，在這個方法中將調(diào)用onLongClick()：
public boolean performLongClick() {
…
if (mOnLongClickListener != null) {
handled = mOnLongClickListener.onLongClick(View.this);
}
…
}
從實(shí)現(xiàn)中可以看到onClick()和onLongClick()方法是由ACTION_DOWN和ACTION_UP事件捕捉后根據(jù)各種情況最終確定是否觸發(fā)的，也就是說如果我們在一個Activity或者View中同時(shí)監(jiān)聽或者覆寫了onClick(),onLongClick()和onTouchEvent()方法，并不意味著只會發(fā)生其中一種。
下面是一個onClick被觸發(fā)的基本時(shí)序的Log：
04-05 05:57:47.123: DEBUG/TSActivity(209): onTouch ACTION_DOWN
04-05 05:57:47.263: DEBUG/TSActivity(209): onTouch ACTION_UP
04-05 05:57:47.323: DEBUG/TSActivity(209): onClick
可以看出是按ACTION_DOWN -> ACTION_UP -> onClick的次序發(fā)生的。
下面是一個onLongClick被觸發(fā)的基本時(shí)序的Log：
04-05 06:00:04.133: DEBUG/TSActivity(248): onTouch ACTION_DOWN
04-05 06:00:04.642: DEBUG/TSActivity(248): onLongClick
04-05 06:00:05.083: DEBUG/TSActivity(248): onTouch ACTION_UP
可以看到，在保持按下的狀態(tài)一定時(shí)間后會觸發(fā)onLongClick,之后抬起手才會發(fā)生ACTION_UP。
3. onClick和onLongClick能同時(shí)發(fā)生嗎?
要弄清楚這個問題只要理解Android對事件處理的所謂消費(fèi)(consume)概念即可，一個用戶的操作會被傳遞到不同的View控件和同一個控件的不同監(jiān)聽方法處理，任何一個接收并處理了該次事件的方法如果在處理完后返回了true，那么該次event就算被完全處理了，其他的View或者監(jiān)聽方法就不會再有機(jī)會處理該event了。
onLongClick的發(fā)生是由單獨(dú)的線程完成的，并且在ACTION_UP之前，而onClick的發(fā)生是在ACTION_UP后，因此同一次用戶touch操作就有可能既發(fā)生onLongClick又發(fā)生onClick。這樣是不是不可思議?所以及時(shí)向系統(tǒng)表示“我已經(jīng)完全處理(消費(fèi))了用戶的此次操作”，是很重要的事情。例如，我們?nèi)绻趏nLongClick()方法的最后return true，那么onClick事件就沒有機(jī)會被觸發(fā)了。
下面的Log是在onLongClick()方法return false的情況下，一次觸碰操作的基本時(shí)序：
04-05 06:00:53.023: DEBUG/TSActivity(277): onTouch ACTION_DOWN
04-05 06:00:53.533: DEBUG/TSActivity(277): onLongClick
04-05 06:00:55.603: DEBUG/TSActivity(277): onTouch ACTION_UP
04-05 06:00:55.663: DEBUG/TSActivity(277): onClick
可以看到，在ACTION_UP后仍然觸發(fā)了onClick()方法。
評論