Android之ArcSlidingHelper制作圓弧滑動(dòng)效果

更新時(shí)間：2021年08月26日 14:35:07 作者：陳小緣

這篇文章主要介紹了Android之ArcSlidingHelper制作圓弧滑動(dòng)效果，本文給大家介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下

前言

我們平時(shí)在開發(fā)中，難免會(huì)遇到一些比較特殊的需求，就比如我們這篇文章的主題，一個(gè)關(guān)于圓弧滑動(dòng)的，一般是比較少見的。其實(shí)在遇到這些東西時(shí)，不要怕，一步步分析他實(shí)現(xiàn)原理，問題便能迎刃而解。

前幾天一位群友發(fā)了一張圖，問類似這種要怎么實(shí)現(xiàn)：

要支持手勢(shì)旋轉(zhuǎn)
旋轉(zhuǎn)后慣性滾動(dòng)
滾動(dòng)后自動(dòng)選中

這里寫圖片描述

哈哈，來(lái)一張自己實(shí)現(xiàn)的效果圖：

這里寫圖片描述

初步分析

首先我們看下設(shè)計(jì)圖，Item繞著一個(gè)半圓旋轉(zhuǎn)，如果我們是自定義ViewGroup的話，那么在onLayout之后，就要把這些Item按一定的角度旋轉(zhuǎn)了。如果直接繼承View，這個(gè)比較方便，可以直接用Canvas的rotate方法。不過如果繼承View的話，做起來(lái)是簡(jiǎn)單，也能滿足上面的需求，但局限性就比較大了: 只能draw，而且Item內(nèi)容不宜過多。所以這次我們打算自定義ViewGroup，它的好處呢就是：什么都能放，我不管你Item里面是什么，反正我就負(fù)責(zé)顯示。慣性滾動(dòng)的話，這個(gè)很容易，我們可以用Scroller配合VelocityTracker來(lái)完成。旋轉(zhuǎn)手勢(shì)，無(wú)非就是計(jì)算手指滑動(dòng)的角度。

選擇旋轉(zhuǎn)方案

說(shuō)起View的動(dòng)畫播放，大家肯定都是輕車熟路了，如果一個(gè)View，它有監(jiān)聽點(diǎn)擊事件，那么在播放位移動(dòng)畫后，監(jiān)聽的位置按道理，也應(yīng)該在它最新的位置上(即位移后的位置)，在這種情況下我們用View的startAnimation就不奏效了：

        TranslateAnimation translateAnimation = new TranslateAnimation(0, 150, 0, 300);
        translateAnimation.setDuration(500);
        translateAnimation.setFillAfter(true);
        mView.startAnimation(translateAnimation);

這里寫圖片描述

可以看到，在View位移之后，監(jiān)聽點(diǎn)擊事件的區(qū)域還是在原來(lái)的地方。我們?cè)倏聪掠脤傩詣?dòng)畫的：

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

這里寫圖片描述

監(jiān)聽點(diǎn)擊事件的區(qū)域隨著View的移動(dòng)而更新了。嘻嘻，我們通過實(shí)踐來(lái)驗(yàn)證了這個(gè)說(shuō)法。

那么我們做的這個(gè)是要支持觸摸事件的，肯定是使用第二種方法。 ViewPropertyAnimator的源碼分析相信大家之前也都已經(jīng)看過其他大佬們的文章了，這里就只講講關(guān)鍵代碼： ViewPropertyAnimator它不是ValueAnimator的子類，哈哈，這個(gè)有點(diǎn)意外吧，我們直接看startAnimation方法（這個(gè)方法是start()里面調(diào)用的）：

     private void startAnimation() {
	    ...
	    //可以看到這里創(chuàng)建了ValueAnimator對(duì)象
        ValueAnimator animator = ValueAnimator.ofFloat(1.0f);
        ...
        animator.addUpdateListener(mAnimatorEventListener);
        ...
        animator.start();
    }

中間那里addUpdateListener(mAnimatorEventListener)，我們來(lái)看看這個(gè)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里面調(diào)用了setValue方法，我們?cè)倮^續(xù)跟下去 (哈哈，感覺好像捉賊一樣)：

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;
        }
    }

我們可以看到，它就調(diào)用了View的mRenderNode里面的setXXX方法，最關(guān)鍵就是這些方法啦，其實(shí)這幾個(gè)setXXX方法在View里面也有公開的，我們也是可以直接調(diào)用的，所以我們?cè)谔幚鞟CTION_MOVE的時(shí)候，就直接調(diào)用它而不用播放動(dòng)畫啦。我們現(xiàn)在驗(yàn)證一下這個(gè)方案可不可行：先試試setTranslationY:

這里寫圖片描述

將setTranslationY方法換成setRotation看看：

這里寫圖片描述

好了，經(jīng)過我們實(shí)踐驗(yàn)證了這個(gè)方案是可行的，在旋轉(zhuǎn)之后，監(jiān)聽點(diǎn)擊事件的位置也更新了，這正好是我們需要的效果。

知其然，知其所以然

哈哈，其實(shí)現(xiàn)在就有點(diǎn) 知其然而不知其所以然的感覺了，既然我們都知道補(bǔ)間動(dòng)畫不能改變接受觸摸事件的區(qū)域，而屬性動(dòng)畫就可以。那么，有沒有想過為什么會(huì)這樣呢？可能有同學(xué)就會(huì)說(shuō)了: “因?yàn)閷傩詣?dòng)畫改變了坐標(biāo)” 真的是這樣嗎？額，如果這個(gè)"坐標(biāo)"指的是getX，getY取得的值，那就是對(duì)的。為什么呢？很簡(jiǎn)單，我們來(lái)看看getX和getY的方法源碼就知道了：

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

