主頁 > 移動端開發 > 看完全都會了！Android-事件體系全面總結+實踐分析

看完全都會了！Android-事件體系全面總結+實踐分析

2021-06-15 07:23:22 移動端開發

在這之前看了很多相關文章，有一個整體認識以后，就要開始動手體驗一下了，動手之前要明確事件分發機制要研究的是什么：事件序列在ViewGroup/View之間的傳遞規則，
注意幾點：

  • 研究的是事件序列而不是單個事件
  • 至少要考慮到一個ViewGroup和一個View
  • 傳遞或者說分發包括父View向子View傳遞事件（事件下發程序）和子View向父View傳遞事件（事件消費程序），

舉例說明一下為什么要考慮上面這幾點，如果事件傳到了一個沒有子View的View里面，這時view的onTouchEvent()會被回呼，我們可以通過重寫onTouchEvent()的回傳值來決定是否消費這個事件，如果這個事件是down，而onTouchEvent()回傳false不消費它，那么事件序列后面的事件都不再分發給這個View，如果消費了down事件，那么后續事件會繼續分發給這個View，這時，如果不消費后續事件的某個move事件，那么這個move事件后面的事件依然會分發給這個View，
由此可見，對事件序列里某個事件的消費情況是會影響后續事件的分發的，
另一方面，如果這個View沒消費down事件，那么會一層層往上回呼父View的onTouchEvent()將down事件傳遞給父View，所以事件的消費也是一個傳遞事件的程序，

上面的例子是通過撰寫代碼驗證的一個事實，至于原因，會在文中詳細分析，這里只為說明需要考慮上面的幾個注意點，

雖然事件體系很復雜，但是是有規律可循的，我們實踐的目的就是尋找這個規律，根據我的理解，畫了一張圖作為Android事件機制的一個總結：

由圖可以看到將整個流程分為了4種情況，下面將通過實踐詳細分析這4種情況，包括為什么這樣劃分，其他更多的情況如何歸類排除等，

首先實作下圖界面，界面每一層View的dispatchTouchEvent()，onInterceptTouchEvent()，onTouchEvent()三個方法中加上相應的log并回傳默認的super，也可以使用這份代碼：示例代碼，圖中，我們可以把Activity看作是頂級父View，

然后研究 Android 事件分發流程圖中的4種情況：

  1. 默認情況，全部回傳super，默認情況是不攔截不消費事件的，
  2. View的onTouchEvent()消費down事件，其他默認，
  3. ViewGroup2的onTouchEvent()消費down事件，其他默認，
  4. ViewGroup2的onInterceptTouchEvent()攔截down之后的事件，

消費事件指onTouchEvent()回傳true，攔截事件指onInterceptTouchEvent()回傳true，從4種情況可以看出，將一個事件序列的ACTION_DOWN和ACTION_DOWN之后的事件分開考慮了，分析完原始碼之后就會明白為什么這樣做，

下面開始結合log分析4種情況，為了方便查看和描述，我會把log用空行分為三部分，第一部分是down事件，第二部分是move事件，第三部分是up事件，

情況1：默認情況，全部回傳super，默認情況是不攔截不消費事件的，

( 1955): MainActivity->dispatchTouchEvent
( 1955): MyViewGroup1-->dispatchTouchEvent
( 1955): MyViewGroup1-->onInterceptTouchEvent
( 1955): MyViewGroup2--->dispatchTouchEvent
( 1955): MyViewGroup2--->onInterceptTouchEvent
( 1955): MyView--------------->dispatchTouchEvent    //down事件下發程序結束
( 1955): MyView--------------->onTouchEvent    // down事件消費程序開始
( 1955): MyViewGroup2--->onTouchEvent
( 1955): MyViewGroup1-->onTouchEvent
( 1955): MainActivity->onTouchEvent

( 1955): MainActivity->dispatchTouchEvent  //move1事件
( 1955): MainActivity->onTouchEvent
( 1955): MainActivity->dispatchTouchEvent //move2事件
( 1955): MainActivity->onTouchEvent

( 1955): MainActivity->dispatchTouchEvent   //up事件
( 1955): MainActivity->onTouchEvent

上面的log我手動加了幾個注釋，默認情況下Activity/ViewGroup/View不攔截不消費事件，由log很容易看出，down事件經歷了一下一上的程序，下是分發程序，上是消費程序，如果下發無人攔截，事件會一直向下傳遞到子View，如果子View不消費事件，會傳給父View去消費，即依次回呼父View的onTouchEvent，
然后就是move和up事件，log很簡單，因為down事件子View們無人消費，那么事件序列里面的后續事件也就不再下發了，直接頂級Activity（DecorView）自己來處理，
為什么后續事件不再下發給子View，答案在原始碼里，接下來開始分析原始碼，

下面是ViewGroup的dispatchTouchEvent()方法，只保留了關鍵代碼，其中if陳述句都是完整的，可以通過if陳述句在完整原始碼中定位代碼，數字編號的注釋是 ACTION_DOWN事件的下發程序，注意是down事件的下發程序，

