原文鏈接:http://www.gcssloop.com/customview/dispatch-touchevent-theory,版權歸作者所有!
之前講解了很多與View繪圖相關的知識,你可以在 安卓自定義View教程目錄 中查看到這些文章,如果你理解了這些文章,那麼至少2D繪圖部分不是難題了,大部分的需求都能滿足,但是關於View還有很多知識點,例如: 讓繪圖更加炫酷的Paint
,讓View動起來的動畫
,與用戶交互的觸控事件
等一系列內容。本次就帶大家簡單的瞭解一下與交互息息相關的東西-事件分發原理。
本次魔法小火車的終點站是事件分發,請各位魔法師帶好裝備,準備登車啓程。
注意:本文中所有源碼分析部分均基於 API23(Android 6.0) 版本,由於安卓系統源碼改變很多,可能與之前版本有所不同,但基本流程都是一致的。
爲什麼要有事件分發機制?
安卓上面的View是樹形結構的,View可能會重疊在一起,當我們點擊的地方有多個View都可以響應的時候,這個點擊事件應該給誰呢?爲了解決這一個問題,就有了事件分發機制。
如下圖,View是一層一層嵌套的,當手指點擊 View1
的時候,下面的ViewGroupA
、 RootView
等也是能夠響應的,爲了確定到底應該是哪個View處理這次點擊事件,就需要事件分發機制來幫忙。
<img src="http://www.itwendao.com/images/load.gif" rel="nofollow" target="_blank" class="lazy" data-original="http://www.itwendao.cosrc=" http:="" www.itwendao.com="" images="" load.gif"="" width="auto" height="auto" data-type="jpeg" data-ratio="1.7133333333333334" data-w="300" style="border: 0px; height: auto; max-width: 100%; vertical-align: baseline; display: block; margin: 0px auto; font-style: inherit; font-variant: inherit; font-weight: inherit; font-stretch: inherit; font-size: inherit; line-height: inherit; font-family: inherit; border-radius: 3px; text-align: center;">
View的結構:
我們的View是樹形結構的,在上一個問題中實例View的結構大致如下:
layout文件:
<com.gcssloop.touchevent.test.RootView xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="300dp" android:background="#4E5268" android:layout_margin="20dp" tools:context="com.gcssloop.touchevent.MainActivity"> <com.gcssloop.touchevent.test.ViewGroupA android:background="#95C3FA" android:layout_width="200dp" android:layout_height="200dp"> <com.gcssloop.touchevent.test.View1 android:background="#BDDA66" android:layout_width="130dp" android:layout_height="130dp"/> </com.gcssloop.touchevent.test.ViewGroupA> <com.gcssloop.touchevent.test.View2 android:layout_alignParentRight="true" android:background="#BDDA66" android:layout_width="80dp" android:layout_height="80dp"/></com.gcssloop.touchevent.test.RootView>
View結構:
可以看到在上面的View結構中莫名多出來的兩個東西,PhoneWindow
和 DecorView
,這兩個我們並沒有在Layout文件中定義過,但是爲什麼會存在呢?
仔細觀察上面的 layout 文件,你會發現一個問題,我在 layout 文件中的最頂層 View(Group) 的大小並不是填滿父窗體的,留下了大量的空白區域,由於我們的手機屏幕不能透明,所以這些空白區域肯定要顯示一些東西,那麼應該顯示什麼呢?
有過安卓開發經驗的都知道,屏幕上沒有View遮擋的部分會顯示主題的顏色。不僅如此,最上面的一個標題欄也沒有在 layout 文件中,這個標題欄又是顯示在哪裏的呢?
你沒有猜錯,這個主題顏色和標題欄等內容就是顯示在
DecorView
中的。
現在知道 DecorView
是幹什麼的了,那麼PhoneWindow
又有什麼作用?
要了解 PhoneWindow 是幹啥的,首先要了解啥是 Window ,看官方說明:
Abstract base class for a top-level window look and behavior policy. An instance of this class should be used as the top-level view added to the window manager. It provides standard UI policies such as a background, title area, default key processing, etc.
簡單來說,Window是一個抽象類,是所有視圖的最頂層容器,視圖的外觀和行爲都歸他管,不論是背景顯示,標題欄還是事件處理都是他管理的範疇,它其實就像是View界的太上皇(雖然能管的事情看似很多,但是沒實權,因爲抽象類不能直接使用)。
而 PhoneWindow 作爲 Window 的唯一親兒子(唯一實現類),自然就是 View 界的皇帝了,PhoneWindow 的權利可是非常大大,不過對於我們來說用處並不大,因爲皇帝平時都是躲在深宮裏面的,雖然偶爾用特殊方法能見上一面,但想要完全指揮 PhoneWindow 爲你工作是很困難的。
而上面說的 DecorView 是 PhoneWindow 的一個內部類,其職位相當於小太監,就是跟在 PhoneWindow 身邊專業爲 PhoneWindow 服務的,除了自己要幹活之外,也負責消息的傳遞,PhoneWindow 的指示通過 DecorView 傳遞給下面的 View,而下面 View 的信息也通過 DecorView 回傳給 PhoneWindow。
事件分發、攔截與消費
下表省略了 PhoneWidow 和 DecorView。
√
表示有該方法。
X
表示沒有該方法。
類型 | 相關方法 | Activity | ViewGroup | View |
---|---|---|---|---|
事件分發 | dispatchTouchEvent | √ | √ | √ |
事件攔截 | onInterceptTouchEvent | X | √ | X |
事件消費 | onTouchEvent | √ | √ | √ |
這個三個方法均有一個 boolean(布爾) 類型的返回值,通過返回 true 和 false 來控制事件傳遞的流程。
PS: 從上表可以看到 Activity 和 View 都是沒有事件攔截的,這是因爲:
Activity 作爲原始的事件分發者,如果 Activity 攔截了事件會導致整個屏幕都無法響應事件,這肯定不是我們想要的效果。
View最爲事件傳遞的最末端,要麼消費掉事件,要麼不處理進行回傳,根本沒必要進行事件攔截。
事件分發流程
前面我們瞭解到了我們的View是樹形結構的,基於這樣的結構,我們的事件可以進行有序的分發。
事件收集之後最先傳遞給 Activity, 然後依次向下傳遞,大致如下:
Activity -> PhoneWindow -> DecorView -> ViewGroup -> ... -> View
這樣的事件分發機制邏輯非常清晰,可是,你是否注意到一個問題?如果最後分發到View,如果這個View也沒有處理事件怎麼辦,就這樣讓事件浪費掉?
當然不會啦,如果沒有任何View消費掉事件,那麼這個事件會按照反方向回傳,最終傳回給Activity,如果最後 Activity 也沒有處理,本次事件纔會被拋棄:
Activity <- PhoneWindow <- DecorView <- ViewGroup <- ... <- View
看到這裏,我不禁微微一皺眉,這個東西咋看起來那麼熟悉呢?再仔細一看,這不就是一個非常經典的責任鏈模式嗎, 如果我能處理就攔截下來自己幹,如果自己不能處理或者不確定就交給責任鏈中下一個對象。
這種設計是非常精巧的,上層View既可以直接攔截該事件,自己處理,也可以先詢問(分發給)子View,如果子View需要就交給子View處理,如果子View不需要還能繼續交給上層View處理。既保證了事件的有序性,又非常的靈活。在我第一次將這個邏輯弄清楚的時候,看着這樣精妙的設計,簡直想歡呼慶賀一下。
其實關於事件傳遞機制,吳小龍的 Android事件傳遞機制分析 一文中的比喻非常有趣,本文也會借鑑一些其中的內容。
先確定幾個角色:
Activity - 公司大老闆
RootView - 項目經理
ViewGroupA - 技術小組長
View1 - 碼農小王(公司裏唯一的碼農)
View2 - 跑龍套的路人甲,無視即可
PS:由於 PhoneWindow 和 DecorView 我們無法直接操作,以下所有示例均省略了 PhoneWindow 和 DecorView。
1.點擊 View1 區域但沒有任何 View 消費事件
當手指在 View1
區域點擊了一下之後,如果所有View都不消耗事件,你就能看到一個完整的事件分發流程,大致如下:
紅色箭頭方向表示事件分發方向。
綠色箭頭方向表示事件回傳方向。
注意: 上圖顯示分發流程僅僅是一個示意流程,並不代表實際情況,如果按照實際情況繪製,會導致流程圖非常複雜和混亂,在糾結了好久之後做了一個艱難的決定,採用這樣一個簡化後的流程。
上面的流程中存在部分不合理內容,請大家選擇性接受。
事件返回時
dispatchTouchEvent
直接指向了父View的onTouchEvent
這一部分是不合理的,實際上它僅僅是給了父View的dispatchTouchEvent
一個 false 返回值,父View根據返回值來調用自身的onTouchEvent
。ViewGroup 是根據
onInterceptTouchEvent
的返回值來確定是調用子View的dispatchTouchEvent
還是自身的onTouchEvent
, 並沒有將調用交給onInterceptTouchEvent
。ViewGroup 的事件分發機制僞代碼如下,可以看出調用的順序。
public boolean dispatchTouchEvent(MotionEvent ev) { boolean result = false; // 默認狀態爲沒有消費過 if (!onInterceptTouchEvent(ev)) { // 如果沒有攔截交給子View result = child.dispatchTouchEvent(ev); } if (!result) { // 如果事件沒有被消費,詢問自身onTouchEvent result = onTouchEvent(ev); } return result;}
測試:
情景:老闆: 我看公司最近業務不咋地,準備發展一下電商業務,下週之前做個淘寶出來試試怎麼樣。
事件順序,老闆(MainActivity)要做淘寶,這個事件通過各個部門(ViewGroup)一層一層的往下傳,傳到最底層的時候,碼農小王(View1)發現做不了,於是消息又一層一層的回傳到老闆那裏。
可以看到整個事件傳遞路線非常有序。從Activity開始,最後回傳給Activity結束(由於我們無法操作Phone Window和DecorView,所以沒有它們的信息)。
MainActivity [老闆]: dispatchTouchEvent 經理,我準備發展一下電商業務,下週之前做一個淘寶出來. RootView [經理]: dispatchTouchEvent 呼叫技術部,老闆要做淘寶,下週上線. RootView [經理]: onInterceptTouchEvent (老闆可能瘋了,但又不是我做.) ViewGroupA [組長]: dispatchTouchEvent 老闆要做淘寶,下週上線? ViewGroupA [組長]: onInterceptTouchEvent (看着不太靠譜,先問問小王怎麼看) View1 [碼農]: dispatchTouchEvent 做淘寶??? View1 [碼農]: onTouchEvent 這個真心做不了啊. ViewGroupA [組長]: onTouchEvent 小王說做不了. RootView [經理]: onTouchEvent 報告老闆, 技術部說做不了. MainActivity [老闆]: onTouchEvent 這麼簡單都做不了,你們都是幹啥的(憤怒).
2.點擊 View1 區域且事件被 View1 消費
如果事件被View1消費掉了則事件會回傳告訴上層View這個事件已經被我解決了,上層View就無需再響應了。
注意:這張圖中的事件回傳路徑纔是正確的路徑。
測試:
情景:老闆: 我覺得咱們這個app按鈕不好看,做的有光澤一點,要讓人有一種想點的慾望。
事件順序,老闆(MainActivity)要做改界面,這個事件通過各個部門(ViewGroup)一層一層的往下傳,傳到最底層的時候,碼農小王(View1)就在按鈕上添加了一道光(爲啥是小王呢?因爲公司沒有設計師)。
可以看出,事件一旦被消費就意味着消息傳遞的結束,上層View知道了事件已經被消費掉,就不再處理了。
MainActivity [老闆]: dispatchTouchEvent 把按鈕做的好看一點,要有光澤,給人一種點擊的慾望. RootView [經理]: dispatchTouchEvent 技術部,老闆說按鈕不好看,要加一道光. RootView [經理]: onInterceptTouchEvent ViewGroupA [組長]: dispatchTouchEvent 給按鈕加上一道光. ViewGroupA [組長]: onInterceptTouchEvent View1 [碼農]: dispatchTouchEvent 加一道光. View1 [碼農]: onTouchEvent 做好了.
加一道光:
3.點擊 View1 區域但事件被 ViewGroupA 攔截
上層的View有權攔截事件,不傳遞給下層View,例如 ListView 滑動的時候,就不會將事件傳遞給下層的子 View。
注意:可以看到,如果上層攔截了事件,下層View將接收不到事件信息。
測試:
情景:老闆: 報告一下項目進度。
事件順序,老闆(MainActivity)要知道項目進度,這個事件通過各個部門(ViewGroup)一層一層的往下傳,傳到技術組組長(ViewGroupA)的時候,組長(ViewGroupA)上報任務即可。無需告知碼農小王(View1)。
MainActivity [老闆]: dispatchTouchEvent 現在項目做到什麼程度了? RootView [經理]: dispatchTouchEvent 技術部,你們的app快做完了麼? RootView [經理]: onInterceptTouchEvent ViewGroupA [組長]: dispatchTouchEvent 項目進度? ViewGroupA [組長]: onInterceptTouchEvent ViewGroupA [組長]: onTouchEvent 正在測試,明天就測試完了
其他情況
事件分發機制設計到到情形非常多,這裏就不一一列舉了,記住以下幾條原則就行了。
-
1.如果事件被消費,就意味着事件信息傳遞終止。
-
2.如果事件一直沒有被消費,最後會傳給Activity,如果Activity也不需要就被拋棄。
-
3.判斷事件是否被消費是根據返回值,而不是根據你是否使用了事件。
文中測試用的源碼下載
總結
View的事件分發機制實際上就是一個非常經典的責任鏈模式,如果你瞭解責任鏈模式,那麼事件分發對你來說並不是什麼難題,如果你不瞭解責任鏈模式,剛好藉此機會學習一下啦。
責任鏈模式:
當有多個對象均可以處理同一請求的時候,將這些對象串聯成一條鏈,並沿着這條鏈傳遞改請求,直到有對象處理它爲止。
Android 中事件分發機制原理雖然非常簡單,但由於實際場景非常複雜,一旦具體到某個場景中變得很麻煩,而本文僅僅是帶你簡單的瞭解一下事件分發機制,更詳細的內容和具體的一些特殊情形處理會在後續文章中進行講解。
由於個人水平有限,文章中可能會出現錯誤,如果你覺得哪一部分有錯誤,或者發現了錯別字等內容,歡迎在評論區告訴我,另外,據說關注作者微博不僅能第一時間收到新文章消息,還能變帥哦。