微信号:guolin_blog

介绍:Android技术分享平台,在这里不仅可以学到各种Android相关的最新技术,还可以将你自己的技术总结分享给其他人,每周定期更新.

Android自定义之圆弧滑动效果

2018-07-11 07:59 陈小缘



今日科技快讯


近日,2022年世界上首座浮动城市将在南太平洋建成,据这座城市的赞助者称,它将拥有自己的政府和加密货币。这座孤立乌托邦式城市的建造工作将在明年开始,这个研究所是由科技界亿万富翁Peter Thiel合创的一个非营利性组织。Peter Thiel是脸书的董事会成员,而且也是美国总统唐纳德-特朗普的前顾问。


作者简介


本篇来自 陈小缘 的投稿,分享了利用 ArcSlidingHelper 实现的圆弧滑动效果,一起来看看!希望大家喜欢。

陈小缘 的博客地址:

https://blog.csdn.net/u011387817


前言


我们平时在开发中,难免会遇到一些比较特殊的需求,就比如我们这篇文章的主题,一个关于圆弧滑动的,一般是比较少见的。其实在遇到这些东西时,不要怕(反而觉得很好玩),一步步分析他实现原理,问题便能迎刃而解。

前几天一位群友发了一张图,问类似这种要怎么实现:

  1. 要支持手势旋转

  2. 旋转后惯性滚动

  3. 滚动后自动选中

哈哈, 来一张自己实现的效果图:


初步分析


首先我们看下设计图,Item 绕着一个半圆旋转,如果我们是自定义 ViewGroup 的话,那么在 onLayout 之后,就要把这些 Item 按一定的角度旋转了。如果直接继承 View,这个比较方便,可以直接用 Canvas 的 rotate 方法。不过如果继承 View 的话,做起来是简单,也能满足上面的需求,但局限性就比较大了: 只能 draw,而且 Item 内容不宜过多。所以这次我们打算自定义 ViewGroup,它的好处呢就是:什么都能放,我不管你 Item 里面是什么,反正我就负责显示。 惯性滚动的话,这个很容易,我们可以用 Scroller 配合 VelocityTracker 来完成。 旋转手势,无非就是计算手指滑动的角度。


选择旋转方案


说起 View 的动画播放,大家肯定都是轻车熟路了,如果一个 View,它有监听点击事件,那么在播放位移动画后,监听的位置按道理,也应该在它最新的位置上(即位移后的位置),在这种情况下我们用 View 的 startAnimation 就不奏效了:

TranslateAnimation translateAnimation = new TranslateAnimation(01500300);
translateAnimation.setDuration(500);
translateAnimation.setFillAfter(true);
mView.startAnimation(translateAnimation);

可以看到,在 View 位移之后,监听点击事件的区域还是在原来的地方。 我们再看下用属性动画的:

mView.animate().translationX(150).translationY(300).setDuration(500).start();

监听点击事件的区域随着 View 的移动而更新了。 嘻嘻,我们通过实践来验证了这个说法。那么我们做的这个是要支持触摸事件的,肯定是使用第二种方法。 ViewPropertyAnimator 的源码分析相信大家之前也都已经看过其他大佬们的文章了,这里就只讲讲关键代码: ViewPropertyAnimator 它不是 ValueAnimator 的子类,哈哈,这个有点意外吧,我们直接看 startAnimation 方法(这个方法是 start() 里面调用的):

 private void startAnimation() {
        ...
        //可以看到这里创建了ValueAnimator对象
        ValueAnimator animator = ValueAnimator.ofFloat(1.0f);
        ...
        animator.addUpdateListener(mAnimatorEventListener);
        ...
        animator.start();
    }

中间那里 addUpdateListener(mAnimatorEventListener),我们来看看这个 listener 里面做了什么:

 @Override
        public void onAnimationUpdate(ValueAnimator animation) {
            ...
            ...
            ArrayList<NameValuesHolder> valueList = propertyBundle.mNameValuesHolder;
            if (valueList != null) {
                int count = valueList.size();
                for (int i = 0; i < count; ++i) {
                    NameValuesHolder values = valueList.get(i);
                    float value = values.mFromValue + fraction * values.mDeltaValue;
                    if (values.mNameConstant == ALPHA) {
                        alphaHandled = mView.setAlphaNoInvalidation(value);
                    } else {
                        setValue(values.mNameConstant, value);
                    }
                }
            }
            ...
            ...
        }

else 里面调用了 setValue 方法,我们再继续跟下去 (哈哈,感觉好像捉贼一样):

 private void setValue(int propertyConstant, float value) {
        final View.TransformationInfo info = mView.mTransformationInfo;
        final RenderNode renderNode = mView.mRenderNode;
        switch (propertyConstant) {
            case TRANSLATION_X:
                renderNode.setTranslationX(value);
                break;
            case TRANSLATION_Y:
                renderNode.setTranslationY(value);
                break;
            case TRANSLATION_Z:
                renderNode.setTranslationZ(value);
                break;
            case ROTATION:
                renderNode.setRotation(value);
                break;
            case ROTATION_X:
                renderNode.setRotationX(value);
                break;
            case ROTATION_Y:
                renderNode.setRotationY(value);
                break;
            case SCALE_X:
                renderNode.setScaleX(value);
                break;
            case SCALE_Y:
                renderNode.setScaleY(value);
                break;
            case X:
                renderNode.setTranslationX(value - mView.mLeft);
                break;
            case Y:
                renderNode.setTranslationY(value - mView.mTop);
                break;
            case Z:
                renderNode.setTranslationZ(value - renderNode.getElevation());
                break;
            case ALPHA:
                info.mAlpha = value;
                renderNode.setAlpha(value);
                break;
        }
    }