public boolean dispatchTouchEvent(MotionEvent ev) {

    boolean handled = false;
    if (onFilterTouchEventForSecurity(ev)) {
        //1.首先如果是down事件，reset 一些狀態，其中包括將mFirstTouchTarget置空
        if (actionMasked == MotionEvent.ACTION_DOWN) {
            cancelAndClearTouchTargets(ev);
            resetTouchState();
        }

        //2.是否攔截事件，用布爾變數intercepted表示
        final boolean intercepted;
        if (actionMasked == MotionEvent.ACTION_DOWN
                || mFirstTouchTarget != null) {
            final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
            if (!disallowIntercept) {
                //這里呼叫onInterceptTouchEvent()看是否攔截事件
                intercepted = onInterceptTouchEvent(ev);
                ev.setAction(action);
            } else {
                intercepted = false;
            }
        } else {//如果mFirstTouchTarget是空，而且當前事件不是ACTION_DOWN，就攔截事件
                //注意此處直接給intercepted賦值而沒有呼叫onInterceptTouchEvent()方法
            intercepted = true;
        }

        // 3.得到intercepted之后，如果不攔截，進入這個if
        if (!canceled && !intercepted) {
            //4.如果是down事件，進入這個if
            if (actionMasked == MotionEvent.ACTION_DOWN
                    || (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
                    || actionMasked == MotionEvent.ACTION_HOVER_MOVE) {
                //5.newTouchTarget是這個方法里面定義的，默認是空，進入這個if
                if (newTouchTarget == null && childrenCount != 0) {
                    //6.回圈，尋找處理事件的子View
                    for (int i = childrenCount - 1; i >= 0; i--) {
                        //7.注意這個if里面的dispatchTransformedTouchEvent方法，里面呼叫了子View的dispatchTouchEvent方法
                        //  呼叫子View的dispatchTouchEvent方法即把事件傳給了子View去處理，
                        //  這時先走一遍子View里的dispatchTouchEvent邏輯并回傳一個布林值表示是否消費掉了事件,
                        //  如果子View的dispatchTouchEvent回傳true說明子View消費事件，進入這個if，否則沒消費不進入此if
                        if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
                            //8.如果子View消費了事件，那么給mFirstTouchTarget賦值
                            //  給mFirstTouchTarget賦值的操作在addTouchTarget()方法里
                            newTouchTarget = addTouchTarget(child, idBitsToAssign);
                            break;
                        }
                    }
                }
            }
        }

        //在編號7的if條件里面已經把事件下發到了子View，并得到了子View回傳的結果
        //至此，默認情況下發事件的邏輯結束

        //下面消費事件相關的代碼，省略
    }

    //最后回傳結果，此方法結束
    return handled;
    //至此，如果編號8的代碼沒執行，也就是子View的dispatchTouchEvent沒消費事件，那么mFirstTouchTarget的值是空
    //結合編號3的條件，可以得出結論：當ViewGroup不攔截事件且它的子View消費事件的時候，mFirstTouchTarget不為空，否則mFirstTouchTarget是空，
}

代碼中注釋很詳細，最終可以得到一個結論：當ViewGroup不攔截down事件且它的子View消費down事件的時候，mFirstTouchTarget不為空，否則mFirstTouchTarget是空，

下面帶著這個結論重新看原始碼，不過這次分析的不是down事件，而是down之后的事件，只看關鍵部分，上面代碼的編號2部分如下：

///2.是否攔截事件，用布爾變數intercepted表示
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
        || mFirstTouchTarget != null) {
    final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
    if (!disallowIntercept) {
        //這里呼叫onInterceptTouchEvent()看是否攔截事件
        intercepted = onInterceptTouchEvent(ev);
        ev.setAction(action);
    } else {
        intercepted = false;
    }
} else {//如果mFirstTouchTarget是空，而且當前事件不是ACTION_DOWN，就攔截事件
        //注意此處直接給intercepted賦值而沒有呼叫onInterceptTouchEvent()方法
    intercepted = true;
}

首先if里面的actionMasked == MotionEvent.ACTION_DOWN肯定是不成立了，看mFirstTouchTarget != null，如果mFirstTouchTarget不是空，那么說明子View消費了down事件，會執行到intercepted = onInterceptTouchEvent(ev);這一行代碼，如果mFirstTouchTarget是空，說明子View沒消費down事件，直接else里面intercepted = true;攔截事件，然后看默認情況下的log：

( 1955): MainActivity->dispatchTouchEvent
( 1955): MyViewGroup1-->dispatchTouchEvent
( 1955): MyViewGroup1-->onInterceptTouchEvent
( 1955): MyViewGroup2--->dispatchTouchEvent
( 1955): MyViewGroup2--->onInterceptTouchEvent
( 1955): MyView--------------->dispatchTouchEvent    //down事件下發程序結束
( 1955): MyView--------------->onTouchEvent    // down事件消費程序開始
( 1955): MyViewGroup2--->onTouchEvent
( 1955): MyViewGroup1-->onTouchEvent
( 1955): MainActivity->onTouchEvent

( 1955): MainActivity->dispatchTouchEvent  //move1事件
( 1955): MainActivity->onTouchEvent
( 1955): MainActivity->dispatchTouchEvent //move2事件
( 1955): MainActivity->onTouchEvent

( 1955): MainActivity->dispatchTouchEvent   //up事件
( 1955): MainActivity->onTouchEvent

