聊一聊关于Glide在面试中的那些事

1.前言

今天填完离职表，帮着公司面试几个帮着填坑的同行，聊着聊着就聊到了Glide，信誓旦旦的和我说，这块很熟悉，以前在掘金社区里，看过一个叫蓝师傅写的这块的文章，基本细节都掌握😏。（一副胜利在望的表情，好吧，正巧我也看过，我们就问一问看的仔细状况）

2. 来简单介绍下Glide的缓存

2.1 分析

（这货口若悬河的说了一大通，从LruCache说到了LinkedHashMap，巴拉巴拉。。。我的建议这块必定要简述，面试时原理说的太多，第一不少细节会被打断问到，第二点，说这么多，给人的感受就是在背诵东西，原理归纳能力很弱或者感受根本就没有本身的体会。）

2.2 答案

Glide的缓存机制，主要分为2种缓存，一种是内存缓存，一种是磁盘缓存。 之因此使用内存缓存的缘由是：防止应用重复将图片读入到内存，形成内存资源浪费。 之因此使用磁盘缓存的缘由是：防止应用重复的从网络或者其余地方下载和读取数据。 正式由于有着这两种缓存的结合，才构成了Glide极佳的缓存效果。

（先告诉人家有哪几种缓存，主要是为了什么目的才用的缓存，而后能够看着面试官，要么等着他继续问，若是他不问，等着你，这个时候你就能够继续的往细节处介绍）

3. 嗯，具体说一说Glide的三级缓存原理

3.1 分析

（记得，若是须要具体谈原理时，要先宏观，后细节）

3.2 答案

读取一张图片的时候，获取顺序： Lru算法缓存-》弱引用缓存-》磁盘缓存（若是设置了的话）

当咱们的APP中想要加载某张图片时，先去LruCache中寻找图片，若是LruCache中有，则直接取出来使用，并将该图片放入WeakReference中，若是LruCache中没有，则去WeakReference中寻找，若是WeakReference中有，则从WeakReference中取出图片使用，若是WeakReference中也没有图片，则从磁盘缓存/网络中加载图片。

注：图片正在使用时存在于 activeResources 弱引用map中

流程以下图

将图片缓存的时候，写入顺序： 弱引用缓存-》Lru算法缓存-》磁盘缓存中

当图片不存在的时候，先从网络下载图片，而后将图片存入弱引用中，glide会采用一个acquired（int）变量用来记录图片被引用的次数， 当acquired变量大于0的时候，说明图片正在使用中，也就是将图片放到弱引用缓存当中； 若是acquired变量等于0了，说明图片已经再也不被使用了，那么此时会调用方法来释放资源，首先会将缓存图片从弱引用中移除，而后再将它put到LruResourceCache当中。 这样也就实现了正在使用中的图片使用弱引用来进行缓存，不在使用中的图片使用LruCache来进行缓存的功能。

引深： 关于LruCache

最近最少使用算法，设定一个缓存大小，当缓存达到这个大小以后，会将最老的数据移除，避免图片占用内存过大致使OOM。 LruCache 内部用LinkHashMap存取数据，在双向链表保证数据新旧顺序的前提下，设置一个最大内存，往里面put数据的时候，当数据达到最大内存的时候，将最老的数据移除掉，保证内存不超过设定的最大值。

关于LinkedHashMap

LinkHashMap 继承HashMap，在 HashMap的基础上，新增了双向链表结构，每次访问数据的时候，会更新被访问的数据的链表指针，具体就是先在链表中删除该节点，而后添加到链表头header以前，这样就保证了链表头header节点以前的数据都是最近访问的（从链表中删除并非真的删除数据，只是移动链表指针，数据自己在map中的位置是不变的）

4. Glide加载一个一兆的图片（100 * 100），是否会压缩后再加载，放到一个300 * 300的view上会怎样，800*800呢，图片会很模糊，怎么处理？

4.1 分析

（由于你缓存机制不管是看博客仍是看一些面试宝典，若是只是考原理或者定义，光把上面的文字背诵下来就能够了，可是背诵和真正的理解是两回事，本身没有造成感悟，不理解这个框架，只是一味的迎合面试，这个问题就能够卡住你，另外千万别和面试官嘚瑟，果真，这个面试的哥们，这块就卡住了，支支吾吾的半天没答上来，果真是只看了博客，没真正的阅读过源码）

