建站
咨詢
售后
建站咨詢
新聞中心
類似標(biāo)題的文章在網(wǎng)上不要講的太多，我也曾經(jīng)以為自己掌握了，直到最近用的時候發(fā)現(xiàn)問題，才知道自己之前并非真的理解了，遂寫下這篇筆記、
創(chuàng)新互聯(lián)建站長期為1000多家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為嫩江企業(yè)提供專業(yè)的網(wǎng)站制作、做網(wǎng)站，嫩江網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
事件分發(fā)傳遞的邏輯取決于ACTION_DOWN
同時要注意的是ACTION_MOVE和ACTION_UP的流程并不完全跟ACTION_DOWN一樣
下面這幅圖是ACTION_DOWN手勢的處理邏輯圖
以前我對手勢處理的概念也僅僅停留在這里，而且我還錯誤的把ACTION_MOVE和ACTION_UP的邏輯也理所應(yīng)當(dāng)?shù)南氤蛇@樣(就我身邊的情況來看，并不僅僅是我這么認(rèn)為)。
這里我們以ViewGroup為例來總結(jié)一下(注意，為了方便理解，我只分析了ViewGroup，activity和View有些許不同)
dispatchTouchEvent
可以消費(fèi)事件
如果返回true，則自己消費(fèi)掉事件，終止傳遞;
如果返回false，不消費(fèi)事件，交由父的onTouchEvent做處理;
如果返回super，不消費(fèi)事件，將事件派發(fā)給onInterceptTouchEvent做處理。
onInterceptTouchEvent
不能消費(fèi)事件
如果返回true，將事件派發(fā)給自己的onTouchEvent做處理;
如果返回false/super，將事件派發(fā)給子的dispatchTouchEvent做處理;
onTouchEvent
可以消費(fèi)事件
如果返回true，則自己消費(fèi)掉事件，終止傳遞;
如果返回false/super，將事件派發(fā)給父的onTouchEvent做處理;
大家可以看到，最終消費(fèi)掉事件的位置只有兩個，dispatchTouchEvent和onTouchEvent返回true的時候，而且在它們返回為false的時候，都是將事件交給上層的onTouchEvent來處理，它們一個在onInterceptTouchEvent前，一個在onInterceptTouchEvent后，而onInterceptTouchEvent只是將事件進(jìn)行分流，這樣就構(gòu)成了這張Android事件傳遞圖、
關(guān)于ACTION_MOVE和ACTION_UP
總結(jié)一句話，在默認(rèn)都返回super的情況下，哪一層的onTouchEvent返回true，那一層的onTouchEvent才會收到ACTION_MOVE和ACTION_UP，跟它同級及以上的dispatchTouchEvent和onInterceptTouchEvent能收到ACTION_MOVE和ACTION_UP，如下圖所示
從上圖中我們可以看到，最終能夠收到ACTION_MOVE和ACTION_UP的onTouchEvent只能有一個，就算你上層的onInterceptTouchEvent對ACTION_MOVE返回了true，那也只會把ACTION_MOVE事件分發(fā)到上一層，子View就不會收到ACTION_MOVE事件了，也就是說，當(dāng)一個View在onTouchEvent里的ACTION_DOWN里面返回了true，那它的ACTION_MOVE和ACTION_UP事件不管返回什么結(jié)果其實(shí)都是一樣的，因為ACTION_MOVE事件已經(jīng)分發(fā)到這了，就算返回false上層也是收!不!到!的!(這個概念跟我以前的三觀是完全不符的，當(dāng)然你覺得錯誤也可以反駁我，剛開始我自己都不太相信)
requestDisallowInterceptTouchEvent的使用
在手勢處理中，我們還可以使用requestDisallowInterceptTouchEvent方法，來駁回onInterceptTouchEvent對事件的攔截
對于某些GroupView，它會在onInterceptTouchEvent事件中攔截ACTION_MOVE事件，例如ListView、ScrollView等，這個時候childView就無法獲取到ACTION_MOVE事件了(常見的ScrollView嵌套ViewPager，ViewPager無法滑動)，除了重寫GroupView的onInterceptTouchEvent方法，我們還可以重寫ChildView的dispatchTouchEvent方法來解決、
首先，不管再霸道的GroupView，在默認(rèn)情況下，都不會在onInterceptTouchEvent的ACTION_DOWN事件返回true的，因為這樣會導(dǎo)致childView根本沒有獲取手勢的機(jī)會。那么，childView在dispatchTouchEvent方法中就能收到ACTION_DOWN事件，這個時候，我們調(diào)用parent的requestDisallowInterceptTouchEvent方法,設(shè)置為true，來通知GroupView不要攔截我的事件，那么接下來，原本應(yīng)該被GroupView攔截的ACTION_MOVE事件就會繞過GroupView的onInterceptTouchEvent方法，直接下傳到childView的dispatchTouchEvent
而值得注意的是，在dispatchTouchEvent中g(shù)etParent().requestDisallowInterceptTouchEvent(false)和return false效果是不同的
當(dāng)GroupView.requestDisallowInterceptTouchEvent(true)時，onTouchEvent方法并不會接收到任何事件，所以此時若在ChildView的dispatchTouchEvent方法中return false，其實(shí)效果是跟return true一樣的。只有當(dāng)GroupView.requestDisallowInterceptTouchEvent(false)時，手勢才會再次交給GroupView處理。
所以，這時，在ChildView中假如你想只消費(fèi)某一類型的ACTION_MOVE事件(如水平滑動)，那就需要調(diào)用getParent().requestDisallowInterceptTouchEvent(false)，而不是return false，如下圖所示：
另外，網(wǎng)上很多在ACTION_UP的時候會調(diào)用getParent().requestDisallowInterceptTouchEvent(false)，其實(shí)并不是必要的，因為在收到ACTION_DOWN時，GroupView默認(rèn)會重新將requestDisallowInterceptTouchEvent設(shè)置為false狀態(tài)。
標(biāo)題名稱：Android觸摸事件（筆記篇）
分享地址：http://www.dlmjj.cn/article/dpiihjj.html
