堅持原創(chuàng)日更，短平快的 Android 進階系列，敬請直接在微信公眾號搜索：nanchen，直接關(guān)注并設(shè)為星標，精彩不容錯過。

在 Android 開發(fā)中，滑動沖突總是我們一個無法避免的話題。而對于解決方案卻是眾說紛紜。比如 RecyclerView 嵌套 RecyclerView，直接通過相關(guān)方法禁掉內(nèi)部 RecyclerView 的滑動；ScrollView 嵌套 RecyclerView 直接把 ScrollView 替換為 NestedScrollView 等等。但我們今天要說的是在自定義 View 中遇到滑動沖突時，我們又應(yīng)該如何處理呢？

當然，今天的話題需要 View 的事件分發(fā)機制做理論前提，還不了解 View 的事件分發(fā)機制的小伙伴可以移步我之前面試系列的一篇文章：面試系列：講講 Android 的事件分發(fā)機制。

簡單介紹 View 的事件分發(fā)機制

當然，這里也可以簡單地提一下，基本的流程就是下面的偽代碼。

public boolean dispatchTouchEvent(MotionEvent ev) {boolean consume = false;if (onInterceptTouchEvent(ev)) {consume = onTouchEvent(ev);}else{consume = child.dispatchTouchEvent(ev);}return consume; }

當一個 ViewGroup 接收到一個事件的時候，首先會調(diào)用 dispatchTouchEvent() 方法進行事件分發(fā)，如果 onInterceptTouchEvent() 返回 true，則代表當前 View 會攔截事件，則直接回調(diào) onTouchEvent() 方法進行事件處理。如果不攔截，則直接回調(diào)子 View 的 dispatchTouchEvent() 方法，如此反復(fù)，一直到最里面的子 View。

當一個點擊事件產(chǎn)生后，它的傳遞過程遵循以下順序：Activity => Window => View，即事件總是先傳遞給 Activity，Activity 再傳遞給 Window，最后 Window 再傳遞給頂層 DecorView，然后遵循上面的方式一直在最里層 View。

而處理事件則從最里層 View 不斷回傳給自己的外層 View，如果一直沒有 View 進行處理，則直接會回傳到 Activity 中。

onTouchEvent() 返回 true 代表自己要處理。

既然都提了這么一點，也就突然想給出一些結(jié)論，參考自 Android 開發(fā)藝術(shù)探索：

同一個事件序列是指從手指接觸屏幕（ACTION_DOWN）的那一刻起，到手指離開屏幕（ACTION_UP）的那一刻結(jié)束，中間含不定數(shù)量的 ACTION_MOVE 事件。

某個 View 一旦決定攔截事件，那么這一個事件序列都只能由它處理，并且它的 onInterceptTouchEvent() 方法也不會再調(diào)用。換句話說，比如一個 ViewGroup 里面有數(shù)個子 View，一旦 ACTION_DOWN 事件從 Activity 傳到這個 ViewGroup 被其攔截，則后續(xù)的 MOVE 和 UP 等事件也不會傳遞到里面的子 View 中。

如果一個 View 一旦開始處理事件，如果它不消耗 ACTION_DOWN 事件，即 onTouchEvent() 返回為 false，那么同一事件序列中的其他事件也不會再交給它處理，直接會調(diào)用其父 View 的 onTouchEvent()。

如果 View 不消耗除 ACTION_DOWN 以外的其他事件，那么這個點擊事件會消失，此時父元素的 onTouchEvent() 并不會被調(diào)用，并且當然 View 可以持續(xù)收到后續(xù)的事件，最終這些消失的點擊事件會傳遞給 Activity 處理。

ViewGroup 默認不攔截事件，View 沒有 onInterceptTouchEvent() 方法，一旦有事件傳遞給它，則直接會調(diào)用 onTouchEvent()，并且起默認都會消耗掉事件。除非它是不可點擊的（即 clickable 和 longClickable 均為 false）。View 的 longClickable 默認都為 false，而 clickable 分情況，比如 Button 默認為 true，TextView 默認為 false。

View 的 enable 屬性不會影響 onTouchEvent() 的默認返回值，哪怕一個 View 是 disable 狀態(tài)的，只要它的 clickable 或者 longClickable 有一個為 true，那么它的 onTouchEvent() 就會返回 true。

requestDisallowInterceptTouchEvent() 可以在子元素中干預(yù)父元素的事件分發(fā)過程，但是無法干預(yù) ACTION_DOWN 事件。

事件優(yōu)先順序：setOnTouchListener() => onTouchEvent() => onClickListener()

一不小心發(fā)現(xiàn)還是挺多的，當然這些都是結(jié)論，具體可以跟著 面試系列：講講 Android 的事件分發(fā)機制 進行源碼流程探討，你會發(fā)現(xiàn)上面的結(jié)論很容易得到。