4.2 答案

当咱们调整imageview的大小时，Picasso会无论imageview大小是什么，老是直接缓存整张图片，而Glide就不同了，它会为每一个不一样尺寸的Imageview缓存一张图片，也就是说无论你的这张图片有没有加载过，只要imageview的尺寸不同，那么Glide就会从新加载一次，这时候，它会在加载的imageview以前从网络上从新下载，而后再缓存。

举个例子，若是一个页面的imageview是300 * 300像素，而另外一个页面中的imageview是100 * 100像素，这时候想要让两个imageview像是同一张图片，那么Glide须要下载两次图片，而且缓存两张图片。

public <R> LoadStatus load() {
    // 根据请求参数获得缓存的键
    EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,
        resourceClass, transcodeClass, options);
}
复制代码

看到了吧，缓存Key的生成条件之一就是控件的长宽。

5. 简单说一下内存泄漏的场景，若是在一个页面中使用Glide加载了一张图片，图片正在获取中，若是忽然关闭页面，这个页面会形成内存泄漏吗？

5.1 分析

（注意必定要审题，由于以前问了这个小伙，内存泄漏的缘由，无非是长生命周期引用了短生命周期的对象等等，而后忽然画风一变，直接问了Glide加载图片会不会引发图片泄漏，这个小伙想也没想，直接回答道会引发内存泄漏，能够用LeakCanary检测，巴拉巴拉。。。）

5.2 答案

由于Glide 在加载资源的时候，若是是在 Activity、Fragment 这一类有生命周期的组件上进行的话，会建立一个透明的 RequestManagerFragment 加入到FragmentManager 之中，感知生命周期，当 Activity、Fragment 等组件进入不可见，或者已经销毁的时候，Glide 会中止加载资源。

可是若是，是在非生命周期的组件上进行时，会采用Application 的生命周期贯穿整个应用，因此 applicationManager 只有在应用程序关闭的时候终止加载。

6.如何设计一个大图加载框架

6.1 分析

(这个孩子，总算是羞愧的低下了头，一脸懵逼的和我说，这个我忘记了)

6.2 答案

归纳来讲，图片加载包含封装，解析，下载，解码，变换，缓存，显示等操做。

1. 封装参数：从指定来源，到输出结果，中间可能经历不少流程，因此第一件事就是封装参数，这些参数会贯穿整个过程；
2. 解析路径：图片的来源有多种，格式也不尽相同，须要规范化；
3. 读取缓存：为了减小计算，一般都会作缓存；一样的请求，从缓存中取图片（Bitmap）便可；
4. 查找文件/下载文件：若是是本地的文件，直接解码便可；若是是网络图片，须要先下载；
5. 解码：这一步是整个过程当中最复杂的步骤之一，有很多细节，下个博客会说；
6. 变换：解码出Bitmap以后，可能还须要作一些变换处理（圆角，滤镜等）；
7. 缓存：获得最终bitmap以后，能够缓存起来，以便下次请求时直接取结果；
8. 显示：显示结果，可能须要作些动画（淡入动画，crossFade等）。
   

END

先写到这，基本上问的也就这么多了，要是再细扣，感受有些故意为难了，面试的通常都是在30分钟之内，感受对方会的，我会跳过，由于你会了，我就不必问了，浪费时间，感受不会的，问道你说出不会或者不清楚为止，我也不会再在这方面细扣，缘由也是同样，浪费时间。主要是发现每一个人的长处，及对待事情的态度。

另外其实吧，不必定都答的上来才会要你，也不是由于答不上来就不要你，主要吧，仍是靠感受，好相处，人又不是太滑，性格nice，给人踏实的感受的，都会网开一面的。

下期我会仿照着Glide本身仿照一个，将Glide的主流程所涉及的，都会加上，这样方便你们的理解。有兴趣的能够关注我。

仍是那句话 虽然更新时间没准，快则半天，慢则半年，可是每一篇文章，我都深刻浅出，要么丰富的流程图，一看就懂，要么就是一步一步仿照着写，学习框架原理仍是那句话，先搞清楚为何要这么设计，可不能够不这么写或者不加这个功能，根据情境分析，而后再去解读这块源码逻辑，这样才会记的牢固