Bitmap这个“内存刺客”你也要小心～
写在前面
「雪糕刺客」是最近被网友们玩坏了的梗，指的是那些以平平无奇的外表混迹于众多平价雪糕之中的贵价雪糕。由于没有明确标明价格，通常要等到结账的时候才会发现，犹如一个潜藏于普通人群中的刺客般，伺机对那些大意的顾客们的钱包刺上一剑，因此得名。
而在Android中，也有这么一个「内存刺客」，其作为我们日常开发中经常接触的对象之一，却常常因为使用方式的不当，时不时地就会给我们有限的内存来上一个背刺，甚至毫不留情地就给我们抛出一个OOM，它，就是「Bitmap」。
为了讲好Bitmap这个话题，本系列文章将分为上下两篇，上篇「从图像基础知识出发，结合源码讲解Bitmap内存的计算方式」；下篇则「基于Android系统提供的API，讲解在实际开发中如何管理好Bitmap的内存，包括缩放、缓存、内存复用等」，敬请期待。
本文为上篇，开始之前，先奉上的思维导图一张，方便后续复习：
Bitmap内存计算
2从一个问题出发
假设有这么一张「PNG格式」的图片，其大小为「15.3KB」，尺寸为「96x96」，色深为「32 bit」，放到「xhdpi目录」下，并加载到一台「dpi为480」的Android设备上显示，那么请问，该图片实际会占用多大的内存？
实际会占用多大的内存
如果你回答不了这个问题，那你就有必要深入往下读了。
3压缩格式大小≠占用内存大小
首先我们要明确的是，无论是JPEG还是PNG，它们本质上都是一种「压缩格式」，压缩的目的是为了「降低存储和传输的成本」。
区别就在于：
「JPEG」是一种「有损压缩格式」，压缩比大，压缩后的体积比较小，但其高压缩率是通过「去除冗余的图像数据」进行的，因此解压后无法还原出完整的原始图像数据。
「PNG」则是一种「无损压缩格式」，不会损失图片质量，解压后能还原出完整的原始图像数据，但也因此压缩比小，压缩后的体积仍然很大。
开篇问题中所特意强调的「图片大小」，实际指的就是「压缩格式文件的大小」。而问题最后所问的「图片实际占用的内存」，指的则是「解压缩后显示在设备屏幕上的原始图像数据所占用的内存」。
在实际的Android开发中，我们经常直接接触到的「原始图像数据」，就是通过各种decode方法解码出的「Bitmap对象」。
Bitmap即「位图」，它还有另外一个名称叫做「点阵图」，相对来说，「点阵图」这个名称更能表述Bitmap的特征。
「点」指的是「像素点」，「阵」指的是「阵列」。点阵图，就是「以像素为最小单位构成的图」，缩放会失真。「每个像素实则都是一个非常小的正方形，并被分配不同的颜色，然后通过不同的排列来构成像素阵列，最终呈现出完整的图像」。
放大12倍显示独立像素
那么每个像素是如何存储自己的颜色信息的呢？这涉及到图片的色深。
4色深是什么？
「色深」，又叫「色彩深度」(Color Depth)。假设色深的数值为n，代表每个像素会「采用n个二进制位来存储颜色信息」，也即「2的n次方」，表示的是「每个像素能显示2^n种颜色」。
常见的色深有：
• 「1 bit」：只能显示黑与白两个中的一个。因为在色深为1的情况下，每个像素只能存储2^1=2种颜色。
• 「8 bit」：可以存储2^8=256种的颜色，典型的如GIF图像的色深就为8 bit。
• 「24 bit」：可以存储2^24=16,777,216种的颜色。每个像素的颜色由红（Red）、绿（Green）、蓝（Blue）3个颜色通道合成，每个颜色通道用8bit来表示，其取值范围是：
二进制：00000000~11111111
十进制：0~255
十六进制：00~FF
这里很自然地就让人联想起Android中常用于表示颜色的两种形式，即：
▪ Color.rgb(float red, float green, float blue)，对应十进制；
▪ Color.parceColor(String colorString)，对应十六进制
• 「32 bit」：在24位的基础上，增加多8个位的透明通道。
色深会影响「图片的整体质量」，我们可以来看同一张图片在不同色深下的表现：
24-bit color: 224 = 16,777,216 colors, 45 KB
8-bit color: 28 = 256 colors, 17 KB
4-bit color: 24 = 16 colors, 6 KB
2-bit color: 22 = 4 colors, 4 KB
1-bit color: 21 = 2 colors, 3 KB
可以看出，「色深越大，能表示的颜色越丰富，图片也就越鲜艳，颜色过渡就越平滑」。但相对的，「图片的体积也会增加」，因为「每个像素必须存储更多的颜色信息」。
Android中与色深配置相关的类是「Bitmap.Config」，其取值会直接影响「位图的质量(色彩深度)以及显示透明/半透明颜色的能力」。在Android 2.3（API 级别 9）及更高版本中的默认配置是「ARGB_8888」，也即32 bit的色深，1 byte = 8 bit，因此该配置下每个像素的大小为4 byte。
「位图内存 = 像素数量(分辨率) * 每个像素的大小」，想要进一步计算加载位图所需要的内存，我们还需要得知像素的总数量，而描述像素数量的说法就是分辨率。
5分辨率是什么？
如果说，色深决定了「位图颜色的丰富程度」，那么分辨率决定的则是「位图图像细节的精细程度」。「图像的分辨率越高，所包含的像素就越多，图像也就越清晰」，同样的，它也会相应「增加图片的体积」。
通常，我们用「每一个方向上的像素数量」来表示分辨率，也即「水平像素数×垂直像素数」，比如320×240，640×480，1280×1024等。
一张分辨率为640x480的图片，其像素数量就达到了307200，也就是我们常说的30万像素。
现在，我们明白了公式中2个变量的含义，就可以代入开篇问题中的例子来计算位图内存：
96 * 96 * 4 byte = 36864 bytes = 36KB
Bitmap提供了两个方法用于获取「系统为该Bitmap存储像素所分配的内存大小」，分别为：
public int getByteCount ()
public int getAllocationByteCount ()
一般情况下，两个方法返回的值是相同的。但如果我们手动重新配置了Bitmap的属性(宽、高、Bitmap.Config等)，或者将BitmapFactory.Options.inBitmap属性设为true以支持其他更小的Bitmap复用其内存时，那么getAllocationByteCount ()返回的值就有可能会大于getByteCount()。
我们暂时不考虑以上两种场景，所以直接选择调用getByteCount()方法 来获取为Bitmap分配的字节数，得到的结果是：82944 bytes = 81KB。
可以看到，getByteCount()方法返回的值与我们的计算结果有差异，是我们的计算公式有问题吗？
6探究getByteCount()的计算公式
为了验证我们的计算公式是否准确，我们需要深入getByteCount()方法的源码进行探究。
public final int getByteCount() {
if (mRecycled) {
Log.w(TAG, "Called getByteCount() on a recycle()'d bitmap! "
+ "This is undefined behavior!");
return 0;
}
// int result permits bitmaps up to 46,340 x 46,340
return getRowBytes() * getHeight();
}
可以看到，getByteCount()方法的返回值是「每一行的字节数 * 高度」，那么每一行的字节数又是怎么计算的呢？
public final int getRowBytes() {
if (mRecycled) {
Log.w(TAG, "Called getRowBytes() on a recycle()'d bitmap! This is undefined behavior!");
}
return nativeRowBytes(mFinalizer.mNativeBitmap);
}
正如你所见，getRowBytes()方法的实现是在Native层。先别灰心，接下来坐好扶稳了，我们省去一些不重要的步骤，乘坐飞船一路跨越Bitmap.cpp、SkBitmap.h，途经SkBitmap.cpp时稍微停下：
size_t SkBitmap::ComputeRowBytes(Config c, int width) {
return SkColorTypeMinRowBytes(SkBitmapConfigToColorType(c), width);
}
并最终到达SkImageInfo.h：
static int SkColorTypeBytesPerPixel(SkColorType ct) {
static const uint8_t gSize[] = {
0,// Unknown
1,// Alpha_8
2,// RGB_565
2,// ARGB_4444
4,// RGBA_8888
4,// BGRA_8888
1,// kIndex_8
};
SK_COMPILE_ASSERT(SK_ARRAY_COUNT(gSize) == (size_t)(kLastEnum_SkColorType + 1),
size_mismatch_with_SkColorType_enum);
SkASSERT((size_t)ct < SK_ARRAY_COUNT(gSize));
return gSize[ct];
}
static inline size_t SkColorTypeMinRowBytes(SkColorType ct, int width) {
return width * SkColorTypeBytesPerPixel(ct);
}
都说正确清晰的函数名有替代注释的作用，这就是优秀的典范。
让我们把目光停留在width * SkColorTypeBytesPerPixel(ct)这一行，不难看出，其计算方式是先「根据颜色类型获取每个像素对应的字节数，再去乘以其宽度」。
那么，结合Bitmap.java的getByteCount()方法的实现，我们最终得出，「系统为Bitmap存储像素所分配的内存大小 = 宽度 * 每个像素的大小 * 高度」，与我们上面的计算公式一致。
公式没错，那问题究竟出在哪里呢？
其实，如果我们的图片是从磁盘、网络等地方获取的，理论上确实是按照上面的公式那样计算没错。但你还记得吗？我们在开篇的问题中，还特意强调了图片是放在xhdpi目录下的。在Android设备上，这种情况下计算位图内存，还有一个维度要考虑进来，那就是「像素密度」。
7像素密度是什么？
「像素密度」指的是「屏幕单位面积内的像素数」，称为dpi(dots per inch，每英寸点数)。当两个设备的尺寸相同而像素密度不同时，图像的效果呈现如下：
在尺寸相同但像素密度不同的两个设备上放大图像
是不是感觉跟分辨率的概念有点像？区别就在于，前者是「屏幕单位面积内的像素数」，后者是「屏幕上的总像素数」。
由于Android是开源的，任何硬件制造商都可以制造搭载Android系统的设备，因此从手表、手机到平板电脑再到电视，各种屏幕尺寸和屏幕像素密度的设备层出不穷。
Android碎片化
为了优化不同屏幕配置下的用户体验，确保图像能在所有屏幕上显示最佳效果，Android建议应「针对常见的不同的屏幕尺寸和屏幕像素密度，提供对应的图片资源」。于是就有了Android工程res目录下，加上各种配置限定符的drawable/mipmap文件夹。
为了简化不同的配置，Android针对不同像素密度范围进行了归纳分组，如下：
适用于不同像素密度的配置限定符
我们通常选取中密度 (mdpi) 作为基准密度（1倍图），并保持ldpi～xxxhdpi这六种主要密度之间 「3:4:6:8:12:16」 的缩放比，来放置相应尺寸的图片资源。
例如，在创建Android工程时IDE默认为我们添加的ic_launcher图标，就遵循了这个规则。该图标在中密度 (mdpi)目录下的大小为48x48，在其他各种密度的目录下的大小则分别为：
• 36x36 (0.75x) - 低密度 (ldpi)
• 48x48（1.0x 基准）- 中密度 (mdpi)
• 72x72 (1.5x) - 高密度 (hdpi)
• 96x96 (2.0x) - 超高密度 (xhdpi)
• 144x144 (3.0x) - 超超高密度 (xxhdpi)
• 192x192 (4.0x) - 超超超高密度 (xxxhdpi)
当我们引用该图标时，系统就会「根据所运行设备屏幕的dpi，与不同密度目录名称中的限定符进行比较，来选取最符合当前设备的图片资源」。如果在该密度目录下没有找到合适的图片资源，系统会有对应的规则查找另外一个可能的匹配资源，并「对其进行相应的缩放，以适配屏幕，由此可能造成图片有明显的模糊失真」。
不同密度大小的ic_launcher图标
那么，具体的查找规则是怎样的呢？
8Android查找最佳匹配资源的规则
一般来说，Android会「更倾向于缩小较大的原始图像，而非放大较小的原始图像」。在此前提下：
• 假设最接近设备屏幕密度的目录选项为xhdpi，如果图片资源存在，则匹配成功；
• 如果不存在，系统就会从更高密度的资源目录下查找，依次为xxhdpi、xxxhdpi；
• 如果还不存在，系统就会从「像素密度无关的资源目录nodpi」下查找；
• 如果还不存在，系统就会向更低密度的资源目录下查找，依次为hdpi、mdpi、ldpi。
那么，当匹配到其他密度目录下的图片资源后，对于原始图像的放大或缩小，Android是怎么实现的呢？又会对加载位图所需要的内存有什么影响呢？
想解决这些疑惑，我们还是得从源码中找寻答案。
9decode*方法的猫腻
众所周知，在Android中要读取drawable/mipmap目录下的图片资源，需要用到的是BitmapFactory类下的decodeResource方法：
public static Bitmap decodeResource(Resources res, int id, Options opts) {
...
final TypedValue value = new TypedValue();
is = res.openRawResource(id, value);
bm = decodeResourceStream(res, value, is, null, opts);
...
}
decodeResource方法的主要工作，就只是调用「Resource#openRawResource」方法「读取原始图片资源」，同时传递一个「TypedValue」对象用于「持有图片资源的相关信息」，并返回一个输入流作为内部继续调用decodeResourceStream方法的参数。
public static Bitmap decodeResourceStream(Resources res, TypedValue value,InputStream is, Rect pad, Options opts) {
if (opts == null) {
opts = new Options();
}
if (opts.inDensity == 0 && value != null) {
final int density = value.density;
if (density == TypedValue.DENSITY_DEFAULT) {
opts.inDensity = DisplayMetrics.DENSITY_DEFAULT;
} else if (density != TypedValue.DENSITY_NONE) {
opts.inDensity = density;
}
}
if (opts.inTargetDensity == 0 && res != null) {
opts.inTargetDensity = res.getDisplayMetrics().densityDpi;
}
return decodeStream(is, pad, opts);
}
decodeResourceStream方法的主要工作，则是负责Options(解码选项)类2个重要参数inDensity和inTargetDensity的初始化，其中：
• 「inDensity」代表的是「Bitmap的像素密度」，取决于原始图片资源所存放的密度目录。
• 「inTargetDensity」代表的是「Bitmap将绘制到的目标的像素密度」，通常就是指屏幕的像素密度。
这两个参数起什么作用呢，让我们继续往下看：
public static Bitmap decodeStream(InputStream is, Rect outPadding, Options opts) {
···
if (is instanceof AssetManager.AssetInputStream) {
final long asset = ((AssetManager.AssetInputStream) is).getNativeAsset();
bm = nativeDecodeAsset(asset, outPadding, opts);
} else {
bm = decodeStreamInternal(is, outPadding, opts);
}
···
}
private static Bitmap decodeStreamInternal(InputStream is, Rect outPadding, Options opts) {
byte [] tempStorage = null;
if (tempStorage == null) tempStorage = new byte[DECODE_BUFFER_SIZE];
return nativeDecodeStream(is, tempStorage, outPadding, opts);
}
又见到熟悉的Native层方法了，让我们重新开动星际飞船再次跨越到BitmapFactory.cpp下查看：
static jobject nativeDecodeStream(JNIEnv* env, jobject clazz, jobject is, jbyteArray storage, jobject padding, jobject options) {
···
bitmap = doDecode(env, bufferedStream, padding, options);
···
}
static jobject doDecode(JNIEnv* env, SkStreamRewindable* stream, jobject padding, jobject options) {
····
float scale = 1.0f;
···
if (env->GetBooleanField(options, gOptions_scaledFieldID)) {
const int density = env->GetIntField(options, gOptions_densityFieldID);
const int targetDensity = env->GetIntField(options, gOptions_targetDensityFieldID);
const int screenDensity = env->GetIntField(options, gOptions_screenDensityFieldID);
if (density != 0 && targetDensity != 0 && density != screenDensity) {
scale = (float) targetDensity / density;
}
}
···
const bool willScale = scale != 1.0f;
···
int scaledWidth = decodingBitmap.width();
int scaledHeight = decodingBitmap.height();
if (willScale && decodeMode != SkImageDecoder::kDecodeBounds_Mode) {
scaledWidth = int(scaledWidth * scale + 0.5f);
scaledHeight = int(scaledHeight * scale + 0.5f);
}
if (options != NULL) {
env->SetIntField(options, gOptions_widthFieldID, scaledWidth);
env->SetIntField(options, gOptions_heightFieldID, scaledHeight);
env->SetObjectField(options, gOptions_mimeFieldID,
getMimeTypeString(env, decoder->getFormat()));
}
...
}
以上节选的doDecode方法的部分源码，就是Android系统如何对其他密度目录下的原始图像进行缩放的具体实现，我们来梳理一下它的执行逻辑：
\1. 首先，设置scale值也即初始的缩放比为1。
\2. 取出关键的density值以及targetDensity值，以「目标像素密度/位图像素密度」重新计算缩放比。
\3. 如果缩放比不再为1，则说明原始图像需要进行缩放。
\4. 「取出待解码的位图的宽度，按int(scaledWidth * scale + 0.5f)计算缩放后的宽度」，高度同理。
\5. 重新填充缩放后的宽高回Options。
基于以上内容，我们重新调整下我们的计算公式：
位图内存 = (位图宽度 * 缩放比) * 每个像素的大小 * (位图高度 * 缩放比) = (96 * 1.5) * 4 * (96 * 1.5) = 82944 bytes = 81KB
可以看到，这样计算得出来的结果则与Bitmap#getByteCount()返回的值一致。
10总结
汇总上述的所有内容后，我们可以得出结论，即：
Android系统为Bitmap存储像素所分配的内存大小，取决于以下几个因素：
• 「色深」，也即每个像素的大小，对应的是Bitmap.Config的配置。
• 「分辨率」，也即像素的总数量，对应的是Bitmap的高度和宽度
• 「像素密度」，对应的是图片资源所在的密度目录，以及设备的屏幕像素密度
由此我们还衍生出其他的结论，即：
• 「图片资源放到正确的密度目录很重要」，否则可能会对较大尺寸的图片进行不合理的缩放，从而加大不必要的内存占用。