Android之ArcSlidingHelper制作圓弧滑動效果
前言
我們平時在開發(fā)中，難免會遇到一些比較特殊的需求，就比如我們這篇文章的主題，一個關于圓弧滑動的，一般是比較少見的。其實在遇到這些東西時，不要怕，一步步分析他實現(xiàn)原理，問題便能迎刃而解。
前幾天一位群友發(fā)了一張圖，問類似這種要怎么實現(xiàn)：
- 要支持手勢旋轉(zhuǎn)
- 旋轉(zhuǎn)后慣性滾動
- 滾動后自動選中
哈哈， 來一張自己實現(xiàn)的效果圖：
初步分析
首先我們看下設計圖，Item繞著一個半圓旋轉(zhuǎn)，如果我們是自定義ViewGroup的話，那么在onLayout之后，就要把這些Item按一定的角度旋轉(zhuǎn)了。如果直接繼承View，這個比較方便，可以直接用Canvas的rotate方法。不過如果繼承View的話，做起來是簡單，也能滿足上面的需求，但局限性就比較大了: 只能draw，而且Item內(nèi)容不宜過多。所以這次我們打算自定義ViewGroup，它的好處呢就是：什么都能放，我不管你Item里面是什么，反正我就負責顯示。慣性滾動的話，這個很容易，我們可以用Scroller配合VelocityTracker來完成。旋轉(zhuǎn)手勢，無非就是計算手指滑動的角度。
選擇旋轉(zhuǎn)方案
說起View的動畫播放，大家肯定都是輕車熟路了，如果一個View，它有監(jiān)聽點擊事件，那么在播放位移動畫后，監(jiān)聽的位置按道理，也應該在它最新的位置上(即位移后的位置)，在這種情況下我們用View的startAnimation就不奏效了：
TranslateAnimation translateAnimation = new TranslateAnimation(0, 150, 0, 300);
translateAnimation.setDuration(500);
translateAnimation.setFillAfter(true);
mView.startAnimation(translateAnimation);
可以看到，在View位移之后，監(jiān)聽點擊事件的區(qū)域還是在原來的地方。我們再看下用屬性動畫的：
mView.animate().translationX(150).translationY(300).setDuration(500).start();
監(jiān)聽點擊事件的區(qū)域隨著View的移動而更新了。嘻嘻，我們通過實踐來驗證了這個說法。
那么我們做的這個是要支持觸摸事件的，肯定是使用第二種方法。 ViewPropertyAnimator的源碼分析相信大家之前也都已經(jīng)看過其他大佬們的文章了，這里就只講講關鍵代碼： ViewPropertyAnimator它不是ValueAnimator的子類，哈哈，這個有點意外吧，我們直接看startAnimation方法（這個方法是start()里面調(diào)用的）：
private void startAnimation() {
...
//可以看到這里創(chuàng)建了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里面調(diào)用了setValue方法，我們再繼續(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方法，最關鍵就是這些方法啦，其實這幾個setXXX方法在View里面也有公開的，我們也是可以直接調(diào)用的，所以我們在處理ACTION_MOVE的時候，就直接調(diào)用它而不用播放動畫啦。我們現(xiàn)在驗證一下這個方案可不可行：先試試setTranslationY:
將setTranslationY方法換成setRotation看看：
好了，經(jīng)過我們實踐驗證了這個方案是可行的，在旋轉(zhuǎn)之后，監(jiān)聽點擊事件的位置也更新了，這正好是我們需要的效果。
知其然，知其所以然
哈哈，其實現(xiàn)在就有點 知其然而不知其所以然 的感覺了，既然我們都知道補間動畫不能改變接受觸摸事件的區(qū)域，而屬性動畫就可以。那么，有沒有想過為什么會這樣呢？可能有同學就會說了: “因為屬性動畫改變了坐標” 真的是這樣嗎？額，如果這個"坐標"指的是getX，getY取得的值，那就是對的。為什么呢？很簡單，我們來看看getX和getY的方法源碼就知道了：
public float getX() {
return mLeft + getTranslationX();
}
public float getY() {
return mTop + getTranslationY();
}
哈哈，看到了吧，它們返回的值都分別加上了對應的Translation的值，而屬性動畫更新幀時，也是更新了Translation的值，所以當動畫播放完畢，getX和getY時，總是能取到正確的值。
但如果說這個坐標是指left，top，right，bottom呢，那就不對了，為什么呢？因為經(jīng)過我們剛剛對ViewPropertyAnimator的源碼分析，知道了位移動畫最終也只是調(diào)用了RenderNode的setTranslation方法，而left，top，right，bottom這四個值并沒有改變。這時候可能有同學就會說了：我不信！既然沒有真正改變它的坐標，那它接受觸摸事件的區(qū)域怎么也會跟著移動呢？好吧，既然你不信，那我們來做個試驗就知道了，這次需要到 設置 - 開發(fā)者選項 里面把顯示布局邊界這個選項打開：
關鍵代碼：
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，我們開啟了布局邊界選項之后，可以看到當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的話，就像元神出竅了一樣。。。相信現(xiàn)在大家都已經(jīng)知道了為什么說setTranslation方法也不是真正能改變坐標了吧。
好了，我們現(xiàn)在回到上面的問題：既然setTranslation方法沒有真正的改變坐標，那為什么觸摸區(qū)域卻會跟著移動呢？這個就需要看一下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);
...
//判斷當前遍歷到的子View是否符合條件
if (!canViewReceivePointerEvents(child)
|| !isTransformedTouchPointInView(x, y, child, null)) {
ev.setTargetAccessibilityFocus(false);
continue;
}
//找到合適的子View之后，將事件向下傳遞
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
...
}
...
}
}
}
我們重點看for循環(huán)里面的第一個if，因為它能決定是否還要繼續(xù)往下執(zhí)行。通過看方法名能猜到，前面的方法大概就是判斷子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;
}
中間調(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);
}
}
我們先放一放這個hasIdentityMatrix方法，直接看if里面的內(nèi)容，它是get了一個矩陣然后調(diào)用了mapPoints方法，這個mapPoints方法就是：當矩陣發(fā)生變化后(旋轉(zhuǎn)，縮放等)，將最初位置上面的坐標，轉(zhuǎn)換成變化后的坐標，比如說：數(shù)組[0, 0]（分別對應x和y）在矩陣向右邊平移了50(matrix.postTranslate(50, 0))之后，調(diào)用mapPoints方法并將這個數(shù)組作為參數(shù)傳進去，那這個數(shù)組就變成[50, 0]，如果這個矩陣繞[100, 100]上的點順時針旋轉(zhuǎn)了90度(matrix.postRotate(90, 100, 100))的話，那這個數(shù)組就會變成[200, 0]了，只看文字可能有點難理解，沒關系，我們做個圖出來就很清晰明了了：例如這個順時針旋轉(zhuǎn)90度的：
我們可以把矩形的寬高當作100x100，那個紅點的坐標就是[0, 0]了，當這個矩形旋轉(zhuǎn)的時候，可以看到它是以[100, 100]的點作旋轉(zhuǎn)中心的，在旋轉(zhuǎn)完之后，那個紅點的Y軸并沒有變化，而X軸則向右移動了兩個矩形的寬，emmm，這下大家都明白上面說的為什么會由[0, 0]變成[200, 0]了吧。現(xiàn)在就不難理解，為什么ViewGroup能找到“元神出竅”的View了，我們回到上面的isTransformedTouchPointInView方法：可以看到，當它調(diào)用transformPointToViewLocal方法時，把觸摸點的坐標傳進去了，那么，等這個transformPointToViewLocal方法執(zhí)行完畢之后呢，這個觸摸點坐標就是轉(zhuǎn)換后的坐標了，隨后它還調(diào)用了View的pointInView方法，并把轉(zhuǎn)換后的坐標分別傳了進去，這個方法我們看名字就大概能猜到是檢測傳進去的xy坐標點是否在View內(nèi)(哈哈，我們平時在開發(fā)中也應該盡量把方法和變量命名得通俗易懂些，一看就知道個大概那種，這樣在團隊協(xié)作中，就算注釋寫的比較少，同事也不會太難看懂)，我們來看看這個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中。
好了，現(xiàn)在我們來總結(jié)一下：
- ViewGroup在分派事件的時候，會從最后添加到ViewGroup的View(最上面的)開始遞減遍歷;
- 通過調(diào)用isTransformedTouchPointInView方法來處理判斷觸摸的坐標是否在子View內(nèi);
- 這個isTransformedTouchPointInView方法會調(diào)用transformPointToViewLocal來把相對于ViewGroup的觸摸坐標轉(zhuǎn)換成相對于該子View的坐標，并且如果該子View所對應的矩陣有應用過變換(平移，旋轉(zhuǎn)，縮放等)的話，還會繼續(xù)將坐標轉(zhuǎn)換成矩陣變換前的坐標。觸摸坐標轉(zhuǎn)換后，會調(diào)用View的pointInView方法來判斷此觸摸點是否在View內(nèi);
- ViewGroup會根據(jù)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方法，我們都不能直接調(diào)用到的，所以要用反射，來看看效果：
哈哈，現(xiàn)在大家都明白ViewGroup為什么還能找到 “元神出竅” 后的View了吧。
好了，現(xiàn)在來回顧一下transformPointToViewLocal方法，我們剛剛忽略了里面調(diào)用的hasIdentityMatrix方法，到現(xiàn)在這個方法也大概能猜到個大概了：就是鑒定這個View所對應的矩陣有沒有應用過比如setTranslation，setRotation，setScale這些方法，如果有就返回false, 沒有就true。
再回到最初的問題：既然屬性動畫可以，那為什么補間動畫就不行呢？大家都是動畫??！
有同學可能已經(jīng)知道為什么了，因為播放補間動畫并沒有影響到上面說的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，通過對比他們各自實現(xiàn)的方法，發(fā)現(xiàn)最后都是調(diào)用Transformation的getMatrix方法來獲取到矩陣對象然后對這個矩陣進行操作的，那我們就要看看這個Transformation是在哪里傳進來的了: 回到Animation中，會發(fā)現(xiàn)applyTransformation方法是在getTransformation(long currentTime, Transformation outTransformation)方法中調(diào)用的，它直接把參數(shù)中的outTransformation作為applyTransformation方法的t參數(shù)傳進去了，那現(xiàn)在就要看看在哪里調(diào)用了會發(fā)現(xiàn)applyTransformation方法是在getTransformation方法了：在View中，我們通過搜索方法名可以找到調(diào)用它的是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);
}
...
}
我們繼續(xù)搜 “parent.getChildTransformation()”，最終發(fā)現(xiàn)在draw方法有再次調(diào)用，來看看精簡后的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不為空的時候，它就會先調(diào)用applyLegacyAnimation方法，而這個方法最終會調(diào)用到Animation的applyTransformation方法，Animation的子類會在這個方法中根據(jù)傳進來的Transformation對象get到矩陣，然后那些平移呀，旋轉(zhuǎn)，縮放等操作都只是對這個矩陣進行操作。那么等這個applyLegacyAnimation方法執(zhí)行完畢之后呢，就是時候刷新幀了，在draw方法中他會根據(jù)一個drawingWithRenderNode，來決定是調(diào)用RenderNode的setAnimationMatrix還是Canvas的concat方法，還記不記得我們上面分析的屬性動畫？它更新幀也是調(diào)用RenderNode提供的一系列方法，那我們再看看這個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);
}
看它的文檔注釋可以大概知道：當動畫正在播放的時候就會顯示這個矩陣，當播放完畢時，就應該把它清除掉。 emmm，那就說明，播放補間動畫的時候，我們所看到的變化，都只是臨時的。而屬性動畫呢，它所改變的東西，卻會更新到這個View所對應的矩陣中，所以當ViewGroup分派事件的時候，會正確的將當前觸摸坐標，轉(zhuǎn)換成矩陣變化后的坐標，這就是為什么播放補間動畫不會改變觸摸區(qū)域的原因了。
哈哈，現(xiàn)在我們就知其然，知其所以然了，是不是很開心？
計算旋轉(zhuǎn)角度
現(xiàn)在旋轉(zhuǎn)這一塊是搞定了，那么我們怎么計算出來手指滑動的角度呢？
想一下，它旋轉(zhuǎn)的時候，肯定是有一個開始角度和結(jié)束角度的，我們把圓心坐標，起始坐標，結(jié)束坐標用線連起來，不就是三角形了？我們先來看看下面的圖：
哈哈，看到了吧，黃色兩個圓點就是我們手指的開始和結(jié)束坐標，所以我們現(xiàn)在只要計算出紅色兩條線的夾角就行了。先找下我們能直接拿到的東西：
圓心坐標起始點坐標結(jié)束點坐標
我們知道，三角形中，只要拿到三條邊的長度，就能求出它的三個角，那么能不能計算出三邊的長度呢？答案是肯定的，我們可以這樣做：
哈哈，想必大家都已經(jīng)想到了吧，三角形的三條邊都有屬于自己的矩形，我們現(xiàn)在只要計算出三個矩形的對角線長度，進而求出夾角的大小。藍色矩形上的黃點為起始點，那么 (mPivotX和mPivotY是圓心的坐標，mStartX和mStartY是手指按下的坐標，mEndX和mEndY就是手指松開的所在坐標)：
矩形寬(小三角形的直角邊1) = Math.abs(mStartX - mPivotX); 矩形高(直角邊2) = Math.abs(mStartY - mPivotY);
根據(jù)勾股定理公式：bc = √ (ab² + ac²) 那么 第一條邊 = (float) Math.sqrt(Math.pow(矩形寬, 2) + Math.pow(矩形高, 2));
我們按照這個公式依次計算出剩余兩條邊之后，再根據(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)));
好了，我們來看看效果如何：
現(xiàn)在角度是計算出來了，但是，有沒有發(fā)現(xiàn)，我們的角度都是正數(shù)，這在順時針旋轉(zhuǎn)時沒問題，但是逆時針旋轉(zhuǎn)的話，角度就應該為負數(shù)了，所以我們要加一個判斷它是順時針還是逆時針旋轉(zhuǎn)的方法：
要判斷手指的旋轉(zhuǎn)方向，我們要先知道手指是水平滑動還是垂直滑動 (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;
}
好了，現(xiàn)在我們來看下效果：
哈哈，現(xiàn)在可以正確的判斷出是順時針滑動還是逆時針了，逆時針旋轉(zhuǎn)后，我們得到的角度是負數(shù)，這是我們想要的結(jié)果。
實現(xiàn)慣性滾動 (Scroller的妙用)
說到Scroller，相信大家第一時間想到要配合View中的computeScroll方法來使用對吧，但是呢，我們這篇文章的主題是輔助類，并不打算繼承View，而且不持有Context引用，這個時候，可能有同學就會有以下疑問了：
這種情況下，Scroller還能正常工作嗎？調(diào)用它的startScroll或fling方法后，不是還要調(diào)用View中的invalidate方法來觸發(fā)的嗎？不繼承View，哪來的 invalidate方法？不繼承View，怎么重寫computeScroll方法？在哪里處理慣性滾動？
哈哈，其實Scroller是完全可以脫離View來使用的，既然說是妙用，妙在哪里呢？在開始之前，我們先來了解一下Scroller： 1.它看上去更像是一個ValueAnimator，但它跟ValueAnimator有個明顯的區(qū)別就是：它不會主動更新動畫的值。我們在獲取最新值之前，總是要先調(diào)用computeScrollOffset方法來刷新內(nèi)部的mCurrX、mCurrY的值，如果是慣性滾動模式(調(diào)用fling方法)，還會刷新mCurrVelocity的值。
2.在這里先分享大家一個理解源碼調(diào)用順序的方法：比如我們想知道是哪個方法調(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方法來觸發(fā)，是這樣的：我們都知道，調(diào)用了這個方法之后，onDraw方法就會回調(diào)，而調(diào)用onDraw的那個方法，是draw(Canvas canvas)，再上一級，是draw(Canvas canvas, ViewGroup parent, long drawingTime)，重點來了： computeScroll也是在這個方法中回調(diào)的，現(xiàn)在可以得出一個結(jié)論：我們在View中調(diào)用invalidate方法，也就是間接地調(diào)用computeScroll，而computeScroll中，是我們處理滾動的方法，在使用Scroller時，我們都會重寫這個方法，并在里面調(diào)用Scroller的computeScrollOffset方法，然后調(diào)用getCurrX或getCurrY來獲取到最新的值。(好像我前面說的都是多余的) 但是！有沒有發(fā)現(xiàn)，這個過程，我們完全可以不依賴View來做到的？
3.現(xiàn)在思路就很清晰了，invalidate方法？對于Scroller來說，它的作用只是回調(diào)computeScroll從而更新x和y的值而已。
4.所以完全可以自己寫兩個方法來實現(xiàn)Scroller在View中的效果，我們這次打算利用Hanlder來幫我們處理異步的問題，這樣的話，我們就不用自己新開線程去不斷的調(diào)用方法啦。
好了，現(xiàn)在我們所遇到的問題，都已經(jī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方法，當ACTION_UP時，調(diào)用它的computeCurrentVelocity方法計算速率后，再配合Scroller來實現(xiàn)慣性滾動。感覺VelocityTracker設計得非常好，我們使用起來很舒服，沒有多余的操作，簡單明了，干凈利落，恭喜發(fā)財，六畜興旺。所以我們決定使用它這種設計模式：
- 我們也可公開一個handleMovement(MotionEvent event)方法，用來傳入觸摸事件
- 我們打算用回調(diào)的方式來通知滑動的角度，所以還要寫一個接口OnSlidingListener
- 公開一個靜態(tài)的create方法，用來創(chuàng)建ArcSlidingHelper對象
好了，現(xiàn)在我們ArcSlidingHelper的基本結(jié)構(gòu)也已經(jīng)確定了。
創(chuàng)建ArcSlidingHelper
先是構(gòu)造方法，參數(shù)呢，我們需要：
- pivotX和pivotY，這個是圓心的坐標值。
- 因為創(chuàng)建Scroller對象需要Context，所以還需要傳進來一個Context。
- 滑動的監(jiān)聽器OnSlidingListener，當計算出滑動角度的時候，會回調(diào)這個方法
我們來看代碼：
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對象
*
* @param targetView 接受滑動手勢的View (圓弧滑動事件以此View的中心點為圓心)
* @param listener 當發(fā)生圓弧滾動時的回調(diào)
* @return ArcSlidingHelper
*/
public static ArcSlidingHelper create(@NonNull View targetView, @NonNull OnSlidingListener listener) {
int width = targetView.getWidth();
int height = targetView.getHeight();
//如果寬度為0，提示寬度無效，需要調(diào)用updatePivotX方法來設置x軸的旋轉(zhuǎn)基點
if (width == 0) {
Log.e(TAG, "targetView width = 0! please invoke the updatePivotX(int) method to update the PivotX!", new RuntimeException());
}
//如果高度為0，提示高度無效，需要調(diào)用updatePivotY方法來設置y軸的旋轉(zhuǎ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方法只有兩個參數(shù)，targetView就是要檢測滑動的View (其實也不絕對是，因為最終決定旋轉(zhuǎn)哪些View，都是在回調(diào)里面完成的，我們現(xiàn)在無從得知。傳入這個targetView的主要作用就是獲取到Context對象(用來初始化Scroller)，還有圓心的坐標(pivotX和pivotY，默認是View的中心點，當然這個我們等下也會提供更新圓心坐標的方法的))。
里面還有個getAbsoluteX和getAbsoluteY方法，這兩個方法分別是獲取view在屏幕中的絕對x和y坐標，為什么要有這兩個方法呢，因為targetView所在的ViewGroup不一定top、left都是0的，所以如果我們直接獲取這個View的xy坐標的話，是不夠的，還要加上它父容器的xy坐標，我們要一直遞歸下去，這樣就能真正獲取到View在屏幕中的絕對坐標值了:
/**
* 獲取view在屏幕中的絕對x坐標
*/
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在屏幕中的絕對y坐標
*/
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;
}
好了，接下來就是要處理TouchEvent了，我們效仿VelocityTracker公開一個handleMovement(MotionEvent event)方法，我們的核心代碼，也是在這里面了。像VelocityTracker一樣，在View中的onTouchEvent方法中，調(diào)用此方法，我們在內(nèi)部計算出旋轉(zhuǎn)的角度之后，通過OnSlidingListener來回調(diào)。流程基本也是這樣了。
我們來看看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就是檢測是否已經(jīng)調(diào)用過release方法(釋放資源)，如果資源已回收則拋異常。我們還判斷了isSelfSliding，這個表示接受觸摸事件的和實際旋轉(zhuǎn)的都是同一個View。在ACTION_DOWN的時候，如果Scroller還沒滾動完成，則停止。當ACTION_MOVE的時候，調(diào)用了handleActionMove方法，我們來看看handleActionMove是怎么寫的：
private void handleActionMove(float x, float y) {
// __________
//根據(jù)公式 bc = √ ab² + ac² 計算出對角線的長度
//圓心到起始點的線條長度
float lineA = (float) Math.sqrt(Math.pow(Math.abs(mStartX - mPivotX), 2) + Math.pow(Math.abs(mStartY - mPivotY), 2));
//圓心到結(jié)束點的線條長度
float lineB = (float) Math.sqrt(Math.pow(Math.abs(x - mPivotX), 2) + Math.pow(Math.abs(y - mPivotY), 2));
//起始點到結(jié)束點的線條長度
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);
}
}
}
哈哈，其實也就是我們前面所說的，根據(jù)起始點和結(jié)束點，計算出夾角的角度。其中還有一個fixAngle方法，這個方法就是不讓角度超出0 ~ 360這個范圍的，看代碼：
/**
* 調(diào)整角度，使其在0 ~ 360之間
*
* @param rotation 當前角度
* @return 調(diào)整后的角度
*/
private float fixAngle(float rotation) {
float angle = 360F;
if (rotation < 0) {
rotation += angle;
}
if (rotation > angle) {
rotation %= angle;
}
return rotation;
}
例如傳進去的是-90，返回的就是270，傳進去是365，返回的就是5。我們最終看到的效果都是一樣的。計算出滑動的角度之后呢，還判斷了一下數(shù)值是否合法，然后就是判斷順時針還是逆時針旋轉(zhuǎn)啦，判斷順逆時針這個問題我們在前面就解決了，嘻嘻。最后把角度傳給監(jiān)聽器。獲取到角度具體要做什么，那就要看這個監(jiān)聽器的onSliding是怎么寫了的，哈哈。
ACTION_MOVE處理完之后，還剩一個ACTION_UP的，沒錯，慣性滑動就是在這里處理的，我們再來看看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就是是否開啟慣性滾動。接下來就是Scroller所妙之處了，可以看到，我們在調(diào)用Scroller的fling方法之后，并沒有調(diào)用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方法中直接又調(diào)用了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，妙就妙在這里啦，嘻嘻?；氐秸}，我們在調(diào)用computeScrollOffset方法(更新currX和currY的值)之后，判斷isShouldBeGetY來決定究竟是getCurrX好還是getCurrY好，這個isShouldBeGetY的值就是在判斷是否順時針旋轉(zhuǎn)的時候更新的，我們不是有一個isVerticalScroll(是否垂直滑動)嗎，isShouldBeGetY的值其實也就是isVerticalScroll的值，因為如果是垂直滑動的話，VelocityTracker的Y速率會更大，所以這個時候getCurrY是很明智的，反之。在確定好了get哪個值之后，我們還將它跟mScrollAvailabilityRatio相乘，這個mScrollAvailabilityRatio就是速率的利用率，默認是0.3，就是用來縮短慣性滾動的距離的，因為在測試的時候，覺得這個慣性滾動的距離有點長，輕輕一劃就轉(zhuǎn)了十幾圈，好像很輕的樣子，當然了，貼心的我們還提供了一個setScrollAvailabilityRatio方法來動態(tài)設置這個值：
/**
* VelocityTracker的慣性滾動利用率
* 數(shù)值越大，慣性滾動的動畫時間越長
*
* @param ratio (范圍: 0~1)
*/
public void setScrollAvailabilityRatio(@FloatRange(from = 0.0, to = 1.0) float ratio) {
mScrollAvailabilityRatio = ratio;
}
計算出本次滾動的角度之后，像handleActionMove一樣，判斷順時針還是逆時針，回調(diào)接口，最后還調(diào)用了startFling，開始了下一輪的計算。。。
好了，我們的ArcSlidingHelper算是完工了，來兩張效果圖檢驗下勞動成果：
使用起來是非常簡單的，看下布局代碼：
<?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)建對象
mArcSlidingHelper = ArcSlidingHelper.create(mView,
angle -> mView.setRotation(mView.getRotation() + angle));
//開啟慣性滾動
mArcSlidingHelper.enableInertialSliding(true);
});
getWindow().getDecorView().setOnTouchListener((v, event) -> {
//處理滑動事件
mArcSlidingHelper.handleMovement(event);
return true;
});
}
@Override
protected void onDestroy() {
super.onDestroy();
//釋放資源
mArcSlidingHelper.release();
}
效果：
這么少的代碼就實現(xiàn)了圓弧滑動的效果，是不是很開心(__) 我們來把普通的View換成RecyclerView試試：
哈哈
RecyclerView居然可以斜著滑動，利用這點我們可以做很多意想不到的效果哦~
好啦，本篇文章到此結(jié)束，有錯誤的地方請指出，謝謝大家！ github地址：https://github.com/wuyr/ArcSlidingHelper 歡迎star 下集：Android之FanLayout制作圓弧滑動效果
到此這篇關于Android之ArcSlidingHelper制作圓弧滑動效果的文章就介紹到這了,更多相關ArcSlidingHelper制作圓弧滑動效果內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
相關文章
Qt6.5.3?Android環(huán)境配置的實現(xiàn)
本文主要介紹了Qt6.5.3?Android環(huán)境配置的實現(xiàn),文中通過圖文介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2024-01-01
百度地圖API提示230 錯誤app scode碼校驗失敗的解決辦法
筆者近2天在 Android Studio上玩了一下百度地圖,碰到了常見的"230錯誤 APP Scode校驗失敗",下面我來介紹一下具體的解決辦法2016-01-01
這篇文章主要為大家詳細介紹了Android仿微信朋友圈圖片查看器的具體實現(xiàn)代碼，具有一定的參考價值，感興趣的小伙伴們可以參考一下2016-05-05
Cocos2d-x 3.0中集成社交分享ShareSDK的詳細步驟和常見問題解決
這篇文章主要介紹了Cocos2d-x 3.0中集成社交分享ShareSDK的詳細步驟和常見問題的解決方法以及需要注意的問題,需要的朋友可以參考下2014-04-04
本篇文章主要介紹了android數(shù)據(jù)存儲之文件存儲的方法，具有一定的參考價值，有需要的可以了解一下。2016-11-11
這篇文章主要為大家詳細介紹了ViewPager打造輪播圖Banner和引導頁Guide，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-08-08
Android打賞功能實現(xiàn)代碼(支付寶轉(zhuǎn)賬)
這篇文章主要介紹了Android打賞功能之支付寶轉(zhuǎn)賬 ,需要的朋友可以參考下2017-12-12
Android源碼中final關鍵字的用法及final,finally,finalize的區(qū)別
Android的源碼中很多地方對final關鍵字的用法很是“別出心裁”，之所以這么說是因為我從沒看過是這么使用final關鍵字的，通過本文給大家分享Android源碼中final關鍵字的用法及final,finally,finalize的區(qū)別，感興趣的朋友一起學習吧2015-12-12
Android學習筆記之AndroidManifest.xml文件解析(詳解)
這篇文章主要介紹了Android學習筆記之AndroidManifest.xml文件解析,需要的朋友可以參考下2015-10-10
Android中利用動態(tài)加載實現(xiàn)手機淘寶的節(jié)日特效
這篇文章主要介紹了Android中利用動態(tài)加載實現(xiàn)手機淘寶的節(jié)日特效,非常不錯，具有參考借鑒價值，需要的朋友可以參考下2016-12-12