哈哈，看到了吧，它們返回的值都分別加上了對(duì)應(yīng)的Translation的值，而屬性動(dòng)畫更新幀時(shí)，也是更新了Translation的值，所以當(dāng)動(dòng)畫播放完畢，getX和getY時(shí)，總是能取到正確的值。

但如果說(shuō)這個(gè)坐標(biāo)是指left，top，right，bottom呢，那就不對(duì)了，為什么呢？因?yàn)榻?jīng)過我們剛剛對(duì)ViewPropertyAnimator的源碼分析，知道了位移動(dòng)畫最終也只是調(diào)用了RenderNode的setTranslation方法，而left，top，right，bottom這四個(gè)值并沒有改變。這時(shí)候可能有同學(xué)就會(huì)說(shuō)了：我不信！既然沒有真正改變它的坐標(biāo)，那它接受觸摸事件的區(qū)域怎么也會(huì)跟著移動(dòng)呢？好吧，既然你不信，那我們來(lái)做個(gè)試驗(yàn)就知道了，這次需要到設(shè)置 - 開發(fā)者選項(xiàng) 里面把顯示布局邊界這個(gè)選項(xiàng)打開：

關(guān)鍵代碼：

        mView.setOnTouchListener(new View.OnTouchListener() {

            int lastX, lastY;
            Toast toast = Toast.makeText(TestActivity.this, "", Toast.LENGTH_SHORT);

            @Override
            public boolean onTouch(View v, MotionEvent event) {
                int x = (int) event.getRawX();
                int y = (int) event.getRawY();

                if (event.getAction() == MotionEvent.ACTION_MOVE) {
                    //Toolbar和狀態(tài)欄的高度
                    int toolbarHeight = (getWindow().getDecorView().getHeight() - findViewById(R.id.root_view).getHeight());
                    int widthOffset = mView.getWidth() / 2;
                    int heightOffset = mView.getHeight() / 2;

                    mView.setTranslationX(x - mView.getLeft() - widthOffset);
                    mView.setTranslationY(y - mView.getTop() - heightOffset - toolbarHeight);

                    toast.setText(String.format("left: %d, top: %d, right: %d, bottom: %d",
                            mView.getLeft(), mView.getTop(), mView.getRight(), mView.getBottom()));
                    toast.show();
                }
                lastX = x;
                lastY = y;
                return true;
            }
        });

看看效果：

emmm，我們開啟了布局邊界選項(xiàng)之后，可以看到當(dāng)View移動(dòng)的時(shí)候，那個(gè)框框并沒有跟著移動(dòng)，且我們打印的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方法來(lái)移動(dòng)View，那個(gè)框框也會(huì)跟著走的，且打印的ltrb值，也會(huì)跟著變(廢話)，而使用setTranslation的話，就像元神出竅了一樣。。。相信現(xiàn)在大家都已經(jīng)知道了為什么說(shuō)setTranslation方法也不是真正能改變坐標(biāo)了吧。

好了，我們現(xiàn)在回到上面的問題：既然setTranslation方法沒有真正的改變坐標(biāo)，那為什么觸摸區(qū)域卻會(huì)跟著移動(dòng)呢？這個(gè)就需要看一下ViewGroup的源碼了，我們先從哪里開始看呢？emmm，肯定是從dispatchTouchEvent方法開始啦，原因想必大家都已經(jīng)想到了吧。我們要先找到判斷ACTION_DOWN的，然后再找遍歷子View的for循環(huán)，看看它是怎么找到偏移后的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);

                ...

                //判斷當(dāng)前遍歷到的子View是否符合條件
                if (!canViewReceivePointerEvents(child)
                        || !isTransformedTouchPointInView(x, y, child, null)) {
                    ev.setTargetAccessibilityFocus(false);
                    continue;
                }

                //找到合適的子View之后，將事件向下傳遞
                if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
                    ...
                }

                ...
            }
        }

    }

我們重點(diǎn)看for循環(huán)里面的第一個(gè)if，因?yàn)樗軟Q定是否還要繼續(xù)往下執(zhí)行。通過看方法名能猜到，前面的方法大概就是判斷子View能不能接受到事件，它里面是這樣的：

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

emmm，不可見的時(shí)候又沒有設(shè)置動(dòng)畫，自然就不會(huì)把觸摸事件給它了。我們來(lái)看看第二個(gè)：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;
    }

中間調(diào)用了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);
        }
    }

我們先放一放這個(gè)hasIdentityMatrix方法，直接看if里面的內(nèi)容，它是get了一個(gè)矩陣然后調(diào)用了mapPoints方法，這個(gè)mapPoints方法就是：當(dāng)矩陣發(fā)生變化后(旋轉(zhuǎn)，縮放等)，將最初位置上面的坐標(biāo)，轉(zhuǎn)換成變化后的坐標(biāo)，比如說(shuō)：數(shù)組[0, 0]（分別對(duì)應(yīng)x和y）在矩陣向右邊平移了50(matrix.postTranslate(50, 0))之后，調(diào)用mapPoints方法并將這個(gè)數(shù)組作為參數(shù)傳進(jìn)去，那這個(gè)數(shù)組就變成[50, 0]，如果這個(gè)矩陣?yán)@[100, 100]上的點(diǎn)順時(shí)針旋轉(zhuǎn)了90度(matrix.postRotate(90, 100, 100))的話，那這個(gè)數(shù)組就會(huì)變成[200, 0]了，只看文字可能有點(diǎn)難理解，沒關(guān)系，我們做個(gè)圖出來(lái)就很清晰明了了：例如這個(gè)順時(shí)針旋轉(zhuǎn)90度的：

