一：前言

最近在學(xué)Android的觸摸事件分發(fā)，我覺得網(wǎng)上說的太雜太亂，而且有很多博客都有明顯的錯誤。什么自頂向下分發(fā)，自下向頂分發(fā)，什么攔截又一直消費什么什么之類，非常難懂。為了自己將來回顧可以更好的理解這塊知識，也為了后來之人可以更好的學(xué)習(xí)，我寫下這篇博客。

二：說在前面的知識

• 點擊，滑動，松手都是由MotionEvent這個類來表示。
• 屏幕上的一個事件序列是指以一個MotionEvent.action_down按下開始，以若干個MotionEvent.action_move移動事件在中間，再以一個MotionEvent.action_up作為結(jié)束的事件流。
• view group是view的子類。view group和view都有dispatchTouchEvent方法；view group有onTnterceptTouchEvent和onTouchEvent方法，view 只有onTouchEvent方法。

三：整體流程

1：activity

我們點擊屏幕的所有事件，都會被第一個接收。

public boolean dispatchTouchEvent(MotionEvent ev) {
        if (ev.getAction() == MotionEvent.ACTION_DOWN) {
            onUserInteraction();//是一個空方法，如果想知道按下了屏幕，可以重寫這個方法打印日志
        }
        if (getWindow().superDispatchTouchEvent(ev)) {//把這個事件傳給window屬性
            return true;
        }
        return onTouchEvent(ev);
    }

2：window就是PhoneWindow

每一個activity都會對應(yīng)一個PhoneWindow（在onCreate方法之前、activity內(nèi)部的attach方法中創(chuàng)建）。PhoneWindow含有一個decor view屬性（setContentView中創(chuàng)建），phone window把事件傳給decor view。 decor view繼承于view group。點擊事件現(xiàn)在傳到decor view這里，就開始view group的事件分發(fā)邏輯了。

3：view group

view group收到點擊事件， 進入dispatchTouchEvent, 如果滿足以下二個條件中的任何一個條件：

• 事件為down事件
• 有一個子view或子view group在處理著事件流了

mFirstTouchTarget ！=null

就進入判斷，如果沒有被禁用攔截（子view調(diào)用parent.requestDisallowed....）就執(zhí)行， onInterceptTouchEvent代碼。

如果決定攔截，后面還會把mFirstTouchTarget置為null，這樣，之后就不會在調(diào)用onInterceptTouchEvent了。而且之后的事件流都會由這個view group的dispatchTouchEvent處理

如果不決定攔截，就遍歷子view、子view group，挨個調(diào)用它們的dispatchTouchEvent。如果沒有人接收，那就調(diào)用自己的super.dispatchTouchEvent. view group的super.dispatchTouchEvent就是自己view那部分 的 dispatchTouchEvent。

4：view

在view這一層，對于down事件，返回true就表示消費這個down事件之后的序列。具體看圖。

 view調(diào)用setOnTouchLIstener可以設(shè)置OnTouchListener，重寫onTouch方法。從源碼中可以看出，若onTouch返回true，將不再回調(diào)onTouchEvent方法。不回調(diào)onTouchEvent的話，那onClickListener也不能回調(diào)了。

四：一些關(guān)鍵點

即使有view消費著一組事件，事件流由底向上傳遞時，依然會調(diào)用每一個view group的intercept攔截方法判斷是否攔截。當(dāng)一個view group遍歷它所有的子view沒有一個接收時，就會進入view模式，調(diào)用自己繼承于view的那一個dispatchTouchEvent方法。如果自己不接收，那會交給調(diào)用自己的dispatchTouchEvent的那個父view.

事件流沒有什么自上而下，就是自下而上的。

ViewGroup的實現(xiàn)負(fù)責(zé)將觸摸事件沿著控件樹向子控件進行派發(fā)，而View的實現(xiàn)則主要用于事件接收與處理工作。當(dāng)view group沒有子view接收時，view group作為一個“view”去處理。

五：從源碼看觸摸事件分發(fā)

由于專欄關(guān)注自定義控件，所以關(guān)于系統(tǒng)如何從硬件獲取觸摸事件以及傳遞到Activity的dispatchTouchEvent就不詳細(xì)分解，下面將從Activity的dispatchTouchEvent方法來一步步看事件是如何被分發(fā)傳遞的：

Activity中的dispatchTouchEvent:

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

其中onUserInteraction();是一個空實現(xiàn)，是系統(tǒng)留給我們的一個修改事件分發(fā)的一個方法，這里可以忽略。

所以實際上Activity的dispatchTouchEvent方法是調(diào)用的PhoneWindow的superDispatchTouchEvent方法，如果superDispatchTouchEvent返回false，沒有消費掉事件，那么才會再交給activity的onTouchEvent方法去處理，從這個角度來講，如果所有地方都沒有消費掉事件，最后接收事件的會是Activity的onTouchEvent方法。

那么下面我們來看看PhoneWindow中的superDispatchTouchEvent方法：

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

發(fā)現(xiàn)實際上調(diào)用的是DecorView對象mDecor的superDispatchTouchEvent方法，來看看DecorView的superDispatchTouchEvent方法：

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

調(diào)用的super.dispatchTouchEvent，而再來看看這個DecorView的繼承關(guān)系：

private final class DecorView extends FrameLayout implements RootViewSurfaceTaker

所以調(diào)用的是FrameLayout中的dispatchTouchEvent方法，而FrameLayout并沒有重寫dispatchTouchEvent方法，所以實際調(diào)用的是FrameLayout的父類 ---> ViewGroup中的dispatchTouchEvent方法，下面這個圖描述了從系統(tǒng)得到MotionEvent實際到傳遞給DecorView的super.dispatchTouchEvent的過程：

總結(jié)

到此這篇關(guān)于Android觸摸事件分發(fā)原理的文章就介紹到這了,更多相關(guān)Android觸摸事件分發(fā)原理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論