Android Bitmap 图片框架效果处理对比（精华六）

对比对象: UIL Volley 官方教程中的方法(此系列教程一里介绍的,ImageLoader的处理方法和官方的差不多)

------------------------------------------------------------------------

首先单张图片的压缩处理,也是分析重点

专门撸了一个小demo(结尾会放出下载连接)将对应计算方法copy了出来,然后计算了几十组数据,进行了对比

原图宽高都是一个10000以内的随机整数,限定大小是400 200,然后进行压缩处理,记录了10组数据如下

<ignore_js_op> 

控件缩放类型FIT_INSIDE和CROP在教程三-1的UIL框架分析中有详细说明,这里再简单说下

FIT_INSIDE是默认控件显示类型,图片会完整的显示在控件内,不一定会填满控件

CROP是使图片填充整个控件,图片可能会显示不全

具体效果大家可以在android项目里建一个imageview不设置缩放类型(即FIT_INSIDE效果), 再建一个scaleType为CROP的同大小控件,然后显示同一张图片,就会看出来区别了

官方/volley/imageloader都没有对缩放类型做区别处理,所以不同缩放类型下,最终压缩图片是一个size

结果我们也可以明显看出

官方算法是和UIL的CROP类型时结果一样的,实质上作用是保证压缩后图片宽高都要大于等于限定宽高,

Volley的那种对限定值的特殊处理方式,则实质上最终的效果是让压缩后的图片宽高任意一个大于等于限定宽高即可,则对应UIL的FIT_INSIDE效果

哪种好呢?(只针对图片的压缩处理而言)

UIL我们已经长篇详细的分析过了(教程系列三-1),对于缩放类型的处理是十分准确的,明显是最好的~(这么多人用不是没道理的)

那对比起来,官方的处理和Volley的则各有不足了~

官方=UIL CROP 即官方的处理方法其实更适合于CROP缩放类型的图片显示

然而在处理宽高比差别较大的图片时,如果是FIT_INSIDE显示模式,则会造成压缩图片略大,虽然能保证显示质量,但是浪费小部分内存资源

比如上图中的第一组数据,664 3640的压缩结果,明显和我们所需的400 200差别过大- - 脑补一下大概就是火柴盒跟西瓜刀吧(不是太准确~)

Volley=UIL FIT_INSIDE 则代表Volley更适合默认情况下的图片显示情况了

那么在处理宽高比差别过大的图片时,如果是CROP缩放类型,则压缩大小看起来是差不多了,但实际上显示效果是无法达到预期的,大小我们可以从size数值上看出来,显示效果我还是弄个实际图片大家对比看看吧(可以在文章末尾下载demo项目)

丧心病狂的找了个微博长图实验,项目一共四个ImageView控件,上面俩是Volley,下排是UIL,左边俩是FIT_INSIDE效果,右边则是CROP

而我说的Volley在过大宽高差时,用CROP类型显示无法达到预期质量的效果,就是右上角这个图了,简直就是我不戴眼镜看世界滴样子

对比下,UIL在处理CROP情况时效果十分有保障~

<ignore_js_op> 

上面缺点都有个条件宽高比差别过大,因为大部分情况下,原图的宽高比是比较稳定的,而我们限定值也都是差不多的,大部分情况都是设为一个正方形的限定大小,原图基本也都是接近正方形的矩形~这就解释了为什么大部分的图片框架包括官方教程中都没有专门对不同缩放类型做区分处理,因为一般情况下,即长宽比稳定差别不大的情况下,官方的那种简单处理都是适用滴

参考上面数据我们也可以得出,当原图长宽比和限定长宽比越相近,则两种不同算法(官方和UIL的CROP是一种,Volley和UIL的FIT_INSIDE是另一种)的区别越小,当原图和限定值的长宽比十分相似甚至相等时,那两种算法最终的结果就一样了(比如数据中红色加粗的部分)

而我们看长宽比差别较大的第一组数据和倒数第二组数据,两种算法的差别直接是2^4=16倍~大家有兴趣可以自行尝试,弄几个更大比例的特殊值试一试

------------------------------------------------------------------------

图片色彩样式对比

Volley写死了是RGB_565

ImageLoader没有设置,那应该就是默认的ARGB_8888

UIL提供设置API,默认则也是ARGB_8888

------------------------------------------------------------------------

缓存池对比

Volley只有接口...实例类都没有,不过写起来也很简单

ImageLoader则主要是单强引用,单软引用两种

UIL提供了8种类型,弱和强,单独以及混合的,包括不同的算法

区别就在于软引用和弱引用的不同,这个直接看教程二里面针对不同引用类型的介绍就行了,也可以自行百度搜,其实两者区别不大

强引用部分也都差不多,即使使用了最新的LruCache类,其实看源码我们也会发现内部还是用LinkedHashMap实现的

------------------------------------------------------------------------


综上,肯定是UIL完全胜出了,还有很多拓展功能部分也都是UIL更加强大没跑了
不过Volley框架我们之前也说过了,虽然功能不够完善,但十分适合我们二次开发
ImageLoader吗,稍微简单点,可以当学习源码的小练手来用


------------------------------------------------------------------------

最后滴最后,demo简单介绍下

drawable包下有一个长宽比很大的微博长图,还有一个正常的接近正方形的图,

代码只有一个类,里面把几种压缩算法都贴出来了,测试方法也已经写好,大家可以自行修改数值计算,也可以拷贝一些图片进去看其他比例图片的效果

布局文件对应也只有一个,里面放了4个imageView,俩普通的,俩center_crop的,也就是对应的CROP缩放类型,控件缩放类型和UIL框架缩放类型的对应关系,参考教程三-1的UIL介绍里