這里寫圖片描述

我們可以把矩形的寬高當(dāng)作100x100，那個(gè)紅點(diǎn)的坐標(biāo)就是[0, 0]了，當(dāng)這個(gè)矩形旋轉(zhuǎn)的時(shí)候，可以看到它是以[100, 100]的點(diǎn)作旋轉(zhuǎn)中心的，在旋轉(zhuǎn)完之后，那個(gè)紅點(diǎn)的Y軸并沒有變化，而X軸則向右移動(dòng)了兩個(gè)矩形的寬，emmm，這下大家都明白上面說(shuō)的為什么會(huì)由[0, 0]變成[200, 0]了吧?，F(xiàn)在就不難理解，為什么ViewGroup能找到“元神出竅”的View了，我們回到上面的isTransformedTouchPointInView方法：可以看到，當(dāng)它調(diào)用transformPointToViewLocal方法時(shí)，把觸摸點(diǎn)的坐標(biāo)傳進(jìn)去了，那么，等這個(gè)transformPointToViewLocal方法執(zhí)行完畢之后呢，這個(gè)觸摸點(diǎn)坐標(biāo)就是轉(zhuǎn)換后的坐標(biāo)了，隨后它還調(diào)用了View的pointInView方法，并把轉(zhuǎn)換后的坐標(biāo)分別傳了進(jìn)去，這個(gè)方法我們看名字就大概能猜到是檢測(cè)傳進(jìn)去的xy坐標(biāo)點(diǎn)是否在View內(nèi)(哈哈，我們平時(shí)在開發(fā)中也應(yīng)該盡量把方法和變量命名得通俗易懂些，一看就知道個(gè)大概那種，這樣在團(tuán)隊(duì)協(xié)作中，就算注釋寫的比較少，同事也不會(huì)太難看懂)，我們來(lái)看看這個(gè)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);
    }

嗯，很顯然就是判斷傳進(jìn)去的坐標(biāo)是否在此View中。

好了，現(xiàn)在我們來(lái)總結(jié)一下：

ViewGroup在分派事件的時(shí)候，會(huì)從最后添加到ViewGroup的View(最上面的)開始遞減遍歷;
通過調(diào)用isTransformedTouchPointInView方法來(lái)處理判斷觸摸的坐標(biāo)是否在子View內(nèi);
這個(gè)isTransformedTouchPointInView方法會(huì)調(diào)用transformPointToViewLocal來(lái)把相對(duì)于ViewGroup的觸摸坐標(biāo)轉(zhuǎn)換成相對(duì)于該子View的坐標(biāo)，并且如果該子View所對(duì)應(yīng)的矩陣有應(yīng)用過變換(平移，旋轉(zhuǎn)，縮放等)的話，還會(huì)繼續(xù)將坐標(biāo)轉(zhuǎn)換成矩陣變換前的坐標(biāo)。觸摸坐標(biāo)轉(zhuǎn)換后，會(huì)調(diào)用View的pointInView方法來(lái)判斷此觸摸點(diǎn)是否在View內(nèi);
ViewGroup會(huì)根據(jù)isTransformedTouchPointInView方法的返回值來(lái)決定要不要把事件交給這個(gè)子View;

好，我們來(lái)模擬一下ViewGroup是怎么找到這個(gè) “元神出竅” 的View的，加深下理解：關(guān)鍵代碼：

    @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("綠點(diǎn)在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;
    }

因?yàn)閂iew的getInverseMatrix和pointInView方法，我們都不能直接調(diào)用到的，所以要用反射，來(lái)看看效果：

這里寫圖片描述

哈哈，現(xiàn)在大家都明白ViewGroup為什么還能找到 “元神出竅” 后的View了吧。

好了，現(xiàn)在來(lái)回顧一下transformPointToViewLocal方法，我們剛剛忽略了里面調(diào)用的hasIdentityMatrix方法，到現(xiàn)在這個(gè)方法也大概能猜到個(gè)大概了：就是鑒定這個(gè)View所對(duì)應(yīng)的矩陣有沒有應(yīng)用過比如setTranslation，setRotation，setScale這些方法，如果有就返回false, 沒有就true。

再回到最初的問題：既然屬性動(dòng)畫可以，那為什么補(bǔ)間動(dòng)畫就不行呢？大家都是動(dòng)畫?。?/p>

有同學(xué)可能已經(jīng)知道為什么了，因?yàn)椴シ叛a(bǔ)間動(dòng)畫并沒有影響到上面說(shuō)的hasIdentityMatrix方法的返回值，那它是怎么改變View的位置或大小的呢？我們還是來(lái)看看源碼吧：通過看ScaleAnimation，TranslateAnimation和RotateAnimation能看出來(lái)，他們都重寫了Animation類的applyTransformation和initialize方法，這個(gè)initialize方法看名字就大概知道是初始化一些東西，所以我們重點(diǎn)還是看他們重寫之后的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，通過對(duì)比他們各自實(shí)現(xiàn)的方法，發(fā)現(xiàn)最后都是調(diào)用Transformation的getMatrix方法來(lái)獲取到矩陣對(duì)象然后對(duì)這個(gè)矩陣進(jìn)行操作的，那我們就要看看這個(gè)Transformation是在哪里傳進(jìn)來(lái)的了: 回到Animation中，會(huì)發(fā)現(xiàn)applyTransformation方法是在getTransformation(long currentTime, Transformation outTransformation)方法中調(diào)用的，它直接把參數(shù)中的outTransformation作為applyTransformation方法的t參數(shù)傳進(jìn)去了，那現(xiàn)在就要看看在哪里調(diào)用了會(huì)發(fā)現(xiàn)applyTransformation方法是在getTransformation方法了：在View中，我們通過搜索方法名可以找到調(diào)用它的是applyLegacyAnimation方法，我們這次主要是看它傳進(jìn)取的Transformation對(duì)象是哪里來(lái)的，最終要到哪里去：

    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);
        } 
        ...
    }