這里頂級的ViewGroup是MainActivity（DecorView），首先down事件下發到子View，然后子View沒消費它，又一層層交給父View消費，最終無人消費傳回了MainActivity，down事件結束，由上面的原始碼分析可知，這時的mFirstTouchTarget是空，如果move事件來了，那么直接執行原始碼編號2部分的else攔截事件，所以后續事件的log就是上面這樣不再下發（同時也沒有onInterceptTouchEvent()方法的log因為沒呼叫到它），如果子View消費down事件，mFirstTouchTarget就不是空，后續事件的流程就與down相似了，讀者可以修改MyView的onTouchEvent()消費掉down事件試一下消費down事件的情況，

對于后續事件，無非就是攔截不攔截，決定權還是在編號2部分的代碼，決定的結果是是否進入編號3的if，進入的話，如果不是down事件的就直接跳出編號3的if了，

擴展：由上面的分析可知，dispatchTouchEvent()方法是由父View呼叫的，子View是通過這個方法的回傳值來告訴父View是否消費事件了，這個大家都知道，但是，考慮一個問題，Activity -> ViewGroup1 -> ViewGroup2 -> View，如果事件按這個順序下發，最終View消費了down事件，那么Activity如何知道View是否消費事件呢，程序必然是這樣
View.dispatchTouchEvent() 回傳 true ->
ViewGroup2.dispatchTouchEvent() 回傳 true ->
ViewGroup1.dispatchTouchEvent() 回傳 true ->
Activity得到ViewGroup1.dispatchTouchEvent() 回傳 true后就是上面分析的原始碼流程了，

**這個程序只是猜測，我沒有深入分析原始碼，不過我打了個log，結果是一系列的dispatchTouchEvent()確實是回傳了true，**也就是說ViewGroup1和ViewGroup2并沒有消費事件，dispatchTouchEvent()卻回傳了true，那么網上的一種說法：dispatchTouchEvent()回傳true就是消費事件，這種說法或許并不完全準確，具體還需去原始碼找答案，這里先不分析了，只是說明一個問題：不要輕易重寫dispatchTouchEvent()，就算重寫，也要盡量保證呼叫到super方法并且回傳值與super結果一致，其實，原始碼已經提供了兩個介面來間接的重寫它，就是onInterceptTouchEvent()和onTouchEvent()，通過原始碼可以知道它們最終都是dispatchTouchEvent()來呼叫的，而且用onTouchEvent()的回傳值來描述是否消費事件是沒有問題的（不消費事件的View根本呼叫不到onTouchEvent()），

針對默認情況下的log的原始碼分析到此結束，理解了默認情況，后面3種情況就簡單了，

情況2：View的onTouchEvent()消費down事件，其他默認

（這里說的View是界面圖里的最小的子View，不是ViewGroup1或ViewGroup2）
先分析一下，由上面的默認情況來看，對于事件機制只研究單個事件是不能說明問題的，需要看整個事件序列里每個事件是如何處理的，所以研究事件消費需要考慮以下幾種情況：

說明一下上圖，對于圖中第1點不消費down事件，其實就是情況1（默認情況），由情況1的log可以看出，不消費down事件的時候，后續事件不再分發給該View，所以圖中分支1對于View來說不用再考慮后續事件，
然后看圖中2,3,4,5分支，通過前面的Android事件分發流程圖可以看出，它們可以得出同一個結論，所以它們可以看成是一種情況，
分析至此，只有情況1和情況2兩種情況，對于2,3,4,5分支得出結論？這里拿圖中分支5來舉例，修改MyView的onTouchEvent()的代碼如下：

int x = 0;
@Override
public boolean onTouchEvent(MotionEvent event) {
    if (event.getAction() == MotionEvent.ACTION_DOWN) {
        x = 0;
        Log.d(TAG, "MyView--------------->onTouchEvent  x=" + x);
        return true;
    }
    x++;
    Log.d(TAG, "MyView--------------->onTouchEvent  x=" + x);
    if (x == 3) {
        return true;
    }
    if (x == 5) {
        return true;
    }
    return super.onTouchEvent(event);
}

代碼不難理解，實作了MyView消費事件序列里的down事件和第3個，第5個事件（從0開始計數），其他事件都不消費，同時，為了方便查看，在log中列印出了x的值，log如下（每個事件的log用空行分開了）：

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent
( 1888): MyView--------------->dispatchTouchEvent   // 下發程序結束
( 1888): MyView--------------->onTouchEvent  x=0    //  消費程序開始

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent
( 1888): MyView--------------->dispatchTouchEvent   // 下發程序結束
( 1888): MyView--------------->onTouchEvent  x=1    //  消費程序開始
( 1888): MainActivity->onTouchEvent

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent
( 1888): MyView--------------->dispatchTouchEvent   // 下發程序結束
( 1888): MyView--------------->onTouchEvent  x=2    //  消費程序開始
( 1888): MainActivity->onTouchEvent

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent
( 1888): MyView--------------->dispatchTouchEvent   // 下發程序結束
( 1888): MyView--------------->onTouchEvent  x=3    //  消費程序開始

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent
( 1888): MyView--------------->dispatchTouchEvent   // 下發程序結束
( 1888): MyView--------------->onTouchEvent  x=4    //  消費程序開始
( 1888): MainActivity->onTouchEvent

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent
( 1888): MyView--------------->dispatchTouchEvent   // 下發程序結束
( 1888): MyView--------------->onTouchEvent  x=5    //  消費程序開始

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent
( 1888): MyView--------------->dispatchTouchEvent   // 下發程序結束
( 1888): MyView--------------->onTouchEvent  x=6    //  消費程序開始
( 1888): MainActivity->onTouchEvent

