Android 面试之Glide做了哪些优化 _glide 对bitmap 做了哪些优化(1)

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注Android）

正文

3.下次加载就可以直接加载活动缓存了
4.当图片引用为0时，会从活动缓存中清除并添加到LRU缓存中
5.之所以要设计两种内存缓存的原因是为了防止加载中的图片被LRU回收

2.2 磁盘缓存

首先了解一下磁盘缓存策略

• DiskCacheStrategy.NONE： 表示不缓存任何内容。
• DiskCacheStrategy.RESOURCE： 在资源解码后将数据写入磁盘缓存，即经过缩放等转换后的图片资源。
• DiskCacheStrategy.DATA： 在资源解码前将原始数据写入磁盘缓存。
• DiskCacheStrategy.ALL ： 使用DATA和RESOURCE缓存远程数据，仅使用RESOURCE来缓存本地数据。
• DiskCacheStrategy.AUTOMATIC：它会尝试对本地和远程图片使用最佳的策略。当你加载远程数据时，AUTOMATIC 策略仅会存储未被你的加载过程修改过的原始数据，因为下载远程数据相比调整磁盘上已经存在的数据要昂贵得多。对于本地数据，AUTOMATIC 策略则会仅存储变换过的缩略图，因为即使你需要再次生成另一个尺寸或类型的图片，取回原始数据也很容易。默认使用这种缓存策略

在了解磁盘缓存时我们主要需要明确一个概念，是当我们使用 Glide 去加载一张图片的时候，Glide 默认并不会将原始图片展示出来，而是会对图片进行压缩和转换，总之就是经过种种一系列操作之后得到的图片，就叫转换过后的图片。
我们既可以缓存变换之前的原始图片，也可以缓存变换后的图片

2.2.1 为什么需要两种磁盘缓存

上文已经说了，DiskCacheStrategy.RESOURCE缓存的是变换后的资源，DiskCacheStrategy.DATA缓存的是变换前的资源
举个例子，同一张图片，我们先在100*100的View是展示，再在200*200的View上展示
如果不缓存变换后的类型相当于每次都要进行一次变换操作，如果不缓存原始数据则每次都要去重新下载数据
如下可以看出，两种缓存的key不一样

DiskCacheStrategy.RESOURCE
currentKey = new ResourceCacheKey(helper.getArrayPool(),sourceId,helper.getSignature(),helper.getWidth(),helper.getHeight(),transformation,resourceClass,helper.getOptions());

DiskCacheStrategy.DATA
DataCacheKey newOriginalKey = new DataCacheKey(loadData.sourceKey, helper.getSignature());

2.2.2 小结

本节主要介绍了Glide磁盘缓存的几种策略并介绍了为什么需要两种磁盘缓存的原因
这里也没有贴什么源码，如果想要看源码的同学可参考：从源码的角度分析 Glide 缓存策略

3.Glide做了哪些内存优化？

Glide的内存优化主要也是对Bitmap的优化，在回答这个问题前，我们可以想想有哪些常见的Bitmap优化手段
1.当图片大小与View大小不一致时，可以用inSampleSize进行尺寸优化
2.图片所占内存即宽高每像素所占内存大小，不同的模式每个像素所占的内存大小不同，我们可以利用inpreferredconfig配置
3.Bitmpa所占内存比较大，如果频繁创建回收Bitmap内存可能造成内存抖动，我们可以利用inBitmap利用Bitmap内存
4.内存缓存，上文我们已经介绍了Glide的弱引用缓存与LRU缓存

其实常见的Bitmap内存优化也就这么几种了，不过我们在工作中比较少直接使用他们。
下面我们就介绍下Glide中具体是怎么使用他们的.

3.1 尺寸优化

当装载图片的容器例如ImageView只有100*100，而图片的分辨率为800 * 800，这个时候将图片直接放置在容器上，很容易OOM，同时也是对图片和内存资源的一种浪费。当容器的宽高都很小于图片的宽高，其实就需要对图片进行尺寸上的压缩，将图片的分辨率调整为ImageView宽高的大小，一方面不会对图片的质量有影响，同时也可以很大程度上减少内存的占用

我们通常使用inSampleSize对Bitmap进行尺寸缩放