我們繼續(xù)搜 “parent.getChildTransformation()”，最終發(fā)現(xiàn)在draw方法有再次調(diào)用，來(lái)看看精簡(jiǎn)后的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，可以看到，當(dāng)getAnimation不為空的時(shí)候，它就會(huì)先調(diào)用applyLegacyAnimation方法，而這個(gè)方法最終會(huì)調(diào)用到Animation的applyTransformation方法，Animation的子類會(huì)在這個(gè)方法中根據(jù)傳進(jìn)來(lái)的Transformation對(duì)象get到矩陣，然后那些平移呀，旋轉(zhuǎn)，縮放等操作都只是對(duì)這個(gè)矩陣進(jìn)行操作。那么等這個(gè)applyLegacyAnimation方法執(zhí)行完畢之后呢，就是時(shí)候刷新幀了，在draw方法中他會(huì)根據(jù)一個(gè)drawingWithRenderNode，來(lái)決定是調(diào)用RenderNode的setAnimationMatrix還是Canvas的concat方法，還記不記得我們上面分析的屬性動(dòng)畫？它更新幀也是調(diào)用RenderNode提供的一系列方法，那我們?cè)倏纯催@個(gè)setAnimationMatrix方法的源碼：

    /**
     * Set the Animation matrix on the display list. This matrix exists if an Animation is
     * currently playing on a View, and is set on the display list during at draw() time. When
     * the Animation finishes, the matrix should be cleared by sending <code>null</code>
     * for the matrix parameter.
     *
     * @param matrix The matrix, null indicates that the matrix should be cleared.
     */
    public boolean setAnimationMatrix(Matrix matrix) {
        return nSetAnimationMatrix(mNativeRenderNode,
                (matrix != null) ? matrix.native_instance : 0);
    }

看它的文檔注釋可以大概知道：當(dāng)動(dòng)畫正在播放的時(shí)候就會(huì)顯示這個(gè)矩陣，當(dāng)播放完畢時(shí)，就應(yīng)該把它清除掉。 emmm，那就說(shuō)明，播放補(bǔ)間動(dòng)畫的時(shí)候，我們所看到的變化，都只是臨時(shí)的。而屬性動(dòng)畫呢，它所改變的東西，卻會(huì)更新到這個(gè)View所對(duì)應(yīng)的矩陣中，所以當(dāng)ViewGroup分派事件的時(shí)候，會(huì)正確的將當(dāng)前觸摸坐標(biāo)，轉(zhuǎn)換成矩陣變化后的坐標(biāo)，這就是為什么播放補(bǔ)間動(dòng)畫不會(huì)改變觸摸區(qū)域的原因了。

哈哈，現(xiàn)在我們就知其然，知其所以然了，是不是很開心？

計(jì)算旋轉(zhuǎn)角度

現(xiàn)在旋轉(zhuǎn)這一塊是搞定了，那么我們?cè)趺从?jì)算出來(lái)手指滑動(dòng)的角度呢？

想一下，它旋轉(zhuǎn)的時(shí)候，肯定是有一個(gè)開始角度和結(jié)束角度的，我們把圓心坐標(biāo)，起始坐標(biāo)，結(jié)束坐標(biāo)用線連起來(lái)，不就是三角形了？我們先來(lái)看看下面的圖：

這里寫圖片描述

哈哈，看到了吧，黃色兩個(gè)圓點(diǎn)就是我們手指的開始和結(jié)束坐標(biāo)，所以我們現(xiàn)在只要計(jì)算出紅色兩條線的夾角就行了。先找下我們能直接拿到的東西：

圓心坐標(biāo)起始點(diǎn)坐標(biāo)結(jié)束點(diǎn)坐標(biāo)

我們知道，三角形中，只要拿到三條邊的長(zhǎng)度，就能求出它的三個(gè)角，那么能不能計(jì)算出三邊的長(zhǎng)度呢？答案是肯定的，我們可以這樣做：

這里寫圖片描述

哈哈，想必大家都已經(jīng)想到了吧，三角形的三條邊都有屬于自己的矩形，我們現(xiàn)在只要計(jì)算出三個(gè)矩形的對(duì)角線長(zhǎng)度，進(jìn)而求出夾角的大小。藍(lán)色矩形上的黃點(diǎn)為起始點(diǎn)，那么 (mPivotX和mPivotY是圓心的坐標(biāo)，mStartX和mStartY是手指按下的坐標(biāo)，mEndX和mEndY就是手指松開的所在坐標(biāo))：

矩形寬(小三角形的直角邊1) = Math.abs(mStartX - mPivotX); 矩形高(直角邊2) = Math.abs(mStartY - mPivotY);

根據(jù)勾股定理公式：bc = √ (ab² + ac²) 那么第一條邊 = (float) Math.sqrt(Math.pow(矩形寬, 2) + Math.pow(矩形高, 2));

我們按照這個(gè)公式依次計(jì)算出剩余兩條邊之后，再根據(jù)余弦定理進(jìn)一步計(jì)算出夾角的角度，公式：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)));

好了，我們來(lái)看看效果如何：