處理自定義 View 中的滑動沖突

對于大多數(shù) Android 開發(fā)來說，處理滑動沖突好像很難，但實戰(zhàn)一下又發(fā)現(xiàn)，好像也挺簡單，因為這個實際上是有套路可循的。基本就兩種方案：外部攔截法 && 內(nèi)部攔截法。

外部攔截法

所謂外部攔截法，顧名思義，就是直接在父容器中直接攔截掉我們的滑動事件，讓其不能進入到子元素中，這似乎和我們 RecyclerView 嵌套 RecyclerView 時禁用內(nèi)部 RecyclerView 滑動有那么一絲相似之處，就是內(nèi)部不處理就完事兒了。但細細品來又完全不一樣，這里的外部攔截法會讓內(nèi)部元素根本就收不到滑動事件。

這種方法明顯非常適合我們上面講的事件分發(fā)機制。我們在接收 ACTION_MOVE 事件的時候，直接通過使 onInterceptTouchEvent() 方法返回 true 來直接攔截掉事件就可以了，偽代碼想必大家也知道了：

override fun onInterceptTouchEvent(ev: MotionEvent?): Boolean {ev?.run { if (action == MotionEvent.ACTION_MOVE && 父容器需要點擊事件){return true}}return super.onInterceptTouchEvent(ev) }

代碼很簡單，我們僅僅需要在事件 ACTION_MOVE 時去處理我們的邏輯就好了，當滿足我們的邏輯的時候，就攔截掉 ACTION_MOVE 事件給自己處理。

至于為什么不去攔截 ACTION_DOWN 和 ACTION_UP，想必大家也清楚了。上面說了，如果攔截了 ACTION_DOWN 事件，那后續(xù)的 ACTION_MOVE、ACTION_UP 等其它事件均不會在調(diào)用 onInterceptTouchEvent() 方法，會直接交給當前容器處理。而如果我們攔截掉 ACTION_UP 的話，肯定會導(dǎo)致子元素的點擊事件無法被處理，因為大家肯定都知道一個點擊事件從 ACTION_DOWN 開始，從 ACTION_UP 結(jié)束，二者缺一不可。

內(nèi)部攔截法

內(nèi)部攔截法相對外部攔截法會復(fù)雜一些，所以我們通常來說，都更加推薦用外部攔截法進行處理。不過，內(nèi)部攔截法依然有著它非常重要的地位，具體情況有可能會遇到。

內(nèi)部攔截法的話，需要 requestDisallowInterceptTouchEvent() 方法的支持，這個方法是干什么的呢？顧名思義，請求是否不允許攔截事件，其接收一個 boolean 參數(shù)，表示是否不允許攔截。

我們直接重寫子元素的 dispatchTouchEvent() 方法，得到偽代碼如下：

override fun dispatchTouchEvent(ev: MotionEvent?): Boolean {ev?.run { when(action){MotionEvent.ACTION_DOWN -> parent.requestDisallowInterceptTouchEvent(true)MotionEvent.ACTION_MOVE ->{if(滿足需要讓外部容器攔截事件){parent.requestDisallowInterceptTouchEvent(false)}}}}return super.dispatchTouchEvent(ev) }

想必代碼也是非常簡單易懂的，我們給父容器的 requestDisallowInterceptTouchEvent() 傳遞的參數(shù)代表是否不允許其攔截事件，當參數(shù)為 true 的時候代表不允許攔截，為 false 的時候代表攔截。所以看起來和外部攔截法也就如出一轍了。

不過僅僅有這點修改還不夠，我們通過前面的理論基礎(chǔ)知道，當我們的父容器攔截掉 ACTION_DOWN 事件的時候，所有的事件都無法再傳遞到子元素中，自然也就不會調(diào)用上面我們寫的 dispatchTouchEvent() 方法了。所以我們在內(nèi)部攔截法的時候還需要重寫父容器的 onInterceptTouchEvent() 方法。

override fun onInterceptTouchEvent(ev: MotionEvent?): Boolean {ev?.run { if (action == MotionEvent.ACTION_DOWN){return false}}return super.onInterceptTouchEvent(ev) }

至此，基本介紹了兩種處理滑動沖突的解決方案，在自定義 View 的時候結(jié)合實際場景也就可以得心應(yīng)手了。

除了滑動沖突，滑動處理也是一項非常有意思的工作，感興趣的可以可以參考 NestedScrollingParent2 和 NestedScrollingChild2 喲。

文章參考自：《Android 開發(fā)藝術(shù)探索》

轉(zhuǎn)載于:https://www.cnblogs.com/liushilin/p/11197376.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的每日一问：Android 滑动冲突，你们都是怎样处理的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。