如果inSampleSize 设置的值大于1，则请求解码器对原始的bitmap进行子采样图像，然后返回较小的图片来减少内存的占用，例如inSampleSize == 4，则采样后的图像宽高为原图像的1/4，而像素值为原图的1/16，也就是说采样后的图像所占内存也为原图所占内存的1/16；当inSampleSize <=1时，就当作1来处理也就是和原图一样大小。另外最后一句还注明，inSampleSize的值一直为2的幂，如1，2，4，8。任何其他的值也都是四舍五入到最接近2的幂。

    //1
    int widthScaleFactor = orientedSourceWidth / outWidth;
    int heightScaleFactor = orientedSourceHeight / outHeight;
    //2
    int scaleFactor =
        rounding == SampleSizeRounding.MEMORY
            ? Math.max(widthScaleFactor, heightScaleFactor)
            : Math.min(widthScaleFactor, heightScaleFactor);

    int powerOfTwoSampleSize;
    //3
    if (Build.VERSION.SDK_INT <= 23
        && NO_DOWNSAMPLE_PRE_N_MIME_TYPES.contains(options.outMimeType)) {
      powerOfTwoSampleSize = 1;
    } else {
      //4
      powerOfTwoSampleSize = Math.max(1, Integer.highestOneBit(scaleFactor));
      //5
      if (rounding == SampleSizeRounding.MEMORY
      	  // exactScaleFactor由各个裁剪策略如CenterCrop重写得到，详情可见代码
          && powerOfTwoSampleSize < (1.f / exactScaleFactor)) {
        powerOfTwoSampleSize = powerOfTwoSampleSize << 1;
      }
    }
    options.inSampleSize = powerOfTwoSampleSize;

如上就是Glide图片进行尺寸缩放相关的代码
1.首先计算出图片与View的宽高比
2.根据缩放策略是省内存还是高品质，决定取宽高比的最大值还是最小值
3.当Build.VERSION.SDK_INT<=23时，一些格式的图片不能缩放
4.highestOneBit的功能是把我们计算的比例四舍五入到最接近2的幂
5.如果缩放策略为省内存，并且我们计算的SampleSize<exactScaleFactor,将inSampleSize*2

如上就是Glide图片加载时做尺寸优化的大概逻辑

3.2 图片格式优化

我们知道，Bitmap所占内存大小，由宽*高*每像素所占内存决定
上面的尺寸优化决定宽高，图片格式优化决定每像素所占内存

在API29中，将Bitmap分为ALPHA_8, RGB_565, ARGB_4444, ARGB_8888, RGBA_F16, HARDWARE六个等级。

• ALPHA_8：不存储颜色信息，每个像素占1个字节；
• RGB_565：仅存储RGB通道，每个像素占2个字节，对Bitmap色彩没有高要求，可以使用该模式；
• ARGB_4444：已弃用，用ARGB_8888代替；
• ARGB_8888：每个像素占用4个字节，保持高质量的色彩保真度，默认使用该模式；
• RGBA_F16：每个像素占用8个字节，适合宽色域和HDR；
• HARDWARE：一种特殊的配置，减少了内存占用同时也加快了Bitmap的绘制。

每个等级每个像素所占用的字节也都不一样，所存储的色彩信息也不同。同一张100像素的图片，ARGB_8888就占了400字节，RGB_565才占200字节，RGB_565在内存上取得了优势，但是Bitmap的色彩值以及清晰度却不如ARGB_8888模式下的Bitmap

值得注意的是在Glide4.0之前,Glide默认使用RGB565格式，比较省内存
但是Glide4.0之后，默认格式已经变成了ARGB_8888格式了,这一优势也就不存在了。
这本身也就是质量与内存之间的取舍，如果应用所需图片的质量要求不高，也可以修改默认格式

//默认格式修改为了ARGB_8888
 public static final Option<DecodeFormat> DECODE_FORMAT =
      Option.memory(
          "com.bumptech.glide.load.resource.bitmap.Downsampler.DecodeFormat", DecodeFormat.DEFAULT);

3.3 内存复用优化

Bitmap所占内存比较大，如果我们频繁创建与回收Bitmap，那么很容易造成内存抖动,所以我们应该尽量复用Bitmap内存
Glide主要使用了inBitmap与BitmapPool来实现内存的复用

3.3.1 inBitmap介绍

在 Android 3.0（API 级别 11）开始，系统引入了 BitmapFactory.Options.inBitmap 字段。如果设置了此选项，那么采用 Options 对象的解码方法会在生成目标 Bitmap 时尝试复用 inBitmap，这意味着 inBitmap 的内存得到了重复使用，从而提高了性能，同时移除了内存分配和取消分配。不过 inBitmap 的使用方式存在某些限制，在 Android 4.4（API 级别 19）之前系统仅支持复用大小相同的位图，4.4 之后只要 inBitmap 的大小比目标 Bitmap 大即可

3.3.2 BitmapPool介绍

通过上文我们知道了可以通过inBitmap复用内存，但是还需要一个地方存储可复用的Bitmap,这就是BitmapPool
JDK 中的 ThreadPoolExecutor 相信大多数开发者都很熟悉，我们一般将之称为“线程池”。池化是一个很常见的概念，其目的都是为了实现对象复用，例如 ThreadPoolExecutor 就实现了线程的复用机制
BitmapPool即实现了Bitmap的池化

3.3.3 Glide的应用

  private static void setInBitmap(
      BitmapFactory.Options options, BitmapPool bitmapPool, int width, int height) {
    @Nullable Bitmap.Config expectedConfig = null;
    if (expectedConfig == null) {
      expectedConfig = options.inPreferredConfig;
    }
    // BitmapFactory will clear out the Bitmap before writing to it, so getDirty is safe.
    options.inBitmap = bitmapPool.getDirty(width, height, expectedConfig);
  }

如上即是Glide设置inBitmap的代码，向BitmapPool中传入宽高与格式，得到一个可复用的对象，这样就实现了Bitmap的内存复用
由于篇幅原因，详细的源码这里没有贴出来，想要了解更多的读者可参考:Coil 和 Glide 的 Bitmap 缓存复用机制

4.Glide如何管理生命周期?

当我们在做一个网络请示时，页面退出时应该中止请示，不然容易造成内存泄漏
对于图片加载也是如此，我们在页面退出时应该中止请示，销毁资源。
但是我们使用Glide的时候却不需要在页面退出时做什么操作，说明Glide可以做到在页面关闭时自动释放资源
下面我们一起看下Glide是如何实现的
主要是两步:
1.调用时通过Glide.with传入context,利用context构建一个Fragment
2.监听Fragment生命周期，销毁时释放Glide资源

4.1 传入context构建Fragment

//通过Activity拿到RequestManager
public RequestManager get(@NonNull Activity activity) {
      //拿到当前Activity的FragmentManager
      android.app.FragmentManager fm = activity.getFragmentManager();
      //生成一个Fragment去绑定一个请求管理RequestManager
      return fragmentGet(
          activity, fm, /*parentHint=*/ null, isActivityVisible(activity));
  }

 private RequestManager fragmentGet(@NonNull Context context,
     @NonNull android.app.FragmentManager fm,
     @Nullable android.app.Fragment parentHint,
     boolean isParentVisible) {
   //①在当前Activity添加一个Fragment用于管理请求的生命周期
   RequestManagerFragment current = getRequestManagerFragment(fm, parentHint, isParentVisible);
   //获取RequestManager
   RequestManager requestManager = current.getRequestManager();
   //如果不存在RequestManager，则创建
   if (requestManager == null) {
     Glide glide = Glide.get(context);
     //②构建RequestManager  
     //current.getGlideLifecycle()就是ActivityFragmentLifecycle，也就是构建RequestManager时会传入fragment中的ActivityFragmentLifecycle
     requestManager =
         factory.build(
             glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);
     //将构建出来的RequestManager绑定到fragment中
     current.setRequestManager(requestManager);
   }
   //返回当前请求的管理者
   return requestManager;
 }  

如上所示：
1.在当前Activity添加一个透明Fragment用于管理请示生命周期
2.构建RequestManager并传入Fragment生命周期

4.2 RequestManager监听生命周期

public class RequestManager implements LifecycleListener,
    ModelTypes<RequestBuilder<Drawable>> { 

	RequestManager(
      Glide glide,
      Lifecycle lifecycle,
      RequestManagerTreeNode treeNode,
      RequestTracker requestTracker,
      ConnectivityMonitorFactory factory,
      Context context) {
    ... 
    //将当前对象注册到ActivityFragmentLifecycle
    lifecycle.addListener(this);
  }
  //...

  //RequestManager实现了fragment生命周期回调
  @Override
  public synchronized void onStart() {
    resumeRequests();
    targetTracker.onStart();
  }

  @Override
  public synchronized void onStop() {
    pauseRequests();
    targetTracker.onStop();
  }

  @Override
  public synchronized void onDestroy() {
    targetTracker.onDestroy();
  }

}

public class RequestManagerFragment extends Fragment {
  //生命周期的关键就在ActivityFragmentLifecycle
  private final ActivityFragmentLifecycle lifecycle;
  public RequestManagerFragment() {
    this(new ActivityFragmentLifecycle());
  }

  RequestManagerFragment(@NonNull ActivityFragmentLifecycle lifecycle) {
    this.lifecycle = lifecycle;
  }
  @Override
  public void onStart() {
    super.onStart();
    lifecycle.onStart();
  }

  @Override
  public void onStop() {
    super.onStop();
    lifecycle.onStop();
  }

  @Override
  public void onDestroy() {
    super.onDestroy();
    lifecycle.onDestroy();
    unregisterFragmentWithRoot();
  }
  //...
}

逻辑很简单：Fragment生命周期变化会回调RequestManager生命周期，然后在进行相关的资源释放工作

尾声

如果你想成为一个优秀的 Android 开发人员，请集中精力，对基础和重要的事情做深度研究。

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

这里，笔者分享一份从架构哲学的层面来剖析的视频及资料分享给大家梳理了多年的架构经验，筹备近6个月最新录制的，相信这份视频能给你带来不一样的启发、收获。

PS：之前因为秋招收集的二十套一二线互联网公司Android面试真题 （含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

架构篇

《Jetpack全家桶打造全新Google标准架构模式》

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

RDw-1713029335937)]

架构篇

《Jetpack全家桶打造全新Google标准架构模式》
[外链图片转存中…(img-9KalnI3O-1713029335937)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）
[外链图片转存中…(img-mRK10HDp-1713029335938)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！