現(xiàn)在角度是計(jì)算出來(lái)了，但是，有沒有發(fā)現(xiàn)，我們的角度都是正數(shù)，這在順時(shí)針旋轉(zhuǎn)時(shí)沒問題，但是逆時(shí)針旋轉(zhuǎn)的話，角度就應(yīng)該為負(fù)數(shù)了，所以我們要加一個(gè)判斷它是順時(shí)針還是逆時(shí)針旋轉(zhuǎn)的方法：

要判斷手指的旋轉(zhuǎn)方向，我們要先知道手指是水平滑動(dòng)還是垂直滑動(dòng) (mPivotX和mPivotY是圓心的坐標(biāo)，mStartX和mStartY是手指按下的坐標(biāo)，mEndX和mEndY就是手指松開的所在坐標(biāo))：

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

我們將x軸和y軸的滑動(dòng)距離進(jìn)行對(duì)比，判斷哪個(gè)距離更長(zhǎng)，如果x軸的滑動(dòng)距離長(zhǎng)，那就是水平滑動(dòng)了，反之，如果y軸滑動(dòng)距離比x軸的長(zhǎng)，就是垂直滑動(dòng)。

進(jìn)一步：如果他是垂直滑動(dòng)的話：如果它是在圓心的左邊，即mEndX < mPivotX：這時(shí)候，如果是向上滑動(dòng)(mEndY < mStartY，則認(rèn)為是順時(shí)針，如果是向下滑動(dòng)呢，就是逆時(shí)針了。如果是在圓心右邊呢，剛好相反：即向上滑動(dòng)是逆時(shí)針，向下是順時(shí)針。

水平滑動(dòng)的話：如果它是在圓心上面(mEndY < mPivotY)：這時(shí)候，如果是向左滑動(dòng)就是逆時(shí)針，向右就是順時(shí)針。如果在圓心下面則相反。

看代碼：

    private boolean isClockwise() {
        boolean isClockwise;
        //垂直滑動(dòng)  上下滑動(dòng)的幅度 > 左右滑動(dòng)的幅度，則認(rèn)為是垂直滑動(dòng)，反之
        boolean isVerticalScroll = Math.abs(mEndY - mStartY) > Math.abs(mEndX - mStartX);
        //手勢(shì)向下
        boolean isGestureDownward = mEndY > mStartY;
        //手勢(shì)向右
        boolean isGestureRightward = mEndX > mStartX;

        if (isVerticalScroll) {
            //如果手指滑動(dòng)的地方是在圓心左邊的話：向下滑動(dòng)就是逆時(shí)針，向上滑動(dòng)則順時(shí)針。反之，如果在圓心右邊，向下滑動(dòng)是順時(shí)針，向上則逆時(shí)針。
            isClockwise = mEndX < mPivotX != isGestureDownward;
        } else {
            //邏輯同上：手指滑動(dòng)在圓心的上方：向右滑動(dòng)就是順時(shí)針，向左就是逆時(shí)針。反之，如果在圓心的下方，向左滑動(dòng)是順時(shí)針，向右是逆時(shí)針。
            isClockwise = mEndY < mPivotY == isGestureRightward;
        }
        return isClockwise;
    }

好了，現(xiàn)在我們來(lái)看下效果：

這里寫圖片描述

哈哈，現(xiàn)在可以正確的判斷出是順時(shí)針滑動(dòng)還是逆時(shí)針了，逆時(shí)針旋轉(zhuǎn)后，我們得到的角度是負(fù)數(shù)，這是我們想要的結(jié)果。

實(shí)現(xiàn)慣性滾動(dòng) (Scroller的妙用)

說(shuō)到Scroller，相信大家第一時(shí)間想到要配合View中的computeScroll方法來(lái)使用對(duì)吧，但是呢，我們這篇文章的主題是輔助類，并不打算繼承View，而且不持有Context引用，這個(gè)時(shí)候，可能有同學(xué)就會(huì)有以下疑問了：

這種情況下，Scroller還能正常工作嗎？調(diào)用它的startScroll或fling方法后，不是還要調(diào)用View中的invalidate方法來(lái)觸發(fā)的嗎？不繼承View，哪來(lái)的 invalidate方法？不繼承View，怎么重寫computeScroll方法？在哪里處理慣性滾動(dòng)？

哈哈，其實(shí)Scroller是完全可以脫離View來(lái)使用的，既然說(shuō)是妙用，妙在哪里呢？在開始之前，我們先來(lái)了解一下Scroller： 1.它看上去更像是一個(gè)ValueAnimator，但它跟ValueAnimator有個(gè)明顯的區(qū)別就是：它不會(huì)主動(dòng)更新動(dòng)畫的值。我們?cè)讷@取最新值之前，總是要先調(diào)用computeScrollOffset方法來(lái)刷新內(nèi)部的mCurrX、mCurrY的值，如果是慣性滾動(dòng)模式(調(diào)用fling方法)，還會(huì)刷新mCurrVelocity的值。

2.在這里先分享大家一個(gè)理解源碼調(diào)用順序的方法：比如我們想知道是哪個(gè)方法調(diào)用了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

這樣我們就能夠很清晰的看到它的調(diào)用鏈了。

