下图是一个客户端图片加载模块常见的处理流程。
imagepipeline.png本文以UniversalImageLoader为例分析了这一流程,然后分析了Fresco的优势和问题,最终推荐大家使用Glide。
从UniversalImageLoader分析图片加载中需要处理的问题
网络
主要用于下载网络图片,在UIL中是将图片地址变为InputStream。UIL支持多种类型来源的图片显示,包括:
- 网络
- 文件
- Uri资源(如果是视频,会找到缩略图显示)
- assets
- drawable
缓存
- UIL使用两级缓存:磁盘缓存图片文件、内存缓存Bitmap
- UIL已经实现了多种缓存策略,但一般都使用LRU缓存
- UIL可以指定图片缓存的路径,和缓存文件名的生成规则
- 需要自己确定缓存的大小,确定内存缓存的大小尤其重要
- 通过
ActivityManager#getMemoryClass
或Runtime.getRuntime().maxMemory()
获得单个应用的最大内存(前者单位为MB,后者单位为B),一般最多划分1/4的最大内存,否则容易导致OOM。 - 图片较多,大图较多的应用,需要使用较大的缓存,提高缓存的命中率
- 内存也不宜太小,最少应该能缓存2~3个屏幕大小的Bitmap
- 通过
解码
- 要按需解码,否则会造成内存的浪费,主要通过
options.inJustDecodeBounds
进行预解析 - ImageAware可以帮助控制解码图片的大小,ImageViewAware就是对ImageView的一个封装
- 注意照片方向Exif,避免图片错误旋转
显示
实现接口BitmapDisplayer可以自定义显示效果,已实现的包括:带描边的圆形、渐入、圆角矩形(不能四个角分别指定)等。
某些设计可能会出现两个角圆角、另外两个直角的特殊裁剪模式。自己实现这类Displayer时,不要生成一个新的Bitmap,定义一个Drawable会更高效。因为生成新的Bitmap会引起内存分配和回收,从而使GC更加频繁,而Drawable只是在绘制时会使用很少的计算资源。可以参考源码中RoundedBitmapDisplayer。
多线程
图片的下载和解码都需要再后台线程中处理,而且为了提高效率,一般都使用多个线程分别进行解码和网络请求。
共有三个Executor,分别用于
- 分发任务
- 处理已缓存图片
- 处理未缓存图片
已缓存的图片主要占用计算资源,未缓存的图片则主要占用网络资源,所以不应该在一个Executor中竞争。可以分别指定Executor的线程数量,UIL默认为3个。
监听
UIL向外提供了两类监听:ImageLoadingListener和ImageLoadingProgressListener
PauseOnScrollListener主要用于,在列表滚动时暂停图片加载,但在现在的RecyclerView中无法使用。需要自己使用ImageLoader#pause
和ImageLoader#resume
了解了UIL是如何处理图片加载的问题之后,其他的第三方库也都是大同小异,下面再介绍下Fresco和Glide。
Fresco的优势和问题
Fresco在解决图片加载问题上的思路和其他框架有很大的不同。它最大的问题有两个:
- 不能直接使用ImageView:这个问题对于老项目的重构几乎是致命的。
- 需要指定宽高:指定宽高对于图片加载其实是一件好事,但在加载网络图片的时候需要服务端告知原图的尺寸,才能帮助客户端实现更好的体验。
相比UIL,它的优点主要包括:
- 5.0以下的系统上,使用ASHMEM,不会占用Java堆内容
- 多一级未解码图片的内存缓存,减少文件IO(很多Android机器使用1年之后变慢,很大的原因就是IO变慢了,所以这一优化的效果还是很显著的)
- 支持多图请求,可以在大图显示之前展现缩略图
- 支持Gif动画和渐进式JPEG(图片还未下载完成的时候就可以先显示一部分)
更多关于Fresco的特点可以参考Android图片加载开源库深度推荐,安利Fresco
缓存和网络:Image Pipeline
在5.0系统以下,Image Pipeline 使用 pinned purgeables 将Bitmap数据避开Java堆内存,存在ASHMEM中。这要求图片不使用时,要显式地释放内存。SimpleDraweeView自动处理了这个释放过程,所以没有特殊情况,尽量使用SimpleDraweeView。
显示
修改图片的显示效果需要使用DraweeHolder,它不仅能控制图片的显示,还可以处理View的Touch事件。默认支持圆角和圆形。
另一个控制图片显示的方法是在Postprocessor
中修改Bitmap,但效率很低。
监听
- ControllerListener:监听图片显示的过程
- RequestListener:监听图片获取的过程
Glide是个不错的选择
优点
- 支持本地Video
- 分别控制每次请求的优先级
- 支持缩略图
- 可直接更新AppWidget和Notification中的图片
- 自定义图片转换效果,还可使用GPU转换(使用GPU处理图片变换,并保持到缓存文件中,在Demo中可以看到GPU变换的10种特效)
- 定义加载动画
- 很方便的使用图片裁剪服务
- 使用Bitmap回收池,减少系统gc
可参考Glide相关文章了解怎么通过自定义的GlideModule优化加载的图片。本文也提供给了参考代码,在代码中引入七牛裁图服务,同时也可体验10种GPU变化的特效。
关于Transformation和BitmapImageViewTarget的使用
-
Transformation#transform
:在缓存前对图片进行处理,处理之后的图片才会进行缓存。处理图片的过程中会产生额外的内存消耗,处理后的图片会占据独立的缓存空间。但第二次使用的时候,不再需要处理,直接从缓存中读取。 -
BitmapImageViewTarget#setResource
:控制图片的显示逻辑,每次显示的时候都会处理。因此在setResource中应该定义特殊的Drawable来控制显示效果,而不应该对Bitmap进行处理。(Bitmap的频繁生成和回收会导致gc;Drawable是在绘制的时候,通过Paint设置特殊的绘制效果,不会产生新的Bitmap)
关于Bitmap的回收机制
系统的Bitmap内存管理机制随着Android系统的演进可以分为三个阶段,关于这部分可以参考官网文章Managing Bitmap Memory。
- 2.3.3及以下:Bitmap的像素数据存储在native内存中,但依旧会计算在一个进程的内存上限之中。
- 3.0~4.4:Bitmap的像素数据存储在Java堆内存中,解码Bitmap时可以通过
Options#inBitmap
复用不再使用的Bitmap,从而减少系统gc。但要求被复用的Bitmap和新Bitmap的像素数据一样大。 - 5.0及以上:对于复用Bitmap的限制不再严格要求一样大,只要别复用的Bitmap的像素数据不小于新Bitmap即可。
如有兴趣,可参考笔者的另一篇文章了解《Glide如何通过引用计数复用Bitmap》
Android系统使用的内存除了native heap和Java heap以外,还有ASHMEM。在5.0之前可以通过Options#inPurgeable
将Bitmap的数据存储在ASHMEM中,从而不占据一个进程的内存上限。
BitmapFactory.Options = new BitmapFactory.Options();
options.inPurgeable = true;
Bitmap bitmap = BitmapFactory.decodeByteArray(jpeg, 0, jpeg.length, options);
关于Android系统中三种内存的和Bitmap的关系可以参考Introducing Fresco: A new image library for Android
网友评论
1. 增加了Bitmap的回收机制,以及Bitmap是如何占据3中Android内存的
2. 删除了Fresco获取本地缓存文件的方法,Fresco是可以同步获取本地缓存文件的,可以参考http://www.jianshu.com/p/cd058a924288