原作者是分爲上下兩篇進行講解的,轉載時直接轉載爲一篇了,原作出處如下:
上集:http://blog.csdn.net/guolin_blog/article/details/9097463
下集:http://blog.csdn.net/guolin_blog/article/details/9153761
其實我一直準備寫一篇關於Android事件分發機制的文章,從我的第一篇博客開始,就零零散散在好多地方使用到了Android事件分發的知識。也有好多朋友問過我各種問題,比如:onTouch和onTouchEvent有什麼區別,又該如何使用?爲什麼給ListView引入了一個滑動菜單的功能,ListView就不能滾動了?爲什麼圖片輪播器裏的圖片使用Button而不用ImageView?等等……對於這些問題,我並沒有給出非常詳細的回答,因爲我知道如果想要徹底搞明白這些問題,掌握Android事件分發機制是必不可少的,而Android事件分發機制絕對不是三言兩語就能說得清的。
在我經過較長時間的籌備之後,終於決定開始寫這樣一篇文章了。目前雖然網上相關的文章也不少,但我覺得沒有哪篇寫得特別詳細的(也許我還沒有找到),多數文章只是講了講理論,然後配合demo運行了一下結果。而我準備帶着大家從源碼的角度進行分析,相信大家可以更加深刻地理解Android事件分發機制。
閱讀源碼講究由淺入深,循序漸進,因此我們也從簡單的開始,本篇先帶大家探究View的事件分發,下篇再去探究難度更高的ViewGroup的事件分發。
那我們現在就開始吧!比如說你當前有一個非常簡單的項目,只有一個Activity,並且Activity中只有一個按鈕。你可能已經知道,如果想要給這個按鈕註冊一個點擊事件,只需要調用:
這樣在onClick方法裏面寫實現,就可以在按鈕被點擊的時候執行。你可能也已經知道,如果想給這個按鈕再添加一個touch事件,只需要調用:onTouch方法裏能做的事情比onClick要多一些,比如判斷手指按下、擡起、移動等事件。那麼如果我兩個事件都註冊了,哪一個會先執行呢?我們來試一下就知道了,運行程序點擊按鈕,打印結果如下:
可以看到,onTouch是優先於onClick執行的,並且onTouch執行了兩次,一次是ACTION_DOWN,一次是ACTION_UP(你還可能會有多次ACTION_MOVE的執行,如果你手抖了一下)。因此事件傳遞的順序是先經過onTouch,再傳遞到onClick。
細心的朋友應該可以注意到,onTouch方法是有返回值的,這裏我們返回的是false,如果我們嘗試把onTouch方法裏的返回值改成true,再運行一次,結果如下:
我們發現,onClick方法不再執行了!爲什麼會這樣呢?你可以先理解成onTouch方法返回true就認爲這個事件被onTouch消費掉了,因而不會再繼續向下傳遞。
如果到現在爲止,以上的所有知識點你都是清楚的,那麼說明你對Android事件傳遞的基本用法應該是掌握了。不過別滿足於現狀,讓我們從源碼的角度分析一下,出現上述現象的原理是什麼。
首先你需要知道一點,只要你觸摸到了任何一個控件,就一定會調用該控件的dispatchTouchEvent方法。那當我們去點擊按鈕的時候,就會去調用Button類裏的dispatchTouchEvent方法,可是你會發現Button類裏並沒有這個方法,那麼就到它的父類TextView裏去找一找,你會發現TextView裏也沒有這個方法,那沒辦法了,只好繼續在TextView的父類View裏找一找,這個時候你終於在View裏找到了這個方法,示意圖如下:
然後我們來看一下View中dispatchTouchEvent方法的源碼:
這個方法非常的簡潔,只有短短几行代碼!我們可以看到,在這個方法內,首先是進行了一個判斷,如果mOnTouchListener != null,(mViewFlags & ENABLED_MASK) == ENABLED和mOnTouchListener.onTouch(this, event)這三個條件都爲真,就返回true,否則就去執行onTouchEvent(event)方法並返回。
先看一下第一個條件,mOnTouchListener這個變量是在哪裏賦值的呢?我們尋找之後在View裏發現瞭如下方法:
Bingo!找到了,mOnTouchListener正是在setOnTouchListener方法裏賦值的,也就是說只要我們給控件註冊了touch事件,mOnTouchListener就一定被賦值了。
第二個條件(mViewFlags & ENABLED_MASK) == ENABLED是判斷當前點擊的控件是否是enable的,按鈕默認都是enable的,因此這個條件恆定爲true。
第三個條件就比較關鍵了,mOnTouchListener.onTouch(this, event),其實也就是去回調控件註冊touch事件時的onTouch方法。也就是說如果我們在onTouch方法裏返回true,就會讓這三個條件全部成立,從而整個方法直接返回true。如果我們在onTouch方法裏返回false,就會再去執行onTouchEvent(event)方法。
現在我們可以結合前面的例子來分析一下了,首先在dispatchTouchEvent中最先執行的就是onTouch方法,因此onTouch肯定是要優先於onClick執行的,也是印證了剛剛的打印結果。而如果在onTouch方法裏返回了true,就會讓dispatchTouchEvent方法直接返回true,不會再繼續往下執行。而打印結果也證實瞭如果onTouch返回true,onClick就不會再執行了。
根據以上源碼的分析,從原理上解釋了我們前面例子的運行結果。而上面的分析還透漏出了一個重要的信息,那就是onClick的調用肯定是在onTouchEvent(event)方法中的!那我們馬上來看下onTouchEvent的源碼,如下所示:
相較於剛纔的dispatchTouchEvent方法,onTouchEvent方法複雜了很多,不過沒關係,我們只挑重點看就可以了。
首先在第14行我們可以看出,如果該控件是可以點擊的就會進入到第16行的switch判斷中去,而如果當前的事件是擡起手指,則會進入到MotionEvent.ACTION_UP這個case當中。在經過種種判斷之後,會執行到第38行的performClick()方法,那我們進入到這個方法裏瞧一瞧:
可以看到,只要mOnClickListener不是null,就會去調用它的onClick方法,那mOnClickListener又是在哪裏賦值的呢?經過尋找後找到如下方法:一切都是那麼清楚了!當我們通過調用setOnClickListener方法來給控件註冊一個點擊事件時,就會給mOnClickListener賦值。然後每當控件被點擊時,都會在performClick()方法裏回調被點擊控件的onClick方法。
這樣View的整個事件分發的流程就讓我們搞清楚了!不過別高興的太早,現在還沒結束,還有一個很重要的知識點需要說明,就是touch事件的層級傳遞。我們都知道如果給一個控件註冊了touch事件,每次點擊它的時候都會觸發一系列的ACTION_DOWN,ACTION_MOVE,ACTION_UP等事件。這裏需要注意,如果你在執行ACTION_DOWN的時候返回了false,後面一系列其它的action就不會再得到執行了。簡單的說,就是當dispatchTouchEvent在進行事件分發的時候,只有前一個action返回true,纔會觸發後一個action。
說到這裏,很多的朋友肯定要有巨大的疑問了。這不是在自相矛盾嗎?前面的例子中,明明在onTouch事件裏面返回了false,ACTION_DOWN和ACTION_UP不是都得到執行了嗎?其實你只是被假象所迷惑了,讓我們仔細分析一下,在前面的例子當中,我們到底返回的是什麼。
參考着我們前面分析的源碼,首先在onTouch事件裏返回了false,就一定會進入到onTouchEvent方法中,然後我們來看一下onTouchEvent方法的細節。由於我們點擊了按鈕,就會進入到第14行這個if判斷的內部,然後你會發現,不管當前的action是什麼,最終都一定會走到第89行,返回一個true。
是不是有一種被欺騙的感覺?明明在onTouch事件裏返回了false,系統還是在onTouchEvent方法中幫你返回了true。就因爲這個原因,才使得前面的例子中ACTION_UP可以得到執行。
那我們可以換一個控件,將按鈕替換成ImageView,然後給它也註冊一個touch事件,並返回false。如下所示:
運行一下程序,點擊ImageView,你會發現結果如下:
在ACTION_DOWN執行完後,後面的一系列action都不會得到執行了。這又是爲什麼呢?因爲ImageView和按鈕不同,它是默認不可點擊的,因此在onTouchEvent的第14行判斷時無法進入到if的內部,直接跳到第91行返回了false,也就導致後面其它的action都無法執行了。
好了,關於View的事件分發,我想講的東西全都在這裏了。現在我們再來回顧一下開篇時提到的那三個問題,相信每個人都會有更深一層的理解。
1. onTouch和onTouchEvent有什麼區別,又該如何使用?
從源碼中可以看出,這兩個方法都是在View的dispatchTouchEvent中調用的,onTouch優先於onTouchEvent執行。如果在onTouch方法中通過返回true將事件消費掉,onTouchEvent將不會再執行。
另外需要注意的是,onTouch能夠得到執行需要兩個前提條件,第一mOnTouchListener的值不能爲空,第二當前點擊的控件必須是enable的。因此如果你有一個控件是非enable的,那麼給它註冊onTouch事件將永遠得不到執行。對於這一類控件,如果我們想要監聽它的touch事件,就必須通過在該控件中重寫onTouchEvent方法來實現。
2. 爲什麼給ListView引入了一個滑動菜單的功能,ListView就不能滾動了?
如果你閱讀了Android實現圖片滾動控件,含頁籤功能,讓你的應用像淘寶一樣炫起來 這篇文章。當時我在圖片輪播器裏使用Button,主要就是因爲Button是可點擊的,而ImageView是不可點擊的。如果想要使用ImageView,可以有兩種改法。第一,在ImageView的onTouch方法裏返回true,這樣可以保證ACTION_DOWN之後的其它action都能得到執行,才能實現圖片滾動的效果。第二,在佈局文件裏面給ImageView增加一個android:clickable="true"的屬性,這樣ImageView變成可點擊的之後,即使在onTouch裏返回了false,ACTION_DOWN之後的其它action也是可以得到執行的。
今天的講解就到這裏了,相信大家現在對Android事件分發機制又有了進一步的認識,在後面的文章中我會再帶大家一起探究Android中ViewGroup的事件分發機制,感興趣的朋友請繼續閱讀 Android事件分發機制完全解析,帶你從源碼的角度徹底理解(下) 。
記得在前面的文章中,我帶大家一起從源碼的角度分析了Android中View的事件分發機制,相信閱讀過的朋友對View的事件分發已經有比較深刻的理解了。
還未閱讀過的朋友,請先參考 Android事件分發機制完全解析,帶你從源碼的角度徹底理解(上) 。
那麼今天我們將繼續上次未完成的話題,從源碼的角度分析ViewGroup的事件分發。
首先我們來探討一下,什麼是ViewGroup?它和普通的View有什麼區別?
顧名思義,ViewGroup就是一組View的集合,它包含很多的子View和子VewGroup,是Android中所有佈局的父類或間接父類,像LinearLayout、RelativeLayout等都是繼承自ViewGroup的。但ViewGroup實際上也是一個View,只不過比起View,它多了可以包含子View和定義佈局參數的功能。ViewGroup繼承結構示意圖如下所示:
可以看到,我們平時項目裏經常用到的各種佈局,全都屬於ViewGroup的子類。
簡單介紹完了ViewGroup,我們現在通過一個Demo來演示一下Android中VewGroup的事件分發流程吧。
首先我們來自定義一個佈局,命名爲MyLayout,繼承自LinearLayout,如下所示:
然後,打開主佈局文件activity_main.xml,在其中加入我們自定義的佈局:
可以看到,我們在MyLayout中添加了兩個按鈕,接着在MainActivity中爲這兩個按鈕和MyLayout都註冊了監聽事件:我們在MyLayout的onTouch方法,和Button1、Button2的onClick方法中都打印了一句話。現在運行一下項目,效果圖如下所示:
分別點擊一下Button1、Button2和空白區域,打印結果如下所示:
你會發現,當點擊按鈕的時候,MyLayout註冊的onTouch方法並不會執行,只有點擊空白區域的時候纔會執行該方法。你可以先理解成Button的onClick方法將事件消費掉了,因此事件不會再繼續向下傳遞。
那就說明Android中的touch事件是先傳遞到View,再傳遞到ViewGroup的?現在下結論還未免過早了,讓我們再來做一個實驗。
查閱文檔可以看到,ViewGroup中有一個onInterceptTouchEvent方法,我們來看一下這個方法的源碼:
如果不看源碼你還真可能被這注釋嚇到了,這麼長的英文註釋看得頭都大了。可是源碼竟然如此簡單!只有一行代碼,返回了一個false!
好吧,既然是布爾型的返回,那麼只有兩種可能,我們在MyLayout中重寫這個方法,然後返回一個true試試,代碼如下所示:
現在再次運行項目,然後分別Button1、Button2和空白區域,打印結果如下所示:
你會發現,不管你點擊哪裏,永遠都只會觸發MyLayout的touch事件了,按鈕的點擊事件完全被屏蔽掉了!這是爲什麼呢?如果Android中的touch事件是先傳遞到View,再傳遞到ViewGroup的,那麼MyLayout又怎麼可能屏蔽掉Button的點擊事件呢?
看來只有通過閱讀源碼,搞清楚Android中ViewGroup的事件分發機制,才能解決我們心中的疑惑了,不過這裏我想先跟你透露一句,Android中touch事件的傳遞,絕對是先傳遞到ViewGroup,再傳遞到View的。記得在Android事件分發機制完全解析,帶你從源碼的角度徹底理解(上) 中我有說明過,只要你觸摸了任何控件,就一定會調用該控件的dispatchTouchEvent方法。這個說法沒錯,只不過還不完整而已。實際情況是,當你點擊了某個控件,首先會去調用該控件所在佈局的dispatchTouchEvent方法,然後在佈局的dispatchTouchEvent方法中找到被點擊的相應控件,再去調用該控件的dispatchTouchEvent方法。如果我們點擊了MyLayout中的按鈕,會先去調用MyLayout的dispatchTouchEvent方法,可是你會發現MyLayout中並沒有這個方法。那就再到它的父類LinearLayout中找一找,發現也沒有這個方法。那隻好繼續再找LinearLayout的父類ViewGroup,你終於在ViewGroup中看到了這個方法,按鈕的dispatchTouchEvent方法就是在這裏調用的。修改後的示意圖如下所示:
那還等什麼?快去看一看ViewGroup中的dispatchTouchEvent方法的源碼吧!代碼如下所示:
這個方法代碼比較長,我們只挑重點看。首先在第13行可以看到一個條件判斷,如果disallowIntercept和!onInterceptTouchEvent(ev)兩者有一個爲true,就會進入到這個條件判斷中。disallowIntercept是指是否禁用掉事件攔截的功能,默認是false,也可以通過調用requestDisallowInterceptTouchEvent方法對這個值進行修改。那麼當第一個值爲false的時候就會完全依賴第二個值來決定是否可以進入到條件判斷的內部,第二個值是什麼呢?竟然就是對onInterceptTouchEvent方法的返回值取反!也就是說如果我們在onInterceptTouchEvent方法中返回false,就會讓第二個值爲true,從而進入到條件判斷的內部,如果我們在onInterceptTouchEvent方法中返回true,就會讓第二個值爲false,從而跳出了這個條件判斷。
這個時候你就可以思考一下了,由於我們剛剛在MyLayout中重寫了onInterceptTouchEvent方法,讓這個方法返回true,導致所有按鈕的點擊事件都被屏蔽了,那我們就完全有理由相信,按鈕點擊事件的處理就是在第13行條件判斷的內部進行的!
那我們重點來看下條件判斷的內部是怎麼實現的。在第19行通過一個for循環,遍歷了當前ViewGroup下的所有子View,然後在第24行判斷當前遍歷的View是不是正在點擊的View,如果是的話就會進入到該條件判斷的內部,然後在第29行調用了該View的dispatchTouchEvent,之後的流程就和 Android事件分發機制完全解析,帶你從源碼的角度徹底理解(上) 中講解的是一樣的了。我們也因此證實了,按鈕點擊事件的處理確實就是在這裏進行的。
然後需要注意一下,調用子View的dispatchTouchEvent後是有返回值的。我們已經知道,如果一個控件是可點擊的,那麼點擊該控件時,dispatchTouchEvent的返回值必定是true。因此會導致第29行的條件判斷成立,於是在第31行給ViewGroup的dispatchTouchEvent方法直接返回了true。這樣就導致後面的代碼無法執行到了,也是印證了我們前面的Demo打印的結果,如果按鈕的點擊事件得到執行,就會把MyLayout的touch事件攔截掉。
那如果我們點擊的不是按鈕,而是空白區域呢?這種情況就一定不會在第31行返回true了,而是會繼續執行後面的代碼。那我們繼續往後看,在第44行,如果target等於null,就會進入到該條件判斷內部,這裏一般情況下target都會是null,因此會在第50行調用super.dispatchTouchEvent(ev)。這句代碼會調用到哪裏呢?當然是View中的dispatchTouchEvent方法了,因爲ViewGroup的父類就是View。之後的處理邏輯又和前面所說的是一樣的了,也因此MyLayout中註冊的onTouch方法會得到執行。之後的代碼在一般情況下是走不到的了,我們也就不再繼續往下分析。
再看一下整個ViewGroup事件分發過程的流程圖吧,相信可以幫助大家更好地去理解:
現在整個ViewGroup的事件分發流程的分析也就到此結束了,我們最後再來簡單梳理一下吧。
1. Android事件分發是先傳遞到ViewGroup,再由ViewGroup傳遞到View的。
2. 在ViewGroup中可以通過onInterceptTouchEvent方法對事件傳遞進行攔截,onInterceptTouchEvent方法返回true代表不允許事件繼續向子View傳遞,返回false代表不對事件進行攔截,默認返回false。
3. 子View中如果將傳遞的事件消費掉,ViewGroup中將無法接收到任何事件。
好了,Android事件分發機制完全解析到此全部結束,結合上下兩篇,相信大家對事件分發的理解已經非常深刻了。