滑动冲突的常见场景与处理思路
当我们内外两层View都可以滑动时候，就会产生滑动冲突！
常见的滑动冲突场景：
滑动冲突.png
1.外层与内层滑动方向不一致，外层ViewGroup是可以横向滑动的，内层View是可以竖向滑动的（类似ViewPager，每个页面里面是ListView）
2.外层与内层滑动方向一致，外层ViewGroup是可以竖向滑动的，内层View同样也是竖向滑动的（类似ScrollView包裹ListView）
当然还有上面两种组合起来，三层或者多层嵌套产生的冲突，然而不管是多么复杂，解决的思路都是一模一样。所以遇到多层嵌套的小伙伴也不用惊慌，一层一层处理即可。
有小伙伴肯定有疑问，ViewPager带ListView并没有出现滑动冲突啊。
那是因为ViewPager已经为我们处理了滑动冲突！如果我们自己定义一个水平滑动的ViewGroup内部再使用ListView，那么是一定需要处理滑动冲突的。
针对上面第一种场景，由于外部与内部的滑动方向不一致，那么我们可以根据当前滑动方向，水平还是垂直来判断这个事件到底该交给谁来处理。至于如何获得滑动方向，我们可以得到滑动过程中的两个点的坐标。一般情况下根据水平和竖直方向滑动的距离差就可以判断方向，当然也可以根据滑动路径形成的夹角（或者说是斜率如下图）、水平和竖直方向滑动速度差来判断。
ViewPager当斜率小于0.5时判断为横向滑动，拦截事件
有兴趣的小伙伴可以看ViewPager源码分析（2）：滑动及冲突处理
针对第二种场景，由于外部与内部的滑动方向一致，那么不能根据滑动角度、距离差或者速度差来判断。这种情况下必需通过业务逻辑来进行判断。比较常见ScrollView嵌套了ListView。虽然需求不同，业务逻辑自然也不同，但是解决滑动冲突的方式都是一样的。下面为大家截取了微博和天猫当中的同方向滑动冲突场景，方便大家更直观的感受这个场景。
同方向，竖向滑动冲突
微博的这个是同方向，竖向滑动冲突的场景，可以看到发现布局整体是可以滚动的，而且下方的微博列表也是可以滚动的。根据业务逻辑，当热门，榜单...这一行标签栏滑动到顶部的时候微博列表才可以滚动。否则就是发现布局的整体滚动。这个场景是不是在很多app里面都能够见到呢！
同方向，横向滑动冲突
天猫的这个是同方向，横向滑动冲突的场景，内外两层都是可以横向滚动的。它的处理逻辑也很明显，根据用户滑动的位置来判断到底是那个View需要响应滑动。
上述两种滑动冲突的场景区别只是在于拦截的逻辑处理上。第一种是根据水平还是竖直滑动来判断谁来处理滑动，第二种是根据业务逻辑来判断谁来处理滑动，但是处理的套路都是一样的
滑动冲突解决套路
套路一 外部拦截法：
即父View根据需要对事件进行拦截。逻辑处理放在父View的onInterceptTouchEvent方法中。我们只需要重写父View的onInterceptTouchEvent方法，并根据逻辑需要做相应的拦截即可。
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;
break;
}
case MotionEvent.ACTION_MOVE: {
if (满足父容器的拦截要求) {
intercepted = true;
} else {
intercepted = false;
}
break;
}
case MotionEvent.ACTION_UP: {
intercepted = false;
break;
}
default:
break;
}
mLastXIntercept = x;
mLastYIntercept = y;
return intercepted;
}
上面伪代码表示外部拦截法的处理思路，需要注意下面几点
根据业务逻辑需要，在ACTION_MOVE方法中进行判断，如果需要父View处理则返回true，否则返回false，事件分发给子View去处理。
ACTION_DOWN 一定返回false，不要拦截它，否则根据View事件分发机制，后续ACTION_MOVE 与 ACTION_UP事件都将默认交给父View去处理！
原则上ACTION_UP也需要返回false，如果返回true，并且滑动事件交给子View处理，那么子View将接收不到ACTION_UP事件，子View的onClick事件也无法触发。而父View不一样，如果父View在ACTION_MOVE中开始拦截事件，那么后续ACTION_UP也将默认交给父View处理！
套路二 内部拦截法：
即父View不拦截任何事件，所有事件都传递给子View，子View根据需要决定是自己消费事件还是给父View处理。这需要子View使用requestDisallowInterceptTouchEvent方法才能正常工作。下面是子View的dispatchTouchEvent方法的伪代码：
public boolean dispatchTouchEvent(MotionEvent event) {
int x = (int) event.getX();
int y = (int) event.getY();
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN: {
parent.requestDisallowInterceptTouchEvent(true);
break;
}
case MotionEvent.ACTION_MOVE: {
int deltaX = x - mLastX;
int deltaY = y - mLastY;
if (父容器需要此类点击事件) {
parent.requestDisallowInterceptTouchEvent(false);
}
break;
}
case MotionEvent.ACTION_UP: {
break;
}
default:
break;
}
mLastX = x;
mLastY = y;
return super.dispatchTouchEvent(event);
}
父View需要重写onInterceptTouchEvent方法：
public boolean onInterceptTouchEvent(MotionEvent event) {
int action = event.getAction();
if (action == MotionEvent.ACTION_DOWN) {
return false;
} else {
return true;
}
}
使用内部拦截法需要注意：
内部拦截法要求父View不能拦截ACTION_DOWN事件，由于ACTION_DOWN不受FLAG_DISALLOW_INTERCEPT标志位控制，一旦父容器拦截ACTION_DOWN那么所有的事件都不会传递给子View。
滑动策略的逻辑放在子View的dispatchTouchEvent方法的ACTION_MOVE中，如果父容器需要获取点击事件则调用 parent.requestDisallowInterceptTouchEvent(false)方法，让父容器去拦截事件。
滑动冲突解决示例代码
理论最终的落脚是在实践，下面我通过一个例子来演示外部解决法和内部解决法解决滑动冲突，大家只要get到了精髓，那么今后遇到滑动冲突问题都将迎刃而解，不再是开发拦路虎！
我们一开始说过ViewPager已经默认给我们处理了滑动冲突，而它作为ViewGroup使用的是外部拦截法解决的冲突，即在onInterceptTouchEvent方法中进行判断的。为了造成滑动冲突场景，那么我们自定义一个ViewPager，重写onInterceptTouchEvent方法并默认返回false，如下所示：
public class BadViewPager extends ViewPager {
public BadViewPager(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
return false;
}
}
这样，一个好好的ViewPager就被我们玩坏了！
接下来新建一个ScrollConflicActivity用来测试滑动冲突。
public class ScrollConflictActivity extends BaseActivity {
private BadViewPager mViewPager;
private List<View> mViews;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_scroll_conflict);
initViews();
initData(false);
}
protected void initViews() {
mViewPager = findAviewById(R.id.viewpager);
mViews = new ArrayList<>();
}
protected void initData(final boolean isListView) {
//初始化mViews列表
Flowable.just("view1", "view2", "view3", "view4").subscribe(new Consumer<String>() {
@Override
public void accept(String s) throws Exception {
//当前View
View view;
if (isListView) {
//初始化ListView
ListView listView = new ListView(mContext);
final ArrayList<String> datas = new ArrayList<>();
//初始化数据，datas ,data0 ...data49
Flowable.range(0, 50).subscribe(new Consumer<Integer>() {
@Override
public void accept(Integer integer) throws Exception {
datas.add("data" + integer);
}
});
//初始化adapter
ArrayAdapter<String> adapter = new ArrayAdapter<>
(mContext, android.R.layout.simple_list_item_1, datas);
//设置adapter
listView.setAdapter(adapter);
//将ListView赋值给当前View
view = listView;
} else {
//初始化TextView
TextView textView = new TextView(mContext);
textView.setGravity(Gravity.CENTER);
textView.setText(s);
//将TextView赋值给当前View
view = textView;
}
//将当前View添加到ViewPager的ViewList中去
mViews.add(view);
}
});
//设置ViewPager的Adapter
mViewPager.setAdapter(new BasePagerAdapter<>(mViews));
}
}
注：Flowable是RxJava2的方法，这里其实用for循环也是一样的
BasePagerAdapter是BaseProject里的方法
上面的代码我们使用了BadViewPager，初始化了BadViewPager里面的子View。
initData(false);方法传false表示里面的子View是一个TextView，传true表示里面的子View是ListView。首先我们看BadViewPager里面子View是TextView是否可以滑动。
BadViewPager_bad_textview.gif
似乎对BadViewPager的滑动没有任何影响。
大家别急，我们来分析一下，BadViewPager的onInterceptTouchEvent默认返回false则所有事件都会给子View去处理。大家是否还记得上一篇说到的View处理事件的原则？
View 的onTouchEvent 方法默认都会消费掉事件（返回true），除非它是不可点击的（clickable和longClickable同时为false），View的longClickable默认为false，clickable需要区分情况，如Button的clickable默认为true，而TextView的clickable默认为false。
所以TextView默认并没有消费事件，因为他是不可点击的。事件会交由父View即BadViewPager的onTouchEvent方法去处理。所以它自然是可以滑动的。
我们将textview的Clickable设置成true，即让它来消费事件。大家再看看呢
BadViewPager_bad_textview_clickable.gif
所以我们不难推测如果将TextView换成Button，将是一样的无法滑动的效果。虽然这并不是常规的滑动冲突（子View不是滑动的），但是造成的原因其实是一样的，没有做滑动判断导致父View不能正确响应滑动事件。
接下来稍稍修改一下代码 initData(true);传入true，即BadViewPager的子View使用ListView，显然ListView是可以滑动的，BadViewPager是不能滑动的。我们分别通过外部拦截和内部拦截方法来对BadViewPager进行修复。
BadViewPager_bad_listview.gif
1.外部拦截法Fix BadViewPager：
public class BadViewPager extends ViewPager {
private static final String TAG = "BadViewPager";
private int mLastXIntercept;
private int mLastYIntercept;
public BadViewPager(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
boolean intercepted = false;
int x = (int) ev.getX();
int y = (int) ev.getY();
final int action = ev.getAction() & MotionEvent.ACTION_MASK;
switch (action) {
case MotionEvent.ACTION_DOWN:
intercepted = false;
//调用ViewPager的onInterceptTouchEvent方法初始化mActivePointerId
super.onInterceptTouchEvent(ev);
break;
case MotionEvent.ACTION_MOVE:
//横坐标位移增量
int deltaX = x - mLastXIntercept;
//纵坐标位移增量
int deltaY = y - mLastYIntercept;
if (Math.abs(deltaX)>Math.abs(deltaY)){
intercepted = true;
}else{
intercepted = false;
}
break;
case MotionEvent.ACTION_UP:
intercepted = false;
break;
default:
break;
}
mLastXIntercept = x;
mLastYIntercept = y;
LogUtil.e(TAG,"intercepted = "+intercepted);
return intercepted;
}
}
根据我们的外部拦截法的套路，需要重写BadViewPager 的onInterceptTouchEvent方法，并且ACTION_DOWN 和 ACTION_UP返回为false。处理逻辑在ACTION_MOVE中，Math.abs(deltaX)>Math.abs(deltaY)表示横向位移增量大于竖向位移增量，即水平滑动，则BadViewPager 拦截事件。
这里我们在ACTION_DOWN 当中还调用了super.onInterceptTouchEvent(ev);即ViewPager的onInterceptTouchEvent方法。主要是为了初始化ViewPager的成员变量mActivePointerId。mActivePointerId默认值为-1，在ViewPager的onTouchEvent方法的ACTION_MOVE中有这么一段：
class ViewPager
@Override
public boolean onTouchEvent(MotionEvent ev) {
...
switch (action & MotionEventCompat.ACTION_MASK) {
case MotionEvent.ACTION_MOVE:
if (!mIsBeingDragged) {
final int pointerIndex = ev.findPointerIndex(mActivePointerId);
if (pointerIndex == -1) {
// A child has consumed some touch events and put us into an inconsistent
// state.
needsInvalidate = resetTouch();
break;
}
//具体的滑动操作...
}
...
break;
...
}
...
}
假如mActivePointerId不进行初始化，ViewPager会认为这个事件已经被子View给消费了，然后break掉，接下来的滑动操作也就不执行了。
BadViewPager_fixed_listview.gif
2.内部拦截法Fix BadViewPager：
内部拦截法需要重写ListView的dispatchTouchEvent方法，所以我们自定义一个ListView：
public class FixListView extends ListView {
private static final String TAG = "FixListView";
private int mLastX;
private int mLastY;
public FixListView(Context context) {
super(context);
}
public FixListView(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
int x = (int) ev.getX();
int y = (int) ev.getY();
final int action = ev.getAction() & MotionEvent.ACTION_MASK;
switch (action) {
case MotionEvent.ACTION_DOWN:
getParent().requestDisallowInterceptTouchEvent(true);
break;
case MotionEvent.ACTION_MOVE:
//水平移动的增量
int deltaX = x - mLastX;
//竖直移动的增量
int deltaY = y - mLastY;
//当水平增量大于竖直增量时，表示水平滑动，此时需要父View去处理事件
if (Math.abs(deltaX) > Math.abs(deltaY)){
getParent().requestDisallowInterceptTouchEvent(false);
}
break;
case MotionEvent.ACTION_UP:
break;
default:
break;
}
mLastX = x;
mLastY = y;
return super.dispatchTouchEvent(ev);
}
}
再看BadViewPager，需要重写拦截方法
public class BadViewPager extends ViewPager {
private static final String TAG = "BadViewPager";
public BadViewPager(Context context, AttributeSet attrs) {
super(context, attrs);
}
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
final int action = ev.getAction() & MotionEvent.ACTION_MASK;
if (action == MotionEvent.ACTION_DOWN){
super.onInterceptTouchEvent(ev);
return false;
}
return true;
}
}
可以看到和我们的套路代码基本上一样，只是ACTION_MOVE中有我们自己的逻辑处理，处理的方式与外部拦截法也是一致的，并且效果也一样，在此不作赘述。
大家只用掌握上述滑动冲突的解决套路，不论场景是不同方向，还是同方向，还是乱七八糟的堆加在一起，就用套路去解决，万变不离其宗。根据上述的外部拦截和内部拦截法，可以看出外部拦截法实现起来更加简单，而且也符合View的正常事件分发机制，所以推荐使用外部拦截法（重写父View的onInterceptTouchEvent，父View决定是否拦截）来处理滑动冲突
原文：https://blog.csdn.net/u010302764/article/details/72778732
3635
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
