Android開發(fā)中俺榆，在很多的滑動控件嵌套的情況下經(jīng)常會出現(xiàn)滑動事件沖突等等感昼。以及在自定義控件的時候，需要處理觸摸罐脊、點擊定嗓、滑動等事件。需要考慮父容器的這些事件的沖突問題萍桌，所以在面對這些問題的時候我們就需要了解Android的事件傳遞機制宵溅，了解系統(tǒng)的機制方面的問題，最有效的方式就是研究系統(tǒng)的實現(xiàn)源碼上炎。這篇我們就參照源碼來分析Android中的事件傳遞機制恃逻。
在Android中的事件 大量存在于Activity View ViewGroup Key 我們這里主要研究的是View和ViewGroup的事件傳遞
View的事件傳遞機制
我們先從一個栗子講起，先創(chuàng)建一個布局藕施，界面很簡單寇损，只有一個按鈕，我們通過觀察這個按鈕的點擊事件的日志輸出來觀察事件的傳遞
- activity.xml
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/rl"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">
<Button
android:id="@+id/btn"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="BUTTON" />
</RelativeLayout>
然后我們在activity中對父布局的RelativeLayout和Button的touch事件和點擊click事件進行監(jiān)聽裳食，RelativeLayout繼承自ViewGroup矛市，Button繼承自View所有兩個控件都有TouchEvent和Click事件，并分別輸出對應的log日志
- MainActivity.java
public class MainActivity extends AppCompatActivity implements View.OnTouchListener, View.OnClickListener {
private static final String TAG = "PROBUING";
private RelativeLayout rl;
private Button btn;
@SuppressLint("ClickableViewAccessibility")
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
rl = ((RelativeLayout) findViewById(R.id.rl));
btn = ((Button) findViewById(R.id.btn));
rl.setOnTouchListener(this);
rl.setOnClickListener(this);
btn.setOnTouchListener(this);
btn.setOnClickListener(this);
}
@Override
public boolean onTouch(View v, MotionEvent event) {
Log.d(TAG, "onTouch: event----" + event.getAction() + "view----" + v);
return false;
}
@Override
public void onClick(View v) {
Log.d(TAG, "onClick: view" + v);
}
}
我們運行起來項目诲祸。點擊按鈕浊吏，查看log日志輸出
我們可以看到OnTouchListener首先響應了事件，分別執(zhí)行了按下事件和松開事件烦绳。然后才執(zhí)行了Button的點擊事件onClick事件卿捎，觸摸事件先響應然后才響應onClick事件，而且是當松開按鈕的時候才響應觸摸事件径密，如果持續(xù)保持按壓狀態(tài)午阵，則按鈕不會響應按鈕的onClick事件
然后，我們將onTouch的返回值改為true。再次觀察一下log輸出
@Override
public boolean onTouch(View v, MotionEvent event) {
Log.d(TAG, "onTouchListener: event----" + event.getAction() + "view----" + v);
return true;
}
所以我們發(fā)現(xiàn)：在當onTouch返回為true的時候底桂，阻止了onClick的事件傳遞植袍，我們在前面已經(jīng)測試發(fā)現(xiàn)，只有在按鈕松開后才會響應onClick籽懦，也就是響應了ACTION_UP事件才會執(zhí)行于个。也可以說在onTouch返回true后，ACTION_UP事件沒有傳遞暮顺。這是怎么一回事呢厅篓？
我們需要先了解一下View的事件分發(fā)
View的事件分發(fā)
View的事件分發(fā)我們需要看一個方法 。我們通過View的事件分發(fā)的實現(xiàn)源碼來分析分發(fā)流程
首先捶码，View的事件分發(fā)流程是：由dispatchTouchEvent方法分發(fā)到對應的onTouchListener的onTouch方法羽氮，然后再分發(fā)到View自己的onTouchEvent，最后到onClick()
在view的dispathcTouchEvent方法的注釋中惫恼，對于返回值的解釋是
/**
* Pass the touch screen motion event down to the target view, or this
* view if it is the target.
*
* @param event The motion event to be dispatched.
* @return True if the event was handled by the view, false otherwise.
*/
public boolean dispatchTouchEvent(MotionEvent event) {
也就是說如果返回true表示view接受處理這個事件档押，如果返回false則表示不接受處理這個事件，我們再往下看在下面的邏輯中有這樣的邏輯
if (onFilterTouchEventForSecurity(event)) {
if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
result = true;
}
//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;
}
}
源碼分析 API28
其中ListenerInfo是View的內部類祈纯，這個類定義了各種的監(jiān)聽以及事件令宿，包括焦點變化監(jiān)聽，滾動變化監(jiān)聽腕窥，點擊事件監(jiān)聽等粒没。
這里的判斷邏輯就是，如果存在相關監(jiān)聽的事件也就是在之前setListener油昂，并且view的flag狀態(tài)是ENABLED也就是可以響應事件的革娄，還有 onTouch方法返回true，則改變result為true dispathcTouchEvent則返回true表示這個view需要處理這個事件冕碟。
在往下看拦惋，如果上面的這些條件都不滿足，此時result為false,那么下面的判斷安寺，如果View自身的onTouchEvent返回為true則也會將result=true也表示View需要處理事件厕妖。
這里我們也能看出，如果在第一個if判斷中設置了onTouchListener挑庶，并且onTouchListener的onTouch方法返回true言秸，那么view自身的onTouchEvent就不會再被調用了
所以我們可以看出view的事件分發(fā)順序就是
dispathcTouchEvent-->onTouchListener--->return false ---> onTouchEvent
如果view的事件響應設置為disable，則不會執(zhí)行onTouchListener的onTouch方法迎捺。但是會執(zhí)行View自身的onTouchEvent方法
但是我們沒有發(fā)現(xiàn)view的onClick方法的調用举畸，其實onClick在中，在判斷事件類型的swithc中凳枝，我們看ACTION_DOWN按下的事件抄沮，這里的邏輯是保存一些狀態(tài)跋核，記錄一些按鈕的信息，以及延遲一些反饋(感覺像5.0版本以上的水波紋效果)叛买，
在ACTION_UP抬起的事件中砂代，我們看到這樣的代碼
if (!mHasPerformedLongPress && !mIgnoreNextUpEvent) {
// 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)) {
performClickInternal();
}
}
}
在performClickInternal中調用了 performClick()方法，就是在這個方法中執(zhí)行了view的onClick方法
/**
* Entry point for {@link #performClick()} - other methods on View should call it instead of
* {@code performClick()} directly to make sure the autofill manager is notified when
* necessary (as subclasses could extend {@code performClick()} without calling the parent's
* method).
*/
private boolean performClickInternal() {
// Must notify autofill manager before performing the click actions to avoid scenarios where
// the app has a click listener that changes the state of views the autofill service might
// be interested on.
notifyAutofillManagerOnClick();
return performClick();
}
在performClick中率挣，可以看到如果設置了監(jiān)聽的話就會調用view的onClick方法刻伊。
public boolean performClick() {
// We still need to call this method to handle the cases where performClick() was called
// externally, instead of through performClickInternal()
notifyAutofillManagerOnClick();
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);
notifyEnterOrExitForAutoFillIfNeeded(true);
return result;
}
所以我們可以得出一個初步的結論。也就是說在view的onTouchEventListener中的onTouch()如果返回了true椒功，表示此次事件被處理捶箱，也就是按下的ACTION_DOWN事件被消耗，但是ACTION_UP事件無法傳遞執(zhí)行蛾茉，所以onClick不會執(zhí)行讼呢。
如果onTouchEventListener中的onTouch返回false撩鹿。則會執(zhí)行View自身的onTouchEvent方法谦炬，表示onTouch不會消耗事件，所以onClick點擊事件會響應节沦。
View事件分發(fā)調用順序
我們在了解了View的源碼事件分發(fā)的基本情況后键思，那么我們需要驗證一下事件的分發(fā)順序是否和我們觀測到的是一致的呢，我們使用一個自定義的控件來驗證一下猜想
- MyButton.java
/**
* @author wxblack-mac
* @DESCRIBE:
* @DATE 2019/3/27 18:25
* GOOD LUCK
*/
@SuppressLint("AppCompatCustomView")
public class MyButton extends Button {
public MyButton(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
Log.d(TAG, "dispatchTouchEvent: dispatchTouch" + event.getAction());
return super.dispatchTouchEvent(event);
}
@Override
public boolean onTouchEvent(MotionEvent event) {
Log.d(TAG, "onTouchEvent: action:" + event.getAction());
return super.onTouchEvent(event);
}
}
然后再修改布局文件
- activity_main.xml
<com.d9ing.toucheventlsn.MyButton
android:id="@+id/btn"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="BUTTON" />
onTouch返回true
我們先將onTouchEventListener的onTouch方法返回true看點擊事件click是否執(zhí)行,以及執(zhí)行順序
我們看到按鈕點擊后的日志打印是：
dispathcTouchEvent---->onTouch
沒有看到onTouchEvent執(zhí)行甫贯，也沒有onClick執(zhí)行吼鳞。所以當onTouchEventListener的onTouch返回為true的時候事件會被消費，所以不會執(zhí)行onTouchEvent方法叫搁。不會響應點擊事件赔桌。
onTouch返回false
我們再將onTouchEventListener的onTouch方法返回false看一下事件的分發(fā)順序以及響應：
我們可以看到，事件的傳遞順序是：
dispatchTouchEvent---->onTouchListener的onTouch---->onTouchEvent---->onClick
從上面的執(zhí)行順序來看和我們的猜想是一致的渴逻。
onTouchEvent 返回true
接下來我們將MyButton的onTouchEvent的返回結果改為true看一下結果
我們看到onClick事件沒有響應了疾党，DOWN事件消費了，UP事件也分發(fā)了但是沒有執(zhí)行onClick惨奕，這種結果是怎么出現(xiàn)的呢雪位？
通過剛才我們分析源碼得知，事件的響應和調用事件方法是在View的onTouchEvent方法梨撞，可我們重寫了View的onTouchEvent方法后雹洗，但沒有執(zhí)行父類View的事件處理方法，這樣的話就不會有任何的事件被響應卧波。在dispathcTouchEvent中調用了onTouchEvent后时肿，執(zhí)行我們自定義的方法 返回了true，所以不會有onClick執(zhí)行港粱。
那么螃成，我們在返回true之前調用super.onTouchEvent呢？
@Override
public boolean onTouchEvent(MotionEvent event) {
Log.d(TAG, "onTouchEvent: action:" + event.getAction());
super.onTouchEvent(event);
return true;
}
我們看到執(zhí)行就正常了，所以我們重寫onTouchEvent需要執(zhí)行super的onTouchEvent方法锈颗，才能將事件響應顷霹。
onTouchEvent 返回false
那么我們將onTouchEvent的返回false是什么情況呢？
我們看到在按下事件DOWN方法被消費击吱，但是后續(xù)的UP事件被父類消費了淋淀，這是為什么呢？
這就是
- 如果onTouchEvent返回true表示View會消費DOWN按下事件以及以后的事件覆醇。
- 如果onTouchEvent返回false表示View會消費DOWN事件朵纷，并不在響應后續(xù)的事件。自己不消耗后續(xù)的事件后會向父控件傳遞事件永脓。
關于父控件的袍辞，會在下一個篇章中說明
dispatchTouchEvent 返回true
如果我們將MyButton的dispatchTouchEvent返回true,會發(fā)生什么情況呢？
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
Log.d(TAG, "dispatchTouchEvent: dispatchTouch" + event.getAction());
super.dispatchTouchEvent(event);
return true;
}
這里和onTouchEvent一樣常摧，需要調用父類的dispatchTouchEvent搅吁，來保證父類的邏輯執(zhí)行。
我們可以看到事件分發(fā)執(zhí)行正常為：
dispatchTouchEvent--->onTouch--->onTouchEvent---->onClick
事件DOWN和UP都被MyButton消費
其實在源碼中已經(jīng)解釋了落午，會默認返回true
//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;
}
dispatchTouchEvent返回false
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
Log.d(TAG, "dispatchTouchEvent: dispatchTouch" + event.getAction());
super.dispatchTouchEvent(event);
return false;
}
可以看到谎懦，DOWN事件MyButton沒有消費，直接發(fā)給了父類容器溃斋。后續(xù)的事件都發(fā)給了父容器
所以我們可以知道dispatchTouchEvent默認返回true
如果在某個控件的dispatchTouchEvent 返回true消費終結事件界拦，那么收到ACTION_DOWN 的函數(shù)也能收到ACTION_MOVE和ACTION_UP。
在哪個View的onTouchEvent 返回true梗劫，那么ACTION_MOVE和ACTION_UP的事件從上往下傳到這個View后就不再往下傳遞了享甸，而直接傳給自己的onTouchEvent 并結束本次事件傳遞過程。
ACTION_DOWN事件在哪個控件消費了（return true）梳侨， 那么ACTION_MOVE和ACTION_UP就會從上往下（通過dispatchTouchEvent）做事件分發(fā)往下傳蛉威，就只會傳到這個控件，不會繼續(xù)往下傳
如果ACTION_DOWN事件是在dispatchTouchEvent消費猫妙，那么事件到此為止停止傳遞
如果ACTION_DOWN事件是在onTouchEvent消費的瓷翻，那么會把ACTION_MOVE或ACTION_UP事件傳給該控件的onTouchEvent處理并結束傳遞。
