【移動應(yīng)用開發(fā)技術(shù)】Android滑動沖突問題的解決方法

【移動應(yīng)用開發(fā)技術(shù)】Android滑動沖突問題的解決方法

敘述

滑動沖突可以說是日常開發(fā)中比較常見的一類問題，也是比較讓人頭疼的一類問題，尤其是在使用第三方框架的時候，兩個原本完美的控件，組合在一起之后，忽然發(fā)現(xiàn)整個世界都不好了。關(guān)于滑動沖突

滑動沖突分類滑動沖突，總的來說就是兩類。1、同方向滑動沖突

比如ScrollView嵌套ListView，或者是ScrollView嵌套自己2、不同方向滑動沖突

比如ScrollView嵌套ViewPager，或者是ViewPager嵌套ScrollView，這種情況其實很典型。現(xiàn)在大部分應(yīng)用最外層都是ViewPager+Fragment的底部切換（比如微信）結(jié)構(gòu)，這種時候，就很容易出現(xiàn)滑動沖突。不過ViewPager里面無論是嵌套ListView還是ScrollView，滑動沖突是沒有的，畢竟是官方的東西，可能已經(jīng)考慮到了這些，所以比較完善。復(fù)雜一點(diǎn)的滑動沖突，基本上就是這兩個沖突結(jié)合的結(jié)果。滑動沖突解決思路滑動沖突，就其本質(zhì)來說，兩個不同方向（或者是同方向）的View，其中有一個是占主導(dǎo)地位的，每次總是搶著去處理外界的滑動行為，這樣就導(dǎo)致一種很別扭的用戶體驗，明明只是橫向的滑動了一下，縱向的列表卻在垂直方向發(fā)生了動作。就是說，這個占主導(dǎo)地位的View，每一次都身不由己的攔截了這個滑動的動作，因此，要解決滑動沖突，就是得明確告訴這個占主導(dǎo)地位的View，什么時候你該攔截，什么時候你不應(yīng)該攔截，應(yīng)該由下一層的View去處理這個滑動動作。這里不明白的同學(xué)，可以去了解一下AndroidTouch事件的分發(fā)機(jī)制，這也是解決滑動沖突的核心知識。第二種滑動沖突，解決起來是比較簡單的。這里就結(jié)合例子說一下?；瑒記_突

這里，說一下背景情況。之前做下拉刷新、上拉加載更多時一直使用的是PullToRefreshView這個控件，因為很方便，不用導(dǎo)入三方工程。在其內(nèi)部可以放置ListView，GridView及ScrollView，非常方便，用起來可謂是屢試不爽。但是直到有一天，因項目需要，在ListView頂部加了一個輪播圖控件BannerView。結(jié)果發(fā)現(xiàn)輪播圖滑動的時候，和縱向的下拉刷新組件沖突了。如之前所說，解決滑動沖突的關(guān)鍵，就是明確告知接收到Touch的View，是否需要攔截此次事件。解決方法

解決方案1，從外部攔截機(jī)制考慮這里，相當(dāng)于是PullToRefreshView嵌套了ViewPager，那么每次優(yōu)先接收到Touch事件的必然是PullToRefreshView。因為正常情況下，父控件會優(yōu)先接收到touch事件。這樣就清楚了，看代碼：在PullToRefreshView的onInterceptTouchEvent方法中：這里最關(guān)鍵的代碼就是這行橫向滑動距離大于縱向時，無須攔截這次滑動事件，滑動事件會傳遞到下一層的view，也就是這里的輪播圖控件，這樣橫向滑動輪播圖的時候，PullToRefreshView就不會有下拉的動作了。其實，就是這么簡單，但前提是你必須明確了解AndroidTouch事件的傳遞機(jī)制，期間各個方法執(zhí)行的順序及意義。ps:關(guān)于上文中提到的isRefreshViewScroll方法代碼（這個方法其實是PullToRefreshView這個控件自帶的一個方法）解決方案2，從內(nèi)容逆向思維分析有時候，我們不想去修改或者是無法修改最先接收到Touch事件的View時，比如這里我不想去修改PullToRefreshView的代碼。就必須考慮從當(dāng)前從Touch傳遞事件中最后的那個View逆向考慮。首先，由Android中View的Touch事件傳遞機(jī)制，我們知道Touch事件，首先必然由最外層View接收到，并很有可能被它攔截，如果無法更改這個最外層View，那么是不是就沒轍了呢？其實不然，Android這么高大上的系統(tǒng)必然考慮到了這個問題，好了廢話不說，先看代碼首先說一下這個方法publicabstractvoidrequestDisallowInterceptTouchEvent(booleandisallowIntercept)

API里的意思很明確，子View如果不希望其父View攔截Touch事件時，可調(diào)用此方法。當(dāng)disallowIntercept這個參數(shù)為true時，父View將不攔截。好了，言歸正傳。這里攔截直接也很明確，在carouselView的onTouch方法中每次進(jìn)入就設(shè)定父View不攔截此次事件，然后在MOTION_MOVE時候，根據(jù)滑動的距離判斷再決定是父View是否有權(quán)利攔截Touch事件（即滑動行為）。關(guān)鍵的處理邏輯就是這里：這個結(jié)合上面對這個方法的解釋，應(yīng)該很好理解了，就不多做闡述