上面log一共7個事件，雖然log很長，其實很簡單，主要分為兩類：MyView消費的和MyView沒消費的，其中x=0,3,5是消費的，其他未消費，下發程序 log 中的所有事件全部一樣（和默認情況下的down事件也一樣），為什么每次都會呼叫onInterceptTouchEvent()，通過原始碼分析也已經很清楚了，消費程序的規律也很明顯，x=0,3,5的事件消費掉就沒了，其他沒消費的事件直接傳給頂級父View而不是一層層傳回去，

情況3：ViewGroup2的onTouchEvent()消費down事件

首先，由情況1的log可以看出（如果理解了默認情況，這時候是沒必要回去翻log的，腦中自然形成），要想出現當前的情況3，首先得讓View的onTouchEvent()不消費down事件（如果消費就是情況2了，已經分析完），同時，由于View的onTouchEvent()不消費down事件，那么后續事件都不再傳給View，也就是說沒View什么事了，所以界面相當于變成了下圖這樣：

看圖和標題發現了什么，變成情況2了，那就簡單了，直接看log，下面是ViewGroup2的onTouchEvent()消費down事件，后續事件都不消費的log（相當于情況2那個圖的分支2，可以順便驗證上面分支5得出的結論）：

( 2008): MainActivity->dispatchTouchEvent
( 2008): MyViewGroup1-->dispatchTouchEvent
( 2008): MyViewGroup1-->onInterceptTouchEvent
( 2008): MyViewGroup2--->dispatchTouchEvent
( 2008): MyViewGroup2--->onInterceptTouchEvent
( 2008): MyView--------------->dispatchTouchEvent
( 2008): MyView--------------->onTouchEvent
( 2008): MyViewGroup2--->onTouchEvent

( 2008): MainActivity->dispatchTouchEvent
( 2008): MyViewGroup1-->dispatchTouchEvent
( 2008): MyViewGroup1-->onInterceptTouchEvent
( 2008): MyViewGroup2--->dispatchTouchEvent
( 2008): MyViewGroup2--->onTouchEvent
( 2008): MainActivity->onTouchEvent

( 2008): MainActivity->dispatchTouchEvent
( 2008): MyViewGroup1-->dispatchTouchEvent
( 2008): MyViewGroup1-->onInterceptTouchEvent
( 2008): MyViewGroup2--->dispatchTouchEvent
( 2008): MyViewGroup2--->onTouchEvent
( 2008): MainActivity->onTouchEvent

( 2008): MainActivity->dispatchTouchEvent
( 2008): MyViewGroup1-->dispatchTouchEvent
( 2008): MyViewGroup1-->onInterceptTouchEvent
( 2008): MyViewGroup2--->dispatchTouchEvent
( 2008): MyViewGroup2--->onTouchEvent
( 2008): MainActivity->onTouchEvent

log中需要注意down事件經歷了一次MyView的onTouchEvent()方法，down之后的事件不再執行ViewGroup2的onInterceptTouchEvent()方法，原因在原始碼分析中已經給出，結論在前兩種情況已經得出，沒什么好解釋的了，

由上面分析可知，本情況是可以算成情況2的，只是感覺單獨把它分出來邏輯更清楚合理一些，分析情況4的時候也會解釋一些原因，同時，這也是對前兩種情況的一個運用，如果理解了情況1和情況2，其他很多本文沒提到的情況都能解釋通的，

情況4：ViewGroup2的onInterceptTouchEvent()攔截down之后的事件

前面研究的都是onTouchEvent()消費相關的情況，這里研究onInterceptTouchEvent()事件下發攔截，

首先仔細看標題，為什么不考慮攔截down事件而只考慮攔截down之后的事件，因為攔截down事件之后，事件直接交給自身的onTouchEvent()處理，不再經過子View，也就變成了情況3的界面（注意這里是變成情況3的界面而不是變成情況3，內部流程與情況3是有區別的，后面解釋），變成了情況3的界面之后，回呼到自身的onTouchEvent()又分為不消費down和消費down：不消費down就是情況1；消費down就是情況2，

這里解釋為什么 “是變成情況3的界面而不是變成情況3”，這里的情況是ViewGroup2的onInterceptTouchEvent()攔截down之后，down直接交給ViewGroup2的onTouchEvent()去消費，而情況3是沒有攔截，down事件先去子View溜了一圈，發現子View不消費它，然后才傳遞給父親ViewGroup2去消費，
說明了有兩種方式可以讓ViewGroup2消費到down事件，這也是把情況3從情況2分離出來的一個原因，

上面的分析說明攔截down后必然出現前面的三種情況之一，所以這里不再考慮攔截down，下面看看攔截down之后的事件會有什么不同，
修改ViewGroup2的onInterceptTouchEvent()代碼如下：

int x = 0;
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
    Log.d(TAG, "MyViewGroup2--->onInterceptTouchEvent x="+x);
    if (x==3) {
        x++;
        return true;
    }
    x++;
    return super.onInterceptTouchEvent(ev);
}

代碼很簡單，當x==3的時候攔截事件，也就是攔截事件序列里的第4個事件，log如下：

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent x=0
( 1888): MyView--------------->dispatchTouchEvent
( 1888): MyView--------------->onTouchEvent

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent x=1
( 1888): MyView--------------->dispatchTouchEvent
( 1888): MyView--------------->onTouchEvent

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent x=2
( 1888): MyView--------------->dispatchTouchEvent
( 1888): MyView--------------->onTouchEvent

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onInterceptTouchEvent x=3
( 1888): MyView--------------->dispatchTouchEvent
( 1888): MyView--------------->onTouchEvent

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onTouchEvent
( 1888): MainActivity->onTouchEvent

