问题描述：

        公司项目有这么一个需求，扫描sdCard或U盘的音频数据，并分类展示出来，当数据量比较大时（2000多条数据以上），显示列表慢和滑动列表会很卡。

问题的寻找过程：

当时想的就是因为数据过多导致页面绘制的时候卡主线程了。

因为我是通过RecyclerView展示数据的，接着就想到一次性加载2000多条数据会卡顿，那我就分批加载，我将2000多条数据按每100条一批，显示到RecyclerView中，然后发现问题依然存在。被这个问题困住了，试了各种分页加载，依然得不到解决。

后来排查在adapter的onCreateViewHolder() 和 onBindViewHolder()中打了个计数的Log，发现2000多条数据，每条数据加载的时候都会调用onCreateViewHolder()和onBindViewHolder()。这就有问题了，根据官方API的说明，RecyclerView只会 create当前显示的Item，其他的未显示的都是通过ViewHolder的复用来显示的，我想我已经发现问题所在了。

然后我就想是不是我adapter写的有问题呢 ，经过和其他页面RecyclerView 的adapter的对比，却发现并没有什么不同，这让我又开始苦恼起来。

经过和其他页面的一步步的对比，最终发现原来是activity中的布局文件中，RecyclerView 的父布局使用了android:layout_weight百分比例属性设置宽度，导致RecyclerView 的每一条数据都会创建一个Item，在数据量小的时候发现不了，等数据量达到一定程度的时候就会导致由于创建的View过多，程序运行过程中产生了大量的垃圾数据，所以才会导致进程不断的发生GC，因而影响了UI主线程。

出现问题的布局文件：

<LinearLayout

       android:layout_width="0dp"

        android:layout_height="match_parent"

        android:layout_weight="1">

                   <RecyclerView

                        android:layout_width="match_parent"            

                        android:layout_height="match_parent"        />

  </LinearLayout>

解决办法：

1、子布局和父布局的宽度和高度不使用layout_weight设置百分比相对宽高，因此去掉此属性后，问题就解决了。

2、经过百度发现

//设置 这个可以避免以上问题 但也意味着失去了本身设计用来提供支持WRAP_CONTENT的功能了mRecyclerView.getLayoutManager().setAutoMeasureEnabled(false);

貌似也能解决，不过我还没有试过。