Android仿美團實現(xiàn)無縫過度的拖拽效果
效果圖:
如上圖，實現(xiàn)了拖拽事件的無縫過渡。效果很流暢很自然，之所以寫輪子因為實在找不到好用的庫，該庫參考了https://github.com/woxingxiao/SlidingUpPanelLayout ，其實在大神的開源庫里就有Issues提到內(nèi)嵌 scrollView 時滑動沖突的問題。再加上最近項目里面的詳情頁就有這樣的拖拽效果需求，只好自己實現(xiàn)一遍。
在實現(xiàn)的過程中，就遇到幾個比較棘手的問題，也經(jīng)過了一番掙扎才想出解決的方案。
困難
拖拽釋放的時機，如下拉1/6就自動收縮否則回彈，上拉1/3回彈還是展開
釋放后，在回彈過程中更新背后view的視覺差、漸變效果
處理好上面兩個問題，就可以很流暢的實現(xiàn)拖拽展開和收縮效果，接下來過渡的傳遞問題
點擊漸變區(qū)域收縮并把內(nèi)部scrollView滾回頂部
什么時機該攔截事件還是父view處理
狀態(tài)的更新和回調(diào)
以上問題也不是一蹴而就就能羅列清楚，這都是每解決一個問題我就萌新另一種想法逐漸完善而得到的結(jié)果。就比如在實現(xiàn)這個效果之前，我就想應(yīng)該和 ViewDragHelper 有關(guān)，那么拖拽都有哪些需要重寫的方法以及我自己需要實現(xiàn)哪些？
關(guān)于重寫 tryCaptureView、getViewVerticalDragRange、clampViewPositionVertical 必須的就不多說了，下面兩方法在本項目中處理的邏輯簡單說一下：
onViewPositionChanged：當(dāng)拖拽view的位置發(fā)生改變時觸發(fā)。
onViewReleased：簡單可以理解為不再拖拽時觸發(fā)，但還有其狀態(tài)和方法會影響它觸發(fā)的時機，我們沒涉及到就不研究。
回到開始我們想要的拖拽效果，超過多少就回彈、展開、收縮，在這里我們通過第一個方法可以知道，目前拖拽的view到底是展開還是收縮，我用了一個局部的boolean來記錄狀態(tài)，畢竟此方法執(zhí)行頻繁減少消耗。再在釋放時根據(jù) slideUp 來判斷，至于 onPanelDragged() 方法就用來跟新拖拽狀態(tài)和更新視覺差。
@Overridepublic void onViewPositionChanged(View changedView, int left, int top, int dx, int dy) {slideUp = dy > 0;//正為收縮，負(fù)為展開onPanelDragged(top);}@Overridepublic void onViewReleased(View releasedChild, float xvel, float yvel) {int target;if (!slideUp) {if (mSlideOffset >= mAnchorPoint / 6) {target = computePanelToPosition(mAnchorPoint);} else {target = computePanelToPosition(0f);}} else {if (mSlideOffset >= mAnchorPoint / 3) {target = computePanelToPosition(0f);} else {target = computePanelToPosition(mAnchorPoint);}}if (mDragHelper != null) {mDragHelper.settleCapturedViewAt(releasedChild.getLeft(), target);}}
/*** 拖拽狀態(tài)更新以及位置的更新*/private void onPanelDragged(int newTop) {setPanelStateInternal(PanelState.DRAGGING);//重新計算距離頂部偏移mSlideOffset = computeSlideOffset(newTop);//更新視覺差效果和分發(fā)事件applyParallaxForCurrentSlideOffset();//如果偏移是向上，覆蓋則無效，需要增加main的高度LayoutParams lp = mMainView.getLayoutParams();int defaultHeight = getHeight() - getPaddingBottom() - getPaddingTop() - mPanelHeight;if (mSlideOffset <= 0 && !mOverlayFlag) {lp.height = (newTop - getPaddingBottom());if (lp.height == defaultHeight) {lp.height = LayoutParams.MATCH_PARENT;}} else if (lp.height != LayoutParams.MATCH_PARENT && !mOverlayFlag) {lp.height = LayoutParams.MATCH_PARENT;}mMainView.requestLayout();}
緊接著，我們點擊展開后漸變層，收縮并將內(nèi)嵌 scrollView 滾回頂部，點擊肯定就在 onTouchEvent 或者 dispatchTouchEvent 里實現(xiàn)，但有沒有區(qū)別呢?首先明確一點的時，不管方法寫在哪個回調(diào)里面都可以實現(xiàn)我們需求，但在此我寫在了后者里面，因為在 viewGroup 里面的點擊事件傳遞，dispatchTouchEvent（分發(fā)） 會經(jīng)過詢問 onInterceptTouchEvent（攔截） 是否攔截再到 onTouchEvent（響應(yīng)），這也算是優(yōu)化的一點吧。
所有很自然而然地，我在分發(fā)里面處理了事件過渡的邏輯，其實說白了就在 MotionEvent.ACTION_MOVE 里決定了到底誰來消化這個事件。
case?MotionEvent.ACTION_MOVE:{float dx = x - mPrevMotionX;float dy = y - mPrevMotionY;mPrevMotionX = x;mPrevMotionY = y;//橫向滑動就不分發(fā)了if (Math.abs(dx) > Math.abs(dy)) {return true;}//滑動向上、向下if (dy > 0) { //收縮if (mScrollableViewHelper.getScrollableViewScrollPosition(mScrollView, true) > 0) {isMyHandleTouch = true;return super.dispatchTouchEvent(ev);}//之前子view處理了事件//我們就需要重新組合一下讓面板得到一個合理的點擊事件if (isMyHandleTouch) {MotionEvent up = MotionEvent.obtain(ev);up.setAction(MotionEvent.ACTION_CANCEL);super.dispatchTouchEvent(up);up.recycle();ev.setAction(MotionEvent.ACTION_DOWN);}isMyHandleTouch = false;return this.onTouchEvent(ev);} else { //展開//scrollY=0表示沒滑動過，canScroll(1)表示可scroll up//邏輯或的意義：拖拽到頂后，要不要禁用外部拖拽if (isOnTopFlag == 1) {int offset = mDragView.getScrollY();boolean scroll = mScrollableViewHelper.getScrollableViewScrollPosition(mScrollView, true) > 0;setEnabled(offset == 0 || scroll);mDragHelper.abort();return super.dispatchTouchEvent(ev);}//面板是否全部展開if (mSlideOffset < mAnchorPoint) {isMyHandleTouch = false;return this.onTouchEvent(ev);}if (!isMyHandleTouch && mDragHelper.isDragging()) {mDragHelper.cancel();ev.setAction(MotionEvent.ACTION_DOWN);}isMyHandleTouch = true;return super.dispatchTouchEvent(ev);}}
這里消化了橫向滑動事件，因為內(nèi)部 scrollView 可以通過橫向滑動優(yōu)先獲取控制權(quán)，不信你注釋那句代碼，在一開始就先右滑不放再上滑，就會出現(xiàn)所謂的 bug
getScrollableViewScrollPosition 方法是一個輔助類，用來判斷view在豎直方向還有沒有可滑動的距離
關(guān)鍵的 return，是要繼續(xù)處理還是給 dragHelper 處理
收縮和展開其核心都圍繞 event 該給誰處理，邏輯條件有點繞
（也因為在這里的處理邏輯，有很多操作的情況沒完全覆蓋，導(dǎo)致不可預(yù)知的滑動出現(xiàn)bug，如有發(fā)現(xiàn)請給我反饋，我去優(yōu)化）
處理到這里，需求基本達(dá)到了。可以給設(shè)計師秀一波，把手機遞給她然后靜靜地聽她懟iOS了，“為什么 Android 都能做得到，你 iOS 卻做不出來，你看人家多厲害”。
再優(yōu)化一個小問題，狀態(tài)的回調(diào)，為了避免裝逼失敗等下要求展開或者收縮時又要做些什么效果，有點危機意識。我縱觀了一些全局，實在沒有合適的方法可做回調(diào)，實在沒有方法在任何操作都觸發(fā)啊。最后我打起漸變層的主意，這個實現(xiàn)可把我樂了一下，太聰明了哈哈哈哈哈而且狀態(tài)都能正確回調(diào)。你要知道漸變層繪制可是需要不停的觸發(fā)的，回調(diào)只能一次。
@Overrideprotected boolean drawChild(Canvas canvas, View child, long drawingTime) {...(省略一些代碼)//沒有合適的回調(diào)方法，只能另辟蹊徑了//在這里判斷dragView有沒有到頂，然后把事件給內(nèi)嵌viewfinal int targetY = computePanelToPosition(mAnchorPoint);final int originalY = computePanelToPosition(0f);if (mDragView.getTop() == targetY) {//避免多次回調(diào)if (isOnTopFlag != 1 && stateCallback != null) {stateCallback.onExpandedState();}isOnTopFlag = 1;} else if (mDragView.getTop() == originalY) {if (isOnTopFlag == -1 && stateCallback != null) {stateCallback.onCollapsedState();}isOnTopFlag = 0;} else {isOnTopFlag = -1;}...(省略一些代碼)}
需要源碼的童鞋公眾號回復(fù)："仿美團拖拽效果" 即可獲得哦。
到這里就結(jié)束啦。