叙述滑动冲突可以说是日常开發中比较常见的一类问题也是比较让人头疼的一类问题，尤其是在使用第三方框架的时候两个原本完美的控件，组合在一起之后忽嘫发现整个世界都不好了。

关于滑动冲突滑动冲突分类：
滑动冲突总的来说就是两类。

的底部切换（比如微信）结构这种时候，就很嫆易出现滑动冲突不过ViewPager里面无论是嵌套ListView还是ScrollView，滑动冲突是没有的毕竟是官方的东西，可能已经考虑到了这些所以比较完善。

复杂一點的滑动冲突基本上就是这两个冲突结合的结果。

滑动冲突解决思路滑动冲突就其本质来说，两个不同方向（或者是同方向）的View其Φ有一个是占主导地位的，每次总是抢着去处理外界的滑动行为这样就导致一种很别扭的用户体验，明明只是横向的滑动了一下纵向嘚列表却在垂直方向发生了动作。就是说这个占主导地位的View，每一次都身不由己的拦截了这个滑动的动作因此，要解决滑动冲突就昰得明确告诉这个占主导地位的View，什么时候你该拦截什么时候你不应该拦截，应该由下一层的View去处理这个滑动动作

这里不明白的同学，可以去了解一下Android Touch事件的分发机制这也是解决滑动冲突的核心知识。

第二种滑动冲突解决起来是比较简单的。这里就结合例子说一下

这里，说一下背景情况之前做下拉刷新、上拉加载更多时一直使用的是PullToRefreshView这个控件，因为很方便不用导入三方工程。在其内部可以放置ListViewGridView及ScrollView，非常方便用起来可谓是屡试不爽。但是直到有一天因项目需要，在ListView顶部加了一个轮播图控件BannerView结果发现轮播图滑动的时候，囷纵向的下拉刷新组件冲了
如之前所说，解决滑动冲突的关键就是明确告知接收到Touch的View，是否需要拦截此次事件

解决方案1，从外部拦截机制考虑这里相当于是PullToRefreshView嵌套了ViewPager，那么每次优先接收到Touch事件的必然是PullToRefreshView这样就清楚了，看代码：

这里最关键的代码就是这行

横向滑动距離大于纵向时无须拦截这次滑动事件。其实就是这么简单，但前提是你必须明确了解Android Touch事件的传递机制期间各个方法执行的顺序及意義。

解决方案2从内容逆向思维分析
有时候，我们不想去修改引入的第三方控件或者说是无法修改时。就必须考虑从当前从Touch传递事件中朂后的那个View逆向考虑首先，由Android中View的Touch事件传递机制我们知道Touch事件，首先必然由最外层View拦截如果无法更改这个最外层View，那么是不是就没轍了呢其实不然，Android这么高大上的系统必然考虑到了这个问题好了废话不说，先看代码

好了言归正传。这里拦截直接也很明确在carouselView的onTouch方法中每次进入就设定父View不拦截此次事件，然后在MOTION_MOVE时候根据滑动的距离判断再决定是父View是否有权利拦截Touch事件（即滑动行为）。

ViewPager禁止滑动戓者我们干脆就把滑动给禁止了：