Android仿美團拖拽效果採坑記
image
前言
效果圖.gif
效果圖.gif
如上圖，實現了拖拽事件的無縫過渡。效果很流暢很自然，之所以寫輪子因為實在找不到好用的庫，該庫參考了下面的地址：
https://github.com/woxingxiao/SlidingUpPanelLayout
其實在大神的開源庫裡就有Issues提到內嵌 scrollView 時滑動衝突的問題。再加上最近專案裡面的詳情頁就有這樣的拖拽效果需求，只好自己實現一遍。
正文
在實現的過程中，就遇到幾個比較棘手的問題，也經過了一番掙扎才想出解決的方案。
困難
-
拖拽釋放的時機，如下拉1/6就自動收縮否則回彈，上拉1/3回彈還是展開
-
釋放後，在回彈過程中更新背後view的視覺差、漸變效果
-
處理好上面兩個問題，就可以很流暢的實現拖拽展開和收縮效果，接下來過渡的傳遞問題
-
點選漸變區域收縮並把內部scrollView滾回頂部
-
什麼時機該攔截事件還是父view處理
-
狀態的更新和回撥
以上問題也不是一蹴而就就能羅列清楚，這都是每解決一個問題我就萌新另一種想法逐漸完善而得到的結果。就比如在實現這個效果之前，我就想應該和 ViewDragHelper 有關，那麼拖拽都有哪些需要重寫的方法以及我自己需要實現哪些？關於重寫 tryCaptureView、getViewVerticalDragRange、clampViewPositionVertical 必須的就不多說了，下面兩方法在本專案中處理的邏輯簡單說一下
-
onViewPositionChanged：當拖拽view的位置發生改變時觸發
-
onViewReleased：簡單可以理解為不再拖拽時觸發，但還有其狀態和方法會影響它觸發的時機，我們沒涉及到就不研究
回到開始我們想要的拖拽效果，超過多少就回彈、展開、收縮，在這裡我們通過第一個方法可以知道，目前拖拽的view到底是展開還是收縮，我用了一個區域性的boolean來記錄狀態，畢竟此方法執行頻繁減少消耗。再在釋放時根據 slideUp 來判斷，至於 onPanelDragged() 方法就用來跟新拖拽狀態和更新視覺差。
@Override public void onViewPositionChanged(View changedView, int left, int top, int dx, int dy) {slideUp = dy > 0;//正為收縮，負為展開onPanelDragged(top);} @Override public 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);} }
/*** 拖拽狀態更新以及位置的更新* */private void onPanelDragged(int newTop) {setPanelStateInternal(PanelState.DRAGGING);//重新計算距離頂部偏移mSlideOffset = computeSlideOffset(newTop);//更新視覺差效果和分發事件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();}
緊接著，我們點選展開後漸變層，收縮並將內嵌 scrollView 滾回頂部，點選肯定就在 onTouchEvent 或者 dispatchTouchEvent 裡實現，但有沒有區別呢?首先明確一點的時，不管方法寫在哪個回撥裡面都可以實現我們需求，但在此我寫在了後者裡面，因為在 viewGroup 裡面的點選事件傳遞，dispatchTouchEvent（分發） 會經過詢問 onInterceptTouchEvent（攔截） 是否攔截再到 onTouchEvent（響應），這也算是優化的一點吧。
所有很自然而然地，我在分發裡面處理了事件過渡的邏輯，其實說白了就在 MotionEvent.ACTION_MOVE 裡決定了到底誰來消化這個事件。
case MotionEvent.ACTION_MOVE:{float dx = x - mPrevMotionX;float dy = y - mPrevMotionY;mPrevMotionX = x;mPrevMotionY = y;//橫向滑動就不分發了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);}}
-
這裡消化了橫向滑動事件，因為內部 scrollView 可以通過橫向滑動優先獲取控制權，不信你註釋那句程式碼，在一開始就先右滑不放再上滑，就會出現所謂的 bug
-
getScrollableViewScrollPosition 方法是一個輔助類，用來判斷view在豎直方向還有沒有可滑動的距離
-
關鍵的 return，是要繼續處理還是給 dragHelper 處理
-
收縮和展開其核心都圍繞 event 該給誰處理，邏輯條件有點繞
（也因為在這裡的處理邏輯，有很多操作的情況沒完全覆蓋，導致不可預知的滑動出現bug，如有發現請給我反饋，我去優化）
處理到這裡，需求基本達到了。可以給設計師秀一波，把手機遞給她然後靜靜地聽她懟iOS了，“為什麼 Android 都能做得到，你 iOS 卻做不出來，你看人家多厲害”。
再優化一個小問題，狀態的回撥，為了避免裝逼失敗等下要求展開或者收縮時又要做些什麼效果，有點危機意識。我縱觀了一些全域性，實在沒有合適的方法可做回撥，實在沒有方法在任何操作都觸發啊。最後我打起漸變層的主意，這個實現可把我樂了一下，太聰明瞭哈哈哈哈哈而且狀態都能正確回撥。你要知道漸變層繪製可是需要不停的觸發的，回撥只能一次。
@Overrideprotected boolean drawChild(Canvas canvas, View child, long drawingTime) {...(省略一些程式碼)//沒有合適的回撥方法，只能另闢蹊徑了//在這裡判斷dragView有沒有到頂，然後把事件給內嵌viewfinal int targetY = computePanelToPosition(mAnchorPoint);final int originalY = computePanelToPosition(0f);if (mDragView.getTop() == targetY) {//避免多次回撥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;}...(省略一些程式碼)}
專案地址如下所示：
https://github.com/BmobSnail/SlideNestedPanelLayout
【附】相關架構及資料
image
資料領取
關注+點贊+加群：185873940 免費獲取！
點選連結加入群聊【Android IOC架構設計】： https://jq.qq.com/?_wv=1027&k=5tIZkaU
領取獲取往期Android高階架構資料、原始碼、筆記、視訊。高階UI、效能優化、架構師課程、NDK、混合式開發（ReactNative+Weex）微信小程式、Flutter全方面的Android進階實踐技術