Android滑動(dòng)沖突的完美解決方案

更新時(shí)間：2016年08月08日 09:57:24 投稿：daisy

在Android開發(fā)中滑動(dòng)沖突可以說是比較常見的一類問題，也是比較讓人頭疼的一類問題，兩個(gè)原本完美的控件，組合在一起之后，忽然發(fā)現(xiàn)整個(gè)世界都不好了。滑動(dòng)沖突主要分為同方向滑動(dòng)沖突和不同方向滑動(dòng)沖突，下面本文將詳細(xì)說明兩種滑動(dòng)沖突如何解決。

關(guān)于滑動(dòng)沖突

在Android開發(fā)中，如果是一些簡單的布局，都很容易搞定，但是一旦涉及到復(fù)雜的頁面，特別是為了兼容小屏手機(jī)而使用了ScrollView以后，就會(huì)出現(xiàn)很多點(diǎn)擊事件的沖突，最經(jīng)典的就是ScrollView中嵌套了ListView。我想大部分剛開始接觸Android的同學(xué)們都踩到過這個(gè)坑，下面跟著小編一起來看看解決方案吧。。

同方向滑動(dòng)沖突

比如ScrollView嵌套ListView，或者是ScrollView嵌套自己

這里先看一張效果圖

上圖是在購物軟件上常見的上拉查看圖文詳情，關(guān)于這中動(dòng)畫效果的實(shí)現(xiàn)，其實(shí)實(shí)現(xiàn)整體的效果，辦法是有很多的，網(wǎng)上有很多相關(guān)的例子，但是對某些細(xì)節(jié)的處理不是很清晰，比如，下拉之后顯示的部分（例如底部的圖文詳情）又是一個(gè)類ScrollView的控件（比如WebView）的話，又會(huì)產(chǎn)生新的問題。這里就以下拉查看圖文詳情為背景做一下同方向滑動(dòng)沖突的分析。

整體思路
這里看下圖

多個(gè)ScrollView嵌套示意圖

首先，關(guān)于這張圖做一些設(shè)定：

1.黑色的框代表手機(jī)屏幕

2.綠色的框代表一個(gè)外層的ScrollView

3.兩個(gè)紅色的框代表嵌套在里面的兩個(gè)類ScrollView控件，這里我們就暫時(shí)簡稱為 SUp,SDown

好了，接下來就分析一下實(shí)現(xiàn)整個(gè)流程的過程。

這里必須明確的一點(diǎn)，無論何時(shí)，SUp和SDown可見的部分始終是手機(jī)屏幕的高度。知道了這一點(diǎn)，我們就可以按以下步驟展開

首先，我們確保外部的ScrollView不攔截滑動(dòng)事件，這樣SUp必然獲得此次事件，然后根據(jù)其Action_Move事件，當(dāng)其為向下滑動(dòng)且自身滑動(dòng)距離+屏幕高度=其自身高度時(shí)，即可認(rèn)為SUp滑動(dòng)到了底部，此時(shí)外部ScrollView可攔截滑動(dòng)事件，從而保證整個(gè)視圖能夠繼續(xù)向下滑動(dòng)，這個(gè)時(shí)候底部SDown就顯示出來了。

同理，這時(shí)候不允許外部ScrollView攔截滑動(dòng)事件，由SDown處理，根據(jù)其Action_move事件，當(dāng)其為向上滑動(dòng)，且自身可滑動(dòng)距離為0時(shí)，就說明SDown已經(jīng)滑動(dòng)到了頂部，這時(shí)外部ScrollView又可以獲得攔截滑動(dòng)事件的權(quán)利，從而保證整個(gè)視圖能夠向上繼續(xù)滑動(dòng)，此時(shí)SUp再次顯示，又開始新一輪循環(huán)攔截。

這樣整體的一個(gè)流程就可以實(shí)現(xiàn)動(dòng)圖中的效果。好了，說完原理，還是看代碼。

代碼實(shí)現(xiàn)

SUp實(shí)現(xiàn)

