Android应用ViewDragHelper详解及部分源码浅析，安卓开发必须会的技能

最新推荐文章于 2024-06-13 11:55:12 发布

2401_84153262

最新推荐文章于 2024-06-13 11:55:12 发布

阅读量680

点赞数 26

分类专栏：程序员文章标签： android

本文链接：https://blog.csdn.net/2401_84153262/article/details/137442790

版权

程序员专栏收录该内容

167 篇文章 0 订阅

订阅专栏

return t * t * t * t * t + 1.0f;

}

};

关于动画插值器这里不再说了，之前博文有讲过。我们还是把视线回到上面实例部分，可以看见，在获取ViewDragHelper实例之后我们接着重写了ViewGroup的onInterceptTouchEvent和onTouchEvent方法，在其中触发了ViewDragHelper的shouldInterceptTouchEvent和processTouchEvent方法。所以下面我们就来分析这两个方法，首先我们看下shouldInterceptTouchEvent方法，如下：

//这玩意返回值的作用在前面博客中有分析，我们先来看下ACTION_DOWN事件

public boolean shouldInterceptTouchEvent(MotionEvent ev) {

final int action = MotionEventCompat.getActionMasked(ev);

final int actionIndex = MotionEventCompat.getActionIndex(ev);

if (action == MotionEvent.ACTION_DOWN) {

//每次ACTION_DOWN都会调用cancel()，该方法中mVelocityTracker被清空，故mVelocityTracker记录的是本次ACTION_DOWN到ACTION_UP的触摸信息

cancel();

}

//获取VelocityTracker实例，记录下各个触摸点信息用来计算本次滑动速率等

if (mVelocityTracker == null) {

mVelocityTracker = VelocityTracker.obtain();

}

mVelocityTracker.addMovement(ev);

switch (action) {

case MotionEvent.ACTION_DOWN: {

final float x = ev.getX();

final float y = ev.getY();

final int pointerId = MotionEventCompat.getPointerId(ev, 0);

//Step 1

saveInitialMotion(x, y, pointerId);

//Step 2

final View toCapture = findTopChildUnder((int) x, (int) y);

//Step 3

if (toCapture == mCapturedView && mDragState == STATE_SETTLING) {

tryCaptureViewForDrag(toCapture, pointerId);

}

//Step 4

final int edgesTouched = mInitialEdgesTouched[pointerId];

if ((edgesTouched & mTrackingEdges) != 0) {

mCallback.onEdgeTouched(edgesTouched & mTrackingEdges, pointerId);

}

break;

}

//暂时忽略

…

}

//Step 5

return mDragState == STATE_DRAGGING;

}

可以看见，上面代码我们只列出了shouldInterceptTouchEvent关于ACTION_DOWN部分的代码，在注释里我将他分为了5步来叙述。我们先来看当ACTION_DOWN触发时Step 1的代码，他通过saveInitialMotion(x, y, pointerId)保存了事件的初始信息，如下是saveInitialMotion方法代码：

private void saveInitialMotion(float x, float y, int pointerId) {

ensureMotionHistorySizeForId(pointerId);

mInitialMotionX[pointerId] = mLastMotionX[pointerId] = x;

mInitialMotionY[pointerId] = mLastMotionY[pointerId] = y;

//getEdgesTouched就是通过mEdgeSize去判断触摸边沿方向是否OK

mInitialEdgesTouched[pointerId] = getEdgesTouched((int) x, (int) y);

mPointersDown |= 1 << pointerId;

}

接着目光再回到shouldInterceptTouchEvent方法的Step 2，可以发现他尝试通过findTopChildUnder()方法来获取当前触摸点下最顶层的子View，我们可以看下这个方法的源码，如下：