( 1888): MainActivity->dispatchTouchEvent
( 1888): MyViewGroup1-->dispatchTouchEvent
( 1888): MyViewGroup1-->onInterceptTouchEvent
( 1888): MyViewGroup2--->dispatchTouchEvent
( 1888): MyViewGroup2--->onTouchEvent
( 1888): MainActivity->onTouchEvent

log需要分析3個地方：

1. x=3之前的事件，很好理解，就是情況2，

2. x=3的時候的事件，x=3的時候ViewGroup2已經攔截事件了，為什么MyView還是收到了一個事件？如果用log把MyView收到的這個事件的action值列印出來的話發現它是ACTION_CANCEL這個事件，它表示非人為原因結束本次事件，對于ACTION_CANCEL事件我舉一個例子，一般我們處理事件的時候會在down事件記錄一些東西，然后在up事件清掉記錄，那么如果在ListView中有一個Button，我們按住Button的時候按鈕收到down事件，這時手指開始滑動，事件就會被ListView攔截處理了，這時候按鈕就再也收不到up事件了，但是ListView攔截事件的時候按鈕會收到cancel事件表示非人為原因結束本次事件，所以這時可以把up事件要做的事情讓cancel來做，

3. x=3之后的事件，代碼中只改了onInterceptTouchEvent()，而onTouchEvent()是默認回傳，也就是說ViewGroup2攔截事件之后并沒有消費，從log也可以看出，每個事件都傳回了Activity，但是，ViewGroup2不消費事件為什么后續事件還是不斷的分發給ViewGroup2，而且執行到它的onTouchEvent()方法？（看似好像違背了默認情況的規則），這是一個問題，也是需要注意的一點，
首先，事件為什么分發到ViewGroup2？其實原始碼分析中已經解釋了，當有子View消費掉down事件后，（MainActivity的）mFirstTouchTarget就不再是空，后續事件都會被下發到子View（遞回），除非父View的onInterceptTouchEvent()主動攔截事件，而例子中ViewGroup2的父View和Actvity并沒有攔截事件，
然后是為什么總是調到ViewGroup2的onTouchEvent()方法，原因是ViewGroup2沒有處理事件的子View了，所以會呼叫到ViewGroup2的super.dispatchTouchEvent()，也就是呼叫父類View.dispatchTouchEvent()方法，所以如果沒有設定onTouchListener就必然會呼叫到onTouchEvent()了，

結束語

文章到這里就分析完了，這時候再看Android事件分發流程圖，此圖就是根據上面4種情況畫出來的，如果理解了那4種情況（至少要做到給出一種攔截消費方式，能想到每個事件的log是什么樣的），那么看懂這張圖應該是不難的，

關于結論，這里就不給出純文字描述了（即使描述出來也是很復雜的，一堆if），《Android開發藝術探索》中給了11條結論，有興趣的可以看一下，但是，上圖中有一些文字描述，可以當作結論，主要是綠色箭頭對應的兩部分，描述的是各個事件最終的去向，圖中的各個分支箭頭，就是各種情況下的條件，

最后，文中有沒考慮到的情況或不對的地方歡迎留言討論，另外，對于原始碼，文中只給出了下發程序的分析，消費程序就不再給出詳細分析了，提供一個思路，文中的原始碼分析里有一行注釋 //下面消費事件相關的代碼，省略，讀者可以從這里開始看消費相關的代碼，注意這是ViewGroup類里的dispatchTouchEvent()，這行注釋下面會有相關的邏輯呼叫到dispatchTransformedTouchEvent()這個方法（下發程序也調到了這個方法），這個方法里會有super.dispatchTouchEvent(event)這樣的代碼呼叫到ViewGroup類的父類View里面的dispatchTouchEvent()，然后看View里面的dispatchTouchEvent()，就會發現onTouchEvent()被呼叫了，同時也會發現一些其他的東西，比如onTouchListener()和onTouchEvent()的優先級，
關于dispatchTransformedTouchEvent()再解釋一下，里面有兩種代碼：super.dispatchTouchEvent(event)和child.dispatchTouchEvent(event)，簡單理解，前者就是呼叫ViewGroup自身的onTouchEvent()去消費，后者是將事件分發給（界面上的）子View去處理，如果子View是ViewGroup，那么子View處理事件的流程和父View類似，從ViewGroup的dispatchTouchEvent()開始執行；如果子View不是ViewGroup，那么直接執行View的dispatchTouchEvent()邏輯，而View的dispatchTouchEvent()里并沒有將事件傳給父View去消費的代碼，其實消費程序事件不是傳遞的，而是根據子View的dispatchTouchEvent()回傳值和一些ViewGroup自身的記錄來決定是否呼叫super.dispatchTouchEvent(event)來呼叫自身的onTouchEvent()，好了，思路就提供到這里，

解釋一個問題：

問題：情況２分析中最后一段話“消費程序的規律也很明顯，x=0,3,5的事件消費掉就沒了，其他沒消費的事件直接傳給頂級父View而不是一層層傳回去，” 這里是為什么呢？

