Android Bitmap复用高性能设计,你要的细节全在这里

⏰ : 全文字数：10492+

: 内容关键字：Glide,Bitmap复用,内存优化
: 公_众_号：七郎的小院
: 更多文章：blog.softgeek.cn

Android Bitmap 内存存储的演化过程

Android 随着版别的改变，它的内存分配一直在改变，详细改变如下：

• 在 Android 2.3.3（API 级别 10）及更低版别上，Bitmap 的像素数据存储在 Native 内存中。它与存储在 Dalvik 堆中的 Bitmap 自身是分隔的。Native 内存中的像素数据并不以可预测的办法释放，可能会导致应用时间短超出其内存限制并溃散。
• 从 Android 3.0（API 级别 11）到 Android 7.1（API 级别 25），像素数据会与相关的 Bitmap 一同存储在 Dalvik 堆上。
• 在 Android 8.0（API 级别 26）及更高版别中，Bitmap 像素数据存储在 Native 堆中。

Bitmap 复用原理

Android 3.0（API 级别 11）引入了 BitmapFactory.Options.inBitmap 字段。假如设置了此选项，那么采用 Options 方针的解码办法会在加载内容时,尝试重复运用现有 Bitmap。这意味着 Bitmap 的内存得到了重复运用，然后提高了功能，一同避免了内存分配和撤销分配。可是呢，由于 Android 版别碎片化的原因，复用的条件在不同的版别不相同。依据官网的解说有两种差异：分别是 Android 4.4 之前和 Android 4.4 之后

Android 4.4 之前

在 Build.VERSION_CODES.KITKAT 之前，适用其他约束：

• 正在解码的图画（无论是作为资源仍是作为流）必须是 jpeg 或 png 格式。
• 仅支撑相同巨细的位图
• 并将 inSampleSize 设置为 1。
• 重用位图的 configuration 将掩盖 inPreferredConfig 的设置（假如设置）。

Android 4.4 之后

从 Build.VERSION_CODES.KITKAT 开始， BitmapFactory 可以重用任何可变 Bitmap 来解码任何其他 Bitmap，只需解码 Bitmap 的内存巨细 byte count 小于或等于到复用 Bitmap 的 allocated byte count 。这可能是由于固有尺度较小，或者缩放后的尺度（关于密度/样本巨细）较小。

咱们看下官网中关于这块的代码示例：

  if ((options.inSampleSize == 1 || isKitKatOrGreater) && shouldUsePool(imageType)) {
    .......
  }
  private boolean shouldUsePool(ImageType imageType) {
    // On KitKat+, any bitmap (of a given config) can be used to decode any other bitmap
    // (with the same config).
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
      return true;
    }
    return TYPES_THAT_USE_POOL_PRE_KITKAT.contains(imageType);
  }
  private static final Set<ImageHeaderParser.ImageType> TYPES_THAT_USE_POOL_PRE_KITKAT =
      Collections.unmodifiableSet(
          EnumSet.of(
              ImageHeaderParser.ImageType.JPEG,
              ImageHeaderParser.ImageType.PNG_A,
              ImageHeaderParser.ImageType.PNG));

所以依据上面的两种不同战略，可以规划一套 Bitmap 的内存缓存池，使得 Bitmap 的内存可以重复运用，然后提高了功能，一同避免了内存分配和撤销分配。可是怎样规划呢？

这儿我们可以停顿几秒钟，想想假如让自己规划，该怎么规划这一套缓存…………..

好了，咱们一同看下在 Glide 库是怎么规划的。

Glide 缓存池完成

Glide 在构建 Bitmap 缓存池的时候，就对这两种思路进行了完成。它运用战略形式，对这两种形式完成了两种战略，依据版别的不同，来得到对应的战略，详细可以看LruBitmapPool#getDefaultStrategy的完成

  private static LruPoolStrategy getDefaultStrategy() {
    final LruPoolStrategy strategy;
    // 版别在4.4以上，运用SizeConfigStrategy战略
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
      strategy = new SizeConfigStrategy();
    } else {
      // 版别在4.4以下，运用AttributeStrategy战略
      strategy = new AttributeStrategy();
    }
    return strategy;
  }