回到正題，所謂的調(diào)用invalidate方法來(lái)觸發(fā)，是這樣的：我們都知道，調(diào)用了這個(gè)方法之后，onDraw方法就會(huì)回調(diào)，而調(diào)用onDraw的那個(gè)方法，是draw(Canvas canvas)，再上一級(jí)，是draw(Canvas canvas, ViewGroup parent, long drawingTime)，重點(diǎn)來(lái)了： computeScroll也是在這個(gè)方法中回調(diào)的，現(xiàn)在可以得出一個(gè)結(jié)論：我們?cè)赩iew中調(diào)用invalidate方法，也就是間接地調(diào)用computeScroll，而computeScroll中，是我們處理滾動(dòng)的方法，在使用Scroller時(shí)，我們都會(huì)重寫這個(gè)方法，并在里面調(diào)用Scroller的computeScrollOffset方法，然后調(diào)用getCurrX或getCurrY來(lái)獲取到最新的值。(好像我前面說(shuō)的都是多余的) 但是！有沒有發(fā)現(xiàn)，這個(gè)過程，我們完全可以不依賴View來(lái)做到的？

3.現(xiàn)在思路就很清晰了，invalidate方法？對(duì)于Scroller來(lái)說(shuō)，它的作用只是回調(diào)computeScroll從而更新x和y的值而已。

4.所以完全可以自己寫兩個(gè)方法來(lái)實(shí)現(xiàn)Scroller在View中的效果，我們這次打算利用Hanlder來(lái)幫我們處理異步的問題，這樣的話，我們就不用自己新開線程去不斷的調(diào)用方法啦。

好了，現(xiàn)在我們所遇到的問題，都已經(jīng)有解決方案了，可以動(dòng)手咯！

構(gòu)思ArcSlidingHelper

還記得VelocityTracker是怎么用的嗎：

    @Override
    public boolean onTouchEvent(MotionEvent event) {

        mVelocityTracker.addMovement(event);

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

我們每次在onTouchEvent中都調(diào)用它的addMovement方法，當(dāng)ACTION_UP時(shí)，調(diào)用它的computeCurrentVelocity方法計(jì)算速率后，再配合Scroller來(lái)實(shí)現(xiàn)慣性滾動(dòng)。感覺VelocityTracker設(shè)計(jì)得非常好，我們使用起來(lái)很舒服，沒有多余的操作，簡(jiǎn)單明了，干凈利落，~~恭喜發(fā)財(cái)，六畜興旺~~。所以我們決定使用它這種設(shè)計(jì)模式：

我們也可公開一個(gè)handleMovement(MotionEvent event)方法，用來(lái)傳入觸摸事件
我們打算用回調(diào)的方式來(lái)通知滑動(dòng)的角度，所以還要寫一個(gè)接口OnSlidingListener
公開一個(gè)靜態(tài)的create方法，用來(lái)創(chuàng)建ArcSlidingHelper對(duì)象

好了，現(xiàn)在我們ArcSlidingHelper的基本結(jié)構(gòu)也已經(jīng)確定了。

創(chuàng)建ArcSlidingHelper

先是構(gòu)造方法，參數(shù)呢，我們需要：

pivotX和pivotY，這個(gè)是圓心的坐標(biāo)值。
因?yàn)閯?chuàng)建Scroller對(duì)象需要Context，所以還需要傳進(jìn)來(lái)一個(gè)Context。
滑動(dòng)的監(jiān)聽器OnSlidingListener，當(dāng)計(jì)算出滑動(dòng)角度的時(shí)候，會(huì)回調(diào)這個(gè)方法

我們來(lái)看代碼：

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

我們的構(gòu)造方法私有了，再看看create方法：

    /**
     * 創(chuàng)建ArcSlidingHelper對(duì)象
     *
     * @param targetView 接受滑動(dòng)手勢(shì)的View (圓弧滑動(dòng)事件以此View的中心點(diǎn)為圓心)
     * @param listener   當(dāng)發(fā)生圓弧滾動(dòng)時(shí)的回調(diào)
     * @return ArcSlidingHelper
     */
    public static ArcSlidingHelper create(@NonNull View targetView, @NonNull OnSlidingListener listener) {
        int width = targetView.getWidth();
        int height = targetView.getHeight();
        //如果寬度為0，提示寬度無(wú)效，需要調(diào)用updatePivotX方法來(lái)設(shè)置x軸的旋轉(zhuǎn)基點(diǎn)
        if (width == 0) {
            Log.e(TAG, "targetView width = 0! please invoke the updatePivotX(int) method to update the PivotX!", new RuntimeException());
        }
        //如果高度為0，提示高度無(wú)效，需要調(diào)用updatePivotY方法來(lái)設(shè)置y軸的旋轉(zhuǎn)基點(diǎn)
        if (height == 0) {
            Log.e(TAG, "targetView height = 0! please invoke the updatePivotY(int) method to update the PivotY!", new RuntimeException());
        }
        width /= 2;
        height /= 2;

        int x = (int) getAbsoluteX(targetView);
        int y = (int) getAbsoluteY(targetView);
        return new ArcSlidingHelper(targetView.getContext(), x + width, y + height, listener);
    }

我們的create方法只有兩個(gè)參數(shù)，targetView就是要檢測(cè)滑動(dòng)的View (其實(shí)也不絕對(duì)是，因?yàn)樽罱K決定旋轉(zhuǎn)哪些View，都是在回調(diào)里面完成的，我們現(xiàn)在無(wú)從得知。傳入這個(gè)targetView的主要作用就是獲取到Context對(duì)象(用來(lái)初始化Scroller)，還有圓心的坐標(biāo)(pivotX和pivotY，默認(rèn)是View的中心點(diǎn)，當(dāng)然這個(gè)我們等下也會(huì)提供更新圓心坐標(biāo)的方法的))。

