解析Bitmap的density

Bitmap 是内存优化逃不了的一个东西,本文探讨下,Bitmap 中的 density 到底是什么东西,它是如何影响到内存的使用的

先看下 density 的文档注释

/**
  * <p>Returns the density for this bitmap.</p>
  *
  * <p>The default density is the same density as the current display,
  * unless the current application does not support different screen
  * densities in which case it is
  * {@link android.util.DisplayMetrics#DENSITY_DEFAULT}.  Note that
  * compatibility mode is determined by the application that was initially
  * loaded into a process -- applications that share the same process should
  * all have the same compatibility, or ensure they explicitly set the
  * density of their bitmaps appropriately.</p>
  *
  * @return A scaling factor of the default density or {@link #DENSITY_NONE}
  *         if the scaling factor is unknown.
  *
  */

简单来说 density 是用来绘制缩放用的,默认情况下的 density 就是屏幕的 density(resources.displayMetrics.densityDpi),假如我修改了一张 Bitmap 的 density,那么图片的显示应该会发生缩放,写个简单的 demo 验证下

val bitmap = BitmapFactory.decodeResource(resources, R.drawable.male_xhdpi)
Log.i("Bitmap", "display's density: ${resources.displayMetrics.densityDpi}")
Log.i("Bitmap", "source bitmap's density: ${bitmap.density}")
Log.i("Bitmap", "source bitmap width: ${bitmap.width}, height: ${bitmap.height}")
img_src.setImageBitmap(bitmap)

val smallBitmap = bitmap.copy(bitmap.config, bitmap.isMutable)
Log.i("Bitmap", "smallBitmap width: ${smallBitmap.width}, height: ${smallBitmap.height}")
smallBitmap.density = bitmap.density * 2
img_small.setImageBitmap(smallBitmap)

val bigBitmap = bitmap.copy(bitmap.config, bitmap.isMutable)
Log.i("Bitmap", "bigBitmap width: ${bigBitmap.width}, height: ${bigBitmap.height}")
bigBitmap.density = bitmap.density / 2
img_big.setImageBitmap(bigBitmap)

界面


demo

输出:

display's density: 420
source bitmap's density: 420
source bitmap width: 360, height: 360
smallBitmap width: 360, height: 360
bigBitmap width: 360, height: 360

从输出可以看出,Bitmap 的 density 只是会影响到显示而已,并不会影响到 Bitmap 本身的大小,所以这个属性不会影响到内存占用过多的问题

界面中可以看出,density 导致图像的缩小一倍和放大一倍

那么影响内存的是什么呢,我们知道把一张 xxhdpi 的图片放到 xhdpi 中是不行的,这样会导致图片扩大,这里的扩大是指图片本身内存占用的扩大,而不是显示上面的,跟踪下 BitmapFactory.decodeResource(resources, R.drawable.male_xhdpi) 的代码调用,跟踪到 decodeResourceStream() 函数的时候,发现了 density 的身影

public static Bitmap decodeResourceStream(Resources res, TypedValue value,
        InputStream is, Rect pad, Options opts) {
    validate(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);
}

发现 Options 里面有两个属性 (inDensityinTargetDensity),inTargetDensity 被赋值成了当前设备的像素密度,那么 inDensity 被赋值成啥了呢?代码中看是赋值成了参数 value 的 density,回溯函数看看 value.density 是哪里来的

public static Bitmap decodeResource(Resources res, int id, Options opts) {
    // ...
    try {
        final TypedValue value = new TypedValue();
        is = res.openRawResource(id, value);
    }
    // ...
}

TypeValue 的值只有在这里有写入现象,猜测是根据 resource 的等级来赋值的,比如 xhdpi 就是 320dpi,xxhdpi 就是 480dpi(这些数值可以在官网查看),写段代码测试下

val xhdpiValue = TypedValue()
resources.openRawResource(R.drawable.male_xhdpi, xhdpiValue)
Log.i("Bitmap", "xhdpi's density: ${xhdpiValue.density}")

val xxhdpiValue = TypedValue()
resources.openRawResource(R.drawable.male_xxhdpi, xxhdpiValue)
Log.i("Bitmap", "xhdpi's density: ${xxhdpiValue.density}")

输出

xhdpi's density: 320
xxhdpi's density: 480

恩,看来这个推测很准确

既然知道了这两个数值是什么意义,那么继续跟踪代码,跟踪后发现最后调用的是一个 native 函数

private static native Bitmap nativeDecodeStream(InputStream is, byte[] storage,
            Rect padding, Options opts);

androidXRef 看下这部分的代码

static jobject nativeDecodeStream(JNIEnv* env, jobject clazz, jobject is
    , jbyteArray storage, jobject padding, jobject options) {

    jobject bitmap = NULL;
    std::unique_ptr<SkStream> stream(CreateJavaInputStreamAdaptor(env, is, storage));

    if (stream.get()) {
        std::unique_ptr<SkStreamRewindable> bufferedStream(
                SkFrontBufferedStream::Create(stream.release(), SkCodec::MinBufferedBytesNeeded()));
        SkASSERT(bufferedStream.get() != NULL);
        // 在这里进行解码
        bitmap = doDecode(env, bufferedStream.release(), padding, options);
    }
    return bitmap;
}

// 解码函数
static jobject doDecode(JNIEnv* env, SkStreamRewindable* stream
    , jobject padding, jobject options) {
    // ... 忽略部分代码
    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) {
            // 这里通过 density 计算缩放数值
            scale = (float) targetDensity / density;
        }
    }
    // ...
    // Scale is necessary due to density differences.
    if (scale != 1.0f) {
        willScale = true;
        // 计算出缩放后的 width 和 height
        scaledWidth = static_cast<int>(scaledWidth * scale + 0.5f);
        scaledHeight = static_cast<int>(scaledHeight * scale + 0.5f);
    }
    // ...
    if (willScale) {
        // 计算需要缩放的比例
        const float sx = scaledWidth / float(decodingBitmap.width());
        const float sy = scaledHeight / float(decodingBitmap.height());
        // ...
        // 可以看出把解码的 Bitmap 通过 canvas 缩放后绘制到 outBitmap,用于返回
        SkCanvas canvas(outputBitmap);
        canvas.scale(sx, sy);
        canvas.drawBitmap(decodingBitmap, 0.0f, 0.0f, &paint);
    }
}

忽略了多余的代码,分析部分看中文注释

可以在代码中看到,Options 的 inDensityinTargetDensity 是用作 Bitmap 的缩放用的,此缩放并不是视觉上的缩放,而是缩放了 Bitmap 的真正尺寸,那么这里就需要注意内存上的消耗了,不要把 xxhdpi 的图片放到 xhdpi 下面

对于上面的 inScreenDensity,在 decodeResource 的流程里面并没有发现它的赋值过程,那么它肯定是初始值 0,查看了下注释,他表示当前 display 设备的 density,如果 inScreenDensity == density 就不会对图片进行缩放

总结下过程:
通过 resource 获取 Bitmap 的时候,先根据资源文件获得 inDensityinTargetDensity 就是当前设备的 density,图片解码后在通过 canvas 缩放 inTargetDensity / inDensity 个倍数,就获得了缩放尺寸后的 Bitmap

原文链接

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 200,612评论 5 471
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,345评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 147,625评论 0 332
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,022评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,974评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,227评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,688评论 3 392
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,358评论 0 255
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,490评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,402评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,446评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,126评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,721评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,802评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,013评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,504评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,080评论 2 341

推荐阅读更多精彩内容