这篇文章主要是记录、总结在实际项目中遇到关于手势冲突的“破冰之旅”。

旅途目的地

新版本优化searching模块的UI展现，页面列表主要用来展示用户发表的moment，上部配备navigation bar和banner位，banner用来展示、引导话题和活动，允许配置多张，是个ViewPager。因为banner可以划出屏幕，所以决定让banner作为GridView的headerView。

Fame风靡

航行

目标明确，准备就绪，启航！

旅途中，我们使用 GridViewWithHeaderAndFooter 来作伴（从下图.xml代码中看出支持了下拉刷新），一路上海风吹拂、心情愉悦，眼见着美女们的图片、视频都显示出来了，忍不住欣赏了起来…

  <FPtrFrameLayout
    android:id="@+id/layout_refresh"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <LoadMoreGridViewContainer
        android:id="@+id/layout_loadmore"
        android:layout_width="match_parent"
        android:layout_height="match_parent">

        <GridViewWithHeaderAndFooter
            android:id="@+id/gridView"
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:numColumns="3" />
    </LoadMoreGridViewContainer>
</FPtrFrameLayout>

前方海域

往往，当我们以为征服了海洋的时候，它便会还以颜色。

当我欣赏佳作正酣之时，突然感觉到前方海域寒气逼人，赶紧转换为高能状态，严阵以待。经过仔细的勘测和侦查，查明低温造成海面结冰，如不想办法破除，可能会给航行带来不好的体验，旅客会觉得你的服务不够专业。

原来是，从后台配置完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的航海日记」
转载请标明出处：//www.greatytc.com/p/0336b527da3f