glide图片加载原理
参考 链接一
简介的简介
第一步:Glide.with(context) 在传入为fragment或者Activity的时候添加一个没有view的fragment来监控生命周期
第二步:load(url)生成RequestBuilder
第三步:into(ImageView) 开始工作 先在DiskCacheService 中查找 :先找LRU cache 再找activeCache(会删除LRUCache中的引用放到activeCache中)如果找不到再在SourceService中查找(大部分是下载)下载完成之后先根据imageview的宽高获取部分图片内容,再在移除之后放在lruCache中
简介
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加载发起流程:
- 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。
- Glide.with(context).load(url)创建需要的Request
- 通常是DrawableTypeRequest,后面可以添加transform、fitCenter、animate、placeholder、error、override、skipMemoryCache、signature等等
- 如果需要进行Resource的转化比如转化为Byte数组等需要,可以加asBitmap来更改为BitmapTypeRequest
- Request是Glide加载图片的执行单位
- 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并进入activeCache当中
- Cache优先级LruCache>activeCache
- Engine在初始化时要传入两个ExecutorService,即会有两个线程池,一个用来从DiskCache获取resource,另一个用来从Source中获取(通常是下载)
- 线程的封装单位是EngineJob,有两个顺序状态,先是CacheState,在此状态先进入DiskCacheService中执行获取,如果没找到则进入SourceState,进到SourceService中执行下载