效果圖
如上圖，實(shí)現(xiàn)了拖拽事件的無(wú)縫過(guò)渡。效果很流暢很自然，之所以寫(xiě)輪子因?yàn)閷?shí)在找不到好用的庫(kù)，該庫(kù)參考了https://github.com/woxingxiao/SlidingUpPanelLayout ，其實(shí)在大神的開(kāi)源庫(kù)里就有Issues提到內(nèi)嵌 scrollView 時(shí)滑動(dòng)沖突的問(wèn)題。再加上最近項(xiàng)目里面的詳情頁(yè)就有這樣的拖拽效果需求，只好自己實(shí)現(xiàn)一遍。
在實(shí)現(xiàn)的過(guò)程中，就遇到幾個(gè)比較棘手的問(wèn)題，也經(jīng)過(guò)了一番掙扎才想出解決的方案。
困難
以上問(wèn)題也不是一蹴而就就能羅列清楚，這都是每解決一個(gè)問(wèn)題我就萌新另一種想法逐漸完善而得到的結(jié)果。就比如在實(shí)現(xiàn)這個(gè)效果之前，我就想應(yīng)該和 ViewDragHelper 有關(guān)，那么拖拽都有哪些需要重寫(xiě)的方法以及我自己需要實(shí)現(xiàn)哪些？關(guān)于重寫(xiě) tryCaptureView、getViewVerticalDragRange、clampViewPositionVertical 必須的就不多說(shuō)了，下面兩方法在本項(xiàng)目中處理的邏輯簡(jiǎn)單說(shuō)一下
onViewPositionChanged：當(dāng)拖拽view的位置發(fā)生改變時(shí)觸發(fā)
onViewReleased：簡(jiǎn)單可以理解為不再拖拽時(shí)觸發(fā)，但還有其狀態(tài)和方法會(huì)影響它觸發(fā)的時(shí)機(jī)，我們沒(méi)涉及到就不研究
回到開(kāi)始我們想要的拖拽效果，超過(guò)多少就回彈、展開(kāi)、收縮，在這里我們通過(guò)第一個(gè)方法可以知道，目前拖拽的view到底是展開(kāi)還是收縮，我用了一個(gè)局部的boolean來(lái)記錄狀態(tài)，畢竟此方法執(zhí)行頻繁減少消耗。再在釋放時(shí)根據(jù) slideUp 來(lái)判斷，至于 onPanelDragged() 方法就用來(lái)跟新拖拽狀態(tài)和更新視覺(jué)差
@Override public void onViewPositionChanged(View changedView, int left, int top, int dx, int dy) { slideUp = dy > 0;//正為收縮，負(fù)為展開(kāi) 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); } } /** * 拖拽狀態(tài)更新以及位置的更新 * */ private void onPanelDragged(int newTop) { setPanelStateInternal(PanelState.DRAGGING); //重新計(jì)算距離頂部偏移 mSlideOffset = computeSlideOffset(newTop); //更新視覺(jué)差效果和分發(fā)事件 applyParallaxForCurrentSlideOffset(); //如果偏移是向上，覆蓋則無(wú)效，需要增加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(); }緊接著，我們點(diǎn)擊展開(kāi)后漸變層，收縮并將內(nèi)嵌 scrollView 滾回頂部，點(diǎn)擊肯定就在 onTouchEvent 或者 dispatchTouchEvent 里實(shí)現(xiàn)，但有沒(méi)有區(qū)別呢?首先明確一點(diǎn)的時(shí)，不管方法寫(xiě)在哪個(gè)回調(diào)里面都可以實(shí)現(xiàn)我們需求，但在此我寫(xiě)在了后者里面，因?yàn)樵?viewGroup 里面的點(diǎn)擊事件傳遞，dispatchTouchEvent（分發(fā)） 會(huì)經(jīng)過(guò)詢問(wèn) onInterceptTouchEvent（攔截） 是否攔截再到 onTouchEvent（響應(yīng)），這也算是優(yōu)化的一點(diǎn)吧。
所有很自然而然地，我在分發(fā)里面處理了事件過(guò)渡的邏輯，其實(shí)說(shuō)白了就在 MotionEvent.ACTION_MOVE 里決定了到底誰(shuí)來(lái)消化這個(gè)事件
case MotionEvent.ACTION_MOVE:{ float dx = x - mPrevMotionX; float dy = y - mPrevMotionY; mPrevMotionX = x; mPrevMotionY = y; //橫向滑動(dòng)就不分發(fā)了 if (Math.abs(dx) > Math.abs(dy)) { return true; } //滑動(dòng)向上、向下 if (dy > 0) { //收縮 if (mScrollableViewHelper.getScrollableViewScrollPosition(mScrollView, true) > 0) { isMyHandleTouch = true; return super.dispatchTouchEvent(ev); } //之前子view處理了事件 //我們就需要重新組合一下讓面板得到一個(gè)合理的點(diǎn)擊事件 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 { //展開(kāi) //scrollY=0表示沒(méi)滑動(dòng)過(guò)，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); } //面板是否全部展開(kāi) 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); }}（也因?yàn)樵谶@里的處理邏輯，有很多操作的情況沒(méi)完全覆蓋，導(dǎo)致不可預(yù)知的滑動(dòng)出現(xiàn)bug，如有發(fā)現(xiàn)請(qǐng)給我反饋，我去優(yōu)化）
處理到這里，需求基本達(dá)到了。可以給設(shè)計(jì)師秀一波，把手機(jī)遞給她然后靜靜地聽(tīng)她懟iOS了，“為什么 Android 都能做得到，你 iOS 卻做不出來(lái)，你看人家多厲害”。
再優(yōu)化一個(gè)小問(wèn)題，狀態(tài)的回調(diào)，為了避免裝逼失敗等下要求展開(kāi)或者收縮時(shí)又要做些什么效果，有點(diǎn)危機(jī)意識(shí)。我縱觀了一些全局，實(shí)在沒(méi)有合適的方法可做回調(diào)，實(shí)在沒(méi)有方法在任何操作都觸發(fā)啊。最后我打起漸變層的主意，這個(gè)實(shí)現(xiàn)可把我樂(lè)了一下，太聰明了哈哈哈哈哈而且狀態(tài)都能正確回調(diào)。你要知道漸變層繪制可是需要不停的觸發(fā)的，回調(diào)只能一次
@Overrideprotected boolean drawChild(Canvas canvas, View child, long drawingTime) { ...(省略一些代碼) //沒(méi)有合適的回調(diào)方法，只能另辟蹊徑了 //在這里判斷dragView有沒(méi)有到頂，然后把事件給內(nèi)嵌view final 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; }...(省略一些代碼)}github:https://github.com/BmobSnail/SlideNestedPanelLayout
總結(jié)
以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)VEVB武林網(wǎng)的支持。
新聞熱點(diǎn)
疑難解答
圖片精選
網(wǎng)友關(guān)注