public class UpScrollView extends ScrollView {
 /**
 * 屏幕高度
 */
 private int mScreenHeight;
 /**
 * 上一次的坐標(biāo)
 */
 private float mLastY;
 /**
 * 當(dāng)前View滑動(dòng)距離
 */
 private int mScrollY;
 /**
 * 當(dāng)前View內(nèi)子控件高度
 */
 private int mChildH;

 public UpScrollView(Context context) {
 super(context);
 init(context);
 }

 public UpScrollView(Context context, AttributeSet attrs) {
 super(context, attrs);
 init(context);
 }

 public UpScrollView(Context context, AttributeSet attrs, int defStyleAttr) {
 super(context, attrs, defStyleAttr);
 init(context);

 }

 private void init(Context context) {
 WindowManager wm = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
 DisplayMetrics dm = new DisplayMetrics();
 wm.getDefaultDisplay().getMetrics(dm);
 mScreenHeight = dm.heightPixels;
 }

 @Override
 public boolean onTouchEvent(MotionEvent ev) {
 //默認(rèn)設(shè)定頂層View不攔截

 getParent().getParent().requestDisallowInterceptTouchEvent(true);

 switch (ev.getAction()) {
  case MotionEvent.ACTION_DOWN:
  mLastY = (int) ev.getY();
  break;
  case MotionEvent.ACTION_MOVE:
  float y = ev.getY();
  float deltaY = y - mLastY;

  mChildH = this.getChildAt(0).getMeasuredHeight();

  int translateY = mChildH - mScrollY;

  //向上滑動(dòng)時(shí)，如果translateY等于屏幕高度時(shí)，即表明滑動(dòng)到底部，可又頂層View控制滑動(dòng)
  if (deltaY < 0 && translateY == mScreenHeight) {
   getParent().getParent().requestDisallowInterceptTouchEvent(false);
  }
  break;
  default:
  break;

 }

 return super.onTouchEvent(ev);
 }

 @Override
 protected void onScrollChanged(int l, int t, int oldl, int oldt) {
 super.onScrollChanged(l, t, oldl, oldt);
 mScrollY = t;
 }
}

這里在ACTION_MOVE里做了減法，其實(shí)道理是一樣的。

onScrollChanged 是在View類中實(shí)現(xiàn)，查看其API可以看到其第二個(gè)參數(shù)t解釋

@param t Current vertical scroll origin.

即為當(dāng)前View此次滑動(dòng)的距離

SDown實(shí)現(xiàn)

public class MyWebView extends WebView {
 public float oldY;
 private int t;

 public MyWebView(Context context) {
 super(context);
 init();
 }

 public MyWebView(Context context, AttributeSet attrs) {
 super(context, attrs);
 init();
 }

 public MyWebView(Context context, AttributeSet attrs, int defStyleAttr) {
 super(context, attrs, defStyleAttr);
 init();
 }

 private void init() {
 WebSettings settings = getSettings();
 settings.setJavaScriptEnabled(true);
 setWebViewClient(new WebViewClient() {
  @Override
  public boolean shouldOverrideUrlLoading(WebView view, String url) {
  view.loadUrl(url);
  return true;
  }
 });
 }

 @Override
 public boolean onTouchEvent(MotionEvent ev) {
 getParent().getParent().requestDisallowInterceptTouchEvent(true);
 switch (ev.getAction()) {
  case MotionEvent.ACTION_DOWN:
  oldY = ev.getY();
  break;
  case MotionEvent.ACTION_MOVE:

  float Y = ev.getY();
  float Ys = Y - oldY;
  if (Ys > 0 && t == 0) {
   getParent().getParent().requestDisallowInterceptTouchEvent(false);
  }
  break;

 }

 return super.onTouchEvent(ev);
 }

 @Override
 protected void onScrollChanged(int l, int t, int oldl, int oldt) {
 this.t = t;
 super.onScrollChanged(l, t, oldl, oldt);
 }

}

以上看到，這里底部的View并沒有繼承ScrollView，而是選擇繼承了WebView，這里只是為了方便，當(dāng)然繼承ScrollView也是沒有問題。這里只是需要按實(shí)際情況考慮，因?yàn)榈撞繄D文詳情的內(nèi)容就是一個(gè)WebView加載數(shù)據(jù)。

