记一次RecyclerView卡顿
项目中一个菜品列表用RecyclerView实现，可以拖动调换位置。但是数据项越多的时候拖动就越卡顿了
展示在界面上也就8条数据 按道理不应该卡。
-
用./systrace.py -t 10 sched gfx view wm am app -a com.mwee.myd.xiaosan 分析 发现在onMeasure方法下不停的在 createView 而且耗时非常严重image-20190606170452615.png
-
按理解 拖动的时候也不应该回收view，而且RecyclerView还有自己的缓存机制， 也没有数据更新怎么会不断的去onCreateViewholder呢
我理解的缓存机制 mAttachedScrap:用于缓存暂时detach的viewholder,detach就是和parent剪开关系但是不回去通知windowmanager,recyclerview每次dispatchLayout都会先把子view 一起detach放到mAttachedScrap中，我认为这是因为recyclerview通知改变是先把操作提交到一个队列，然后requestLayout. 在layoutStep1步骤中回去处理列表中的事件去改变viewholder的position 状态等，layoutStep2步骤中根据position会先从mAttachedScrap去加载重新attach到parent。
mCachedViews: 最多缓存3个ViewHolder 。view在上滑下滑过程中离开屏幕会被回收到mCachedViews中
fill方法中每次添加玩一个view 都会去计算是否需要recycleByLayoutState。下次遇到匹配的position就可以被复用啦。 一般我们下滑3个以内再上滑 是不用去bindview的。空间换时间，也不知道3是怎么算得。
RecycledViewPool:当mCachedViews不够用的时候我们就将ViewHolder保存到RecycledViewPool当中
recycleView是根据ViewType去绑定ViewHolder的，而且放倒RecycledViewPool中的ViewHolder是需要经过reset就是使用需要重新bindView了，所以如果两个RecyclerView布局一样是可以共用一个RecycledViewPool的。
回到原来话题 先在在onCreateViewHolder和onBindView中打个日志，发现拖动过程中一直在onCreateViewHolder.
-
接下来debug呗 看看为啥需要一直创建，debug发型 fill的position远远超过了当前屏幕position和数据项保持一致了。那就是fill的判断条件可能出了问题 找到这个地方
while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {满足上面条件remainingSpace>0 表示当前recyclerview还有布局空间，layoutState.hasMore(state)一般是指是否还有数据项。那这个layoutState.mInfinite是啥？这样描述：Used when there is no limit in how many views can be laid out.不限制布局个数。调式发现这个layoutState.mInfinite有时确实为true
-
而这个值的判断是HeightMeasureSpec中Mode 为UNSPECIFIED 高度为0 。看堆栈主要源头是有一个
看下LinearLayout的onMeasure方法片段
final LayoutParams lp = (LayoutParams) child.getLayoutParams(); totalWeight += lp.weight; final boolean useExcessSpace = lp.width == 0 && lp.weight > 0; if (widthMode == MeasureSpec.EXACTLY && useExcessSpace) { // Optimization: don't bother measuring children who are only // laid out using excess space. These views will get measured // later if we have space to distribute. if (isExactly) { mTotalLength += lp.leftMargin + lp.rightMargin; } else { final int totalLength = mTotalLength; mTotalLength = Math.max(totalLength, totalLength + lp.leftMargin + lp.rightMargin); } // Baseline alignment requires to measure widgets to obtain the // baseline offset (in particular for TextViews). The following // defeats the optimization mentioned above. Allow the child to // use as much space as it wants because we can shrink things // later (and re-measure). if (baselineAligned) { final int freeWidthSpec = MeasureSpec.makeSafeMeasureSpec( MeasureSpec.getSize(widthMeasureSpec), MeasureSpec.UNSPECIFIED); final int freeHeightSpec = MeasureSpec.makeSafeMeasureSpec( MeasureSpec.getSize(heightMeasureSpec), MeasureSpec.UNSPECIFIED); child.measure(freeWidthSpec, freeHeightSpec); } else { skippedMeasure = true; }看堆栈我们LinearLayout的子view RelativeLayout useExcessSpace成立，widthMode == MeasureSpec.EXACTLY成立，baselineAligned成立 所以传给RelativeLayout的是一个MeasureSpec.UNSPECIFIED类型的MeasureSpec。
接下来看RelativeLayout处理,其中myHeight在MeasureSpec.UNSPECIFIED时为-1
for (int i = 0; i < count; i++) {
View child = views[i];
if (child.getVisibility() != GONE) {
LayoutParams params = (LayoutParams) child.getLayoutParams();
int[] rules = params.getRules(layoutDirection);
applyHorizontalSizeRules(params, myWidth, rules);
measureChildHorizontal(child, params, myWidth, myHeight);
if (positionChildHorizontal(child, params, myWidth, isWrapContentWidth)) {
offsetHorizontalAxis = true;
}
}
}
最终调用了RecyclerView的measure 这时候HeightMeasureSpec为0
final int childHeightMeasureSpec;
if (myHeight < 0 && !mAllowBrokenMeasureSpecs) {
if (params.height >= 0) {
childHeightMeasureSpec = MeasureSpec.makeMeasureSpec(
params.height, MeasureSpec.EXACTLY);
} else {
// Negative values in a mySize/myWidth/myWidth value in
// RelativeLayout measurement is code for, "we got an
// unspecified mode in the RelativeLayout's measure spec."
// Carry it forward.
childHeightMeasureSpec = MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED);
}
}
child.measure(childWidthMeasureSpec, childHeightMeasureSpec);
导致layoutState.mInfinite为true,二RecyclerView在onMeasure方法中也是会去layout fill的 就导致卡顿了，上面trace图也证明了这一点measure大量耗时
-
解决方法 尝试把高度固定或者把RelativeLayout改为LinearLayout均解决了这个问题。其实这里还有个判断条件需要理一下。
<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="horizontal" android:layout_width="match_parent" android:layout_height="match_parent" android:background="@color/bg" > <RelativeLayout android:layout_width="0dp" android:layout_weight="1" android:layout_height="match_parent"> </RelativeLayout> <RelativeLayout android:layout_width="0dp" android:layout_weight="3" android:layout_height="match_parent"> <android.support.v7.widget.RecyclerView android:id="@+id/rv_list" android:layout_width="match_parent" android:layout_height="match_parent" android:fadingEdge="none"/> </RelativeLayout> </LinearLayout>上述布局便可以复现出问题。