先看下Activity里面的dispatchTouchEvent()原始碼

public boolean dispatchTouchEvent(MotionEvent ev) {
    if (ev.getAction() == MotionEvent.ACTION_DOWN) {
        onUserInteraction();
    }
    if (getWindow().superDispatchTouchEvent(ev)) {
        return true;
    }
    return onTouchEvent(ev);
}

不難看出activity的onTouchEvent()能否被呼叫取決于if條件getWindow().superDispatchTouchEvent(ev)，
從前面的原始碼分析那可以知道一點：dispatchTouchEvent()方法是由父View呼叫的，子View是通過這個方法的回傳值來告訴父View是否消費事件了（具體看原始碼分析編號7那里，還有情況1末尾的擴展那一部分），
所以在這個問題中，對于不消費的事件，每一層View/ViewGroup的dispatchTouchEvent()回傳值如下：
MyView.dispatchTouchEvent() 回傳 false ->
ViewGroup2.dispatchTouchEvent() 回傳 false ->
ViewGroup1.dispatchTouchEvent() 回傳 false ->
…
最終根View，DecorView.dispatchTouchEvent() 回傳 false

這個程序由于每個View都不消費事件，它們的onTouchEvent()都沒被呼叫到，具體的代碼就不分析了，

然后看Activity的dispatchTouchEvent()原始碼，getWindow().superDispatchTouchEvent(ev)，這個方法是Window抽象類類的方法，大家都知道Window的實作類是PhoneWindow，所以直接看PhoneWindow的superDispatchTouchEvent()方法:

public boolean superDispatchTouchEvent(MotionEvent event) {
    return mDecor.superDispatchTouchEvent(event);
}

ctrl+左鍵跳到DecorView.java的superDispatchTouchEvent()方法

public boolean superDispatchTouchEvent(MotionEvent event) {
    return super.dispatchTouchEvent(event);
}

ctrl+左鍵再跳就是ViewGroup的dispatchTouchEvent()方法，上面說了，對于不消費的事件，這一系列的方法都回傳false，所以最終Activity的dispatchTouchEvent()方法里面，if(getWindow().superDispatchTouchEvent(ev))條件是false，執行return onTouchEvent(ev);

最后

如果你覺得文章寫得不錯就給個贊唄？如果你覺得那里值得改進的，請給我留言，一定會認真查詢，修正不足，謝謝，

希望讀到這的您能轉發分享和關注一下我，以后還會更新技術干貨，謝謝您的支持！

轉發+點贊+關注，第一時間獲取最新知識點

Android架構師之路很漫長，一起共勉吧！

以下墻裂推薦閱讀！！！

  • Android學習筆記參考（敲黑板！！）
  • “寒冬未過”，阿里P9架構分享Android必備技術點，讓你offer拿到手軟！
  • 畢業3年，我是如何從年薪10W的拖拽工程師成為30W資深Android開發者！
  • 騰訊T3大牛帶你了解 2019 Android開發趨勢及必備技術點！
  • 八年Android開發，從碼農到架構師分享我的技術成長之路，共勉！

最后祝大家生活愉快~

尾聲

評論里面有些同學有疑問關于如何學習material design控制元件，我的建議是去GitHub搜，有很多同行給的例子，這些栗子足夠入門，

有朋友說要是動真格的話，需要NDK以及JVM等的知識，首現**NDK并不是神秘的東西，**你跟著官方的步驟走一遍就知道什么回事了，無非就是一些代碼格式以及原生/JAVA記憶體互動，進階一點的有原生/JAVA執行緒互動，執行緒互動確實有點蛋疼，但平常避免用就好了，再說對于初學者來說關心NDK干嘛，據鄙人以前的經歷，只在音視頻通信和一個嵌入式信號處理（離線）的兩個專案中用過，嵌入式信號處理是JAVA->NDK->.SO->MATLAB這樣呼叫的我原來MATLAB的代碼，其他的大多就用在游戲上了吧，一般的互聯網公司會有人給你公司的SO包的，
至于JVM,該掌握的那部分，相信我，你會掌握的，不該你掌握的，有那些專門研究JVM的人來做，不如省省心有空看看計算機系統，編譯原理，

一句話，平常多寫多練，這是最基本的程式員的素質，盡量擠時間，讀理論基礎書籍，JVM不是未來30年唯一的虛擬機，JAVA也不一定再風靡未來30年工業界，其他的系統和語言也會雨后春筍冒出來，但你理論扎實會讓你很快理解學會一個語言或者框架，你平常寫的多會讓你很快熟練的將新學的東西應用到實際中，
初學者，一句話，多練，

夠入門，

有朋友說要是動真格的話，需要NDK以及JVM等的知識，首現**NDK并不是神秘的東西，**你跟著官方的步驟走一遍就知道什么回事了，無非就是一些代碼格式以及原生/JAVA記憶體互動，進階一點的有原生/JAVA執行緒互動，執行緒互動確實有點蛋疼，但平常避免用就好了，再說對于初學者來說關心NDK干嘛，據鄙人以前的經歷，只在音視頻通信和一個嵌入式信號處理（離線）的兩個專案中用過，嵌入式信號處理是JAVA->NDK->.SO->MATLAB這樣呼叫的我原來MATLAB的代碼，其他的大多就用在游戲上了吧，一般的互聯網公司會有人給你公司的SO包的，
至于JVM,該掌握的那部分，相信我，你會掌握的，不該你掌握的，有那些專門研究JVM的人來做，不如省省心有空看看計算機系統，編譯原理，