這個(gè)類的實(shí)現(xiàn)，按照之前說的原理應(yīng)該很好理解。

外部ScrollView

public class CustomerScrollViews extends ScrollView {
 /**
 * 屏幕高度
 */
 private int mScreenHeight;

 private UpScrollView upScrollView;
 private MyWebView myWebView;
 private boolean init = false;

 private float fator = 0.2f;
 private int factorHeight;

 private boolean upShow = true;

 public CustomerScrollViews(Context context) {
 super(context);
 init(context);
 }

 public CustomerScrollViews(Context context, AttributeSet attrs) {
 super(context, attrs);
 init(context);
 }

 public CustomerScrollViews(Context context, AttributeSet attrs, int defStyleAttr) {
 super(context, attrs, defStyleAttr);
 init(context);

 }

 private void init(Context context) {
 WindowManager wm = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
 DisplayMetrics dm = new DisplayMetrics();
 wm.getDefaultDisplay().getMetrics(dm);
 mScreenHeight = dm.heightPixels;
 factorHeight = (int) (mScreenHeight * fator);
 }

 @Override
 protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
 if (!init) {

  LinearLayout parentView = (LinearLayout) getChildAt(0);
  //獲得內(nèi)部的兩個(gè)子view
  upScrollView = (UpScrollView) parentView.getChildAt(0);
  myWebView = (MyWebView) parentView.getChildAt(2);
//  //并設(shè)定其高度為屏幕高度
  upScrollView.getLayoutParams().height = mScreenHeight;
  myWebView.getLayoutParams().height = mScreenHeight;
  init = true;
 }

 super.onMeasure(widthMeasureSpec, heightMeasureSpec);
 }

 @Override
 protected void onLayout(boolean changed, int l, int t, int r, int b) {
 super.onLayout(changed, l, t, r, b);
 if (changed) {
  scrollTo(0, 0);
 }
 }

 @Override
 public boolean onTouchEvent(MotionEvent ev) {
 switch (ev.getAction()) {
  case MotionEvent.ACTION_UP:
  int scrollY = getScrollY();
  if (upShow) {
   if (scrollY <= factorHeight) {
   smoothScrollTo(0, 0);
   } else {
   smoothScrollTo(0, mScreenHeight);
   upShow = false;

   }
  } else {
   int scrollpadding = mScreenHeight - scrollY;
   if (scrollpadding >= factorHeight) {
   this.smoothScrollTo(0, 0);
   upShow = true;

   } else {
   this.smoothScrollTo(0, mScreenHeight);
   }

  }

  return true;

 }
 return super.onTouchEvent(ev);
 }

}

這個(gè)類的實(shí)現(xiàn)，就很靈活了，在onMeasure方法中初始化完內(nèi)部的View之后，在OnTouch方法中就可以根據(jù)實(shí)際需求完成不同的邏輯實(shí)現(xiàn)，這里只是為了仿照查看圖文詳情的效果，對整個(gè)視圖通過ScrollView的smoothScrollTo方法進(jìn)行位移變化，這個(gè)邏輯很簡單。

這里重點(diǎn)說一下一個(gè)地方：

upScrollView = (UpScrollView) parentView.getChildAt(0);
myWebView = (MyWebView) parentView.getChildAt(2);

你可能會(huì)奇怪中間的child(1)去了哪里？這里還要從MainActivity的布局文件說起

