由于這部分的內(nèi)容涉及的底層知識較多，沒有讀過源碼小伙伴相對比較難以理解铐达。許多小伙伴遇到滑動沖突的時候只是去知其然而不是去知其所以然限次。其實大家沒必要害怕去接觸復雜的內(nèi)容于宙，其實他們也都是由多個細節(jié)方面的特點堆積形成的扛稽。就此部分的內(nèi)容談一談我自己的看法吁峻，期待各位的不吝賜教。
滑動沖突的產(chǎn)生
那么滑動沖突時如何產(chǎn)生的呢在张？界面中只要在內(nèi)外倆層同時可以滑動的時候就會產(chǎn)生滑動沖突用含，導致內(nèi)外倆層只有一層可以滑動。
場景一：外部和內(nèi)部倆層滑動方向不一致
內(nèi)外層的滑動效果可以通過倆種方式來實現(xiàn)帮匾，ViewPager + Fragment和ScrollView + Fragment啄骇。對于前者來說系統(tǒng)在內(nèi)部已經(jīng)解決了滑動沖突，而后者需要手動解決瘟斜。這就需要小伙伴們了解一些基礎(chǔ)的事件分發(fā)機制的知識缸夹。
場景二：外部和內(nèi)部倆層滑動方向一致
實現(xiàn)方式同場景一，不同的是因為內(nèi)外倆層的滑動方向一致螺句，也就是說當手指滑動的時候虽惭，系統(tǒng)無法確定用戶是想讓那一層滑動。進而會導致要么只有一層滑動蛇尚，要么內(nèi)外倆層都可以滑動但是比較卡頓趟妥。
場景三：主要是針對場景一和二的嵌套
就是針對場景一和場景二的嵌套。其實也沒有看起來這么復雜佣蓉，可以理解為幾個沖突的疊加。簡單來說就是將其拆分成多個場景二或者場景一來處理亲雪。
滑動沖突的解決思路
對于場景一來說勇凭，滑動類型（水平，垂直）可以根據(jù)滑動路徑與水平方向的夾角义辕，或者是水平方向和垂直方向的距離差（dy - dx）虾标，或者是水平和垂直方向上的速度差，然后根據(jù)滑動是水平滑動還是豎直滑動進一步取決于誰來攔截當前事件灌砖。對于場景二璧函，場景三來說比較特殊傀蚌，無法根據(jù)場景一的思路來解決。一般是可以在業(yè)務(wù)找到一個突破點進行相應(yīng)的處理蘸吓。這里將不再贅述善炫。
滑動沖突的解決方式
針對上述的場景一般有倆種方式去解決。分別是外部攔截和內(nèi)部攔截库继。
外部攔截(父容器優(yōu)先)就是由父容器首先決定是否消耗事件箩艺，然后才會傳遞給子元素。相比內(nèi)部攔截更簡單宪萄，也符合View的事件分發(fā)機制艺谆，是解決滑動沖突的優(yōu)先選擇。通過重寫父容器的onInterceptTouchEvent方法實現(xiàn)拜英。針對不同的滑動沖突静汤，只需要修改父容器需要消耗此事件的條件即可，外部攔截的邏輯框架如下：
public boolean?onInterceptTouchEvent(MotionEvent event) {
boolean intercepted =?false;
int?x = ?(int)event.getX();
int?y = ?(int)event.getY();
switch(event.getAction()) {
case MotionEvent.ACTION_DOWN: {
intercepted =?false;
//如果為true的話子元素將接收不到任何事件
if(!scroller.isFinished()) {
scroller.abortAnimation();
intercepted =?true;
}
break;
}
caseMotionEvent.ACTION_MOVE: {
int?tempX = x-lastXIntercept;
int?tempY = y-lastYIntercept;
//是否是水平滑動
if(Math.abs(tempX) >Math.abs(tempY)) {
intercepted =?true;
}else{
intercepted =?false;
}
break;
}
case MotionEvent.ACTION_UP: {
intercepted =?false;//一般不去攔截UP事件
break;
}
default:
break;
}
lastX = x;
lastY = y;
lastXIntercept = x;
lastYIntercept = y;
returnintercepted;
}
內(nèi)部攔截(子元素優(yōu)先)就是父容器默認不去攔截任何事件居凶，所有的事件都傳遞給子元素虫给，如果子元素需要消耗該事件就直接消耗，否則會通過重寫子元素的dispatchTouchEvent方法將事件傳遞給父容器處理排监。針對不同的滑動策略只需修改對應(yīng)的條件即可狰右，內(nèi)部攔截的邏輯框架如下：
public?boolean?dispatchTouchEvent(MotionEvent event){
int x = (int) event.getX();
int?y = (int) event.getY();
switch(event.getAction()) {
case?MotionEvent.ACTION_DOWN: {
horizontalScrollView.requestDisallowInterceptTouchEvent(true);
break;
}
case?MotionEvent.ACTION_MOVE: {
int?tempX = x - lastX;
int?tempY = y - lastY;
if(Math.abs(tempX) > Math.abs(tempY)) {
horizontalScrollView.requestDisallowInterceptTouchEvent(false);
}
break;
}
case?MotionEvent.ACTION_UP: {
break;
}
default:
break;
}
lastX = x;
lastY = y;
return?super.dispatchTouchEvent(event);
}
“MotionEvent.ACTION_DOWN: {// 必須返回false,否則后續(xù)事件無法傳遞到子元素”------why?
這個問題涉及到事件分發(fā)機制的一些知識。我盡量通俗的去分析舆床，方便大家伙兒的理解棋蚌。你有沒有想過，當你單擊一個按鈕的時候系統(tǒng)是如何確定被單擊的組件的呢挨队？是這樣的谷暮，事件一旦被觸發(fā)的話最先傳遞給當前的Activity，由它的dispatchTouchEvent()來完成事件的分發(fā)盛垦。具體工作由它內(nèi)部的Window將事件傳遞給Decor View(頂級父容器)湿弦，再由頂級父容器傳遞給子元素來實現(xiàn)的。對于有使用過標簽優(yōu)化界面的同學一定聽說過最外層的那個神秘的FrameLayout腾夯。是的颊埃，它就是Decor View
對于單個View來說，由于它沒有子元素無法再向下傳遞蝶俱，所以只能自己決定是否消耗事件班利。如果設(shè)置了OnTouchListener()的話，onTouch()就會被調(diào)用否則onTouchEvent()被調(diào)用榨呆。如果同時提供的話onTouch()會將onTouchEvent()屏蔽掉罗标。如果該組件決定處理事件，則會終止Down事件的分發(fā)，并將接下來的所有事件都交給該組件直接進行處理(當然前提是事件可以傳遞給它)闯割。在執(zhí)行UP事件的時候彻消，如果在onTouchEvent()中設(shè)置onClickListener的話onClick()也會被觸發(fā)。
對于ViewGroup來說宙拉，如果不攔截當前事件的話宾尚，就會由子組件繼續(xù)進行事件的分發(fā)。當所有組件都沒有消耗事件的時候也就是說所有的onTouchEvent()方法中都返回false鼓黔，然后就會觸發(fā)Activity的onTouchEvent()事件來消耗事件央勒。否則，之后全部的事件都由ViewGroup來處理澳化，不會傳遞給子元素崔步。
