Glide图片加载器详解(PPT转录)

什么是Glide

  • 来自于Bump科技的一款android平台的快速高效的开源图片加载库
  • 提供多媒体文件的下载、缓存、展示等功能

Glide的使用

与Picasso的API几乎完全一样

Glide.with(context).load(“xxx”).into(imageview);

Glide配置十分灵活

  • 默认使用RGB_565的Bitmap,可以局部或者全局配置为ARGB_8888
  • 默认使用HttpUrlConnection下载图片,可以配置为OkHttp或者Volley下载,也可以自定义下载方式。
  • 默认使用手机内置存储进行磁盘缓存,可以配置为外部存储,可以配置缓存大小,图片池大小。
  • 默认使用两个线程池来分别执行读取缓存和下载任务,都可以自定义

Glide资源层次划分

分为Model,Data,Resource

Glide的资源获取组件

  • Model: 原始资源,比如Url,AndroidResourceId, File等
  • Data: 中间资源,比如Stream,ParcelFileDescriptor(ContentProvider共享文件时比较常用,其实就是操作系统的文件描述符的封装,里面有in out err三个取值。也有人说是链接建立好之后的socket句柄。)等
  • Resource:直接使用的资源,包括Bitmap,Drawable等

Android GC的几种类型

  • GC_CONCURRENT 内存将满时触发的并发垃圾回收,paused time基本在10ms以内
  • GC_FOR_ALLOC 内存已满时尝试分配内存失败时触发,系统会较长时间暂停应用进行内存回收,paused time都在50ms以上,经常为100ms左右
  • GC_HPROF_DUMP_HEAP 创建HPROF内存分析文件时触发
  • GC_EXPLICIT 显示调用的垃圾收集,比如调用gc()

Glide库的资源复用

  • Android的内存申请几乎都在new的时候发生,而new较大对象(比如Bitmap时),更加容易触发GC_FOR_ALLOW。所以Glide尽量的复用资源来防止不必要的GC_FOR_ALLOC引起卡顿。
  • 最显著的内存复用就是内存LruResourceCache(第一次从网络或者磁盘上读取到Resource时,并不会保存到LruCache当中,当Resource被release时,也就是View不在需要此Resource时,才会进入LruCache当中)
  • 还有BitmapPool(Glide会尽量用图片池来获取到可以复用的图片,获取不到才会new,而当LruCache触发Evicted时会把从LruCache中淘汰下来的Bitmap回收,也会把transform时用到的中间Bitmap加以复用及回收)

Glide库图片池

  • 4.4以前是Bitmap复用必须长宽相等才可以复用
  • 4.4及以后是Size>=所需就可以复用,只不过需要调用reconfigure来调整尺寸
  • Glide用AttributeStategy和SizeStrategy来实现两种策略
  • 图片池在收到传来的Bitmap之后,通过长宽或者Size来从KeyPool中获取Key(对象复用到了极致,连Key都用到了Pool),然后再每个Key对应一个双向链表结构来存储。每个Key下可能有很多个待用Bitmap
  • 取出后要减少图片池中记录的当前Size等,并对Bitmap进行eraseColor(Color.TRANSPAENT)操作确保可用

Glide加载发起流程

  1. Glide.with(context)创建RequestManager
    • RequestManager负责管理当前context的所有Request
    • Context可以传Fragment、Activity或者其他Context,当传Fragment、Activity时,当前页面对应的Activity的生命周期可以被RequestManager监控到,从而可以控制Request的pause、resume、clear。这其中采用的监控方法就是在当前activity中添加一个没有view的fragment,这样在activity发生onStart onStop onDestroy的时候,会触发此fragment的onStart onStop onDestroy。
    • RequestManager用来跟踪众多当前页面的Request的是RequestTracker类,用弱引用来保存运行中的Request,用强引用来保存暂停需要恢复的Request。
  2. Glide.with(context).load(url)创建需要的Request
    • 通常是DrawableTypeRequest,后面可以添加transform、fitCenter、animate、placeholder、error、override、skipMemoryCache、signature等等
    • 如果需要进行Resource的转化比如转化为Byte数组等需要,可以加asBitmap来更改为BitmapTypeRequest
    • Request是Glide加载图片的执行单位
  3. Glide.with(context).load(url).into(imageview)
    • 在Request的into方法中会调用Request的begin方法开始执行
    • 在正式生成EngineJob放入Engine中执行之前,如果并没有事先调用override(width, height)来指定所需要宽高,Glide则会尝试去获取imageview的宽和高,如果当前imageview并没有初始化完毕取不到高宽,Glide会通过view的ViewTreeObserver来等View初始化完毕之后再获取宽高再进行下一步

Glide加载资源

  • GlideBuilder在初始化Glide时,会生成一个执行机Engine
  • Engine中包含LruCache缓存及一个当前正在使用的active资源Cache(弱引用)
  • activeCache辅助LruCache,当Resource从LruCache中取出使用时,会从LruCache中remove并进入acticeCache当中
  • Cache优先级LruCache>activeCache
  • Engine在初始化时要传入两个ExecutorService,即会有两个线程池,一个用来从DiskCache获取resource,另一个用来从Source中获取(通常是下载)
  • 线程的封装单位是EngineJob,有两个顺序状态,先是CacheState,在此状态先进入DiskCacheService中执行获取,如果没找到则进入SourceState,进到SourceService中执行下载

Glide的Target

负责图片加载的回调

总结

  • Glide库在使用过程中表现较好,滑动流畅,内存占用低
  • 代码扩展性极强,4.0版本更加如此,但来的问题就是过于复杂,不太便于阅读
  • 但仍会遇到有些需求Glide无法满足
    1. 设置加载图片的最大宽高
    2. PlaceHolder的图片形状不与加载的Bitmap相同会产生的抖动问题
    3. 无法指定删除某一个图片缓存的问题(可以用加signature的方式试其失效并重新下载,但不可以删除)
  • 好在此库开源,我们可以尽情修改完善^^

你可能感兴趣的:(积少成多)