dual_scrollview_activity_layout1.xml

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:orientation="vertical">

 <com.example.dreamwork.activity.superscrollview.CustomerScrollViews
 android:layout_width="match_parent"
 android:layout_height="match_parent">

 <LinearLayout
  android:layout_width="match_parent"
  android:layout_height="wrap_content"
  android:orientation="vertical">

  <com.example.dreamwork.activity.superscrollview.UpScrollView

  android:layout_width="match_parent"
  android:layout_height="wrap_content"
  android:scrollbars="vertical">

  <LinearLayout
   android:layout_width="match_parent"
   android:layout_height="wrap_content"
   android:orientation="vertical">

   <ImageView
   android:layout_width="match_parent"
   android:layout_height="wrap_content"
   android:scaleType="fitXY"
   android:src="@drawable/taobao" />
   <ImageView
   android:layout_width="match_parent"
   android:layout_height="wrap_content"
   android:scaleType="fitXY"
   android:src="@drawable/taobao" />

   <TextView
   android:textSize="20sp"
   android:padding="10dp"
   android:gravity="center"
   android:layout_marginTop="20dp"
   android:layout_marginBottom="60dp"
   android:text="查看圖文詳情"
   android:layout_width="match_parent"
   android:layout_height="wrap_content" />

  </LinearLayout>
  </com.example.dreamwork.activity.superscrollview.UpScrollView>

  <include layout="@layout/selector_tab_items" />

  <com.example.dreamwork.activity.superscrollview.MyWebView
  android:id="@+id/web"
  android:layout_width="match_parent"
  android:layout_height="match_parent"/>

 </LinearLayout>
 </com.example.dreamwork.activity.superscrollview.CustomerScrollViews>

</LinearLayout>

整個(gè)布局文件可以看出，我們在CustomerScrollViews這個(gè)最外層的自定義ScrollView內(nèi)部又放置了兩個(gè)自定義的ScrollView（就如我們看到的原理圖那樣），只不過在這兩個(gè)ScrollView類控件的中間通過layout又放置一個(gè)LinearLayout，里面的內(nèi)容就是在動(dòng)圖中看到的那個(gè)中間的寫著qq,baidu字樣的用于切換WebView內(nèi)容的一個(gè)View。這里就不貼代碼了。

這樣，你就可以理解之前的child(1)為什么被跳過了吧。

使用

public class DualScrollViewActivity1 extends Activity implements View.OnClickListener {

 private MyWebView webView;

 private TextView sinaTv, qqTv, baiduTv;
 private View line1, line2, line3;

 private final String BAIDU = "http://www.baidu.com";
 private final String QQ = "http://www.qq.com";
 private final String SINA = "http://sina.cn";

 @Override
 protected void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 requestWindowFeature(Window.FEATURE_NO_TITLE);
 InitView();
 sinaTv.performClick();
 }

 private void InitView() {
 setContentView(R.layout.dual_scrollview_activity_layout1);
 webView = V.f(this, R.id.web);

 sinaTv = V.f(this, R.id.one);
 sinaTv.setOnClickListener(this);
 qqTv = V.f(this, R.id.two);
 qqTv.setOnClickListener(this);
 baiduTv = V.f(this, R.id.three);
 baiduTv.setOnClickListener(this);

 line1 = V.f(this, R.id.line1);
 line2 = V.f(this, R.id.line2);
 line3 = V.f(this, R.id.line3);
 }

 @Override
 public void onClick(View v) {
 reset();
 String url = "";
 switch (v.getId()) {
  case R.id.one:
  line1.setVisibility(View.VISIBLE);
  url = SINA;
  break;
  case R.id.two:
  line2.setVisibility(View.VISIBLE);
  url = QQ;
  break;
  case R.id.three:
  line3.setVisibility(View.VISIBLE);
  url = BAIDU;
  break;
  default:
  break;
 }

 webView.loadUrl(url);
 }

 private void reset(){
 line1.setVisibility(View.GONE);
 line2.setVisibility(View.GONE);
 line3.setVisibility(View.GONE);
 }
}

關(guān)于底部View內(nèi)容更新，WebView 通過加載不同URL實(shí)現(xiàn)不同視圖效果，只是作為Demo測試，實(shí)際中應(yīng)考慮通過fragment切換實(shí)現(xiàn)。

這里對滑動(dòng)沖突的解決方法，是由內(nèi)而外的展開，默認(rèn)使頂層View失去攔截能力，在由底部View的滑動(dòng)距離，做出不同邏輯判斷控制了頂層的攔截與否；這也是比較容易理解和實(shí)現(xiàn)的思路。當(dāng)然，對于此類滑動(dòng)沖突，有很多不同思路，這里只是列舉其一。

實(shí)際開發(fā)開發(fā)中，這種帶有同方向滑動(dòng)特性的控件嵌套時(shí)，產(chǎn)生的問題不只是滑動(dòng)沖突，有時(shí)候會(huì)有內(nèi)容顯示不全或不顯示的情況。

