Glide在RecyclerView中出现item错乱解决方案

原因，Glide图片加载是异步的，RecyclerView的Item复用机制会利用已绘制好的Item，因此会出现加载完成后，但Item的position已经改变了，Glide再加载到相应的position的item上面。解决方案是对比控件的Tag，如果用Glide加载则需要在res/value文件夹中新建一个ids.xml文件，设置一个Id，具体做法如下：a

```

if(!TextUtils.isEmpty(item.avatar)) {

ivAvatar.setTag(R.id.image_id, item.avatar)

if(ivAvatar.getTag(R.id.image_id) !=null&&TextUtils.equals(item.avatar, (String) ivAvatar.getTag(R.id.image_id))) {

GlideImgManager.loadCircleHead(mContext, item.avatar, ivAvatar)

}

}

```

聊天群组头像要拼成下图样式，最多显示 5 个头像，虽然我觉得两个人已经不是群组了，但是功能上可以删减人，依然保持群组。

要将多个人头像拼成一个，最初的设想是自定义 View，在 onDraw 里自己将多个 Bitmap 绘制上去。

首先分析这个设计效果，假设整个图片的宽为 width，高为 height：

自定义 View

然后

若在 RecyclerView 中使用，会因复用产生错乱问题，要加 tag，Bitmap 列表取回来后进行对比，这已经不是这个头像拼接本身问题了。

参考 文档 ，这种方式使用起来更优雅，更简洁。

除了 glide 依赖还要添加 annotationProcessor "com.github.bumptech.glide:compiler:$rootProject.glideVersion"

在网上搜到的，说 Target 不直接用 ImageView，用普通的 Target，在 onResourceReady 中手动 setImageDrawable，测试的确有用。

后来发现有崩溃，原因是这个 Target 中宽高没设置，想起过去看 Glide3 的 SimpleTarget 了，Glide4 原理也类似，看源码必须把尺寸传进去，不如直接继承 ViewTarget 了，把 View 传进去，框架自己会监听 View 树的变化获取尺寸。

突然变了设计，多张图片有重叠时，每一张图压着别人，也被别人压着，不能像原来那样第一张图被第二张和最后一张都压着。想想其实有很多中实现方法吧。

现在的思路是再搞一张和原来的大圆一模一样的原图，然后将第一张和最后一张以同样的位置在第二个画布上绘制，将两者做个效果，让第一张图被压的那一角跑到最后一张上面去，然后再将这张画布的图片覆盖到原来的上面。

使用 SRC_ATOP 模式，最后一张图先绘作为 DST(黄色)，然后绘制第一张图作为 SRC(蓝色)，这样第一张图的一角就盖在了最后一张图上面。

修改 MucAvatarDataFetcher

Activity 在重建的时候会恢复其包含的 FragmentManager ，FragmentManager 又会恢复其管理的 Fragment ，同理 Fragment 也会恢复其包含的 FragmentManager，层层递进，直到全部恢复。

本文主要讨论Activity重建的时候如何获取Fragment的。即如下情况：

具体通过四种方法来获取复用Fragment。

下面将对这四种情况分别加以分析说明。

首先来一个总结，不建议使用该方法获取Fragment。理由有如下三点：

getFragments方法获取的是所有已经添加到FragmentManager中的Fragment。但是这个FragmentManager中保存的不只是我们定义的Fragment，还有可能会包含其他用途的Fragment。

Fragment不仅仅是界面的载体，同时它可以用来实现生命周期的监听，因为它的生命周期和Activity是一致的，当我们不好监听Activity的生命周期的时候，就可以使用Fragment来辅助监听。图片加载库Glide和Android Jet Pack中的ViewModel都使用了这种模式。

前段时间就遇到过这样的bug

然后就出现了类型转换异常，FragmentA不能被强制转换成FragmentB。

当时我百思不得其解，为什么会出现这个问题啊，我明明是按照Fragment添加到FragmentManager的顺序去获取Fragment的啊。

直到我将getFragments获取到的Fragment列表打印出来才发现，其中的Fragment顺序和我添加到FragmentManager中的顺序是不一致的。

也就是说因为getFragments中获取到的Fragment包含了你不想要的Fragment，而这些Fragment的初始化时机又是不可预料的，所以就不能通过Fragment列表准确定位你需要的Fragment。

这个情况我没有遇到过，参考文章的作者 怪盗kidou 遇到过，就顺便写上了。

在版本25中Activity是新建的请款下，getFragments返回的是null，然后到了26版本，getFragments返回的就是Collectiions.EmpytList()。。。

这就导致原来基于null判断的程序出现bug。

这个方法是通过Fragment中所在的ViewGroup的Android:id定义的id来查找，适合一个ViewGroup中只存在一个Fragment的情况。

当然，如果一个ViewGroup中有多个Fragment的情况下也是可以使用的，不过这个时候获取的就是最后添加到ViewGroup中的Fragment了。

该方法就是用来处理findFragmentById不适用的情况的。因为是通过Tag来查找Fragment，所以ViewGroup的id也就没用了。

需要注意的地方：

有一种情况下是不能够使用getFragmentById和getFragmentByTag,那就是使用ViewPager管理Fragment的情况。

这种方法是可用的，但是太过麻烦，可以使用fm.putFragment和fm.getFragment来处理这种情况。

这两个方法的使用如下：

可能有朋友会感觉这个和getFragmentByTag那么像呢，好像没什么区别。

重点来了，因为在ViewPager中添加和移除Fragment是由ViewPager控制的，所以像是

这种方法就不能被使用了，既然无法在添加fragment的时候设置tag，那我们就不能够通过tag直接从FragmentManager中的Fragment列表中获取了。

那putFragment和getFragment方法是怎么做到这一点的呢？

我们查看下这两个方法的源码：

通过上述源码，我们可以看出，putFragment将待存储的Fragment的Tag和mIndex作为一组数据存储在bundle中，然后在getFragment方法内先从bundle中取出对应Tag的mIndex，最后根据这个mIndex从mActive中取出对应的Fragment。

mActive是真正存储Fragment的对象，但是我们不能够直接使用Tag从中取出，因为ViewPager是使用mIndex来作为key值存储Fragment的。所以我们只能够退而求其次，将Tag和mIndex联系起来，达到间接使用Tag取出Fragment的效果。

下面是对上述源码及步骤的图形化表示：

注意事项：

参考： 你真的会用Fragment吗？Fragment复用的那些事儿

---