一、显示不全、自动滚动异常
NestedScrollView嵌套RecyclerView时,有2个问题:
1、RecyclerView数据加载完成后,会自动滚动到第一个itemView的位置上,导致RecyclerView上面的布局不显示;
2、当RecyclerView的高度发生改变时,也会自动滚动到第一个itemView的位置上;
两个问题的原因其实都一样,就是NestedScrollView的子控件布局发生改变,导致NestedScrollView的高度发生改变,然后会自动滚动到拥有焦点的子view上。
NestedScrollView源码:
@Override
protected void onSizeChanged(int w, int h, int oldw, int oldh) {
super.onSizeChanged(w, h, oldw, oldh);
// 获取当前拥有焦点的子view
View currentFocused = findFocus();
if (null == currentFocused || this == currentFocused) {
return;
}
// 源码官方注释,大意就是:
// 如果height改变前,“焦点view”显示在屏幕上,那么height改变后,也应该滚动屏幕,让其仍然显示在屏幕上
// If the currently-focused view was visible on the screen when the
// screen was at the old height, then scroll the screen to make that
// view visible with the new screen height.
if (isWithinDeltaOfScreen(currentFocused, 0, oldh)) {
currentFocused.getDrawingRect(mTempRect);
offsetDescendantRectToMyCoords(currentFocused, mTempRect);
// 这个方法是计算需要滚动的距离
int scrollDelta = computeScrollDeltaToGetChildRectOnScreen(mTempRect);
// 执行滚动
doScrollY(scrollDelta);
}
}
问题出在computeScrollDeltaToGetChildRectOnScreen()方法上,它的功能是根据“焦点view”的宽高计算需要滚动的距离,计算一般view都是OK的,但是计算RecyclerView/ListView时会出问题,得到的结果总是要滑到第一个item处。具体的计算逻辑就不在这里分析了。
所以解决方案有两种:
1、让“焦点view”不是RecyclerView/ListView,而是一个其它不影响滚动效果的view。
比较简单的做法就是让NestedScrollView的一级子view获取焦点,成为“焦点view”。一个比较简单的方法是,在xml布局时,设置focusable、focusableInTouchMode属性为true,如下:
<android.support.v4.widget.NestedScrollView
android:layout_width="match_parent"
android:layout_height="match_parent">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:focusable="true"
android:focusableInTouchMode="true"
android:orientation="vertical">
<android.support.v7.widget.RecyclerView
android:id="@+id/rv_many_item"
android:layout_width="match_parent"
android:layout_height="0dp"
android:layout_weight="1"/>
</LinearLayout>
</android.support.v4.widget.NestedScrollView>
2、重写computeScrollDeltaToGetChildRectOnScreen()方法,让其返回正确的值。
有时候布局比较复杂、上面两个属性不生效,就重写该方法,判断如果“焦点view”是RecyclerView/ListView,就返回0。
二、惯性滑动,即fling失效
网上有很多解决惯性滑动失效的方案,主要是以下两种:
// 方案一:
mRecyclerView.setNestedScrollingEnabled(false);
// 方案二:
mRecyclerView.setLayoutManager(new LinearLayoutManager(this) {
@Override
public boolean canScrollVertically() {
return false;
}
});
// 这两种方案的本质都是一样:禁止RecyclerView的滑动事件,让NestedScrollView来管理滑动。
但是却找不到一篇分析原因的文章(难道大家都是乱试出来的?),下面就从源码入手,分析一下原因所在。惯性滑动肯定是在dispatchTouchEvent或onTouchEvent的ACTION_UP中,我们直接进去找。
RecyclerView的onTouchEvent()方法:
case MotionEvent.ACTION_UP: {
mVelocityTracker.addMovement(vtev);
eventAddedToVelocityTracker = true;
mVelocityTracker.computeCurrentVelocity(1000, mMaxFlingVelocity);
final float xvel = canScrollHorizontally ?
-VelocityTrackerCompat.getXVelocity(mVelocityTracker, mScrollPointerId) : 0;
final float yvel = canScrollVertically ?
-VelocityTrackerCompat.getYVelocity(mVelocityTracker, mScrollPointerId) : 0;
// 前面经过一大堆判断之后,终于执行了fling()方法
if (!((xvel != 0 || yvel != 0) && fling((int) xvel, (int) yvel))) {
setScrollState(SCROLL_STATE_IDLE);
}
resetTouch();
} break;
RecyclerView的fling()方法:
public boolean fling(int velocityX, int velocityY) {
if (mLayout == null) {
Log.e(TAG, "Cannot fling without a LayoutManager set. " +
"Call setLayoutManager with a non-null argument.");
return false;
}
if (mLayoutFrozen) {
return false;
}
final boolean canScrollHorizontal = mLayout.canScrollHorizontally();
// 判断竖直方向上是否能滑动。这个mLayout就是LayoutManager
final boolean canScrollVertical = mLayout.canScrollVertically();
if (!canScrollHorizontal || Math.abs(velocityX) < mMinFlingVelocity) {
velocityX = 0;
}
if (!canScrollVertical || Math.abs(velocityY) < mMinFlingVelocity) {
velocityY = 0;
}
if (velocityX == 0 && velocityY == 0) {
// If we don't have any velocity, return false
return false;
}
if (!dispatchNestedPreFling(velocityX, velocityY)) {
final boolean canScroll = canScrollHorizontal || canScrollVertical;
// 通知父view(即NestedScrollView)调用onNestedFling()方法,参数canScroll告诉父view自己是否消费;
// 如果不消费,父view就会自己处理fling;如果消费了,父view就不会处理了。这就是上面的解决方案能生效的原因
dispatchNestedFling(velocityX, velocityY, canScroll);
if (mOnFlingListener != null && mOnFlingListener.onFling(velocityX, velocityY)) {
return true;
}
if (canScroll) {
velocityX = Math.max(-mMaxFlingVelocity, Math.min(velocityX, mMaxFlingVelocity));
velocityY = Math.max(-mMaxFlingVelocity, Math.min(velocityY, mMaxFlingVelocity));
// 如果能滑动,就启动fling了。mViewFlinger是RecyclerView的内部类,专门处理fling的,不是很懂的可以参考之前那篇讲Scroller的博客
mViewFlinger.fling(velocityX, velocityY);
return true;
}
}
return false;
}
ViewFlinger类的fling()方法:
public void fling(int velocityX, int velocityY) {
setScrollState(SCROLL_STATE_SETTLING);
mLastFlingX = mLastFlingY = 0;
// 调用Scroller的fling()方法,计算目标点的坐标,并记录下来
mScroller.fling(0, 0, velocityX, velocityY,
Integer.MIN_VALUE, Integer.MAX_VALUE, Integer.MIN_VALUE, Integer.MAX_VALUE);
// 启动“动画”
postOnAnimation();
}
void postOnAnimation() {
if (mEatRunOnAnimationRequest) {
mReSchedulePostAnimationCallback = true;
} else {
removeCallbacks(this);
// 参数this是Runable,因为ViewFlinger实现了Runable接口。真正的滑动操作在run()方法里
ViewCompat.postOnAnimation(RecyclerView.this, this);
}
}
ViewFlinger类的run()方法:
// 方法很长,只贴出部分,可以看到里面调用了类似于scrollBy()的方法来进行view的移动
public void run() {
......
......
......
final int x = scroller.getCurrX();
final int y = scroller.getCurrY();
final int dx = x - mLastFlingX;
final int dy = y - mLastFlingY;
int hresult = 0;
int vresult = 0;
mLastFlingX = x;
mLastFlingY = y;
int overscrollX = 0, overscrollY = 0;
if (mAdapter != null) {
eatRequestLayout();
onEnterLayoutOrScroll();
TraceCompat.beginSection(TRACE_SCROLL_TAG);
if (dx != 0) {
hresult = mLayout.scrollHorizontallyBy(dx, mRecycler, mState);
overscrollX = dx - hresult;
}
if (dy != 0) {
// 所有的滑动都是由N次scrollBy()一点一点移动的。mLayout就是LayoutManager,可见,真正的滑动是在LayoutManager里面实现的
// scrollVerticallyBy()返回的就是滑动的距离
vresult = mLayout.scrollVerticallyBy(dy, mRecycler, mState);
overscrollY = dy - vresult;
}
TraceCompat.endSection();
repositionShadowingViews();
}
......
......
......
}
由于RecyclerView、NestedScrollView的方法基本都是缺省、私有的,所以从外部很难跟踪问题,最终在NestedScrollView的onNestedScroll()方法中跟踪到“RecyclerView消费的距离总是0”,所以才导致滑动异常。
现在的研究方向就是:为什么RecyclerView消费的距离总是0?
最终自己写了一个类,把LinearLayoutManager类的代码完全copy过来,修复各种报错信息,然后通过打印log找到了原因。
LinearLayoutManager的scrollVerticallyBy()方法:
// 这个方法返回的值就是RecyclerView消费的距离,总是返回0
@Override
public int scrollVerticallyBy(int dy, RecyclerView.Recycler recycler,
RecyclerView.State state) {
// LinearLayoutManager的方向默认是VERTICAL
if (mOrientation == HORIZONTAL) {
return 0;
}
// 所以是scrollBy()返回了0
return scrollBy(dy, recycler, state);
}
int scrollBy(int dy, RecyclerView.Recycler recycler, RecyclerView.State state) {
// 打印出来dy肯定不为0,childCount也不为0
if (getChildCount() == 0 || dy == 0) {
return 0;
}
mLayoutState.mRecycle = true;
ensureLayoutState();
final int layoutDirection = dy > 0 ? LayoutState.LAYOUT_END : LayoutState.LAYOUT_START;
final int absDy = Math.abs(dy);
updateLayoutState(layoutDirection, absDy, true, state);
// consumed就是消费的距离,fill()方法的作用就是根据一列参数,计算出应该消费的距离
final int consumed = mLayoutState.mScrollingOffset
+ fill(recycler, mLayoutState, state, false);
if (consumed < 0) {
if (DEBUG) {
Log.d(TAG, "Don't have any more elements to scroll");
}
return 0;
}
// 返回值scrolled最终是在这里赋值,由于consumed为0,所以scrolled也为0
final int scrolled = absDy > consumed ? layoutDirection * consumed : dy;
mOrientationHelper.offsetChildren(-scrolled);
if (DEBUG) {
Log.d(TAG, "scroll req: " + dy + " scrolled: " + scrolled);
}
mLayoutState.mLastScrollDelta = scrolled;
// 最终返回值也是0
return scrolled;
}
再看fill()方法:
private int fill(RecyclerView.Recycler recycler, LayoutState layoutState,RecyclerView.State state, boolean stopOnFocusable) {
// 记录滑动前的位置start
final int start = layoutState.mAvailable;
if (layoutState.mScrollingOffset != LayoutState.SCROLLING_OFFSET_NaN) {
if (layoutState.mAvailable < 0) {
layoutState.mScrollingOffset += layoutState.mAvailable;
}
recycleByLayoutState(recycler, layoutState);
}
int remainingSpace = layoutState.mAvailable + layoutState.mExtra;
LayoutChunkResult layoutChunkResult = mLayoutChunkResult;
// 如果是向下滑,layoutState.hasMore(state)就是获取“下面是否还有itemView未加载”;上滑则反之
// layoutState.hasMore(state)总是返回false,while循环进不去
while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {
layoutChunkResult.resetInternal();
layoutChunk(recycler, state, layoutState, layoutChunkResult);
if (layoutChunkResult.mFinished) {
break;
}
layoutState.mOffset += layoutChunkResult.mConsumed * layoutState.mLayoutDirection;
if (!layoutChunkResult.mIgnoreConsumed || mLayoutState.mScrapList != null
|| !state.isPreLayout()) {
// 通过一些列计算,得到消费距离,用当前位置减去消费的距离,得到滑动后的位置
layoutState.mAvailable -= layoutChunkResult.mConsumed;
remainingSpace -= layoutChunkResult.mConsumed;
}
if (layoutState.mScrollingOffset != LayoutState.SCROLLING_OFFSET_NaN) {
layoutState.mScrollingOffset += layoutChunkResult.mConsumed;
if (layoutState.mAvailable < 0) {
layoutState.mScrollingOffset += layoutState.mAvailable;
}
recycleByLayoutState(recycler, layoutState);
}
if (stopOnFocusable && layoutChunkResult.mFocusable) {
break;
}
}
// 滑动开始前的位置减去滑动后的位置,就是滑动的距离
// 由于while循环进不去,所以layoutState.mAvailable的值不会改变,所以结果总是为0
return start - layoutState.mAvailable;
}
// 判断上/下面是否还有itemView未显示,如果还有,就允许滑动,否则就禁止滑动。由此来保证不会滑出界
@Override
boolean hasMore(RecyclerView.State state) {
// 通过打印发现,下滑时,mCurrentPosition的值总是等于itemCount;上滑时,总是等于-1。所以总是返回false
return mCurrentPosition >= 0 && mCurrentPosition < state.getItemCount();
}
那mCurrentPosition为什么会等于itemCount或-1呢?
因为NestedScrollView加载RecyclerView时,无法确定其高度,所以RecyclerView总是把所有item一次性加载完(可以通过打印onCreateViewHolder()发现)。对于屏幕显示来说,只显示了部分item,但对于RecyclerView来说,所有item都处于“显示状态”,所以hasMore()肯定就返回false。
一点警惕:如果需要加载大量item,最好不要用NestedScrollView嵌套RecyclerView,一次性new出大量itemView,可能会导致OOM。