里面還有個(gè)getAbsoluteX和getAbsoluteY方法，這兩個(gè)方法分別是獲取view在屏幕中的絕對(duì)x和y坐標(biāo)，為什么要有這兩個(gè)方法呢，因?yàn)閠argetView所在的ViewGroup不一定top、left都是0的，所以如果我們直接獲取這個(gè)View的xy坐標(biāo)的話，是不夠的，還要加上它父容器的xy坐標(biāo)，我們要一直遞歸下去，這樣就能真正獲取到View在屏幕中的絕對(duì)坐標(biāo)值了:

    /**
     * 獲取view在屏幕中的絕對(duì)x坐標(biāo)
     */
    private static float getAbsoluteX(View view) {
        float x = view.getX();
        ViewParent parent = view.getParent();
        if (parent != null && parent instanceof View) {
            x += getAbsoluteX((View) parent);
        }
        return x;
    }

    /**
     * 獲取view在屏幕中的絕對(duì)y坐標(biāo)
     */
    private static float getAbsoluteY(View view) {
        float y = view.getY();
        ViewParent parent = view.getParent();
        if (parent != null && parent instanceof View) {
            y += getAbsoluteY((View) parent);
        }
        return y;
    }

好了，接下來(lái)就是要處理TouchEvent了，我們效仿VelocityTracker公開一個(gè)handleMovement(MotionEvent event)方法，我們的核心代碼，也是在這里面了。像VelocityTracker一樣，在View中的onTouchEvent方法中，調(diào)用此方法，我們?cè)趦?nèi)部計(jì)算出旋轉(zhuǎn)的角度之后，通過OnSlidingListener來(lái)回調(diào)。流程基本也是這樣了。

我們來(lái)看看handleMovement方法怎么寫：

    public void handleMovement(MotionEvent event) {
        checkIsRecycled();
        float x, y;
        if (isSelfSliding) {
            x = event.getRawX();
            y = event.getRawY();
        } else {
            x = event.getX();
            y = event.getY();
        }
        mVelocityTracker.addMovement(event);
        switch (event.getAction()) {
            case MotionEvent.ACTION_DOWN:
                if (!mScroller.isFinished()) {
                    mScroller.abortAnimation();
                }
                break;
            case MotionEvent.ACTION_MOVE:
                handleActionMove(x, y);
                break;
            case MotionEvent.ACTION_UP:
            case MotionEvent.ACTION_CANCEL:
            case MotionEvent.ACTION_OUTSIDE:
                if (isInertialSlidingEnable) {
                    mVelocityTracker.computeCurrentVelocity(1000);
                    mScroller.fling(0, 0, (int) mVelocityTracker.getXVelocity(), (int) mVelocityTracker.getYVelocity(),
                            Integer.MIN_VALUE, Integer.MAX_VALUE, Integer.MIN_VALUE, Integer.MAX_VALUE);
                    startFling();
                }
                break;
            default:
                break;
        }
        mStartX = x;
        mStartY = y;
    }

checkIsRecycled就是檢測(cè)是否已經(jīng)調(diào)用過release方法(釋放資源)，如果資源已回收則拋異常。我們還判斷了isSelfSliding，這個(gè)表示接受觸摸事件的和實(shí)際旋轉(zhuǎn)的都是同一個(gè)View。在ACTION_DOWN的時(shí)候，如果Scroller還沒滾動(dòng)完成，則停止。當(dāng)ACTION_MOVE的時(shí)候，調(diào)用了handleActionMove方法，我們來(lái)看看handleActionMove是怎么寫的：

    private void handleActionMove(float x, float y) {
        //              __________
        //根據(jù)公式 bc = √ ab² + ac² 計(jì)算出對(duì)角線的長(zhǎng)度

        //圓心到起始點(diǎn)的線條長(zhǎng)度
        float lineA = (float) Math.sqrt(Math.pow(Math.abs(mStartX - mPivotX), 2) + Math.pow(Math.abs(mStartY - mPivotY), 2));
        //圓心到結(jié)束點(diǎn)的線條長(zhǎng)度
        float lineB = (float) Math.sqrt(Math.pow(Math.abs(x - mPivotX), 2) + Math.pow(Math.abs(y - mPivotY), 2));
        //起始點(diǎn)到結(jié)束點(diǎn)的線條長(zhǎng)度
        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) {
            //根據(jù)公式 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);
            }
        }
    }

哈哈，其實(shí)也就是我們前面所說(shuō)的，根據(jù)起始點(diǎn)和結(jié)束點(diǎn)，計(jì)算出夾角的角度。其中還有一個(gè)fixAngle方法，這個(gè)方法就是不讓角度超出0 ~ 360這個(gè)范圍的，看代碼：

    /**
     * 調(diào)整角度，使其在0 ~ 360之間
     *
     * @param rotation 當(dāng)前角度
     * @return 調(diào)整后的角度
     */
    private float fixAngle(float rotation) {
        float angle = 360F;
        if (rotation < 0) {
            rotation += angle;
        }
        if (rotation > angle) {
            rotation %= angle;
        }
        return rotation;
    }

例如傳進(jìn)去的是-90，返回的就是270，傳進(jìn)去是365，返回的就是5。我們最終看到的效果都是一樣的。計(jì)算出滑動(dòng)的角度之后呢，還判斷了一下數(shù)值是否合法，然后就是判斷順時(shí)針還是逆時(shí)針旋轉(zhuǎn)啦，判斷順逆時(shí)針這個(gè)問題我們?cè)谇懊婢徒鉀Q了，嘻嘻。最后把角度傳給監(jiān)聽器。獲取到角度具體要做什么，那就要看這個(gè)監(jiān)聽器的onSliding是怎么寫了的，哈哈。

ACTION_MOVE處理完之后，還剩一個(gè)ACTION_UP的，沒錯(cuò)，慣性滑動(dòng)就是在這里處理的，我們?cè)賮?lái)看看ACTION_UP下面的代碼：

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

isInertialSlidingEnable就是是否開啟慣性滾動(dòng)。接下來(lái)就是Scroller所妙之處了，可以看到，我們?cè)谡{(diào)用Scroller的fling方法之后，并沒有調(diào)用invalidate方法，而是我們自定義的startFling方法，我們看看是怎么寫的：

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

哈哈哈，就是這樣啦，我們前面所說(shuō)的，用Handler來(lái)處理異步的問題，這樣就不用自己去新開線程了。我們看看Hanlder怎么寫：

    private static class InertialSlidingHandler extends Handler {

        ArcSlidingHelper mHelper;

        InertialSlidingHandler(ArcSlidingHelper helper) {
            mHelper = helper;
        }

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

很簡(jiǎn)單，handleMessage方法中直接又調(diào)用了computeInertialSliding，我們?cè)倏纯碿omputeInertialSliding：

    /**
     * 處理慣性滾動(dòng)
     */
    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;
        }
    }

是不是有種似曾相識(shí)的感覺？沒錯(cuò)啦，我們用computeInertialSliding來(lái)代替了View中的computeScroll方法，用startFling代替了invalidate，可以說(shuō)是完全脫離了View來(lái)使用Scroller，妙就妙在這里啦，嘻嘻?；氐秸}，我們?cè)谡{(diào)用computeScrollOffset方法(更新currX和currY的值)之后，判斷isShouldBeGetY來(lái)決定究竟是getCurrX好還是getCurrY好，這個(gè)isShouldBeGetY的值就是在判斷是否順時(shí)針旋轉(zhuǎn)的時(shí)候更新的，我們不是有一個(gè)isVerticalScroll(是否垂直滑動(dòng))嗎，isShouldBeGetY的值其實(shí)也就是isVerticalScroll的值，因?yàn)槿绻谴怪被瑒?dòng)的話，VelocityTracker的Y速率會(huì)更大，所以這個(gè)時(shí)候getCurrY是很明智的，反之。在確定好了get哪個(gè)值之后，我們還將它跟mScrollAvailabilityRatio相乘，這個(gè)mScrollAvailabilityRatio就是速率的利用率，默認(rèn)是0.3，就是用來(lái)縮短慣性滾動(dòng)的距離的，因?yàn)樵跍y(cè)試的時(shí)候，覺得這個(gè)慣性滾動(dòng)的距離有點(diǎn)長(zhǎng)，輕輕一劃就轉(zhuǎn)了十幾圈，好像很輕的樣子，當(dāng)然了，貼心的我們還提供了一個(gè)setScrollAvailabilityRatio方法來(lái)動(dòng)態(tài)設(shè)置這個(gè)值：

    /**
     * VelocityTracker的慣性滾動(dòng)利用率
     * 數(shù)值越大，慣性滾動(dòng)的動(dòng)畫時(shí)間越長(zhǎng)
     *
     * @param ratio (范圍: 0~1)
     */
    public void setScrollAvailabilityRatio(@FloatRange(from = 0.0, to = 1.0) float ratio) {
        mScrollAvailabilityRatio = ratio;
    }

計(jì)算出本次滾動(dòng)的角度之后，像handleActionMove一樣，判斷順時(shí)針還是逆時(shí)針，回調(diào)接口，最后還調(diào)用了startFling，開始了下一輪的計(jì)算。。。

好了，我們的ArcSlidingHelper算是完工了，來(lái)兩張效果圖檢驗(yàn)下勞動(dòng)成果：

使用起來(lái)是非常簡(jiǎn)單的，看下布局代碼：

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <View
        android:id="@+id/view"
        android:layout_width="match_parent"
        android:layout_height="60dp"
        android:layout_gravity="center"
        android:background="@color/colorPrimary" />
</FrameLayout>

看下MainActivity的：

    private ArcSlidingHelper mArcSlidingHelper;
    private View mView;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.act_main_view);

        mView = findViewById(R.id.view);
        mView.post(() -> {
            //創(chuàng)建對(duì)象
            mArcSlidingHelper = ArcSlidingHelper.create(mView,
                    angle -> mView.setRotation(mView.getRotation() + angle));
            //開啟慣性滾動(dòng)
            mArcSlidingHelper.enableInertialSliding(true);

        });
        getWindow().getDecorView().setOnTouchListener((v, event) -> {
            //處理滑動(dòng)事件
            mArcSlidingHelper.handleMovement(event);
            return true;
        });
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        //釋放資源
        mArcSlidingHelper.release();
    }

效果：

這里寫圖片描述

這么少的代碼就實(shí)現(xiàn)了圓弧滑動(dòng)的效果，是不是很開心(__) 我們來(lái)把普通的View換成RecyclerView試試：

這里寫圖片描述

哈哈

RecyclerView居然可以斜著滑動(dòng)，利用這點(diǎn)我們可以做很多意想不到的效果哦~

好啦，本篇文章到此結(jié)束，有錯(cuò)誤的地方請(qǐng)指出，謝謝大家！ github地址：https://github.com/wuyr/ArcSlidingHelper 歡迎star 下集：Android之FanLayout制作圓弧滑動(dòng)效果

這里寫圖片描述

到此這篇關(guān)于Android之ArcSlidingHelper制作圓弧滑動(dòng)效果的文章就介紹到這了,更多相關(guān)ArcSlidingHelper制作圓弧滑動(dòng)效果內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: