Android中RecyclerView复用错乱的示例分析-创新互联
这篇文章给大家分享的是有关Android中RecyclerView复用错乱的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。
成都创新互联公司是一家集网站建设,爱辉企业网站建设,爱辉品牌网站建设,网站定制,爱辉网站建设报价,网络营销,网络优化,爱辉网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。复用错乱的解决办法
本文的前半部分很简单的,以为关于复用错乱,RecyclerView 已经有他的前辈 ListView 替它踩了很多坑了。虽然他们的复用逻辑是有差异的,例如 ListView 只有两层缓存,但是 RecyclerView 可以理解为有四层;ListView 缓存的单位是 view,而 RecyclerView 缓存的单位是 ViewHolder。但是不管他们复用逻辑的差异如何,终归都是把那个缓存起来的 view 拿过来接着用,所以解决复用错乱的方法是一样的。
RecyclerView 复用导致错乱的原因其实就是拿出来之前的 View 来添加到新 item 上,之前 View 的状态一直保留着,所以也就错乱了。不过解决起来很简单:
首先我们以 adapter 数据的来源分为两大类:
1.当数据来源是同步的
这种情况是最简单的,你就保证当 onBindViewHolder 方法调用的时候,你的 itemview 中每个 view 的状态都有一个默认值。这是什么意思呢?
if ("".equals(artists)) { holder.cbMusicState.setChecked(true); } else { holder.cbMusicState.setChecked(false); }
假设我们的 holder 里面有个 Checkbox 控件,当歌手名为 unknown 时,Checkbox 勾选。注意个时候你一定要加上这个 else 条件,才能保证复用这个 ViewHolder 的时候,Checkbox 的状态不出错。任何控件都一样,总结起来就是你要给每个控件的状态赋一个新的值,替换掉之前的,这样自然不会出现什么复用错乱的问题。
2.当数据的来源是异步的
这种情况也很常见,我们举个栗子,比如你的 ItemView 里面有个 ImageView,每次 onBindViewHolder
的时候,你传入一个 url,等待服务器返回的结果,然后展示在 ImageView 上。这种情况会怎样导致错乱呢?
是这样的,假设我进入了页面,开始为第一个 ImageView 请求图片,但是此刻我下划屏幕,划到了第四个 item,此时第一个 item 已经不可见了,第四个 item 复用了第一个 item 的 imageview,恰好此刻第一个 imageview 的图片结果返回了,就正好展示在了第四个 itemview 上。 这样就发生了图片的错乱。
出现这个问题的原因就是这个 ImageView 和请求的 url 没一一绑定,所以按照这个思路来解决吧:
holder.ivCameraImages.setBackground(R.drawable.place_holder); holder.ivCameraImages.setTag(imageURL); @Override public void handleMessage(Message msg) { super.handleMessage(msg); if (msg.what == MSG_IMAGE) { Bitmap bm = (Bitmap) msg.obj; if (bm != null) { if (TextUtils.equals((String) imageView.getTag(), imageURL)) { imageView.setBackground(new BitmapDrawable(bm)); } } } }
首先在没加载图片之前,给 ImageView 设置一个默认图片,然后通过 setTag 方法,将 ImageView 和 图片的 url 一一对应起来,设置的时候再判断一下,这个 imageview 的 tag 和当时请求的 url,是不是一致的,如果是一致的,再保存。
以上就是复用错乱时两种比较通用的解法,基本上可以覆盖大部分情况。
一个奇怪的问题
这个问题的现象是这样子的:
当 RecyclerView 的条目很少的时候,比如只有六个,将 RecyclerView 从上滑动到下,这个时候是正常的,onBindViewHolder
会调用,不过此时从底部上划的时候,上方的 item 从不可见到可见的这个过程中,onBindViewHolder
并没有调用,这个时候我也就没办法进行一些刷新 item 的操作了。
这个问题的原因是 onBindViewHolder
方法不调用导致的,我在 StackOverflow 上搜索了很多答案,终于找到了一个可以解决我的问题的:
recyclerview-not-recycling-views-if-the-view-count-is-small
(中文资料压根就没有,所以掌握英文搜索是多么的重要)
你可以调用
recyclerView.setItemViewCacheSize(int);
这个 api,去调整 RecyclerView 的复用逻辑和方式来解决 onBindViewHolder
没有调用的这个问题。
但是原理是怎样的呢?作为一名好奇心颇重的程序员,一步步 debug RecyclerView 的源代码,发现了导致这个问题的原因,一起来看看吧。
在上一篇文章中,我们分析了 RecyclerView 的源码,其中复用逻辑的模块,有一个非常重要的核心方法 tryBindViewHolderByDeadline
,这个方法目的就是在 RecyclerView 的层层缓存结构中,取出 ViewHolder。
这里就不再次研究它了,想了解的去看之前的文章,我来描述一下对于这个场景,简化之后的逻辑:
当 RecyclerView 从底部向上滑动的时候,会先后从 mCachedViews 和 mRecyclerPool 中寻找缓存的 ViewHolder。
mCachedViews 和 mRecyclerPool 之间又有什么关系呢?
public void setViewCacheSize(int viewCount) { mRequestedCacheMax = viewCount; updateViewCacheSize(); } void updateViewCacheSize() { int extraCache = mLayout != null ? mLayout.mPrefetchMaxCountObserved : 0; mViewCacheMax = mRequestedCacheMax + extraCache; // first, try the views that can be recycled for (int i = mCachedViews.size() - 1; i >= 0 && mCachedViews.size() > mViewCacheMax; i--) { recycleCachedViewAt(i); } }
当调用 setViewCacheSize
这个方法时,相当于是给 mViewCacheMax 这个变量赋值了, for 循环调用 recycleCachedViewAt 的作用是将 mCachedViews 中缓存的 ViewHolder 放进 RecyclerPool 中。可以看到 for 循环的周期是从 mCachedViews 的最后一个对象直到 mCachedViews.size == mViewCacheMax 这个值时。
也就是可以这么理解, setViewCacheSize
这个方法其实就是为 mCachedViews 集合设置所能持有 ViewHolder 的大数量。
当 setViewCacheSize(0)
时,RecyclerView 想去复用 ViewHolder 时,只能去 RecyclerPool 中去取了,这里就有问题来了,从 RecyclerPool 中取和从 mCachedViews 中取 ViewHolder 中又有什么区别呢?
if (holder == null) { // fallback to pool if (DEBUG) { Log.d(TAG, "tryGetViewHolderForPositionByDeadline(" + position + ") fetching from shared pool"); } holder = getRecycledViewPool().getRecycledView(type); if (holder != null) { holder.resetInternal(); if (FORCE_INVALIDATE_DISPLAY_LIST) { invalidateDisplayListInt(holder); } } }
当从 RecyclerPool 取出 ViewHolder 时,调用了 resetInternal 这个函数的作用是清空一些记录的参数,包括之前记录 ViewHolder 状态的 mFlags。
else if (!holder.isBound() || holder.needsUpdate() || holder.isInvalid()) { if (DEBUG && holder.isRemoved()) { throw new IllegalStateException("Removed holder should be bound and it should" + " come here only in pre-layout. Holder: " + holder); } final int offsetPosition = mAdapterHelper.findPositionOffset(position); bound = tryBindViewHolderByDeadline(holder, offsetPosition, position, deadlineNs); }
代码再往下走的时候,刚刚清空的 flag 参数这个时候就用到了,holder.isBound()
返回 flase,进入 if 判断,调用 tryBindViewHolderByDeadline
进而调用了 onBindViewHolder
。
到这里这个逻辑就描述清楚了,所以设置 setViewCacheSize 来调整 mCachedViews 保存 ViewHolder 的大小,就能解决问题。
当然有些特殊的情况,某些位置就不能调用 onBindViewHolder
,没关系,可以监听 RecyclerView 的滑动,当滑动停止的时候,再调用 notify 刷新下列表也是可以的。
感谢各位的阅读!关于“Android中RecyclerView复用错乱的示例分析”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!
本文标题:Android中RecyclerView复用错乱的示例分析-创新互联
分享路径:http://azwzsj.com/article/dcpdhs.html