一句話，平常多寫多練，這是最基本的程式員的素質，盡量擠時間，讀理論基礎書籍，JVM不是未來30年唯一的虛擬機，JAVA也不一定再風靡未來30年工業界，其他的系統和語言也會雨后春筍冒出來，但你理論扎實會讓你很快理解學會一個語言或者框架，你平常寫的多會讓你很快熟練的將新學的東西應用到實際中，
初學者，一句話，多練，

由于文章篇幅問題復制鏈接查看詳細文章以及獲取學習筆記鏈接：前往我的GitHub

轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/287412.html

標籤：其他

上一篇：在flutter中通過MethodChannel呼叫java層的OpenGL函式渲染圖形

下一篇：自己寫了個Android添加大圖通知欄訊息的代碼并打包成jar包的

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 【從零開始擼一個App】Dagger2

    Dagger2是一個IOC框架，一般用于Android平臺，第一次接觸的朋友，一定會被搞得暈頭轉向。它延續了Java平臺Spring框架代碼碎片化，注解滿天飛的傳統。嘗試將各處代碼片段串聯起來，理清思緒，真不是件容易的事。更不用說還有各版本細微的差別。 與Spring不同的是，Spring是通過反射 ......

    uj5u.com 2020-09-10 06:57:59 more
  • Flutter Weekly Issue 66

    新聞 Flutter 季度調研結果分享 教程 Flutter+FaaS一體化任務編排的思考與設計 詳解Dart中如何通過注解生成代碼 GitHub 用對了嗎？Flutter 團隊分享如何管理大型開源專案 插件 flutter-bubble-tab-indicator A Flutter librar ......

    uj5u.com 2020-09-10 06:58:52 more
  • Proguard 常用規則

    介紹 Proguard 入口，如何查看輸出，如何使用 keep 設定入口以及使用實體，如何配置壓縮，混淆，校驗等規則。

    ......

    uj5u.com 2020-09-10 06:59:00 more
  • Android 開發技術周報 Issue#292

    新聞 Android即將獲得類AirDrop功能：可向附近設備快速分享檔案 谷歌為安卓檔案管理應用引入可安全隱藏資料的Safe Folder功能 Android TV新主界面將顯示電影、電視節目和應用推薦內容 泄露的Android檔案暗示了傳說中的谷歌Pixel 5a與折疊屏新機 谷歌發布Andro ......

    uj5u.com 2020-09-10 07:00:37 more
  • AutoFitTextureView Error inflating class

    報錯： Binary XML file line #0: Binary XML file line #0: Error inflating class xxx.AutoFitTextureView 解決： <com.example.testy2.AutoFitTextureView android: ......

    uj5u.com 2020-09-10 07:00:41 more
  • 根據Uri，Cursor沒有獲取到對應的屬性

    Android： 背景：呼叫攝像頭，拍攝視頻，指定保存的地址，但是回傳的Cursor檔案，只有名稱和大小的屬性，沒有其他諸如時長，連ID屬性都沒有 使用 cursor.getInt(cursor.getColumnIndexOrThrow(MediaStore.Video.Media.DURATIO ......

    uj5u.com 2020-09-10 07:00:44 more
  • Android連載29-持久化技術

    一、持久化技術 我們平時所使用的APP產生的資料，在記憶體中都是瞬時的，會隨著斷電、關機等丟失資料，因此android系統采用了持久化技術，用于存盤這些“瞬時”資料 持久化技術包括：檔案存盤、SharedPreference存盤以及資料庫存盤，還有更復雜的SD卡記憶體儲。 二、檔案存盤 最基本存盤方式， ......

    uj5u.com 2020-09-10 07:00:47 more
  • Android Camera2Video整合到自己專案里

    背景： Android專案里呼叫攝像頭拍攝視頻，原本使用的 MediaStore.ACTION_VIDEO_CAPTURE， 后來因專案需要，改成了camera2 1.Camera2Video 官方demo有點問題，下載后，不能直接整合到專案 問題1.多次拍攝視頻崩潰 問題2.雙擊record按鈕， ......

    uj5u.com 2020-09-10 07:00:50 more
  • Android 開發技術周報 Issue#293

    新聞 谷歌為Android TV開發者提供多種新功能 Android 11將自動填表功能整合到鍵盤輸入建議中 谷歌宣布Android Auto即將支持更多的導航和數字停車應用 谷歌Pixel 5只有XL版本 搭載驍龍765G且將比Pixel 4更便宜 [圖]Wear OS將迎來重磅更新：應用啟動時間 ......

    uj5u.com 2020-09-10 07:01:38 more
  • 海豚星空掃碼投屏 Android 接收端 SDK 集成 六步驟

    掃碼投屏，開放網路，獨占設備，不需要額外下載軟體，微信掃碼，發現設備。支持標準DLNA協議，支持倍速播放。視頻，音頻，圖片投屏。好點意思。還支持自定義基于 DLNA 擴展的操作動作。好像要收費，沒體驗。 這里簡單記錄一下集成程序。 一 跟目錄的build.gradle添加私有mevan倉庫 mave ......

    uj5u.com 2020-09-10 07:01:43 more
最新发布
  • 歡迎頁輪播影片

    如圖，引導開始，球從上落下，同時淡入文字，然后文字開始輪播，最后一頁時停止，點擊進入首頁。 在來看看效果圖。 重力球先不講，主要歡迎輪播簡單實作 首先新建一個類 TextTranslationXGuideView，用于影片展示 文本是類似的，最后會有個圖片箭頭影片，布局很簡單，就是一個 TextVi ......

    uj5u.com 2023-04-20 08:40:31 more
  • 【FAQ】關于華為推送服務因營銷訊息頻次管控導致服務通訊類訊息

    一． 問題描述 使用華為推送服務下發IM訊息時，下發訊息請求成功且code碼為80000000，但是手機總是收不到訊息； 在華為推送自助分析（Beta）平臺查看發現，訊息發送觸發了頻控。 二． 問題原因及背景 2023年1月05日起，華為推送服務對咨詢營銷類訊息做了單個設備每日推送數量上限管理，具體 ......

    uj5u.com 2023-04-20 08:40:11 more
  • 歡迎頁輪播影片

    如圖，引導開始，球從上落下，同時淡入文字，然后文字開始輪播，最后一頁時停止，點擊進入首頁。 在來看看效果圖。 重力球先不講，主要歡迎輪播簡單實作 首先新建一個類 TextTranslationXGuideView，用于影片展示 文本是類似的，最后會有個圖片箭頭影片，布局很簡單，就是一個 TextVi ......

    uj5u.com 2023-04-20 08:39:36 more
  • 【FAQ】關于華為推送服務因營銷訊息頻次管控導致服務通訊類訊息

    一． 問題描述 使用華為推送服務下發IM訊息時，下發訊息請求成功且code碼為80000000，但是手機總是收不到訊息； 在華為推送自助分析（Beta）平臺查看發現，訊息發送觸發了頻控。 二． 問題原因及背景 2023年1月05日起，華為推送服務對咨詢營銷類訊息做了單個設備每日推送數量上限管理，具體 ......

    uj5u.com 2023-04-20 08:39:13 more
  • iOS從UI記憶體地址到讀取成員變數（oc/swift）

    開發除錯時，我們發現bug時常首先是從UI顯示發現例外，下一步才會去定位UI相關連的資料的。XCode有給我們提供一系列debug工具，但是很多人可能還沒有形成一套穩定的除錯流程，因此本文嘗試解決這個問題，順便提出一個暴論：UI顯示例外問題只需要兩個步驟就能完成定位作業的80%： 定位例外 UI 組 ......

    uj5u.com 2023-04-19 09:16:23 more
  • FIDE重磅更新！性能飛躍！體驗有禮！

    FIDE 開發者工具重構升級啦！實作500%性能提升，誠邀體驗！ 一直以來不少開發者朋友在社區反饋，在使用 FIDE 工具的程序中，時常會遇到諸如加載不及時、代碼預覽/渲染性能不如意的情況，十分影響開發體驗。 作為技術團隊，我們深知一件趁手的開發工具對開發者的重要性，因此，在2023年開年，FinC ......

    uj5u.com 2023-04-19 09:16:15 more
  • 游戲內嵌社區服務開放，助力開發者提升玩家互動與留存

    華為 HMS Core 游戲內嵌社區服務提供快速訪問華為游戲中心論壇能力，支持玩家直接在游戲內瀏覽帖子和交流互動，助力開發者擴展內容生產和觸達的場景。 一、為什么要游戲內嵌社區？ 二、游戲內嵌社區的典型使用場景 1、游戲內打開論壇 您可以在游戲內繪制論壇入口，為玩家提供沉浸式發帖、瀏覽、點贊、回帖、 ......

    uj5u.com 2023-04-19 09:15:46 more
  • iOS從UI記憶體地址到讀取成員變數（oc/swift）

    開發除錯時，我們發現bug時常首先是從UI顯示發現例外，下一步才會去定位UI相關連的資料的。XCode有給我們提供一系列debug工具，但是很多人可能還沒有形成一套穩定的除錯流程，因此本文嘗試解決這個問題，順便提出一個暴論：UI顯示例外問題只需要兩個步驟就能完成定位作業的80%： 定位例外 UI 組 ......

    uj5u.com 2023-04-19 09:14:53 more
  • FIDE重磅更新！性能飛躍！體驗有禮！

    FIDE 開發者工具重構升級啦！實作500%性能提升，誠邀體驗！ 一直以來不少開發者朋友在社區反饋，在使用 FIDE 工具的程序中，時常會遇到諸如加載不及時、代碼預覽/渲染性能不如意的情況，十分影響開發體驗。 作為技術團隊，我們深知一件趁手的開發工具對開發者的重要性，因此，在2023年開年，FinC ......

    uj5u.com 2023-04-19 09:14:08 more
  • 游戲內嵌社區服務開放，助力開發者提升玩家互動與留存

    華為 HMS Core 游戲內嵌社區服務提供快速訪問華為游戲中心論壇能力，支持玩家直接在游戲內瀏覽帖子和交流互動，助力開發者擴展內容生產和觸達的場景。 一、為什么要游戲內嵌社區？ 二、游戲內嵌社區的典型使用場景 1、游戲內打開論壇 您可以在游戲內繪制論壇入口，為玩家提供沉浸式發帖、瀏覽、點贊、回帖、 ......

    uj5u.com 2023-04-19 09:08:34 more

Copyright © 2010-2020 有解無憂