问题背景
在开发中我们经常会遇到需要ScrollView嵌套RecyclerView的情况，例如美团商家首页这样式的：
忽略其细节的交互，美团外卖商家首页大致可以抽象成两部分：
- 顶部的商家介绍（我们姑且称之为Header）
- 底部的商品列表（我们姑且称之为Content）
如果对Android开发规范不太了解的新手，布局大概会这样实现：
<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical">
<TextView
android:padding="15dp"
android:layout_width="match_parent"
android:layout_height="200dp"
android:background="@color/colorAccent"
android:gravity="center"
android:text="我是商家介绍，我们家的饭贼好吃，优惠还贼多，买到就是赚到"
android:textColor="#fff"
android:textSize="20dp" />
<android.support.v7.widget.RecyclerView
android:id="@+id/recyclerView"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:background="@color/design_default_color_primary"/>
</LinearLayout>
</ScrollView>
问题出现
上面的布局看起来好像没什么毛病，我们运行一下看看效果：
看到上图我相信大部分的内心是崩溃的：这尼玛什么鬼，为什么Header不会跟随着Content一起滑动呢？说好的滚动视图ScrollView，为什么你就不“滚”了呢？
Header为什么不能滚动了
很简单，我们先来看看官方对于ScrollView是怎么定义的：
/**
* A view group that allows the view hierarchy placed within it to be scrolled.
* 一个允许内部视图层次滚动的视图组。
* Scroll view may have only one direct child placed within it.
* ScrollView 仅可包含一个直接子View
* ...此处省略不相关的注释...
*/
从注释我们能明显看出来，官方对于ScrollView最言简意赅的定位就是可以使其内部布局滚动的布局。
我们再接着看一下RecyclerView的定位：
/**
* A flexible view for providing a limited window into a large data set.
* 一种灵活的视图，用于在有限的窗口展示大量的数据。
*/
在有限的窗口展示大量的数据，说白了，就是以滚动的方式，使用有限的空间展示大量的数据(这里的“有限”很重要，我们下面会用到）。
那么问题就来了：两个视图都能滚动，当我们的手指在屏幕上滑动的时候，Android系统并不知道我们想要哪个视图滚动起来，这就是我们常说的滑动冲突。
除此之外，
ScrollView嵌套ListView时，会疯狂调用Adapter中的getView()方法，将ListView所有的item加载到内存中，消耗大量的内存和cpu资源，引起界面卡顿。这也就是为什么《阿里巴巴Android开发手册》中禁止ScrollView嵌套ListView/GridView/ExpandableListView。
滑动冲突的解决
现在解决滑动冲突的方案主要有两个，其一：基于传统的事件分发机制；其二：使用NestedScrollingChild & NestedScrollingParent。
第一种方案网上相关教程有很多，这里就不再赘述。关于NestedScrollingChild与NestedScrollingParent的用法推荐学习鸿洋大大的博客：Android NestedScrolling机制完全解析 带你玩转嵌套滑动。
由于传统事件分发机制的缺陷（父布局拦截消费滑动事件后无法继续传递给子View），所以我们这里更推荐第二种方式解决滑动冲突。
当然，如果只是为了解决这里遇到的问题，我们大可不必从头研究NestedScrollingParent与NestedScrollingChild的用法，因为Android内置的许多控件已经实现了这两个接口，这其中就包括了我们接下来要提到的NestedScrollView.作为日常开发中的高频控件，RecyclerView当然也实现了这一机制。
换上NestedScrollView试试？
对于NestedScrollView，官方的定义是这样的：
/**
* NestedScrollView is just like {@link android.widget.ScrollView},
* NestedScrollView与ScrollView类似
* but it supports acting as both a nested scrolling parent and child on both new and old versions of Android.
* 但它支持在Android的新旧版本上同时充当嵌套滚动的父视图和子视图。
* Nested scrolling is enabled by default.
* 默认情况下启用嵌套滚动。
*/
看起来NestedScrollView似乎能够完美解决我们遇到的困扰，那我们不妨把上面的根布局换成NestedScrollView试一下:
<android.support.v4.widget.NestedScrollView
xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical">
<TextView
android:padding="15dp"
android:layout_width="match_parent"
android:layout_height="200dp"
android:background="@color/colorAccent"
android:gravity="center"
android:text="我是商家介绍，我们家的饭贼好吃，优惠还贼多，买到就是赚到"
android:textColor="#fff"
android:textSize="20dp" />
<android.support.v7.widget.RecyclerView
android:id="@+id/recyclerView"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:background="@color/design_default_color_primary"/>
</LinearLayout>
</android.support.v4.widget.NestedScrollView>
运行起来看下效果：
鼓掌👏撒花🎉，看起来我们成功解决了问题。真的是这样么？
新问题出现了
我们都知道，RecyclerView 是需要结合 Adapter来使用的，Adapter中有几个关键方法：
- onViewAttachedToWindow
- onCreateViewHolder
- onBindViewHolder
...
其中，关于onViewAttachedToWindow方法的调用，源码中是这么说明的：
/**
* Called when a view created by this adapter has been attached to a window.
* 当Adapter通过onCreateViewHolder方法创建的视图被附加到窗口时调用。
*/
也就是说，当RecyclerView中的视图滚动到屏幕我们可以看到的时候，就会调用该方法。我们复写该方法，打印出Log，看下NestedScrollView嵌套下的RecyclerView的onViewAttachedToWindow()方法的调用情况：
override fun onViewAttachedToWindow(holder: ViewHolder) {
super.onViewAttachedToWindow(holder)
Log.e(TAG, "onViewAttachedToWindow:" +holder.tvPosition.text.toString())
}
override fun getItemCount(): Int {
return 50
}
调用情况如下：
2019-09-06 17:59:02.161 24351-24351/com.vision.advancedui E/MyAdapter: onViewAttachedToWindow:Position：0
2019-09-06 17:59:02.165 24351-24351/com.vision.advancedui E/MyAdapter: onViewAttachedToWindow:Position：1
2019-09-06 17:59:02.168 24351-24351/com.vision.advancedui E/MyAdapter: onViewAttachedToWindow:Position：2
2019-09-06 17:59:02.171 24351-24351/com.vision.advancedui E/MyAdapter: onViewAttachedToWindow:Position：3
......
此处省略45条相似log
......
2019-09-06 17:59:02.304 24351-24351/com.vision.advancedui E/MyAdapter: onViewAttachedToWindow:Position：49
通过日志，我们可以清晰的看到，RecyclerView 几乎一瞬间加载完了所有的（这里为50个）item，和Google官方描述的“按需加载”完全不同，是Google注释描述的不对么？
包括《阿里巴巴Android开发规范》里，也有这样的用法示例，并标注为了“正确“用法。究竟是哪里出了问题呢？
找到问题的根本
我们上文提到了，Google对于RecyclerView的定位是：在有限的窗口展示大量的数据，我们很容易想到，会不会是RecyclerView的高度测量出错了？
View的绘制流程
相信大部分人都知道Android大体的绘制流程（把大象装冰箱，总共分几步？）：
- measure
- layout
- draw
映射到我们平常自定义View中的方法就是onMeasure、onLayout、onDraw三个方法，对于继承自ViewGroup的视图，除了要确定自身的大小外，还要帮助子View测量，确定他们的大小，对此，ViewGroup提供了一个静态方法getChildMeasureSpec:
/**
* Does the hard part of measureChildren: figuring out the MeasureSpec to
* pass to a particular child. This method figures out the right MeasureSpec
* for one dimension (height or width) of one child view.
*
* The goal is to combine information from our MeasureSpec with the
* LayoutParams of the child to get the best possible results. For example,
* if the this view knows its size (because its MeasureSpec has a mode of
* EXACTLY), and the child has indicated in its LayoutParams that it wants
* to be the same size as the parent, the parent should ask the child to
* layout given an exact size.
*
* @param spec The requirements for this view
* @param padding The padding of this view for the current dimension and
* margins, if applicable
* @param childDimension How big the child wants to be in the current
* dimension
* @return a MeasureSpec integer for the child
*/
public static int getChildMeasureSpec(int spec, int padding, int childDimension) {
int specMode = MeasureSpec.getMode(spec);
int specSize = MeasureSpec.getSize(spec);
int size = Math.max(0, specSize - padding);
int resultSize = 0;
int resultMode = 0;
switch (specMode) {
// Parent has imposed an exact size on us
case MeasureSpec.EXACTLY:
if (childDimension >= 0) {
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size. So be it.
resultSize = size;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size. It can't be
// bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
}
break;
// Parent has imposed a maximum size on us
case MeasureSpec.AT_MOST:
if (childDimension >= 0) {
// Child wants a specific size... so be it
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size, but our size is not fixed.
// Constrain child to not be bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size. It can't be
// bigger than us.
resultSize = size;
resultMode = MeasureSpec.AT_MOST;
}
break;
// Parent asked to see how big we want to be
case MeasureSpec.UNSPECIFIED:
if (childDimension >= 0) {
// Child wants a specific size... let him have it
resultSize = childDimension;
resultMode = MeasureSpec.EXACTLY;
} else if (childDimension == LayoutParams.MATCH_PARENT) {
// Child wants to be our size... find out how big it should
// be
resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
resultMode = MeasureSpec.UNSPECIFIED;
} else if (childDimension == LayoutParams.WRAP_CONTENT) {
// Child wants to determine its own size.... find out how
// big it should be
resultSize = View.sUseZeroUnspecifiedMeasureSpec ? 0 : size;
resultMode = MeasureSpec.UNSPECIFIED;
}
break;
}
//noinspection ResourceType
return MeasureSpec.makeMeasureSpec(resultSize, resultMode);
}
该方法返回一个MeasureSpec，关于MeasureSpce，翻译成中文即为测量规格，它是一个32位的int类型，高2位代表测量模式，低30位代表测量大小。网上关于它的介绍有很多，这里就不展开讲了。我们这里只要知道，测量模式有3种：
- UNSPECIFIED 未指明模式 父布局不限制子布局的大小，对其不做任何限制。
- EXACTLY 精确模式 父布局可以确定子布局的最终大小。
- AT_MOST 至多模式 父布局确定不了子布局的最终大小，但是子布局的大小不能超过父布局给出的大小。
总结成表格就是这样的（借用任玉刚大佬的图）：
那这个方法返回的MeasureSpec参数子View又是在哪里用到的呢？
答案就是ViewGroup在测量子View的时候，会调用measureChild将getChildMeasureSpec传递给子View的measure方法，measure方法会继续调用我们自定义View时常用到的onMeasure(int widthMeasureSpec, int heightMeasureSpec)方法，这里的widthMeasureSpec与heightMeasureSpec
参数就是父布局传递过来的。我们来看下View类中的onMeasure方法：
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
setMeasuredDimension(getDefaultSize(getSuggestedMinimumWidth(), widthMeasureSpec),
getDefaultSize(getSuggestedMinimumHeight(), heightMeasureSpec));
}
我们可以认为，调用setMeasuredDimension方法就标志着子View完成了测量，其高度和宽度也就随之确定了下来。通过不断的递归循环这个流程就能完成最终的测量。
RecyclerView的测量出现问题了么？
回到我们这个问题，通过以上View测量流程的回顾，我们可以确定：RecyclerView的高度是由NestedScrollView中传递给RecyclerView中的MeasureSpec参数和RecyclerView中的onMeasure两处决定的
我们先来看看NestedScrollView中传递给RecyclerView中的MeasureSpec参数，在NestedScrollView的measureChild方法中是这么写的：
protected void measureChild(View child, int parentWidthMeasureSpec,
int parentHeightMeasureSpec) {
ViewGroup.LayoutParams lp = child.getLayoutParams();
int childWidthMeasureSpec;
int childHeightMeasureSpec;
childWidthMeasureSpec = getChildMeasureSpec(parentWidthMeasureSpec, getPaddingLeft()
+ getPaddingRight(), lp.width);
childHeightMeasureSpec = MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED);
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
}
我们可以看到，传递给RecyclerView关于高度的测量模式是UNSPECIFIED。
接下来看看RecyclerView中的onMeasure()：
protected void onMeasure(int widthSpec, int heightSpec) {
if (mLayout == null) {
defaultOnMeasure(widthSpec, heightSpec);
return;
}
if (mLayout.mAutoMeasure) {
final int widthMode = MeasureSpec.getMode(widthSpec);
final int heightMode = MeasureSpec.getMode(heightSpec);
final boolean skipMeasure = widthMode == MeasureSpec.EXACTLY
&& heightMode == MeasureSpec.EXACTLY;
mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec);
if (skipMeasure || mAdapter == null) {
return;
}
if (mState.mLayoutStep == State.STEP_START) {
dispatchLayoutStep1();
}
// set dimensions in 2nd step. Pre-layout should happen with old dimensions for
// consistency
mLayout.setMeasureSpecs(widthSpec, heightSpec);
mState.mIsMeasuring = true;
dispatchLayoutStep2();
// now we can get the width and height from the children.
// 这行代码是重点
mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec);
// if RecyclerView has non-exact width and height and if there is at least one child
// which also has non-exact width & height, we have to re-measure.
if (mLayout.shouldMeasureTwice()) {
mLayout.setMeasureSpecs(
MeasureSpec.makeMeasureSpec(getMeasuredWidth(), MeasureSpec.EXACTLY),
MeasureSpec.makeMeasureSpec(getMeasuredHeight(), MeasureSpec.EXACTLY));
mState.mIsMeasuring = true;
dispatchLayoutStep2();
// now we can get the width and height from the children.
mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec);
}
} else {
if (mHasFixedSize) {
mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec);
return;
}
// custom onMeasure
if (mAdapterUpdateDuringMeasure) {
eatRequestLayout();
onEnterLayoutOrScroll();
processAdapterUpdatesAndSetAnimationFlags();
onExitLayoutOrScroll();
if (mState.mRunPredictiveAnimations) {
mState.mInPreLayout = true;
} else {
// consume remaining updates to provide a consistent state with the layout pass.
mAdapterHelper.consumeUpdatesInOnePass();
mState.mInPreLayout = false;
}
mAdapterUpdateDuringMeasure = false;
resumeRequestLayout(false);
}
if (mAdapter != null) {
mState.mItemCount = mAdapter.getItemCount();
} else {
mState.mItemCount = 0;
}
eatRequestLayout();
mLayout.onMeasure(mRecycler, mState, widthSpec, heightSpec);
resumeRequestLayout(false);
mState.mInPreLayout = false; // clear
}
}
这块代码的逻辑还是很清晰的，在mAutoMeasure属性为true时，除了RecyclerView没有精确的宽度和高度 + 至少有一个孩子也有不精确的宽度和高度的时候需要测量两次的时候，高度的测量模式为EXACTLY，其余都是调用mLayout.setMeasuredDimensionFromChildren(widthSpec, heightSpec)来确定RecyclerView的大小。
关于mAutoMeasure属性什么时候为true，源码里的注释是这么说的：
/**
* Defines whether the layout should be measured by the RecyclerView or the LayoutManager
* wants to handle the layout measurements itself.
* <p>
* This method is usually called by the LayoutManager with value {@code true} if it wants
* to support WRAP_CONTENT. If you are using a public LayoutManager but want to customize
* the measurement logic, you can call this method with {@code false} and override
* {@link LayoutManager#onMeasure(int, int)} to implement your custom measurement logic.
* <p>
* AutoMeasure is a convenience mechanism for LayoutManagers to easily wrap their content or
* handle various specs provided by the RecyclerView's parent.
* It works by calling {@link LayoutManager#onLayoutChildren(Recycler, State)} during an
* {@link RecyclerView#onMeasure(int, int)} call, then calculating desired dimensions based
* on children's positions. It does this while supporting all existing animation
* capabilities of the RecyclerView.
知道你们的英语和我也是半斤八两，所以这里用大白话翻译一下，中心意思就是：**如果搭配RecyclerView的LayoutManager支持WRAP_CONTENT的属性时，这个值就应该为true。
看到这里我相信你们又该有疑问了：
都有哪些LayoutManager支持WRAP_CONTENT属性呢？源码注释是这么说的：
/**
* AutoMeasure works as follows:
* <ol>
* <li>LayoutManager should call {@code setAutoMeasureEnabled(true)} to enable it. All of
* the framework LayoutManagers use {@code auto-measure}.</li>
*/
意思就是所用Android提供的原生的LayoutManager的mAutoMeasure属性都为true。
我们再来看下setMeasuredDimensionFromChildren方法。
void setMeasuredDimensionFromChildren(int widthSpec, int heightSpec) {
final int count = getChildCount();
if (count == 0) {
mRecyclerView.defaultOnMeasure(widthSpec, heightSpec);
return;
}
int minX = Integer.MAX_VALUE;
int minY = Integer.MAX_VALUE;
int maxX = Integer.MIN_VALUE;
int maxY = Integer.MIN_VALUE;
for (int i = 0; i < count; i++) {
View child = getChildAt(i);
final Rect bounds = mRecyclerView.mTempRect;
getDecoratedBoundsWithMargins(child, bounds);
if (bounds.left < minX) {
minX = bounds.left;
}
if (bounds.right > maxX) {
maxX = bounds.right;
}
if (bounds.top < minY) {
minY = bounds.top;
}
if (bounds.bottom > maxY) {
maxY = bounds.bottom;
}
}
// 遍历RecyclerView的所有子View，将其left、top、right、bottom四个值赋值给mTempRect
mRecyclerView.mTempRect.set(minX, minY, maxX, maxY);
// 真正确定RecyclerView高度的代码
setMeasuredDimension(mRecyclerView.mTempRect, widthSpec, heightSpec);
}
看来最后还是要看下setMeasuredDimension方法：
public void setMeasuredDimension(Rect childrenBounds, int wSpec, int hSpec) {
int usedWidth = childrenBounds.width() + getPaddingLeft() + getPaddingRight();
// 子View的高度：padding + height
int usedHeight = childrenBounds.height() + getPaddingTop() + getPaddingBottom();
int width = chooseSize(wSpec, usedWidth, getMinimumWidth());
// 看起来chooseSize方法是关键了
int height = chooseSize(hSpec, usedHeight, getMinimumHeight());
// 调用该方法即标志着测量的结束
setMeasuredDimension(width, height);
}
最终，我们定位到：RecyclerView高度的确定重点依靠chooseSize方法，我们来看看：
public static int chooseSize(int spec, int desired, int min) {
final int mode = View.MeasureSpec.getMode(spec);
final int size = View.MeasureSpec.getSize(spec);
switch (mode) {
case View.MeasureSpec.EXACTLY:
return size;
case View.MeasureSpec.AT_MOST:
return Math.min(size, Math.max(desired, min));
case View.MeasureSpec.UNSPECIFIED:
default:
// 这里的desired便是setMeasuredDimension中的子View的高度
return Math.max(desired, min);
}
}
这里我们又发现了熟悉的老朋友MeasureSpec，并且这里我们看到了测量模式为UNSPECIFIED的情况下RecyclerView的处理：返回了RecyclerView中子View的高度与最小值两者之间的最大值。
这也就是我们上面介绍的
UNSPECIFIED的意义： 不对布局大小做限制，即你想要多大就多大。最终RecyclerView的高度就是所有子View的高度了。
问题找到了
通过上面的探索，我相信在坐的各位应该很清楚问题的原因了：NestedScrollView传递给子View的测量模式为UNSPECIFIED，RecyclerView在UNSPECIFIED的测量模式下，会不限制自身的高度，即RecyclerView的窗口高度将会变成所有item高度累加后加上paddding的高度。因此，表现出来就是item一次性全部加载完成。
这样做在RecyclerView的item数量较少的时候可能没什么问题，但是如果item数量比较多，随之带来的性能问题就会很严重。
所以这里我斗胆发出不一样的声音：禁止使用
NestedScrollView嵌套RecyclerView。
这种布局该怎么实现
推荐使用RecyclerView的多样式布局实现，毕竟RecyclerView自带滑动，没必要外层套一个ScrollerView或者NestedScrollView。或者使用CoordinatorLayout布局，玩出更多花样～
写在最后
这篇文章发出来之前，我的内心也是充满忐忑的，毕竟开始接触Android的时候，我也是觉得《阿里巴巴Android开发手册》是不可能错的。没想到文章的反响会这么大，针对评论里提的比较多的话题这里做一个统一的回复：
Q: RecyclerView的高度不使用WRAP_CONTENT而是使用特定的值(比如200dp)是不是就没有这个问题了？
A：答案是肯定的，通过任玉刚大佬总结的表我们也可以知道：只有当Parent的测量模式为UNSPECIFIED、子View的layoutparams中的高度设定为WRAP_CONTENT或者MATCH_PARENT时，子View的测量模式才为UNSPECIFIED。
Q: 《阿里巴巴Android开发手册》中并不是倡导大家使用NestedScrollView嵌套RecyclerView，而是提倡大家使用NestedScrollView嵌套RecyclerView的方案替换ScrollView嵌套RecyclerView的方案。
A：不排除这种情况，可是NestedScrollView嵌套RecyclerView确实会有问题，除了对性能的影响外，如果项目中在onAttachViewToWindow中有其他操作（比如曝光）就会影响该操作的准确程度了，这点《阿里巴巴Android开发手册》没有提到，这篇文章的初衷也只是让大家对NestedScrollView嵌套RecyclerView的缺点有一个具体的认知，而且，我个人对于不分情况的使用NestedScrollView嵌套RecyclerView并不认同。
Q: RecyclerView的数据量小的时候，可以使用NestedScrollView嵌套RecyclerView么？
A：RecyclerView数量可控的情况下，使用NestedScrollView嵌套RecyclerView可能确实不会有性能上的问题，如果在Adapter中没有对onAttachViewToWindow方法做任何扩展，也确实没有其他的影响。但是站在个人立场下我还是不推荐这么做：RecyclerView本身支持滑动，没有必要在外层嵌套NestedScrollView，NestedScrollView嵌套RecyclerView的方案除了开发的时候节省了些许时间外其他没有一点好处。当然，写这篇文章也不是就要求大家一定按照这样的方式去实现，毕竟别人说的再好，不一定适合你的项目。
最后，个人始终觉得《阿里巴巴Android开发手册》是一本好手册，上面确实提供了很多Android开发的开发者注意不到的地方，个人也从中获益匪浅，这片文章也只是针对其中的一点谈了一些自己不一样的理解，毕竟开源平台“百家争鸣”。
最后的最后，谢谢你们喜欢我的文章，不胜感激。