我们可以看到,它就调用了 View 的 mRenderNode 里面的 setXXX 方法,最关键就是这些方法啦,其实这几个 setXXX 方法在 View 里面也有公开的,我们也是可以直接调用的,所以我们在处理 ACTION_MOVE 的时候,就直接调用它而不用播放动画啦。 我们现在验证一下这个方案可不可行: 

先试试 setTranslationY:

将 setTranslationY 方法换成 setRotation 看看:

好了,经过我们实践验证了这个方案是可行的,在旋转之后,监听点击事件的位置也更新了,这正好是我们需要的效果。


知其然,知其所以然


哈哈,其实现在就有点 知其然而不知其所以然 的感觉了,既然我们都知道补间动画不能改变接受触摸事件的区域,而属性动画就可以。 那么,有没有想过为什么会这样呢? 可能有同学就会说了: “因为属性动画改变了坐标” 真的是这样吗? 

额,如果这个”坐标”指的是 getX,getY 取得的值,那就是对的。为什么呢?很简单,我们来看看 getX 和 getY 的方法源码就知道了:

    public float getX() {
        return mLeft + getTranslationX();
    }
    public float getY() {
        return mTop + getTranslationY();
    }

哈哈,看到了吧,它们返回的值都分别加上了对应的 Translation 的值,而属性动画更新帧时,也是更新了 Translation 的值,所以当动画播放完毕,getX 和 getY 时,总是能取到正确的值。

但如果说这个坐标是指 left,top,right,bottom 呢,那就不对了,为什么呢?因为经过我们刚刚对 ViewPropertyAnimator 的源码分析,知道了位移动画最终也只是调用了RenderNode 的 setTranslation 方法,而 left,top,right,bottom 这四个值并没有改变。这时候可能有同学就会说了:我不信!既然没有真正改变它的坐标,那它接受触摸事件的区域怎么也会跟着移动呢? 

好吧,既然你不信,那我们来做个试验就知道了,这次需要到 设置 - 开发者选项 里面把显示布局边界这个选项打开:

关键代码

看看效果

emmm,我们开启了布局边界选项之后,可以看到当 View 移动的时候,那个框框并没有跟着移动,且我们打印的 left, top, right, bottom 的值一直都是一样的。 

好,我们把 setTranslation 改成 layout 方法看看。

代码

    @Override
    public boolean onTouch(View v, MotionEvent event) {
        ...
        if (event.getAction() == MotionEvent.ACTION_MOVE) {
            ...
            mView.layout(x - widthOffset, y - heightOffset - toolbarHeight,
                    x + widthOffset, y + heightOffset - toolbarHeight);
            ...
        }
        return true;
    }

效果

哈哈哈,看到了吧,用 layout 方法来移动 View,那个框框也会跟着走的,且打印的 ltrb值,也会跟着变(废话),而使用 setTranslation 的话,就像元神出窍了一样。。。 相信现在大家都已经知道了为什么说 setTranslation 方法也不是真正能改变坐标了吧。 

好了,我们现在回到上面的问题:既然 setTranslation 方法没有真正的改变坐标,那为什么触摸区域却会跟着移动呢? 

这个就需要看一下 ViewGroup 的源码了,我们先从哪里开始看呢?emmm,肯定是从 dispatchTouchEvent 方法开始啦,原因想必大家都已经想到了吧。 

我们要先找到判断 ACTION_DOWN的,然后再找遍历子 View 的 for 循环,看看它是怎么找到偏移后的View的

@Override
    public boolean dispatchTouchEvent(MotionEvent ev) {

        ...

        if (actionMasked == MotionEvent.ACTION_DOWN
                || (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)
                || actionMasked == MotionEvent.ACTION_HOVER_MOVE) {

            ...

            final View[] children = mChildren;
            //从最后添加到ViewGroup的View(最上面的)开始递减遍历
            for (int i = childrenCount - 1; i >= 0; i--) {
                final int childIndex = getAndVerifyPreorderedIndex(childrenCount, i, customOrder);
                final View child = getAndVerifyPreorderedView(preorderedList, children, childIndex);

                ...

                //判断当前遍历到的子View是否符合条件
                if (!canViewReceivePointerEvents(child)
                        || !isTransformedTouchPointInView(x, y, child, null)) {
                    ev.setTargetAccessibilityFocus(false);
                    continue;
                }

                //找到合适的子View之后,将事件向下传递
                if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
                    ...
                }

                ...
            }
        }

    }

我们重点看 for 循环里面的第一个 if,因为它能决定是否还要继续往下执行。通过看方法名能猜到,前面的方法大概就是判断子 View 能不能接受到事件,它里面是这样的:

  private static boolean canViewReceivePointerEvents(@NonNull View child) {
        return (child.mViewFlags & VISIBILITY_MASK) == VISIBLE
                || child.getAnimation() != null;
    }

emmm,不可见的时候又没有设置动画,自然就不会把触摸事件给它了。 

我们来看看第二个:isTransformedTouchPointInView 方法

    protected boolean isTransformedTouchPointInView(float x, float y, View child,
            PointF outLocalPoint)
 
{
        final float[] point = getTempPoint();
        point[0] = x;
        point[1] = y;
        transformPointToViewLocal(point, child);
        final boolean isInView = child.pointInView(point[0], point[1]);
        if (isInView && outLocalPoint != null) {
            outLocalPoint.set(point[0], point[1]);
        }
        return isInView;
    }

中间调用了 transformPointToViewLocal 方法,看看

    public void transformPointToViewLocal(float[] point, View child) {
        point[0] += mScrollX - child.mLeft;
        point[1] += mScrollY - child.mTop;

        if (!child.hasIdentityMatrix()) {
            child.getInverseMatrix().mapPoints(point);
        }
    }

我们先放一放这个 hasIdentityMatrix 方法,直接看if里面的内容,它是 get 了一个矩阵然后调用了 mapPoints 方法,这个 mapPoints 方法就是:当矩阵发生变化后(平移,旋转,缩放等),将最初位置上面的坐标,转换成变化后的坐标,比如说:数组[0, 0](分别对应x和y)在矩阵向右边平移了50(matrix.postTranslate(50, 0))之后,调用mapPoints 方法并将这个数组作为参数传进去,那这个数组就变成[50, 0],如果这个矩阵绕[100, 100]上的点顺时针旋转了90度(matrix.postRotate(90, 100, 100))的话,那这个数组就会变成[200, 0]了,只看文字可能有点难理解,没关系,我们做个图出来就很清晰明了了: 

例如这个顺时针旋转90度的:

我们可以把矩形的宽高当作100x100,那个红点的坐标就是[0, 0]了,当这个矩形旋转的时候,可以看到它是以[100, 100]的点作旋转中心的,在旋转完之后,那个红点的Y轴并没有变化,而X轴则向右移动了两个矩形的宽,emmm,这下大家都明白上面说的为什么会由[0, 0]变成[200, 0]了吧。 

现在就不难理解,为什么 ViewGroup 能找到“元神出窍”的 View了,我们回到上面的 isTransformedTouchPointInView 方法。

可以看到,当它调用 transformPointToViewLocal 方法时,把触摸点的坐标传进去了,那么,等这个 transformPointToViewLocal 方法执行完毕之后呢,这个触摸点坐标就是转换后的坐标了,随后它还调用了 View 的 pointInView 方法,并把转换后的坐标分别传了进去,这个方法我们看名字就大概能猜到是检测传进去的 xy 坐标点是否在 View 内(哈哈,我们平时在开发中也应该尽量把方法和变量命名得通俗易懂些,一看就知道个大概那种,这样在团队协作中,就算注释写的比较少,同事也不会太难看懂),我们来看看这个 pointInView 方法:

    final boolean pointInView(float localX, float localY) {
        return pointInView(localX, localY, 0);
    }

    public boolean pointInView(float localX, float localY, float slop) {
        return localX >= -slop && localY >= -slop && localX < ((mRight - mLeft) + slop) &&
                localY < ((mBottom - mTop) + slop);
    }

嗯,很显然就是判断传进去的坐标是否在此View中。

好了,现在我们来总结一下:

  • ViewGroup 在分派事件的时候,会从最后添加到 ViewGroup 的 View (最上面的)开始递减遍历;

  • 通过调用isTransformedTouchPointInView方法来处理判断触摸的坐标是否在子 View内;

  • 这个 isTransformedTouchPointInView 方法会调用 transformPointToViewLocal 来把相对于 ViewGroup 的触摸坐标转换成相对于该子 View 的坐标,并且如果该子 View 所对应的矩阵有应用过变换(平移,旋转,缩放等)的话,还会继续将坐标转换成矩阵变换后的坐标。触摸坐标转换后,会调用 View 的 pointInView 方法来判断此触摸点是否在 View内;

  • ViewGroup 会根据 isTransformedTouchPointInView 方法的返回值来决定要不要把事件交给这个子 View;

好,我们来模拟一下 ViewGroup 是怎么找到这个 “元神出窍” 的 View 的,加深下理解。

关键代码

