本文针对Glide图片加载框架的面试点进行了整理,均从 结论 角度出发,不在叙述其原理。
如需了解原理可通过我的其他 两篇文章 了解。
1. Glide有什么优点?
- 链式调用。
- 默认使用RGB_565格式(1像素占2byte),Picasso使用RGB_8888格式(1像素4byte)。
- 入侵性低,使用标准的ImageView,无需使用自定义的View。
- 支持的格式多(png,jpg,gif,webp,video等...)。
- 缓存处理好(正在使用的通过弱引用缓存,已使用过的通过Lru缓存,并且可缓存不同格式)。
- 可感知页面生命周期,动态控制图片加载。防止出现内存泄露。
- 性能好,能防止频繁主线程I/O导致的页面闪烁卡顿。
2. Glide如果感知页面生命周期?
- Glide初始化时根据传入的Context生成一个无UI的Fragment。
- 将无UI的Fragment中的LifeCycle传入RequestManager中。
- 在2的基础上,调用LifeCycle.addListener(this)将RequestManager添加到LifeCycle中。(RequestManager实现了 LifecycleListener)
- Fragment生命周期的方法里通过LifeCycle中的LifecycleListener触发Glide的各种逻辑,从而实现页面生命周期动态控制加载。
3. Glide有几种缓存模式?
- DiskCacheStrategy.ALL:原始图片和转换过的图片都缓存
- DiskCacheStrategy.RESOURCE:只缓存原始图片
- DiskCacheStrategy.NONE:不缓存
- DiskCacheStrategy.DATA:只缓存使用过的图片
- 备注:硬盘缓存使用DiskLruCache(原始数据缓存是在数据请求完成时,转换过的图片是在对图片进行transform转换后缓存)
4. 单介绍下Glide的缓存
- Glide的缓存机制,主要分为2种缓存,一种是内存缓存,一种是磁盘缓存。
- 内存缓存的存在是防止应用重复将图片读入到内存,造成内存资源浪费;硬盘缓存的存在是防止应用重复的从网络或者其他地方下载和读取数据。
- 读取一张图片的时先弱引用缓存 然后Lru算法缓存 最后磁盘缓存(如果设置了的话)。
- 如图片不存在则启动网络下载,然后图片存入弱引用,并通过acquired()记录引用次数,当acquired<=0时说明当前图片不在使用了,则存入Lru中。
5. Gldie加载图片是否会压缩后再加载?当显示控件大小变化时会重新加载还是一直加载原图?
- Glide会为每个尺寸的显示控件缓存一张图,如果控件的尺寸变化会重新加载。(因为缓存的Key生成条件有控件的宽高)。
- 注:Picasso加载不管控件大小直接显示原图。
- Glide会为每个尺寸的显示控件缓存一张图,如果控件的尺寸变化会重新加载。(因为缓存的Key生成条件有控件的宽高)。
- 同一张图显示在不同大小的两个控件上,会缓存两张图片。
- 图片怎么压缩的后续补充
6. Glide会导致内存泄露么?
页面正在加载图片,突然关闭了页面会出现内存泄露么?
- Glide不会导致内存泄露。
- 如果在Activity,Fragment这类页面加载图片则会通过Activity创建一个透明的Fragment来感知生命周期,当页面不可见或者销毁的时候会通过对应回调函数终止加载。具体可参考本文的第2个问题。
- 如果是在非生命周期的组件上加载的图片则会使用Application的生命周期贯穿整个App的生命周期。
7. Glide有什么缺点?
- 控件 wrap_content 不支持,如果放在列表(RecyclerView)中, 由于我们并不知道目标图片大小是多大的,所以我们选择了wrap_content,那么在上下来回滚动过程中,就会导致图片一会大一会小的bug。
- support包 版本问题,由于Glide用到了 fragment,那么自然就有版本冲突问题。support 包不同版本差距很大。