这篇文章主要是记录、总结在实际项目中遇到关于手势冲突的“破冰之旅”。
旅途目的地
新版本优化searching模块的UI展现，页面列表主要用来展示用户发表的moment，上部配备navigation bar和banner位，banner用来展示、引导话题和活动，允许配置多张，是个ViewPager。因为banner可以划出屏幕，所以决定让banner作为GridView的headerView。
航行
目标明确，准备就绪，启航！
旅途中，我们使用 GridViewWithHeaderAndFooter 来作伴（从下图.xml代码中看出支持了下拉刷新），一路上海风吹拂、心情愉悦，眼见着美女们的图片、视频都显示出来了，忍不住欣赏了起来…
前方海域
往往，当我们以为征服了海洋的时候，它便会还以颜色。
当我欣赏佳作正酣之时，突然感觉到前方海域寒气逼人，赶紧转换为高能状态，严阵以待。经过仔细的勘测和侦查，查明低温造成海面结冰，如不想办法破除，可能会给航行带来不好的体验，旅客会觉得你的服务不够专业。
原来是，从后台配置完banner后，发现banner处 ViewPager 的滑动不顺畅，在ViewPager 的滑动过程中，如果手指偏向下滑时，便引起 GridView 的下拉刷新操作。奥，直觉再次告诉我这肯定是手势冲突了，常在海上行，哪能没见过点风浪～
OK，回顾下Android的事件分发机制，下面用伪代码来展示涉及到的几个关键方法之间的关系：
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
boolean consume = false;
//首先执行当前view的onInterceptTouchEvent(ev)方法
if (onInterceptTouchEvent(ev)) {
//如果当前View进行拦截(onInterceptTouchEvent(ev)返回true)，
//接着执行当前Veiw的onTouchEvent(ev)方法
consume = onTouchEvent(ev);
} else {
//如果当前View不拦截，则事件就交给子view，调用子view的dispatchTouchEvent(ev)
consume = getFocusedChild().dispatchTouchEvent(ev);
}
return consume;
}
大家也都知道手势冲突的一般解决方法有两种（此处默认是老水手）：
1、外部拦截法：因为事件都是先经过父View的拦截处理，如果父View需要此事件就直接拦截，如果不需要就不进行拦截让子View来处理就好了。
2、内部拦截法：前提是子View都能接受到事件，如果需要此事件直接消耗掉便是，否则就交由父View进行处理，需要配合 requestDisallowInterceptTouchEvent(boolean disallowIntercept) 方法来使用。这种方法和Android的事件分发机制不一致，因此属于逆向思维，但是在有些场景是很有用的。比如：父View不易修改（直接compile的开源库）、不易继承时（别人写的，且融合有比较多的业务逻辑）…
破冰
了解了当前的处境，那么我们就针对性地开始破冰吧。
由于是compile的 UltraPullToRefresh 库，所以我的第一选择是调整本地自定义 ViewPager 的代码：
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
float x = ev.getX();
float y = ev.getY();
switch (ev.getAction()) {
……
case MotionEvent.ACTION_HOVER_MOVE:
// 当X方向的移动距离大于Y方向时，请求不允许父View拦截，让ViewPager来处理事件
if (Math.abs(x - mLastX) > Math.abs(y - mLastY)) {
getParent().requestDisallowInterceptTouchEvent(true);
}
break;
……
}
mLastX = x;
mLastY = y;
｝
当我满心欢喜地准备重新起航时，不料，现实给了我当头一棒，你！休！想！破！
为什么破不了呢？
是因为 requestDisallowInterceptTouchEvent 方法没起作用？
还是父View直接处理消耗了事件，ViewPager 根本就没机会接收？
对啊！内部拦截法的前提就是子View必须接收到事件，然后才能根据需要进行相应的处理。看来问题是出在父View上了，那么我们就直接找来造事者吧，打开GridViewWithHeaderAndFooter 却并没有发现有关事件处理的方法，它继承自 GridView ，那么就是继承了 GridView 的事件处理机制，基于之前的经验，系统的 AbsListView 组件是没有这个问题的。
好吧，继续追踪水面异常结冰的原因。经过测试发现了一点就是我们在横向滑动 ViewPager 时如果手势偏上的话是没有问题的，只是偏下时会出现下拉刷新操作，然后导致 ViewPager 的横向滑动失效，如果速度快的话就有横向划不动的感觉…
哈哈，原来是下拉刷新在搞鬼，还记得上面我给出的.xml布局中GridViewWithHeaderAndFooter 外部的两个父View LoadMoreGridViewContainer 和 FPtrFrameLayout 吧，基于当前的现象，估计是 FPtrFrameLayout 被施了魔咒，异常缠身了。
OK，让 FPtrFrameLayout 快快现身，快速定位到他的 dispatchTouchEvent 方法：
@Override
public boolean dispatchTouchEvent(MotionEvent e) {
……
int action = e.getAction();
switch (action) {
……
case MotionEvent.ACTION_MOVE:
mLastMoveEvent = e;
mPtrIndicator.onMove(e.getX(), e.getY());
float offsetX = mPtrIndicator.getOffsetX();
float offsetY = mPtrIndicator.getOffsetY();
// 横向滑动相关的判断逻辑
if (mDisableWhenHorizontalMove && !mPreventForHorizontal && (Math.abs(offsetX) > mPagingTouchSlop && Math.abs(offsetX) > Math.abs(offsetY))) {
if (mPtrIndicator.isInStartPosition()) {
mPreventForHorizontal = true;
}
}
if (mPreventForHorizontal) {
return dispatchTouchEventSupper(e);
}
// 以下是处理下拉刷新的逻辑
boolean moveDown = offsetY > 0;
boolean moveUp = !moveDown;
boolean canMoveUp = mPtrIndicator.hasLeftStartPosition();
// disable move when header not reach top
if (moveDown && mPtrHandler != null && !mPtrHandler.checkCanDoRefresh(this, mContent, mHeaderView)) {
return dispatchTouchEventSupper(e);
}
if ((moveUp && canMoveUp) || moveDown) {
movePos(offsetY);
return true;
}
}
return dispatchTouchEventSupper(e);
}
因为怀疑是下拉刷新在搞鬼，所以我们先来看他的逻辑：
// 以下是处理下拉刷新的逻辑
boolean moveDown = offsetY > 0;
boolean moveUp = !moveDown;
boolean canMoveUp = mPtrIndicator.hasLeftStartPosition();
// disable move when header not reach top
// 向下滑动，且配置不支持刷新，则返回
if (moveDown && mPtrHandler != null && !mPtrHandler.checkCanDoRefresh(this, mContent, mHeaderView)) {
return dispatchTouchEventSupper(e);
}
// 向上或向下滑动，执行操作
if ((moveUp && canMoveUp) || moveDown) {
movePos(offsetY);
return true;
}
我们测试的情况是横向滑时偏向下move，配置是支持刷新的，所以会进入 movePos 方法，该方法主要是得到Y方向move的距离，然后执行 updatePos 方法。
private void movePos(float deltaY) {
// has reached the top
if ((deltaY < 0 && mPtrIndicator.isInStartPosition())) {
if (DEBUG) {
PtrCLog.e(LOG_TAG, String.format("has reached the top"));
}
return;
}
int to = mPtrIndicator.getCurrentPosY() + (int) deltaY;
// over top
if (mPtrIndicator.willOverTop(to)) {
if (DEBUG) {
PtrCLog.e(LOG_TAG, String.format("over top"));
}
to = PtrIndicator.POS_START;
}
mPtrIndicator.setCurrentPos(to);
int change = to - mPtrIndicator.getLastPosY();
updatePos(change);
}
private void updatePos(int change) {
if (change == 0) {
return;
}
boolean isUnderTouch = mPtrIndicator.isUnderTouch();
// once moved, cancel event will be sent to child
if (isUnderTouch && !mHasSendCancelEvent && mPtrIndicator.hasMovedAfterPressedDown()) {
mHasSendCancelEvent = true;
sendCancelEvent();
}
……
}
在 updatePos 方法中又会通过判断执行到 sendCancelEvent() 方法，即向子View派发 MotionEvent.ACTION_CANCEL 事件。呵，这便是我刚才横向滑动然后偏向下move时 ViewPager 滑动失效的原因。
OK，滑动失效的原因找到了，那么我们需要做的就是在 dispatchTouchEvent 方法中绕开下拉刷新的逻辑呗，理所当然，lib库作者明显考虑了横向判断的逻辑，我们接着分析：
// （判断1）
// X方向滑动距离的绝对值大于 mPagingTouchSlop 且大于Y方向
if (mDisableWhenHorizontalMove && !mPreventForHorizontal && (Math.abs(offsetX) > mPagingTouchSlop && Math.abs(offsetX) > Math.abs(offsetY))) {
// 列表是否滑到了顶部
if (mPtrIndicator.isInStartPosition()) {
mPreventForHorizontal = true;
}
}
// （判断2）
// 为横向滑动，直接返回。
if (mPreventForHorizontal) {
return dispatchTouchEventSupper(e);
}
可以看出关键点是：如果 mPreventForHorizontal 为true就直接交给super.dispatchTouchEvent(e)，那么便不会执行下拉刷新的逻辑，破冰就指秒可待！mDisableWhenHorizontalMove 默认为false，我们给设成true，mPreventForHorizontal 在 ACTION_DOWN 时被设为false，也不影响。嘿，见鬼了，逻辑没问题呐（哈哈，太多时候我们都会不禁发出这样的疑问：不应该啊，这么没问题啊～）。“看看 mPagingTouchSlop 吧，万一是这哥们呢”，心里回响起这个声音。
mPagingTouchSlop = conf.getScaledTouchSlop() * 2;
即系统的 TOUCH_SLOP ＊ 2，乘以2的话那么 Math.abs(offsetX) > mPagingTouchSlop 条件就不容易成立（除非你快速且准确地横向滑动）。改为正常试试？修改、运行、启动一气呵成，着实有效，你能相信只是两个字符的改动？第一次触发 ACTION_MOVE 分支的逻辑经过判断1为true后，之后的move事件直接进入判断2并返回。哈哈，我们手上挥舞着跳动的字符，幻化起飞跃屏幕的世界…
扬帆
眼见坚冰悄然融化，何不趁机扬起风帆！
1、这并不是一个通过内截法解决手势冲突问题的案例。因为父View在处理下拉时并没有做Intercept，而是向子View派发 ACTION_CANCEL 事件。
2、issues中有人提供了如下解法，但会导致在 ViewPager 区域下拉不会出现刷新效果。
mViewPager.setOnPageChangeListener(new ViewPager.SimpleOnPageChangeListener() {
@Override
public void onPageScrollStateChanged(int state) {
mPtrFrame.setEnabled(state == ViewPager.SCROLL_STATE_IDLE);
}
});
3、也有人说把判断1中的这个去掉，嗯，一样的思路，都是使判断1容易成立。不过 TouchSlop 毕竟是Api定义的认为触发移动的最小距离，不过Y方向的滑动却并没有对比 TouchSlop，所以这点你可以根据情况前后统一便是。
Math.abs(offsetX) > mPagingTouchSlop
4、后来在另外一个issues中看到库的作者说这并不是bug，而是下拉操作比较灵敏而已。对啊，为什么使他如此灵敏呢？可能作者当初设计库时主要考虑逻辑是下拉的动作，随着使用场景的复杂，需要支持横向的业务，后来增加了 mDisableWhenHorizontalMove 字段来控制，但此时2倍的 TouchSlop 就不太合适了。
航海总结
以上，或许带你领略、加深了某些技能，但有可能都是错的，因为这个是我的验证，或许你有不同的声音。so，重要的是让理论指导思考，在实践中验证想法和理论，最后达成目标并反过来总结思考整个过程。
最后，感谢同事鹏哥，是他引入了这个组件并在项目中方便使用，我向他描述了问题，他便准确、快速定位到了关键点。
「spiritTalk的航海日记」
转载请标明出处：http://www.jianshu.com/p/0336b527da3f