记二次RecyclerView卡顿

记一次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>

上述布局便可以复现出问题。

记二次RecyclerView卡顿

记一次RecyclerView卡顿

推荐阅读更多精彩内容