Android图片加载问题分析

作者: 黄怡菲 | 来源:发表于2016-10-31 17:26 被阅读648次

    下图是一个客户端图片加载模块常见的处理流程。

    imagepipeline.png

    本文以UniversalImageLoader为例分析了这一流程,然后分析了Fresco的优势和问题,最终推荐大家使用Glide。

    从UniversalImageLoader分析图片加载中需要处理的问题

    网络

    主要用于下载网络图片,在UIL中是将图片地址变为InputStream。UIL支持多种类型来源的图片显示,包括:

    • 网络
    • 文件
    • Uri资源(如果是视频,会找到缩略图显示)
    • assets
    • drawable

    缓存

    • UIL使用两级缓存:磁盘缓存图片文件、内存缓存Bitmap
    • UIL已经实现了多种缓存策略,但一般都使用LRU缓存
    • UIL可以指定图片缓存的路径,和缓存文件名的生成规则
    • 需要自己确定缓存的大小,确定内存缓存的大小尤其重要
      • 通过ActivityManager#getMemoryClassRuntime.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#pauseImageLoader#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 heapJava 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

      本文标题:Android图片加载问题分析

      本文链接:https://www.haomeiwen.com/subject/qryputtx.html