当Glide搞不定GIF

问题

使用Glide加载图片Glide.with(context).diskCacheStrategy(DiskCacheStrategy.ALL).into(imageVIew)
注意使用了DiskCacheStrategy.ALL
当展示的图片是GIF的时候，会展示很慢，即使是本地有的图片，也经常会显示点位图较长时间才能展示出GIF。
还有一个条件，就是gif要展示的大小与图片的大小不一致，需要Glide进行缩放。
重现问题方法：加载一个gif，使用缓存结果的磁盘缓存策略，就会很慢，如果已经成功加载过图片，可以将缓存的结果删除一下尝试再次重现。

解决

• 加载的时候如果可以区分是gif或者是普通图片，可以将GIF加载设置diskCacheStrategy为Source或者None。
• 实际上经常加载网络的图片，是通过CDN下载的，只有一个图片的Key，在下载完成之前并不知道这是一个普通图片还是GIF，所以想如果能将GIF的图片全部都使用diskCacheStrategy为Source或者None是不可行的（这样会影响普通图片的展示）。我们可以hook住GIF在encode的这一步，直接返回false，就跳过了缓存。Glide在构造完Glide对象前后都会向我们回调，我们在构造完成glide对象之后替换掉他的encoder对象，encode方法直接返回false。下面分析原因，先把解决代码列出来。

    @Override
    public void registerComponents(Context context, Glide glide) {
        ResourceEncoder gifEncoder = new ResourceEncoder() {
            @Override
            public boolean encode(Object data, OutputStream os) {
                return false;
            }
            @Override
            public String getId() {
                return "";
            }
        };

        try {
            DataLoadProviderRegistry dataLoadProviderRegistry =
                (DataLoadProviderRegistry) ReflectionUtil.getValue(glide, "dataLoadProviderRegistry");
            if (dataLoadProviderRegistry == null) {
                return;
            }
            DataLoadProvider dataLoadProvider =
                dataLoadProviderRegistry.get(ImageVideoWrapper.class, GifBitmapWrapper.class);
            if (dataLoadProvider instanceof ImageVideoGifDrawableLoadProvider) {
                ResourceEncoder encoder = dataLoadProvider.getEncoder();
                if (encoder instanceof GifBitmapWrapperResourceEncoder) {
                    ReflectionUtil.setValue(encoder, "gifEncoder", gifEncoder);
                }
            }
        } catch (Exception e) {
            Log.e("ImageModule", "set gif encoder fail" + e);
        }
    } 

原因

查看源码发现glide会对gif的每一帧变换的结果进行缓存，重新组成GIF保存下来，实验的是一个2M，124帧的GIF，图片被放大了3倍，Glide变换后的GIF有54M。
因为问题出在了encode的时候，所以只分析这一部分
在DecodeJob中，拿到源图片之后会进行transform，然后将结果缓存起来

变换并存储

可以看到如果我们不设置缓存result的话就不会存储，就不会有问题，将encoder和转换之后的resource都传给了writer

判断缓存策略，构造writer进行缓存

在Writer的write方法就是将图片写到DiskLRUCache中

使用Encoder进行重新编码再存储

此时的encoder是GifBitmapWrapperResourceEncoder对象，看它的encode方法，第一次decode GIF的时候会走else分支

GIF的EncoderWrapper

上面的gifEncoder是GifResourceEncoder的对象，可以看到重新解析了GIF，实际上之前已经解析过一遍了），对每一帧都要进行变换，encoder的addFrame对第一帧进行了存储。

真正对GIF重新编码的地方

还好Glide有bitmap池，内存不会抖动，不过想想如果图片有个100多帧甚至几百帧，这个过程肯定是耗时的，而且我们从前面的transform开始到encode都是同步调用，不存储完成是无法走下去继续展示的。如果不对图片进行缩放的话不用走这个encode，也就不会慢。

上面的代码我们也可以看到最终使用了gifEncoder这个成员，我们只要将GifBitmapWrapperResourceEncoder这个成员换掉就可以了。
而这个encoder是构造glide的时候就已经设置进去了，并且不会再更改，所以是我们理想的hook点

Glide构造

注意

使用glide3.7
因为使用了反射，要对反射的类进行keep