从上面可以看到，版别在 4.4 以上，运用SizeConfigStrategy战略， 版别在 4.4 以下，运用AttributeStrategy战略。

GroupedLinkedMap

由于这儿触及到一个存储 key-value 的结构 GroupedLinkedMap，需求提早看下Glide 内存优化之 GroupedLinkedMap这篇文章，了解下的原理。

AttributeStrategy(4.4 之前)

put 缓存 Bitmap

咱们看下 4.4 以下的战略，是怎么缓存 Bitmap 的

  public void put(Bitmap bitmap) {
    final Key key = keyPool.get(bitmap.getWidth(), bitmap.getHeight(), bitmap.getConfig());
    groupedMap.put(key, bitmap);
  }

这个逻辑比较简单：

• 运用 Bitmap 的 width，height，config 构建 Key
• 然后把 Bitmap 寄存到 GroupedLinkedMap 中

这儿的 Key 又是啥呢？咱们看下它的完成:

  static class Key implements Poolable {
    ......
    public void init(int width, int height, Bitmap.Config config) {
      this.width = width;
      this.height = height;
      this.config = config;
    }
    @Override
    public boolean equals(Object o) {
      if (o instanceof Key) {
        Key other = (Key) o;
        // 可以看到只有当withd，height，config都持平，key才持平
        return width == other.width && height == other.height && config == other.config;
      }
      return false;
    }
  }

从 Key 的 equals 办法可以看到，只有当 width，height，config 都持平的情况，Key 才持平。这儿响应了 Android 4.4 Bitmap 可缓存的条件。

get 获取可复用的 Bitmap

  @Override
  public Bitmap get(int width, int height, Bitmap.Config config) {
    // 依据宽度和高度，config，获取一个key
    final Key key = keyPool.get(width, height, config);
    // 依据Key找到对应的方针
    return groupedMap.get(key);
  }

获取的逻辑也比较简单，首要步骤

• 依据要创建的 Bitmap 的 with，height，config，组成 key
• 依据 key 到缓存池中获取是否有可复用的 Bitmap

总结：在 Android 4.4 的版别之前，复用的整体逻辑比较简单，便是比较宽度，高度，config 是否持平，持平就复用，否则返回 null。

SizeConfigStrategy(4.4 今后)

在上面说了，在 4.4 版别之后，假如要复用，只需解码 Bitmap 的内存巨细 byte count 小于或等于到复用 Bitmap 的 allocated byte count 。尽管这个复用的条件比较简单，可是完成的好，就比较复杂了。这儿考虑一个问题：

假如一个 Bitmap 缓存池中，有多个内存大于方针 Bitmap 的图片，选哪个才干最高效，最节省内存？比方有内存中存在 2 个 Bitmap 方针，分别是 5M,100M，方针 Bitmap 的巨细是 4M，那么取那一张作为复用？很明显是取 5M 的那张最优。所以这儿触及针对方针内存巨细择优的问题，要怎么规划？

在 Glide 中，运用了多个数据结构来解决这些问题：

public class SizeConfigStrategy implements LruPoolStrategy {
  ......
  private final GroupedLinkedMap<Key, Bitmap> groupedMap = new GroupedLinkedMap<>();
  private final Map<Bitmap.Config, NavigableMap<Integer, Integer>> sortedSizes = new HashMap<>();
  ......
}

从上面可以看到：

• 内部运用 groupedMap 结构存储 key-Bitmap 的数据，关于GroupedLinkedMap可以看我之前写的一篇文章Glide 内存优化之 GroupedLinkedMap
• 运用 sortedSizes 寄存同一个 Bitmap.Config 下，各个图片信息。这些信息包含图片的内存巨细，可能有许多巨细相同的图，所以又记载了每个巨细在缓存池中的个数。运用了 NavigableMap 也便是 TreeMap 保存了图片巨细和这个巨细的图片有几个(数量)。当数据插入时，会依照巨细排序。

记载了这些数据后，就能在查找过程中，经过比较巨细、装备来查找适宜的图。

Key

由于采用了 Key-Bitmap 的办法，所以这儿触及到怎么规划 Key。咱们看下：

 static final class Key implements Poolable {
    .....
    @VisibleForTesting
    Key(KeyPool pool, int size, Bitmap.Config config) {
      this(pool);
      init(size, config);
    }
    .....
    @Override
    public boolean equals(Object o) {
      if (o instanceof Key) {
        Key other = (Key) o;
        return size == other.size && Util.bothNullOrEqual(config, other.config);
      }
      return false;
    }
 }

从上面可以看到，逻辑比较简单，经过 Key 的 equals 办法可以看到，只有当 size持平,config持平或者都为 null 的情况，Key 才持平。

put 办法

同样，先看他的 put 办法，

  @Override
  public void put(Bitmap bitmap) {
    int size = Util.getBitmapByteSize(bitmap);
    Key key = keyPool.get(size, bitmap.getConfig());
    groupedMap.put(key, bitmap);
    NavigableMap<Integer, Integer> sizes = getSizesForConfig(bitmap.getConfig());
    Integer current = sizes.get(key.size);
    // 记载对应Bitmap巨细的记载加1
    sizes.put(key.size, current == null ? 1 : current + 1);
  }

• 先获取要缓存的 Bitmap 的内存巨细
• 然后用内存巨细 size 和装备 config，构建一个 key
• 然后保存到 GroupedLinkedMap 结构中，也便是缓存到内存中保存

继续往下看，它在缓存完 Bitmap 之后，下面还有一个逻辑:

    NavigableMap<Integer, Integer> sizes = getSizesForConfig(bitmap.getConfig());
    Integer current = sizes.get(key.size);
    // 记载对应Bitmap巨细的记载加1
    sizes.put(key.size, current == null ? 1 : current + 1);

这个是干嘛的呢？这个便是咱们上面说的，依照 Bitmap 的 config，size 两个维度记载图片的信息，由于咱们在查找复用条件的时候，就需求依据 config 和 size 的值来判断是否可以缓存。首要特性：

• 运用上面说的Map<Bitmap.Config, NavigableMap<Integer, Integer>>数据结构，把 Bitmap 的 Config 作为 key，Bitmap 的内存巨细作为 value 保存下来。由于同一个装备可能对应多个
  不同巨细的巨细的图片，所以这儿运用一个TreeMap来保存，这个TreeMap会依照巨细进行排序。
• 假如相同巨细和 Config 的图片存在，则数量加 1，否则数量便是 -1（留意这儿不会替换）

get 获取复用 Bitmap