最常見如ScrollView嵌套ListView，這種情況只需自定義ListView使其高度計(jì)算為一個(gè)很大的值，某種意義上讓其失去了滑動(dòng)的特性，但是這樣也讓ListView貌似失去了視圖回收機(jī)制，這種時(shí)候如果加載很多很多很多圖片，效果就會(huì)很不理想。對于這種情況，通過對ListView添加headView及footView也是一種解決的辦法，但也得實(shí)際UI情況允許。

ScrollView嵌套RecyclerView時(shí)稍微麻煩一點(diǎn)，需要自定義ScrollView，還需要自定義實(shí)現(xiàn)LinearLayoutManager。

不同方向滑動(dòng)沖突

比如ScrollView嵌套ViewPager，或者是ViewPager嵌套ScrollView，這種情況其實(shí)很典型?，F(xiàn)在大部分應(yīng)用最外層都是ViewPager+Fragment 的底部切換（比如微信）結(jié)構(gòu)，這種時(shí)候，就很容易出現(xiàn)滑動(dòng)沖突。不過ViewPager里面無論是嵌套ListView還是ScrollView，滑動(dòng)沖突是沒有的，畢竟是官方的東西，可能已經(jīng)考慮到了這些，所以比較完善。

復(fù)雜一點(diǎn)的滑動(dòng)沖突，基本上就是這兩個(gè)沖突結(jié)合的結(jié)果。

滑動(dòng)沖突解決思路
滑動(dòng)沖突，就其本質(zhì)來說，兩個(gè)不同方向（或者是同方向）的View，其中有一個(gè)是占主導(dǎo)地位的，每次總是搶著去處理外界的滑動(dòng)行為，這樣就導(dǎo)致一種很別扭的用戶體驗(yàn)，明明只是橫向的滑動(dòng)了一下，縱向的列表卻在垂直方向發(fā)生了動(dòng)作。就是說，這個(gè)占主導(dǎo)地位的View，每一次都身不由己的攔截了這個(gè)滑動(dòng)的動(dòng)作，因此，要解決滑動(dòng)沖突，就是得明確告訴這個(gè)占主導(dǎo)地位的View，什么時(shí)候你該攔截，什么時(shí)候你不應(yīng)該攔截，應(yīng)該由下一層的View去處理這個(gè)滑動(dòng)動(dòng)作。

這里不明白的同學(xué)，可以去了解一下Android Touch事件的分發(fā)機(jī)制，這也是解決滑動(dòng)沖突的核心知識。

滑動(dòng)沖突

這里，說一下背景情況。之前做下拉刷新、上拉加載更多時(shí)一直使用的是PullToRefreshView這個(gè)控件，因?yàn)楹芊奖?，不用?dǎo)入三方工程。在其內(nèi)部可以放置ListView，GridView及ScrollView，非常方便，用起來可謂是屢試不爽。但是直到有一天，因項(xiàng)目需要，在ListView頂部加了一個(gè)輪播圖控件BannerView（這個(gè)可以參考之前寫的一篇學(xué)習(xí)筆記）。結(jié)果發(fā)現(xiàn)輪播圖滑動(dòng)的時(shí)候，和縱向的下拉刷新組件沖突了。

如之前所說，解決滑動(dòng)沖突的關(guān)鍵，就是明確告知接收到Touch的View，是否需要攔截此次事件。

解決方法

解決方案1，從外部攔截機(jī)制考慮

這里，相當(dāng)于是PullToRefreshView嵌套了ViewPager，那么每次優(yōu)先接收到Touch事件的必然是PullToRefreshView。這樣就清楚了，看代碼：

在PullToRefreshView中：

 @Override
 public boolean onInterceptTouchEvent(MotionEvent e) {
 int y = (int) e.getRawY();
 int x = (int) e.getRawX();
 boolean resume = false;
 switch (e.getAction()) {
  case MotionEvent.ACTION_DOWN:
  // 發(fā)生down事件時(shí),記錄y坐標(biāo)
  mLastMotionY = y;
  mLastMotionX = x;
  resume = false;
  break;
  case MotionEvent.ACTION_MOVE:
  // deltaY > 0 是向下運(yùn)動(dòng),< 0是向上運(yùn)動(dòng)
  int deltaY = y - mLastMotionY;
  int deleaX = x - mLastMotionX;

  if (Math.abs(deleaX) > Math.abs(deltaY)) {
   resume = false;
  } else {
  //當(dāng)前正處于滑動(dòng)
   if (isRefreshViewScroll(deltaY)) {
   resume = true;
   }
  }
  break;
  case MotionEvent.ACTION_UP:
  case MotionEvent.ACTION_CANCEL:
  break;
 }
 return resume;
 }

