随笔博文

Bitmap这个“内存刺客”你也要小心~

2022-12-27 10:22:47 michael007js 62

1写在前面


「雪糕刺客」是最近被网友们玩坏了的梗,指的是那些以平平无奇的外表混迹于众多平价雪糕之中的贵价雪糕。由于没有明确标明价格,通常要等到结账的时候才会发现,犹如一个潜藏于普通人群中的刺客般,伺机对那些大意的顾客们的钱包刺上一剑,因此得名。


而在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的高度和宽度


• 「像素密度」,对应的是图片资源所在的密度目录,以及设备的屏幕像素密度


由此我们还衍生出其他的结论,即:


• 「图片资源放到正确的密度目录很重要」,否则可能会对较大尺寸的图片进行不合理的缩放,从而加大不必要的内存占用。


• 如果是为了减少包体积而不想提供所有密度目录下不同尺寸的图片,应「优先提供更高密度目录下的图片资源」,可以避免图片失真。


首页
关于博主
我的博客
搜索