public class SizeConfigStrategy implements LruPoolStrategy {
  ......
  @Override
  @Nullable
  public Bitmap get(int width, int height, Bitmap.Config config) {
    int size = Util.getBitmapByteSize(width, height, config);
    Key bestKey = findBestKey(size, config);
    // 从对应的巨细中运用Bitmap
    Bitmap result = groupedMap.get(bestKey);
    if (result != null) {
      // Decrement must be called before reconfigure.
      decrementBitmapOfSize(bestKey.size, result);
      result.reconfigure(width, height, config);
    }
    return result;
  }
// 假如Bitmap复用了，那么需求删除去对应Bitmap
  private void decrementBitmapOfSize(Integer size, Bitmap removed) {
    Bitmap.Config config = removed.getConfig();
    // 找到对应config存储的巨细的Map
    NavigableMap<Integer, Integer> sizes = getSizesForConfig(config);
    // 找到这个巨细的元素
    Integer current = sizes.get(size);
    // 假如只剩一个了，就表示已有对应config和巨细的元素，可以删除了
    if (current == 1) {
      sizes.remove(size);
    } else {
      // 减去1
      sizes.put(size, current - 1);
    }
  }
  // 依据config得到对应的缓存中不同巨细的Bitmap，是一个TreeMap的结构，可以依照巨细进行排序
  private NavigableMap<Integer, Integer> getSizesForConfig(Bitmap.Config config) {
    NavigableMap<Integer, Integer> sizes = sortedSizes.get(config);
    if (sizes == null) {
      sizes = new TreeMap<>();
      sortedSizes.put(config, sizes);
    }
    return sizes;
  }

上面的首要逻辑是：

• 先获取 Bitmap 的内存巨细
• 然后经过 size 和 config 查找最优解对应 besetKey，这个后边细讲
• 从内存池中，依据 bestKey 获取对应 Bitmap
• 假如有缓存，经过 decrementBitmapOfSize 更新 Bitmap 的数量和内存的巨细
• 假如有缓存，需求调用 reconfigure 办法重置 Bitmap 的装备

查找 key 的最优解

那么是怎么依据内存巨细 size 和 config，查找最优 key 呢（这儿假如找到了最优的 key，也就找到了最优复用的 Bitmap）？咱们看下 findBestKey 办法的完成

private Key findBestKey(int size, Bitmap.Config config) {
  Key result = keyPool.get(size, config);
  // 依据传入的config，选择适宜和运用的config，可能一种config适宜复用多种config
  // 不过从上面的界说来看，只有RGBA_F16可以有多个
  for (Bitmap.Config possibleConfig : getInConfigs(config)) {
    // 依据config，获取对应config一切巨细的TreeMap
    NavigableMap<Integer, Integer> sizesForPossibleConfig = getSizesForConfig(possibleConfig);
    // 得到巨细大于或者等于指定复用的size的最小值
    Integer possibleSize = sizesForPossibleConfig.ceilingKey(size);
    if (possibleSize != null && possibleSize <= size * MAX_SIZE_MULTIPLE) {
      if (possibleSize != size
          || (possibleConfig == null ? config != null : !possibleConfig.equals(config))) {
        // 把上面不适宜的key放入到key缓存池中
        keyPool.offer(result);
        // 从头用最优的size和config获取对应的最优key
        result = keyPool.get(possibleSize, possibleConfig);
      }
      break;
    }
  }
  return result;
}
......
}

依据上面的逻辑，匹配的逻辑是：

• 先依据方针 size 和 Config，直接从 key 的缓存池中获取对应 key，这个 key 便是方针 Bitmap 对应的 key，可是不一定是最优的 key
• 依据 Bitmap 的 Config，去获取对应的 Config 下一切缓存池中 Bitmap 对应的 size 和数量，也便是上面的 TreeMap
• 然后依据方针 size，取出大于 size 的最小值，这个值便是最优解
• 假如取出的 possibleSize 和方针 size 不持平，阐明找到了最优解，则阐明上面的 result 对应的 key 不是最优解，先把它放到 key 缓存池中，然后用最优的 possibleSize 和 possibleConfig 从头从 key 缓存池中生成或者获取一个 key
• 假如取出的 possibleSize 和方针 size 持平，阐明上面方针 key(resul)就可能是最优的，则把当前的装备和巨细更新 key

总结

从上面的代码逻辑中，可以了解到，Glide 本质上仍是运用了 Android 中的 Bimtap 的复用特性进行封装规划的，不同的版别运用不同的缓存战略。可是不同的是 Glide 的规划愈加完善，愈加合理，个人觉得首要体现在：

• 运用了合理的数据结构，比方GroupedLinkedMap，不会掩盖相同 key 的图片，可以添加复用命中的概率
• 许多运用了方针缓存池的思想，避免内粗的抖动。比方 Key，KeyPool 等
• Android 4.4 今后的战略，考虑了最优解，找到最适宜的 Bitmap 的内存最小值，避免内存复用的糟蹋。比方一个 10*10 的图片，用了一个 200*200 的 Bitmap

最终，咱们可以感受到这些许多运用的三方库，内部是有许多的东西直到咱们学习和研讨的，不论是思想仍是代码质量都写得非常好，这也是正是我现在写深入学习系列的初衷，期望我们持续关注。