這里最關(guān)鍵的代碼就是這行

if (Math.abs(deleaX) > Math.abs(deltaY)) {
   resume = false;
  }

橫向滑動(dòng)距離大于縱向時(shí)，無須攔截這次滑動(dòng)事件。其實(shí)，就是這么簡單，但前提是你必須明確了解Android Touch事件的傳遞機(jī)制，期間各個(gè)方法執(zhí)行的順序及意義。

解決方案2，從內(nèi)容逆向思維分析

有時(shí)候，我們不想去修改引入的第三方控件，或者說是無法修改時(shí)。就必須考慮從當(dāng)前從Touch傳遞事件中最后的那個(gè)View逆向考慮。首先，由Android中View的Touch事件傳遞機(jī)制，我們知道Touch事件，首先必然由最外層View攔截，如果無法更改這個(gè)最外層View，那么是不是就沒轍了呢？其實(shí)不然，Android這么高大上的系統(tǒng)必然考慮到了這個(gè)問題，好了廢話不說，先看代碼

 private BannerView carouselView;
 private Context mContext;

 private PullToRefreshView refreshView;

 .........

 refreshView.setOnTouchListener(new View.OnTouchListener() {
  @Override
  public boolean onTouch(View v, MotionEvent event) {
  carouselView.getParent().requestDisallowInterceptTouchEvent(false);
  return false;
  }
 });

 carouselView.setOnTouchListener(new View.OnTouchListener() {
  @Override
  public boolean onTouch(View v, MotionEvent event) {
  carouselView.getParent().requestDisallowInterceptTouchEvent(true);
  int x = (int) event.getRawX();
  int y = (int) event.getRawY();

  switch (event.getAction()) {
   case MotionEvent.ACTION_DOWN:
   lastX = x;
   lastY = y;
   break;
   case MotionEvent.ACTION_MOVE:
   int deltaY = y - lastY;
   int deltaX = x - lastX;
   if (Math.abs(deltaX) < Math.abs(deltaY)) {
    carouselView.getParent().requestDisallowInterceptTouchEvent(false);
   } else {
    carouselView.getParent().requestDisallowInterceptTouchEvent(true);
   }
   default:
   break;
  }
  return false;
  }
 });

首先說一下這個(gè)方法

public abstract void requestDisallowInterceptTouchEvent (boolean disallowIntercept)

API里的意思很明確，子View如果不希望其父View攔截Touch事件時(shí)，可調(diào)用此方法。當(dāng)disallowIntercept這個(gè)參數(shù)為true時(shí)，父View將不攔截。

PS:這個(gè)方法的命名和其參數(shù)的使用邏輯，讓我想到了一句很有意思的話，敵人的敵人就是朋友，真不知道Google的大神們怎么想的，非要搞一個(gè)反邏輯。

言歸正傳。這里攔截直接也很明確，在carouselView的onTouch方法中每次進(jìn)入就設(shè)定父View不攔截此次事件，然后在MOTION_MOVE時(shí)候，根據(jù)滑動(dòng)的距離判斷再?zèng)Q定是父View是否有權(quán)利攔截Touch事件（即滑動(dòng)行為）。

總結(jié)

好了，本文內(nèi)容到這基本就結(jié)束了，本篇文章只是提供一種解決方法的思路，在具體的場景下，交互往往是貼合具體業(yè)務(wù)需求的。但是不管怎么樣，找出點(diǎn)擊事件截?cái)嗪吞幚淼臅r(shí)機(jī)是最重要的，圍繞這個(gè)關(guān)鍵點(diǎn)，總能找出相應(yīng)的解決方法。

您可能感興趣的文章: