Android Bitmap 详解

一. 常用类

Bitmap.Config
决定 Bitmap 像素点的色彩空间（位数）。有 ALPHA_8、RGB_565、ARGB_4444、ARGB_8888 4 种，详见下文。
BitmapFactory
提供 Bitmap 解析的静态工厂方法。
BitmapFactory 的 decodeFile、decodeResource、decodeStream 最终都是通过 decodeStream 调用 native 方法创建的 Bitmap。其中 decodeResource 还对 inTargetDensity、inDensity 等参数附了值，它们的作用详见下文。
BitmapFactory.Options
用于解析 Bitmap 时的控制参数。
1. inBitmap：解析时重用Bitmap，但必须大小相同；
2. inPreferredConfig：即配置Bitmap.Config；
3. inPurgeable：系统内存不足时是否可回收；待确定：决定 bitmap 保存在 native 还是共享内存区域？（Ashmem 存放数据类似于软引用，内存不足自动回收）`
4. inTempStorage：解码时的临时空间；
5. inSampleSize：压缩比例，值必须大于 1 且是 2 的倍数，例如为 2 时，宽高各减少为原先的 1/2，最终 Bitmap 缩小 1/4。
6. inDensity：Bitmap 像素密度；在 decodeResource 中会被赋值为当前所在资源文件夹对应的像素密度；详见下文；
7. inTargetDensity：目标像素密度；在 decodeResource 中会被赋值为当前手机的像素密度；详见下文；
8. inScaled：是否允许结合 inTargetDensity 进行缩放；
9. outputWidth：返回的 Bitmap 宽；
10. outputHeight：返回的 Bitmap 高；
11. inJustDecodeBounds：为 true 时仅作图片的解析，不生成 Bitmap，即允许查询 Bitmap 信息而不用分配内存。
Bitmap.CompressFormat
Bitmap 的压缩格式：
1. Bitmap.CompressFormat.JPEG：有损压缩；
2. Bitmap.CompressFormat.PNG：无损压缩；
3. Bitmap.CompressFormat.WEBP：有损压缩，同质量下相较 JPEG 小 40%，但编码时间更长；

二. 内存占用分析

以下是根据源码推导出的 Bitmap 内存占用计算公式：

$size = {Bitmap.width \times Bitmap.height \times 像素点大小}$

1. 像素点大小

像素点位数越高表示存储的颜色信息越多、图像越清晰。
Bitmap.Config 声明了几种影响像素点大小的位图格式：

ALPHA_8：1 byte；
RGB_565：2 byte；
ARGB_4444：2 byte；
ARGB_8888：4 byte；
默认情况下 Bitmap 格式为 ARGB_8888，即每像素点 4 byte。

2. Bitmap 宽高

Bitmap 宽高不一定等于图片宽高，它的计算公式如下：

$Bitmap 宽高 = {图片宽高 \times inTargetDensity \over inDensity \times inSampleSize}$

图片宽高
即图片本身原始的宽高，AndroidStudio 点图片即可看到详情：

img

inTargetDensity
目标像素密度，在 BitmapFactory.decodeResource 里，它会被赋值为当前手机的每英寸像素点数。当前手机的 dpi 可以通过下面的方法获取：
resources.displayMetrics.densityDpi
inDensity
Bitmap 的像素密度。在 BitmapFactory.decodeResource 里，它的默认值是 160，我们知道图片可以放到 xxhdpi、xhdpi、hdpi 等等资源文件夹下，不同文件夹也会影响到这个参数，它的对应关系如下：
```
 资源文件夹 | dpi | density
drawable-ldpi | 120 | 0.75
drawable-mdpi | 160 | 1
drawable-hdpi | 240 | 1.5
drawable-xhdpi | 320 | 2
drawable-xxhdpi | 480 | 3
```
inSampleSize
通过 BitmapFactory.Options.inSampleSize 设置的压缩率，默认是 1。

3. 示例

img

将上面的图片放到默认文件夹 drawable-mdpi 下，我的手机 DensityDpi 为 450，所以计算 Bitmap 占用内存为：
宽：275

\times

450

\div

160

\approx

773
高：183

\times

450

\div

160

\approx

515
占用内存：773

\times

515

\times

\approx

1.52 MB
通过系统提供的 bitmap.byteCount 获取 Bitmap 大小可得一样的结果。

4. 结论

通过源码导出的计算公式，我们知道：图片占用内存和存放的资源文件夹有关系。
如果我们将一个图片不由分说丢进默认文件夹或低分辩率文件夹下，则在目前的主流手机上（1080P 或更高分辨率）显示该图片时，占用内存会无端放大很多倍（因为手机认为该图片是为低分辨率手机适配的，所以要放大）。
而将图片统统丢进 xxhdpi 文件夹，则对于低端机来说相当于减小了图片尺寸，会变模糊（同样的，手机认为该图片是为高分辨率手机适配的，所以要缩小）。
公式同时也为我们提供了估算图片内存占用的方式，方便开发。

5. 延伸

如果从 Assets 或网络加载图片呢？
将上例中的图片放到 assets 文件夹并加载：

var bitmap = BitmapFactory.decodeStream(assets.open("test_assets.jpeg"))

获取 bitmap 的参数，会发现其宽高为图片原本的宽高。所以来自 Assets 或网络的图片计算内存占用较简单：

$size = {图片.width \times 图片.height \times 像素点大小}$

那么为什么资源文件会如此特殊？当然和 decodeResource 源码对 inTargetDensity、inDensity 等参数附值有关，但抛开源码不谈，它的设计初衷是这样的：

对于资源文件，尽可能切成不同尺寸的图片，并放到适配 dpi 的资源文件夹下，来保证各分辨率手机都能以最优的方式显示图片，毕竟一张图片不可能同时满足多种分辨率的屏幕；
如果你没有适配低端机，而将资源文件统统放到了 xxhdpi，那么低端机将会自动降低分辨率以减少 OOM 的可能；
如果你更直接，将资源文件统统丢进 drawable（一般也不会直接丢进 drawable-mdpi，不过效果是一样的），那么低端机会原样展示，高端机则会放大，虽然这样并不合理。
另外，如果图片所在目录为 drawable-nodpi，则无论设备 dpi 为多少，保留原图片大小，不进行缩放。
总结下，资源文件夹的设计初衷就是为了适配。

三. 压缩算法

学习 Bitmap 内存占用机制后，下面来了解压缩算法。

1. 质量压缩

说明：不改变图片的宽高及格式，所以占用内存不变，但可以改变图片文件的大小。
原理：通过算法同化图片中某个点附近相似的像素，达到降低质量，减少文件大小的目的。
场景：本地缓存、图片上传。
核心：

val baos = ByteArrayOutputStream()
bitmap.compress(Bitmap.CompressFormat.JPEG, quality, baos)

2. 采样率压缩

说明：即尺寸压缩，通过设置 inSampleSize 控制 Bitmap 的宽高，达到减少内存占用的目的；
原理：见 Bitmap 宽高计算公式；
场景：内存加载 Bitmap；
核心：

val options = BitmapFactory.Options()
options.inSampleSize = inSampleSize
...

3. 色彩格式压缩

说明：通过设置 inPreferredConfig 修改 Bitmap.Config，减少每个像素点的内存占用；
原理：见 Bitmap 宽高计算公式；
场景：内存加载 Bitmap；
核心：

val options = BitmapFactory.Options()
options.inPreferredConfig = Bitmap.Config.RGB_565
...

4. 缩放压缩

说明：通过矩阵对图片进行缩放，既改变大小、也能改变输出的文件；
原理：依据现有 Bitmap 生成新的 Bitmap，性能差，因为需要先加载原图。
核心：

val scaledBitmap = Bitmap.createScaledBitmap(bitmap, (bitmap.width * scale).toInt(), (bitmap.height * scale).toInt(), true)
...

5. 其它压缩

如果是为了减少内存占用，其实压缩的方式无非是修改公式中的各种参数。上面提到的有修改 inSampleSize、Bitmap.Config，另外还可以结合 inScaled 来修改 inTargetDensity、inDensity，达到压缩的目的，这俩个参数能通过计算，进行颜色的混合，显示效果要比 inSampleSize 更还原，但处理性能差，所以有时侯会结合 inSampleSize 使用。

其他压缩方式还有使用 libjpegbither.so 库进行 native 压缩，后面会单开一文，结合上面的几种压缩方式以及 native 压缩创建一个方便使用的工具类。

6. 参考链接

Android Bitmap 详解
 Android 性能优化：Bitmap 详解

四. 内存演化

1. 背景

Android 堆内存可分为 delvik heap（Java 堆）和 native heap。

Java 程序的 OOM 是当前程序申请的内存超出了 JVM 对单个 Java 进程最大申请内存的限制（即 delvik heap 限制），并非 RAM（物理内存）不足。而 native heap 则取决于 RAM，只要 RAM 还有内存就可以一直申请，RAM 不足则会导致 memory killer 杀进程。

Bitmap 引用存储在 Java 栈，对象存储在 Java 堆，而像素数据由于占用大量内存，故在不同 Android 版本因为策略原因有不同的存放位置，并导致了回收方式的不同。

2. 演化

Android 1.0 ～ 2.3

数据存储在 native 堆，这时的 Bitmap 需要手动调用 recycle 释放 native 的内存。

Android 3.0 ～ 7.1

像素数据就和 bitmap 对象一起分配在 delvik heap 中，共同接受GC管理，GC 回收 Bitmap 会同时把像素数据释放掉。

Android 8.0 以后

2.3 之前的 Bitmap 存放在 native heap，缺点是需要用户主动回收，难以管理；
3.0 ～ 7.1 将 Bitmap 存放在 delvik heap，缺点是物理内存明明充足，却因为 delvik heap 的限制导致 OOM；
因此 8.0 之后将 Bitmap 存放在 native heap，同时增加了 NativeAllocationRegistry 辅助回收机制。一方面在 Bitmap 被 GC 回收时自动释放其占用的 native 内存，一方面在 native 内存增长过多时自动触发 GC。

3. NativeAllocationRegistry

之所以不使用 Finalize 实现自动回收，原因有以下几点：

Finalize 可以直接访问对象，对于俩个对象同时不可达的情况，finalize 的执行顺序是任意的。因此一个对象的 finalize 方法可能访问另一个已释放对象的 native 指针。
Finalize 方法是可以在其他 Java 方法执行时被调用的。
当 Java 对象很小，native 对象很大，Java 堆增长与 native 堆增长不成正比，需要提早触发 GC 回收 Java 对象及对应的 native 内存。

使用 NativeAllocationRegistry 解决了以上问题，它主要有俩个作用：

Java 对象回收时触发 native 内存回收

主要利用了 Cleaner 机制。Cleaner 是虚引用的实现类，一般对象被 GC 回收后，它的虚引用会被 ReferenceQueueDaemon 线程加入到与之关联的 ReferenceQueue 中，但是 Cleaner 则会被 ReferenceQueueDaemon 线程直接处理，调用其 clean 方法。

NativeAllocationRegistry 正是使用 Cleaner，传入需要追踪的对象和指定回收的方法 CleanerThunk，CleanerChunk 里记录了 native 对象的指针和 native 资源释放函数的指针，并在 run 方法里使用这些参数完成 native 资源的回收，而 Cleaner.clean 方法最终会调用到 thunk.run。

native 内存增长过多时自动触发 GC

使用 Cleaner 只能实现 Java 对象释放时主动回收 native 内存，无法解决 Java 堆增长与 native 堆增长不成正比、且 native 堆增长过快的问题，因此 NativeAllocationRegistry 提供了 registerNativeAllocation 方法。

以 Bitmap 使用 NativeAllocationRegistry 为例，在 native 调用 Bitmap 构造函数、为 Bitmap 分配内存时，会调用 registerNativeAllocation，检测是否需要 GC 回收内存。如果 native 堆增长 / java 堆增长（简单理解，实际逻辑并非如此）超过了阈值，执行 GC。

4. Fresco 对 Bitmap 内存分配的优化

上面提到使用 Bitmap.Config 的 inPurgeable 属性，可以将图片放到 ashmem（内存共享内存区域），该区域的特点类似于软引用 -- 内存不足时自动回收。Fresco 也利用了这一点。同时为了不让正被使用的 Bitmap 的 native 内存被自动回收，Fresco 还使用了 Android 提供的 AndroidBitmap_lockPixels() 来锁住 Bitmap，并在不需要时调用 AndroidBitmap_unlockPixels()，这样系统在内存不足时就可自动回收 Bitmap 内存。

5. 参考链接

Bitmap 内存在各系统版本的演化
 ART 虚拟机 | Finalize 的替代者 Cleaner
ART 虚拟机 | 如何让 GC 同步回收 native 内存