public View findTopChildUnder(int x, int y) {

//获取mParentView中子View个数

final int childCount = mParentView.getChildCount();

//倒序遍历整个子View，因为最上面的子View最后插入

for (int i = childCount - 1; i >= 0; i–) {

//遍历拿到最靠上且获得触摸焦点的那个子View

final View child = mParentView.getChildAt(mCallback.getOrderedChildIndex(i));

//判断当前DOWN的触摸点是否在该子View范围，也就是说是不是摸上了该子View

if (x >= child.getLeft() && x < child.getRight() &&

y >= child.getTop() && y < child.getBottom()) {

return child;

}

return null;

}

这个方法你不觉的奇怪么？怎么遍历时getChildAt传入的不是index，而是mCallback.getOrderedChildIndex(i)啊，我勒个去，mCallback不就是我们创建ViewDragHelper实例时传入的CallBack对象么？我们还是跳过去看下getOrderedChildIndex()方法吧，如下：

public static abstract class Callback {

…

public int getOrderedChildIndex(int index) {

return index;

}

…

}

猫了个咪的，这玩意默认啥也没干啊，看样子是某些情况下给我们用来重写的，啥情况？原来在上面findTopChildUnder()方法中返回当前被触摸的View时会有一种坑爹的情况出现，那就是如果在mParentView的同一个位置有多个子View是重叠的，此时又想让重叠的View中下面指定的那个被选中（默认for循环是倒序额）时getOrderedChildIndex()方法的默认实现就搞不定了，所以就需要我们自己去实现Callback里的getOrderedChildIndex()方法来改变查找子View的顺序。譬如：

public int getOrderedChildIndex(int index) {

//实现重叠View时让下面的View获得选中

int topIndex = mParentView.indexOfChild(your_top_view);

int BottomSelectedIndex = mParentView.indexOfChild(blow_your_top_view_selected);

return ((index == topIndex) ? indexBottom : index);

}

好了，扯远了，我们还是把目光回到shouldInterceptTouchEvent方法的Step 3，可以发现这里有一个判断，因为第一次触摸屏幕mCapturedView默认为null，所以一开始不会执行这个判断里的代码，同时因为mDragState第一次也不处于STATE_SETTLING状态，所以不执行，等执行时再分析。我们继续往下看Step 4，可以发现这里首先拿了saveInitialMotion方法赋值的结果，然后判断设置的边沿方向进行Callback的onEdgeTouched()方法回调。到这里boolean shouldInterceptTouchEvent()方法的第一次触摸按下ACTION_DOWN所干的事就完了，接着Step 5时直接return了mDragState == STATE_DRAGGING;，因为上面说了，在ACTION_DOWN时mDragState还是STATE_IDLE状态，所以这里返回了false。

至此第一次手指触摸mParentView上时shouldInterceptTouchEvent的ACTION_DOWN流程就结束了，接着我们就是依据这个返回值的情况进行分析（具体参见之前博文关于Android触摸事件传递的分析）。这里返回false就表示mParentView没有拦截这次事件，所以接下来会在mParentView中触发每个子View的boolean dispatchTouchEvent()方法，这时依据Android触摸事件处理机制又分为了两大类情况来处理，一类就是子View消费了这个ACTION_DOWN，一类是没有消费的情况，而这些情况下又分很多中情况，譬如子View消费了本次ACTION_DOWN，mParentView的onTouchEvent()就不会收到ACTION_DOWN了（即ViewDragHelper的processTouchEvent()方法也就收不到ACTION_DOWN了）；这时候又有很多情况，譬如当前子View如果调运了requestDisallowInterceptTouchEvent(true)，则ACTION_MOVE等来时mParentView的onInterceptTouchEvent()方法就不会被回调（即ViewDragHelper的相关方法也就没意义了）；当前子View没有调用requestDisallowInterceptTouchEvent(true)，则ACTION_MOVE等来时mParentView的onInterceptTouchEvent()方法还会被执行，此时若onInterceptTouchEvent()方法返回true，则mParentView的onTouchEvent()就会被调运（即ViewDragHelper的processTouchEvent()会被执行）。

额额额，触摸事件传递本来就很复杂，这里情况又很多，所以我们还是不分情况来说了，浅析源码我们牵一条主线走就行，其它的用到时再分析即可。

所以我们来看下子View没有消费这次ACTION_DOWN事件（即子View的dispatchTouchEvent()方法返回false）的流程。此时mParentView的dispatchTouchEvent()方法会调用自己的super.dispatchTouchEvent()方法（即View的dispatchTouchEvent()），然后super会调用mParentView的onTouchEvent()方法（即调用ViewDragHelper的processTouchEvent()方法）。这时onTouchEvent()方法需要返回true（只用在ACTION_DOWN时返回true，否则onTouchEvent()方法无法接收接下来的ACTION_MOVE等事件），当onTouchEvent()返回true以后ACTION_MOVE、ACTION_UP等事件再来时就不会再执行mParentView的onInterceptTouchEvent()了。

那就牵着主线走吧，我们可以看下processTouchEvent()方法的ACTION_DOWN部份源码，如下：

public void processTouchEvent(MotionEvent ev) {

//和shouldInterceptTouchEvent相似，省略

…

switch (action) {

case MotionEvent.ACTION_DOWN: {

//和shouldInterceptTouchEvent相似，省略解释

final float x = ev.getX();

final float y = ev.getY();

final int pointerId = MotionEventCompat.getPointerId(ev, 0);

final View toCapture = findTopChildUnder((int) x, (int) y);

saveInitialMotion(x, y, pointerId);

//Step 1 重点！！！！

tryCaptureViewForDrag(toCapture, pointerId);

//和shouldInterceptTouchEvent相似，省略解释

final int edgesTouched = mInitialEdgesTouched[pointerId];

if ((edgesTouched & mTrackingEdges) != 0) {

mCallback.onEdgeTouched(edgesTouched & mTrackingEdges, pointerId);

}

break;

}

//省略其他ACTION

…

}

可以看见，该方法里最核心的东西估计就是tryCaptureViewForDrag()方法了，下面我们看下这个方法，如下：

boolean tryCaptureViewForDrag(View toCapture, int pointerId) {

//正在拽就不管了

if (toCapture == mCapturedView && mActivePointerId == pointerId) {

// Already done!

return true;

}

//调用了Callback的tryCaptureView()方法，传递触摸到的View和触摸点编号

//Callback的tryCaptureView()决定是否能够拖动当前触摸的View

if (toCapture != null && mCallback.tryCaptureView(toCapture, pointerId)) {

mActivePointerId = pointerId;

//重点

captureChildView(toCapture, pointerId);

return true;

}

return false;

}

可以看见，通过Callback的tryCaptureView()重写设置是否可以挪动该View，若可以挪动（返回true）则又调运了captureChildView()方法，继续看下captureChildView()方法源码：

public void captureChildView(View childView, int activePointerId) {

…

//暂存被捕获的这个View的相关信息及触摸信息

mCapturedView = childView;

mActivePointerId = activePointerId;

//通过Callback的onViewCaptured()方法回调当前View被捕获了

mCallback.onViewCaptured(childView, activePointerId);

//设置当前被捕获的子View状态为STATE_DRAGGING

//里面会通过mCallback.onViewDragStateChanged(state)回调告知状态

setDragState(STATE_DRAGGING);

}

到此一次mParentView自己消费事件，子View无拦截ACTION_DOWN的事件处理就彻底结束了。接着就是主流程的ACTION_MOVE事件了，这玩意由于mParentView的onTouchEvent消费了事件且没进行拦截ACTION_DOWN，所以一旦触发时就直接走进了processTouchEvent()方法里，下面是ACTION_MOVE代码：

public void processTouchEvent(MotionEvent ev) {

…

switch (action) {

…

case MotionEvent.ACTION_MOVE: {

//分两种情况，依赖上一个ACTION_DOWN事件

if (mDragState == STATE_DRAGGING) {

//ACTION_DOWN时CallBack的tryCaptureView()返回true时对mDragState赋值了STATE_DRAGGING，故此流程

final int index = MotionEventCompat.findPointerIndex(ev, mActivePointerId);

final float x = MotionEventCompat.getX(ev, index);

final float y = MotionEventCompat.getY(ev, index);

final int idx = (int) (x - mLastMotionX[mActivePointerId]);

final int idy = (int) (y - mLastMotionY[mActivePointerId]);

//Step 1 重点！！！！！！

dragTo(mCapturedView.getLeft() + idx, mCapturedView.getTop() + idy, idx, idy);

//Step 2 重点！！！！！！

saveLastMotion(ev);

} else {

//ACTION_DOWN时CallBack的tryCaptureView()返回false时对mDragState没进行赋值，故此流程

// Check to see if any pointer is now over a draggable view.

final int pointerCount = MotionEventCompat.getPointerCount(ev);

for (int i = 0; i < pointerCount; i++) {

final int pointerId = MotionEventCompat.getPointerId(ev, i);

final float x = MotionEventCompat.getX(ev, i);

final float y = MotionEventCompat.getY(ev, i);

final float dx = x - mInitialMotionX[pointerId];

final float dy = y - mInitialMotionY[pointerId];

//Step 3 重点！！！！！！

reportNewEdgeDrags(dx, dy, pointerId);

if (mDragState == STATE_DRAGGING) {

// Callback might have started an edge drag.

break;

}

final View toCapture = findTopChildUnder((int) x, (int) y);

//Step 4 重点！！！！！！

if (checkTouchSlop(toCapture, dx, dy) &&

tryCaptureViewForDrag(toCapture, pointerId)) {

break;

}

saveLastMotion(ev);

}

break;

}

…

}

可以看见，当ACTION_MOVE事件多次触发时该段代码会依据我们重写CallBack的代码分为可以托拽当前View和不能托拽两种情况。

我们先来看下不能托拽的情况，这种相对比较简单，可以看到上面代码的Step 3部分，reportNewEdgeDrags()方法是我们的重点，如下：

//在托拽时该方法会被多次调运

private void reportNewEdgeDrags(float dx, float dy, int pointerId) {

int dragsStarted = 0;

…//四个方向，省略三个

if (checkNewEdgeDrag(dy, dx, pointerId, EDGE_BOTTOM)) {

dragsStarted |= EDGE_BOTTOM;

}

if (dragsStarted != 0) {

mEdgeDragsInProgress[pointerId] |= dragsStarted;

//该方法只会被调运一次，checkNewEdgeDrag方法中有处理

mCallback.onEdgeDragStarted(dragsStarted, pointerId);

}

可以发现，当我们在ACTION_DOWN触发时重写CallBack的tryCaptureView()方法返回false（当前View不能托拽）且是边沿触摸时移动时首先会回调Callback的onEdgeDragStarted()方法通知自定义ViewGroup开始边沿托拽。接着我们把目光投向Step 4部分，if (checkTouchSlop(toCapture, dx, dy) && tryCaptureViewForDrag(toCapture, pointerId)) 判断是我们关注的核心，toCapture其实就是当前捕获的View（这个View在边沿模式时一般摸不到，所以其实拿到的不是想要的childView，所以一般我们会在回调onEdgeDragStarted()方法中重写手动调用captureChildView()方法，传入我们摸不到的View，这样就相当于绕过tryCaptureView将状态设置为STATE_DRAGGING了），下面我们先看下checkTouchSlop()方法，如下：

//检查手指移动的距离有没有超过触发处理移动事件的最短距离mTouchSlop

private boolean checkTouchSlop(View child, float dx, float dy) {

if (child == null) {

return false;

}

//如果想让某个View滑动，就要返回大于0，否则processTouchEvent()的ACTION_MOVE就不会调用tryCaptureViewForDrag()来捕获当前触摸的View

final boolean checkHorizontal = mCallback.getViewHorizontalDragRange(child) > 0;

final boolean checkVertical = mCallback.getViewVerticalDragRange(child) > 0;

if (checkHorizontal && checkVertical) {

return dx * dx + dy * dy > mTouchSlop * mTouchSlop;

} else if (checkHorizontal) {

return Math.abs(dx) > mTouchSlop;

} else if (checkVertical) {

return Math.abs(dy) > mTouchSlop;

}

return false;

}

到此ACTION_MOVE不能托拽的情况就分析完毕了，我们再来看下可以托拽的情况，请看上面processTouchEvent()代码的Step 1,2部分，重点在于dragTo()方法，当我们正常捕获到View时ACTION_MOVE就不停的调用dragTo()对mCaptureView进行拖动，源码如下：

//left、top为mCapturedView.getLeft()+dx、mCapturedView.getTop()+dy，即期望目标坐标

//dx、dy为前后两次ACTION_MOVE移动的距离

private void dragTo(int left, int top, int dx, int dy) {

int clampedX = left;

int clampedY = top;

final int oldLeft = mCapturedView.getLeft();

final int oldTop = mCapturedView.getTop();

if (dx != 0) {

//重写固定横坐标移动到的位置

clampedX = mCallback.clampViewPositionHorizontal(mCapturedView, left, dx);

//这是View中定义的方法，实质是改变View的mLeft、mRight、mTop、mBottom达到移动View的效果，类似layout()方法的效果

//clampedX为新位置，oldLeft为旧位置，若想不动保证插值为0即可！！！！

mCapturedView.offsetLeftAndRight(clampedX - oldLeft);

}

if (dy != 0) {

//重写固定纵坐标移动到的位置

clampedY = mCallback.clampViewPositionVertical(mCapturedView, top, dy);

//这是View中定义的方法，实质是改变View的mLeft、mRight、mTop、mBottom达到移动View的效果，类似layout()方法的效果

mCapturedView.offsetTopAndBottom(clampedY - oldTop);

}

if (dx != 0 || dy != 0) {

final int clampedDx = clampedX - oldLeft;

final int clampedDy = clampedY - oldTop;

//当位置有变化时回调Callback的onViewPositionChanged方法实时通知

mCallback.onViewPositionChanged(mCapturedView, clampedX, clampedY,

clampedDx, clampedDy);

}

到此可以发现ACTION_MOVE时如果可以托拽则会实时挪动View的位置，同时回调很多方法。具体移动到哪和范围由Callback的clampViewPositionHorizontal()和clampViewPositionVertical()来决定。到此一次ACTION_MOVE事件的触发处理也就分析完毕了。下面就该是松手时ACTION_UP或者ACTION_MOVE被mParentView的上级View拦截触发的ACTION_CANCEL事件了，他们与ACTION_MOVE类似，直接触发processTouchEvent()的ACTION_UP或者ACTION_CANCEL，如下：

public void processTouchEvent(MotionEvent ev) {

…

switch (action) {

…

case MotionEvent.ACTION_UP: {

if (mDragState == STATE_DRAGGING) {

releaseViewForPointerUp();

}

//重置所有的状态记录

cancel();

break;

}

case MotionEvent.ACTION_CANCEL: {

if (mDragState == STATE_DRAGGING) {

dispatchViewReleased(0, 0);

}

//重置所有的状态记录

cancel();

break;

}

可以看见，ACTION_UP和ACTION_CANCEL的实质都是重置资源和通知View触摸被释放，一个调运了releaseViewForPointerUp方法，另一个调运了dispatchViewReleased方法而已。那我们先看下releaseViewForPointerUp方法，源码如下：

private void releaseViewForPointerUp() {

//获得相关速率

mVelocityTracker.computeCurrentVelocity(1000, mMaxVelocity);

final float xvel = clampMag(

VelocityTrackerCompat.getXVelocity(mVelocityTracker, mActivePointerId),

mMinVelocity, mMaxVelocity);

final float yvel = clampMag(

VelocityTrackerCompat.getYVelocity(mVelocityTracker, mActivePointerId),

mMinVelocity, mMaxVelocity);

//传入速率

dispatchViewReleased(xvel, yvel);

}

哎哟，握草，dispatchViewReleased(xvel, yvel)不就是ACTION_CANCEL传参为0调运的方法吗？也就是说ACTION_CANCEL与ACTION_UP逻辑一致，只是传入的速率不同而已。那我们就来看看这个方法，如下：

private void dispatchViewReleased(float xvel, float yvel) {

mReleaseInProgress = true;

//通知外部View被释放了

mCallback.onViewReleased(mCapturedView, xvel, yvel);

mReleaseInProgress = false;

//如果之前是STATE_DRAGGING状态，则复位状态为STATE_IDLE

if (mDragState == STATE_DRAGGING) {

// onViewReleased didn’t call a method that would have changed this. Go idle.

setDragState(STATE_IDLE);

}

可以看见dispatchViewReleased()方法主要就是通过CallBack通知手指松开了，同时将状态置位为STATE_IDLE。但是如果你留意该方法的注释和方法里的mReleaseInProgress变量的话，你一定会有疑惑。下面我就从注释和该变量出现的地方进行下简单分析，然后回过头就知道咋回事了，该方法注释提到了mReleaseInProgress变量与settleCapturedViewAt()和flingCapturedView()方法有关，那我们就来看下是啥关系，查看这两个方法的开头可以发现一个共性如下：

if (!mReleaseInProgress) {

throw new IllegalStateException("Cannot XXXXXXXXXX outside of a call to " +

“Callback#onViewReleased”);

}

我靠，默认mReleaseInProgress是false，在dispatchViewReleased()中CallBack回调onViewReleased()方法前把他置位了true，onViewReleased()后置位了false。这就是为啥注释里说唯一可以调用ViewDragHelper的settleCapturedViewAt()和flingCapturedView()的地方就是在Callback的onViewReleased()里，这下你指定就明白了，因为别的地方会抛出异常哇。

握草，这两方法为啥这么神奇，为啥只能在CallBack回调onViewReleased()中使用啊，我们先来分析一下就知道了，如下先看settleCapturedViewAt()方法源码：

//限制最终惯性滚动到的终极位置及滚动过去

public boolean settleCapturedViewAt(int finalLeft, int finalTop) {

//表明只能在CallBack回调onViewReleased()中使用

if (!mReleaseInProgress) {

throw new IllegalStateException("Cannot settleCapturedViewAt outside of a call to " +

“Callback#onViewReleased”);

}

return forceSettleCapturedViewAt(finalLeft, finalTop,

(int) VelocityTrackerCompat.getXVelocity(mVelocityTracker, mActivePointerId),

(int) VelocityTrackerCompat.getYVelocity(mVelocityTracker, mActivePointerId));

}

private boolean forceSettleCapturedViewAt(int finalLeft, int finalTop, int xvel, int yvel) {

…

if (dx == 0 && dy == 0) {

// Nothing to do. Send callbacks, be done.

mScroller.abortAnimation();

setDragState(STATE_IDLE);

return false;

}

//直接用过Scroller滚动到指定位置

final int duration = computeSettleDuration(mCapturedView, dx, dy, xvel, yvel);

mScroller.startScroll(startLeft, startTop, dx, dy, duration);

//滚动时设置状态为STATE_SETTLING

setDragState(STATE_SETTLING);

return true;

}

再看下flingCapturedView()方法，如下：

//不限制终点，由松手时加速度决定惯性滚动过去，fling效果

public void flingCapturedView(int minLeft, int minTop, int maxLeft, int maxTop) {

if (!mReleaseInProgress) {

throw new IllegalStateException("Cannot flingCapturedView outside of a call to " +

“Callback#onViewReleased”);

}

//直接用过Scroller滚动

mScroller.fling(mCapturedView.getLeft(), mCapturedView.getTop(),

(int) VelocityTrackerCompat.getXVelocity(mVelocityTracker, mActivePointerId),

(int) VelocityTrackerCompat.getYVelocity(mVelocityTracker, mActivePointerId),

minLeft, maxLeft, minTop, maxTop);

//滚动时设置状态为STATE_SETTLING

setDragState(STATE_SETTLING);

}

到此确实很奇怪，为啥这两个方法要这么限制设计？我还是没想明白，请教大神指点一下！但是我全局搜索mScroller的相关调运又发现了新的方法，如下：

public boolean smoothSlideViewTo(View child, int finalLeft, int finalTop) {

mCapturedView = child;

mActivePointerId = INVALID_POINTER;

boolean continueSliding = forceSettleCapturedViewAt(finalLeft, finalTop, 0, 0);

if (!continueSliding && mDragState == STATE_IDLE && mCapturedView != null) {

// If we’re in an IDLE state to begin with and aren’t moving anywhere, we

// end up having a non-null capturedView with an IDLE dragState

mCapturedView = null;

}

return continueSliding;

}

这货也能达到上面受限的settleCapturedViewAt()方法的效果，额额额，我凌乱了，这么设计是为啥额，不清楚。不过到此一次完整的ViewDragHelper的触摸移动主流程就分析完成了，其他相关状态请自行分析，对我来说有这些就差不多够了，主流程掌握了基本就能明白他提供的相关API含义了，其它的遇到问题再现查即可。

【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载，请尊重作者劳动成果。私信联系我】

4 源码局部浅析总结

==============

经过上面的浅析与注释总结归纳如下总结方便日后使用；同时我们可以发现ViewDragHelper的本质其实涉及的知识点还是很多的，主要在事件处理上，不得不佩服该工具类考虑的强大。

//常用核心API归纳总结

public class ViewDragHelper {

//当前View处于空闲状态，静止

public static final int STATE_IDLE = 0;

//当前View处于托动状态中

public static final int STATE_DRAGGING = 1;

//当前View处于滚动惯性到settling坐标间的状态

public static final int STATE_SETTLING = 2;

//可托拽边缘方向常量

public static final int EDGE_LEFT = 1 << 0;

public static final int EDGE_RIGHT = 1 << 1;

public static final int EDGE_TOP = 1 << 2;

public static final int EDGE_BOTTOM = 1 << 3;

public static final int EDGE_ALL = EDGE_LEFT | EDGE_TOP | EDGE_RIGHT | EDGE_BOTTOM;

…

//公有静态内部抽象回调类，当ViewDragHelper控制的ViewGroup中View变化时会被回调

public static abstract class Callback {

//当托拽状态变化时回调，譬如动画结束后回调为STATE_IDLE等

//state有三种状态，均以STATE_XXXX模式

public void onViewDragStateChanged(int state) {}

//当前被触摸的View位置变化时回调

//changedView为位置变化的View，left/top变化时新的x左/y顶坐标，dx/dy为从旧到新的偏移量

public void onViewPositionChanged(View changedView, int left, int top, int dx, int dy) {}

//tryCaptureViewForDrag()成功捕获到子View时或者手动调用captureChildView()时回调

public void onViewCaptured(View capturedChild, int activePointerId) {}

//当子View被松手或者ACTION_CANCEL时时回调，xvel/yvel为离开屏幕时各方向每秒运动的速率，为px

public void onViewReleased(View releasedChild, float xvel, float yvel) {}

//当触摸ACTION_DOWN或ACTION_POINTER_DOWN边沿时回调

public void onEdgeTouched(int edgeFlags, int pointerId) {}

//返回true锁定edgeFlags对应的边缘，锁定后的边缘就不会回调onEdgeDragStarted()

public boolean onEdgeLock(int edgeFlags) {

return false;

}

//ACTION_MOVE且没有锁定边缘时触发

//可在此手动调用captureChildView()触发从边缘拖动子View，有点类似略过tryCaptureView返回false响应重定向其他View的效果

public void onEdgeDragStarted(int edgeFlags, int pointerId) {}

//寻找当前触摸点View时回调此方法

//如果需要改变子View的倒序遍历查询顺序则可改写此方法，譬如让重叠的下层View先于上层View被捕获

public int getOrderedChildIndex(int index) {

return index;

}

//返回给定子View在相应方向上可以被拖动的最远距离，默认为0，一般是可被挪动View时指定为指定View的大小等

public int getViewHorizontalDragRange(View child) {

return 0;

}

public int getViewVerticalDragRange(View child) {

return 0;

}

//传递当前触摸上的子View，如果需要当前触摸的子View进行拖拽移动就返回true，否则返回false

public abstract boolean tryCaptureView(View child, int pointerId);

//决定要拖拽的子View在所属方向上应该移动到的位置

//child为拖拽的子View，left为期望值，dx为挪动差值

public int clampViewPositionHorizontal(View child, int left, int dx) {

return 0;

}

public int clampViewPositionVertical(View child, int top, int dy) {

return 0;

}

…

//构造工厂方法，sensitivity用来调节mTouchSlop的值，默认一般传递1即可

//sensitivity越大，mTouchSlop越小，对滑动的检测就越敏感，譬如手指move多少才算滑动，否则忽略

public static ViewDragHelper create(ViewGroup forParent, float sensitivity, Callback cb) {…}

//设置允许父View的某个边缘可以用来响应托拽

//相当于控制了CallBack对象的onEdgeTouched()和onEdgeDragStarted()方法是否被回调

public void setEdgeTrackingEnabled(int edgeFlags) {…}

//两个传递MotionEvent的方法

public boolean shouldInterceptTouchEvent(MotionEvent ev) {…}

public void processTouchEvent(MotionEvent ev) {…}

//主动在父View内捕获指定的子view用于拖曳，会回调tryCaptureView()

public void captureChildView(View childView, int activePointerId) {…}

//指定某个View自动滚动到指定的位置，初速度为0，可在任何地方调用

//如果这个方法返回true，那么在接下来动画移动的每一帧中都会回调continueSettling(boolean)方法，直到结束

public boolean smoothSlideViewTo(View child, int finalLeft, int finalTop) {…}

//以松手前的滑动速度为初值，让捕获到的子View自动滚动到指定位置，只能在Callback的onViewReleased()中使用

//如果这个方法返回true，那么在接下来动画移动的每一帧中都会回调continueSettling(boolean)方法，直到结束

public boolean settleCapturedViewAt(int finalLeft, int finalTop) {…}

//以松手前的滑动速度为初值，让捕获到的子View在指定范围内fling惯性运动，只能在Callback的onViewReleased()中使用

//如果这个方法返回true，那么在接下来动画移动的每一帧中都会回调continueSettling(boolean)方法，直到结束

public void flingCapturedView(int minLeft, int minTop, int maxLeft, int maxTop) {…}

/**

在整个settle状态中,这个方法会返回true，deferCallbacks决定滑动是否Runnable推迟，一般推迟
在调用settleCapturedViewAt()、flingCapturedView()和smoothSlideViewTo()时，
需要实现mParentView的computeScroll()方法，如下：
@Override
public void computeScroll() {

if (mDragHelper.continueSettling(true)) {

    ViewCompat.postInvalidateOnAnimation(this);

```
}
```
}

public boolean continueSettling(boolean deferCallbacks) {…}

…

//设置与获取最小速率，一般保持默认

public void setMinVelocity(float minVel) {…}

public float getMinVelocity() {…}

//获取当前子View所处状态

public int getViewDragState() {…}

//返回可触摸反馈区域边缘大小，单位为px

public int getEdgeSize() {…}

//返回当前捕获的子View，如果没有则为null

public View getCapturedView() {…}

//获取当前拖曳的View的Pointer ID

public int getActivePointerId() {…}

//获取最小触发拖曳动作的灵敏度差值，单位为px

public int getTouchSlop() {…}

//类似ACTION_CANCEL事件的触发调运

public void cancel() {…}

//终止手势，结束动画滚动等，恢复初始STATE_IDLE状态

public void abort() {…}

…
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

要如何成为Android架构师？

搭建自己的知识框架，全面提升自己的技术体系，并且往底层源码方向深入钻研。
大多数技术人喜欢用思维脑图来构建自己的知识体系，一目了然。这里给大家分享一份大厂主流的Android架构师技术体系，可以用来搭建自己的知识框架，或者查漏补缺；

对应这份技术大纲，我也整理了一套Android高级架构师完整系列的视频教程，主要针对3-5年Android开发经验以上，需要往高级架构师层次学习提升的同学，希望能帮你突破瓶颈，跳槽进大厂；

最后我必须强调几点：

1.搭建知识框架可不是说你整理好要学习的知识顺序，然后看一遍理解了能复制粘贴就够了，大多都是需要你自己读懂源码和原理，能自己手写出来的。
2.学习的时候你一定要多看多练几遍，把知识才吃透，还要记笔记，这些很重要！最后你达到什么水平取决你消化了多少知识
3.最终你的知识框架应该是一个完善的，兼顾广度和深度的技术体系。然后经过多次项目实战积累经验，你才能达到高级架构师的层次。

你只需要按照在这个大的框架去填充自己，年薪40W一定不是终点，技术无止境

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。**

[外链图片转存中…(img-KjUBftMI-1712421481286)]

[外链图片转存中…(img-3wOISNTd-1712421481287)]

[外链图片转存中…(img-dft4vs1f-1712421481287)]

[外链图片转存中…(img-jCAfyL1x-1712421481287)]

[外链图片转存中…(img-zlHYeNVb-1712421481288)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

要如何成为Android架构师？

搭建自己的知识框架，全面提升自己的技术体系，并且往底层源码方向深入钻研。
大多数技术人喜欢用思维脑图来构建自己的知识体系，一目了然。这里给大家分享一份大厂主流的Android架构师技术体系，可以用来搭建自己的知识框架，或者查漏补缺；
[外链图片转存中…(img-vSqy3LNO-1712421481288)]

对应这份技术大纲，我也整理了一套Android高级架构师完整系列的视频教程，主要针对3-5年Android开发经验以上，需要往高级架构师层次学习提升的同学，希望能帮你突破瓶颈，跳槽进大厂；

最后我必须强调几点：

你只需要按照在这个大的框架去填充自己，年薪40W一定不是终点，技术无止境

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

2401_84153262

关注

26
点赞
踩
10

收藏

觉得还不错? 一键收藏
0
评论
Android应用ViewDragHelper详解及部分源码浅析，安卓开发必须会的技能

经过上面的浅析与注释总结归纳如下总结方便日后使用；同时我们可以发现ViewDragHelper的本质其实涉及的知识点还是很多的，主要在事件处理上，不得不佩服该工具类考虑的强大。//常用核心API归纳总结//当前View处于空闲状态，静止//当前View处于托动状态中//当前View处于滚动惯性到settling坐标间的状态//可托拽边缘方向常量//公有静态内部抽象回调类，当ViewDragHelper控制的ViewGroup中View变化时会被回调。
复制链接

扫一扫