@Override
    public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) {
        float[] points = new float[2];
        mView.setRotation(progress);
        mView.setTranslationX(-progress);
        mView.setTranslationY(-progress);
        Matrix matrix = getViewMatrix(mView);
        if (matrix != null) {
            matrix.mapPoints(points);
        }
        mToast.setText(String.format("绿点在View中吗?  %s",
                pointInView(mView, points) ? "是的" : "不不不不"));
        mToast.show();
    }

    private Matrix getViewMatrix(View view) {
        try {
            Method getInverseMatrix = View.class.getDeclaredMethod("getInverseMatrix");
            getInverseMatrix.setAccessible(true);
            return (Matrix) getInverseMatrix.invoke(view);
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }

    private boolean pointInView(View view, float[] points) {
        try {
            Method pointInView = View.class.getDeclaredMethod("pointInView"float.class, float.class);
            pointInView.setAccessible(true);
            return (boolean) pointInView.invoke(view, points[0], points[1]);
        } catch (Exception e) {
            e.printStackTrace();
        }
        return false;
    }

因为 View 的 getInverseMatrix和pointInView 方法,我们都不能直接调用到的,所以要用反射,来看看效果:

哈哈,现在大家都明白 ViewGroup 为什么还能找到 “元神出窍” 后的 View了吧。

好了,现在来回顾一下 transformPointToViewLocal 方法,我们刚刚忽略了里面调用的hasIdentityMatrix 方法,到现在这个方法也大概能猜到个大概了:就是鉴定这个 View 所对应的矩阵有没有应用过比如 setTranslation,setRotation,setScale 这些方法,如果有就返回 false, 没有就 true。

再回到最初的问题:既然属性动画可以,那为什么补间动画就不行呢?大家都是动画啊!

有同学可能已经知道为什么了,因为播放补间动画并没有影响到上面说的hasIdentityMatrix 方法的返回值,那它是怎么改变 View 的位置或大小的呢?我们还是来看看源码吧。通过看 ScaleAnimation,TranslateAnimation 和 RotateAnimation 能看出来,他们都重写了 Animation 类的 applyTransformation 和  initialize 方法,这个 initialize 方法看名字就大概知道是初始化一些东西,所以我们重点还是看他们重写之后的 applyTransformation 方法。

首先是 ScaleAnimation:

   @Override
    protected void applyTransformation(float interpolatedTime, Transformation t) {
        ...
        if (mPivotX == 0 && mPivotY == 0) {
            t.getMatrix().setScale(sx, sy);
        } else {
            t.getMatrix().setScale(sx, sy, scale * mPivotX, scale * mPivotY);
        }
    }

TranslateAnimation

@Override
    protected void applyTransformation(float interpolatedTime, Transformation t) {
        ...
        t.getMatrix().setTranslate(dx, dy);
    }

RotateAnimation

  @Override
    protected void applyTransformation(float interpolatedTime, Transformation t) {
        ...
        if (mPivotX == 0.0f && mPivotY == 0.0f) {
            t.getMatrix().setRotate(degrees);
        } else {
            t.getMatrix().setRotate(degrees, mPivotX * scale, mPivotY * scale);
        }
    }

emmm,通过对比他们各自实现的方法,发现最后都是调用 Transformation 的 getMatrix 方法来获取到矩阵对象然后对这个矩阵进行操作的,那我们就要看看这个 Transformation是在哪里传进来的了。回到 Animation 中,会发现 applyTransformation 方法是在 getTransformation(long currentTime, Transformation outTransformation) 方法中调用的,它直接把参数中的 outTransformation 作为 applyTransformation 方法的 t 参数传进去了,那现在就要看看在哪里调用了会发现 applyTransformation 方法是在 getTransformation 方法了。在 View 中,我们通过搜索方法名可以找到调用它的是 applyLegacyAnimation 方法,我们这次主要是看它传进取的 Transformation 对象是哪里来的,最终要到哪里去。

private boolean applyLegacyAnimation(ViewGroup parent, long drawingTime,
            Animation a, boolean scalingRequired)
 
{
        ...
        final Transformation t = parent.getChildTransformation();
        boolean more = a.getTransformation(drawingTime, t, 1f);
        if (scalingRequired && mAttachInfo.mApplicationScale != 1f) {
            invalidationTransform = parent.mInvalidationTransformation;
            a.getTransformation(drawingTime, invalidationTransform, 1f);
        } 
        ...
    }

我们继续搜 “parent.getChildTransformation()”,最终发现在 draw 方法有再次调用,来看看精简后的 draw 方法。

 boolean draw(Canvas canvas, ViewGroup parent, long drawingTime) {

        Transformation transformToApply = null;

        final Animation a = getAnimation();
        if (a != null) {
            more = applyLegacyAnimation(parent, drawingTime, a, scalingRequired);
            transformToApply = parent.getChildTransformation();
        }

        if (transformToApply != null) {
            if (drawingWithRenderNode) {
                renderNode.setAnimationMatrix(transformToApply.getMatrix());
            } else {
                canvas.translate(-transX, -transY);
                canvas.concat(transformToApply.getMatrix());
                canvas.translate(transX, transY);
            }
        }
    }

emmm,可以看到,当 getAnimation 不为空的时候,它就会先调用 applyLegacyAnimation 方法,而这个方法最终会调用到 Animation 的 applyTransformation 方法,Animation的子类会在这个方法中根据传进来的 Transformation 对象 get 到矩阵,然后那些平移呀,旋转,缩放等操作都只是对这个矩阵进行操作。 那么等这个 applyLegacyAnimation 方法执行完毕之后呢,就是时候刷新帧了,在 draw 方法中他会根据一个drawingWithRenderNode,来决定是调用 RenderNode 的 setAnimationMatrix 还是 Canvas 的 concat 方法,还记不记得我们上面分析的属性动画?它更新帧也是调用 RenderNode 提供的一系列方法,那我们再看看这个 setAnimationMatrix 方法的源码。

  public boolean setAnimationMatrix(Matrix matrix) {
        return nSetAnimationMatrix(mNativeRenderNode,
                (matrix != null) ? matrix.native_instance : 0);
    }

当动画正在播放的时候就会显示这个矩阵,当播放完毕时,就应该要清除它了。 

emmm,那就说明,播放补间动画的时候,我们所看到的变化,都只是临时的。而属性动画呢,它所改变的东西,却会更新到这个 View 所对应的矩阵中,所以当 ViewGroup 分派事件的时候,会正确的将当前触摸坐标,转换成矩阵变化后的坐标,这就是为什么播放补间动画不会改变触摸区域的原因了。

哈哈,现在我们就知其然,知其所以然了,是不是很开心?


计算旋转角度


现在旋转这一块是搞定了,那么我们怎么计算出来手指滑动的角度呢?

想一下,它旋转的时候,肯定是有一个开始角度和结束角度的,我们把圆心坐标,起始坐标,结束坐标用线连起来,不就是三角形了?我们先来看看下面的图。

哈哈,看到了吧,黄色两个圆点就是我们手指的开始和结束坐标,所以我们现在只要计算出红色两条线的夹角就行了。 

先找下我们能直接拿到的东西

  • 圆心坐标

  • 起始点坐标

  • 结束点坐标

我们知道,三角形中,只要拿到三条边的长度,就能求出它的三个角,那么能不能计算出三边的长度呢?答案是肯定的,我们可以这样做。

哈哈,想必大家都已经想到了吧,三角形的三条边都有属于自己的矩形,我们现在只要计算出三个矩形的对角线长度,进而求出夹角的大小。 

蓝色矩形上的黄点为起始点,那么 (mPivotX和mPivotY是圆心的坐标,mStartX和mStartY是手指按下的坐标,mEndX 和 mEndY 就是手指松开的所在坐标):

矩形宽(小三角形的直角边1) = Math.abs(mStartX - mPivotX); 

矩形高(直角边2) = Math.abs(mStartY - mPivotY); 

直角三角形求斜边公式:bc = √ ab² + ac² 

那么 第一条边 = (float) Math.sqrt(Math.pow(矩形宽, 2) + Math.pow(矩形高, 2));

我们按照这个公式依次计算出剩余两条边之后,再根据公式:cosC = (a² + b² - c²) / 2ab 即: 

float angle = (float) Math.toDegrees(Math.acos((Math.pow(lineA, 2) + Math.pow(lineB, 2) - Math.pow(lineC, 2)) / (2 * lineA * lineB))); 

记得一定要转为角度! 好了,我们来看看效果如何。

现在角度是计算出来了,但是,有没有发现,我们的角度都是正数,这在顺时针旋转时没问题,但是逆时针旋转的话,角度就应该为负数了,所以我们要加一个判断它是顺时针还是逆时针旋转的方法:

要判断手指的旋转方向,我们要先知道手指是水平滑动还是垂直滑动 (mPivotX和mPivotY是圆心的坐标,mStartX 和 mStartY 是手指按下的坐标,mEndX 和 mEndY 就是手指松开的所在坐标)。

boolean isVerticalScroll = Math.abs(mEndY - mStartY) > Math.abs(mEndX - mStartX);

我们将 x 轴和 y 轴的滑动距离进行对比,判断哪个距离更长,如果 x 轴的滑动距离长,那就是水平滑动了,反之,如果 y 轴滑动距离比 x 轴的长,就是垂直滑动。

进一步:如果他是垂直滑动的话:如果它是在圆心的左边,即 mEndX < mPivotX:这时候,如果是向上滑动(mEndY < mStartY,则认为是顺时针,如果是向下滑动呢,就是逆时针了。如果是在圆心右边呢,刚好相反:即向上滑动是逆时针,向下是顺时针。

水平滑动的话:如果它是在圆心上面(mEndY < mPivotY):这时候,如果是向左滑动就是逆时针,向右就是顺时针。如果在圆心下面则相反。

看代码

    private boolean isClockwise() {
        boolean isClockwise;
        //垂直滑动  上下滑动的幅度 > 左右滑动的幅度,则认为是垂直滑动,反之
        boolean isVerticalScroll = Math.abs(mEndY - mStartY) > Math.abs(mEndX - mStartX);
        //手势向下
        boolean isGestureDownward = mEndY > mStartY;
        //手势向右
        boolean isGestureRightward = mEndX > mStartX;

        if (isVerticalScroll) {
            //如果手指滑动的地方是在圆心左边的话:向下滑动就是逆时针,向上滑动则顺时针。反之,如果在圆心右边,向下滑动是顺时针,向上则逆时针。
            isClockwise = mEndX < mPivotX != isGestureDownward;
        } else {
            //逻辑同上:手指滑动在圆心的上方:向右滑动就是顺时针,向左就是逆时针。反之,如果在圆心的下方,向左滑动是顺时针,向右是逆时针。
            isClockwise = mEndY < mPivotY == isGestureRightward;
        }
        return isClockwise;
    }

好了,现在我们来看下效果:

哈哈,现在可以正确的判断出是顺时针滑动还是逆时针了,逆时针旋转后,我们得到的角度是负数,这是我们想要的结果。 


实现惯性滚动


说到 Scroller,相信大家第一时间想到要配合 View 中的 computeScroll 方法来使用对吧,但是呢,我们这篇文章的主题是辅助类,并不打算继承 View,而且不持有 Context 引用,这个时候,可能有同学就会有以下疑问了。

  1. 这种情况下,Scroller 还能正常工作吗?

  2. 调用它的 startScroll 或 fling 方法后,不是还要调用 View 中的 invalidate 方法来触发的吗?

  3. 不继承 View,哪来的 invalidate方法?

  4. 不继承 View,怎么重写 computeScroll 方法?在哪里处理惯性滚动?

哈哈,其实 Scroller 是完全可以脱离 View 来使用的,既然说是妙用,妙在哪里呢?在开始之前,我们先来了解一下 Scroller: 

它看上去更像是一个 ValueAnimator,但它跟 ValueAnimator 有个明显的区别就是:它不会主动更新动画的值。我们在获取最新值之前,总是要先调用 computeScrollOffset 方法来刷新内部的mCurrX、mCurrY的值,如果是惯性滚动模式(调用fling方法),还会刷新mCurrVelocity 的值。

在这里先分享大家一个理解源码调用顺序的方法。比如我们想知道是哪个方法调用了computeScroll。

   @Override
    public void computeScroll() {
        StackTraceElement[] elements = Thread.currentThread().getStackTrace();
        for (StackTraceElement element : elements) {
            Log.i("computeScroll", String.format(Locale.getDefault(), "%s----->%s\tline: %d",
                    element.getClassName(), element.getMethodName(), element.getLineNumber()));
        }
    }

日志输出

     com.wuyr.testview.MyView----->computeScroll    line: 141
     android.view.View----->updateDisplayListIfDirty    line: 15361
     android.view.View----->draw    line: 16182
     android.view.ViewGroup----->drawChild  line: 3777
     android.view.ViewGroup----->dispatchDraw   line: 3567
     android.view.View----->updateDisplayListIfDirty    line: 15373
     android.view.View----->draw    line: 16182
     android.view.ViewGroup----->drawChild  line: 3777
     android.view.ViewGroup----->dispatchDraw   line: 3567
     android.view.View----->updateDisplayListIfDirty    line: 15373
     android.view.View----->draw    line: 16182

这样我们就能够很清晰的看到它的调用链了。

回到正题,所谓的调用 invalidate 方法来触发,是这样的:我们都知道,调用了这个方法之后,onDraw 方法就会回调,而调用 onDraw 的那个方法,是 draw(Canvas canvas),再上一级,是 draw(Canvas canvas, ViewGroup parent, long drawingTime),重点来了。computeScroll 也是在这个方法中回调的,现在可以得出一个结论。

我们在 View 中调用 invalidate 方法,也就是间接地调用 computeScroll,而 computeScroll 中,是我们处理滚动的方法,在使用 Scroller 时,我们都会重写这个方法,并在里面调用 Scroller 的 computeScrollOffset 方法,然后调用 getCurrX 或 getCurrY 来获取到最新的值。(好像我前面说的都是多余的) 但是!有没有发现,这个过程,我们完全可以不依赖View 来做到的?

现在思路就很清晰了,invalidate 方法?对于 Scroller 来说,它的作用只是回调 computeScroll 从而更新 x 和 y 的值而已。所以完全可以自己写两个方法来实现 Scroller  在 View 中的效果,我们这次打算利用Hanlder来帮我们处理异步的问题,这样的话,我们就不用自己新开线程去不断的调用方法啦。

好了,现在我们所遇到的问题,都已经有解决方案了,可以动手咯!


构思ArcSlidingHelper


还记得 VelocityTracker 是怎么用的吗:

 @Override
    public boolean onTouchEvent(MotionEvent event) {

        mVelocityTracker.addMovement(event);

        switch (event.getAction()) {
            ...
            case MotionEvent.ACTION_UP:
                mVelocityTracker.computeCurrentVelocity(1000);
                mScroller.fling(00, (int) mVelocityTracker.getXVelocity(), (int) mVelocityTracker.getYVelocity(),
                        Integer.MIN_VALUE, Integer.MAX_VALUE, Integer.MIN_VALUE, Integer.MAX_VALUE);
                invalidate();
                break;
        }
        ...
    }

我们每次在 onTouchEvent 中都调用它的 addMovement 方法,当 ACTION_UP 时,调用它的 computeCurrentVelocity 方法计算速率后,再配合 Scroller 来实现惯性滚动。 

感觉 VelocityTracker 设计得非常好,我们使用起来很舒服,没有多余的操作,简单明了,干净利落,恭喜发财,六畜兴旺。所以我们决定使用它这种设计模式。

  • 我们也可公开一个 handleMovement(MotionEvent event) 方法,用来传入触摸事件

  • 我们打算用回调的方式来通知滑动的角度,所以还要写一个接口 OnSlidingListener

  • 公开一个静态的 create 方法,用来创建 ArcSlidingHelper 对象

好了,现在我们 ArcSlidingHelper 的基本结构也已经确定了。


创建ArcSlidingHelper


先是构造方法,参数呢,我们需要:

  1. pivotX 和 pivotY,这个是圆心的坐标值。

  2. 因为创建 Scroller 对象需要 Context,所以还需要传进来一个 Context。

  3. 滑动的监听器 OnSlidingListener,当计算出滑动角度的时候,会回调这个方法

我们来看代码:

    private ArcSlidingHelper(Context context, int pivotX, int pivotY, OnSlidingListener listener) {
        mPivotX = pivotX;
        mPivotY = pivotY;
        mListener = listener;
        mScroller = new Scroller(context);
        mVelocityTracker = VelocityTracker.obtain();
    }

我们的构造方法私有了,再看看 create 方法:

我们的create方法只有两个参数,targetView 就是要检测滑动的 View (其实也不绝对是,因为最终决定旋转哪些View,都是在回调里面完成的,我们现在无从得知。传入这个 targetView 的主要作用就是获取到 Context 对象(用来初始化 Scroller),还有圆心的坐标(pivotX 和 pivotY,默认是 View 的中心点,当然这个我们等下也会提供更新圆心坐标的方法的))。

里面还有个 getAbsoluteX 和 getAbsoluteY 方法,这两个方法分别是获取 view 在屏幕中的绝对x和y坐标,为什么要有这两个方法呢,因为targetView所在的 ViewGroup 不一定 top、left 都是0的,所以如果我们直接获取这个 View 的 xy 坐标的话,是不够的,还要加上它父容器的 xy 坐标,我们要一直递归下去,这样就能真正获取到 View 在屏幕中的绝对坐标值了:

好了,接下来就是要处理 TouchEvent 了,我们效仿 VelocityTracker 公开一个 handleMovement(MotionEvent event)方法,我们的核心代码,也是在这里面了。像 VelocityTracker 一样,在 View 中的 onTouchEvent 方法中,调用此方法,我们在内部计算出旋转的角度之后,通过 OnSlidingListener 来回调。流程基本也是这样了。

我们来看看 handleMovement 方法怎么写:

checkIsRecycled 就是检测是否已经调用过 release 方法(释放资源),如果资源已回收则拋异常。 

我们还判断了isSelfSliding,这个表示接受触摸事件的和实际旋转的都是同一个 View。 在 ACTION_DOWN 的时候,如果Scroller还没滚动完成,则停止。 当 ACTION_MOVE 的时候,调用了 handleActionMove 方法,我们来看看 handleActionMove 是怎么写的。

private void handleActionMove(float x, float y) {
        //              __________
        //根据公式 bc = √ ab² + ac² 计算出对角线的长度

        //圆心到起始点的线条长度
        float lineA = (float) Math.sqrt(Math.pow(Math.abs(mStartX - mPivotX), 2) + Math.pow(Math.abs(mStartY - mPivotY), 2));
        //圆心到结束点的线条长度
        float lineB = (float) Math.sqrt(Math.pow(Math.abs(x - mPivotX), 2) + Math.pow(Math.abs(y - mPivotY), 2));
        //起始点到结束点的线条长度
        float lineC = (float) Math.sqrt(Math.pow(Math.abs(x - mStartX), 2) + Math.pow(Math.abs(y - mStartY), 2));

        if (lineC > 0 && lineA > 0 && lineB > 0) {
            //根据公式 cosC = (a² + b² - c²) / 2ab
            float angle = fixAngle((float) Math.toDegrees(Math.acos((Math.pow(lineA, 2) + Math.pow(lineB, 2) - Math.pow(lineC, 2)) / (2 * lineA * lineB))));
            if (!Float.isNaN(angle)) {
                mListener.onSliding((isClockwiseScrolling = isClockwise(x, y)) ? angle : -angle);
            }
        }
    }

哈哈,其实也就是我们前面所说的,根据起始点和结束点,计算出夹角的角度。其中还有一个 fixAngle 方法,这个方法就是不让角度超出0 ~ 360这个范围的,看代码:

 /**
     * 调整角度,使其在0 ~ 360之间
     *
     * @param rotation 当前角度
     * @return 调整后的角度
     */

    private float fixAngle(float rotation) {
        float angle = 360F;
        if (rotation < 0) {
            rotation += angle;
        }
        if (rotation > angle) {
            rotation %= angle;
        }
        return rotation;
    }

例如传进去的是-90,返回的就是270,传进去是365,返回的就是5。我们最终看到的效果都是一样的。 

计算出滑动的角度之后呢,还判断了一下数值是否合法,然后就是判断顺时针还是逆时针旋转啦,判断顺逆时针这个问题我们在前面就解决了,嘻嘻。最后把角度传给监听器。获取到角度具体要做什么,那就要看这个监听器的 onSliding 是怎么写了的,哈哈。

ACTION_MOVE 处理完之后,还剩一个 ACTION_UP 的,没错,惯性滑动就是在这里处理的,我们再来看看 ACTION_UP 下面的代码。

 if (isInertialSlidingEnable) {
            mVelocityTracker.computeCurrentVelocity(1000);
            mScroller.fling(00, (int) mVelocityTracker.getXVelocity(), (int) mVelocityTracker.getYVelocity(),
                    Integer.MIN_VALUE, Integer.MAX_VALUE, Integer.MIN_VALUE, Integer.MAX_VALUE);
            startFling();
        }

isInertialSlidingEnable 就是是否开启惯性滚动。接下来就是 Scroller 所妙之处了,可以看到,我们在调用 Scroller 的 fling 方法之后,并没有调用 invalidate 方法,而是我们自定义的 startFling 方法,我们看看是怎么写的:

 private void startFling() {
        mHandler.sendEmptyMessage(0);
    }

哈哈哈,就是这样啦,我们前面所说的,用 Handler 来处理异步的问题,这样就不用自己去新开线程了。我们看看 Hanlder 怎么写:

 private static class InertialSlidingHandler extends Handler {

        ArcSlidingHelper mHelper;

        InertialSlidingHandler(ArcSlidingHelper helper) {
            mHelper = helper;
        }

        @Override
        public void handleMessage(Message msg) {
            mHelper.computeInertialSliding();
        }
    }

很简单,handleMessage 方法中直接又调用了computeInertialSliding,我们再看看 computeInertialSliding:

 /**
     * 处理惯性滚动
     */

    private void computeInertialSliding() {
        checkIsRecycled();
        if (mScroller.computeScrollOffset()) {
            float y = ((isShouldBeGetY ? mScroller.getCurrY() : mScroller.getCurrX()) * mScrollAvailabilityRatio);
            if (mLastScrollOffset != 0) {
                float offset = fixAngle(Math.abs(y - mLastScrollOffset));
                mListener.onSliding(isClockwiseScrolling ? offset : -offset);
            }
            mLastScrollOffset = y;
            startFling();
        } else if (mScroller.isFinished()) {
            mLastScrollOffset = 0;
        }
    }

是不是有种似曾相识的感觉?没错啦,我们用 computeInertialSliding 来代替了 View 中的computeScroll 方法,用 startFling 代替了 invalidate,可以说是完全脱离了 View 来使用Scroller,妙就妙在这里啦,嘻嘻。 

回到正题,我们在调用 computeScrollOffset 方法(更新currX和currY的值)之后,判断isShouldBeGetY 来决定究竟是 getCurrX 好还是 getCurrY 好,这个 isShouldBeGetY 的值就是在判断是否顺时针旋转的时候更新的,我们不是有一个 isVerticalScroll(是否垂直滑动)吗,isShouldBeGetY 的值其实也就是 isVerticalScroll 的值,因为如果是垂直滑动的话,VelocityTracker 的 Y 速率会更大,所以这个时候 getCurrY 是很明智的,反之。 在确定好了 get 哪个值之后,我们还将它跟 mScrollAvailabilityRatio 相乘,这个mScrollAvailabilityRatio 就是速率的利用率,默认是0.3,就是用来缩短惯性滚动的距离的,因为在测试的时候,觉得这个惯性滚动的距离有点长,轻轻一划就转了十几圈,好像很轻的样子,当然了,贴心的我们还提供了一个 setScrollAvailabilityRatio 方法来动态设置这个值:

   /**
     * VelocityTracker的惯性滚动利用率
     * 数值越大,惯性滚动的动画时间越长
     *
     * @param ratio (范围: 0~1)
     */

    public void setScrollAvailabilityRatio(@FloatRange(from = 0.0, to = 1.0) float ratio) {
        mScrollAvailabilityRatio = ratio;
    }

计算出本次滚动的角度之后,像 handleActionMove一样,判断顺时针还是逆时针,回调接口,最后还调用了 startFling,开始了下一轮的计算。。。


检验劳动成果


使用起来是非常简单的,看下布局代码:

看下 MainActivity 的:

效果

这么少的代码就实现了圆弧滑动的效果,是不是很开心(^__^) 。我们来把普通的 View 换成 RecyclerView 试试:

RecyclerView 居然可以斜着滑动,利用这点我们可以做很多意想不到的效果哦~


总结


好啦,本篇文章到此结束,有错误的地方请指出,谢谢大家!

github:

https://github.com/wuyr/ArcSlidingHelper

欢迎 star !


欢迎长按下图 -> 识别图中二维码

或者 扫一扫 关注我的公众号

 
郭霖 更多文章 Android Navigation库使用详解 一步步拆解 LeakCanary 不读书的人,思想会停滞 自己动手来实现一个RxJava Android Studio项目模板全面解析
猜您喜欢 Swift 3 及展望 Flask 入门指南 2015五大油气热点事件盘点,关乎你我! 如何使用GBM/GBDT/GBRT 【视频推荐】向怡宁:如何做中国人用的可穿戴设备?