在xml中设置ImageView源时,Android会自动使用inJustDecodeBounds吗?

时间:2017-02-17 23:19:27

标签: android bitmap android-bitmap

我知道如果我正在加载图像并以编程方式将其设置为ImageView ,那么最好的办法是首先用inJustDecodeBounds计算图像的大小,图我需要多少缩放,然后用缩放解码:

BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.drawable.my_drawable, options);

float srcHeight = options.outHeight;
float srcWidth = options.outWidth;

int inSampleSize = ...; // compute

options = new BitmapFactory.Options();
options.inSampleSize = inSampleSize;

Bitmap myBitmap = BitmapFactory.decodeResource(getResources(), R.drawable.my_drawable, options);

myImageview.setImageBitmap(myBitmap);

现在,如果我想在xml 中设置此项,我只在/drawables 中提供基础绘图(/drawables-hdpi中没有其他资源等)

<ImageView
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:src="@drawable/my_drawable"/>

我知道Android会对结果位图进行某种缩放以确保它适合,但是它会有效地执行此操作,就像我自己解码位图一样吗?或者它将整个位图加载到内存中,然后缩放它?

换句话说,当Android留给自己的设备重新采样图像时,当我只提供基础/drawable它是否有效地这样做了?

1 个答案:

答案 0 :(得分:1)

如果你确定你想要的大小,自己缩放位图将节省内存,因为android不会这样做,至少不是你想象的方式(见底部编辑和评论)。

我认为你还需要做一些其他的考虑。当您自己解码位图时,您的目标是一个大小,可能是ImageView的大小(因此在计算了ImageView的大小之后)。当膨胀尚未知道该大小的xml时。如果解码ImageViewBitmap的大小发生变化,会发生什么?你会重新缩放吗?在这种情况下,解码较大的Bitmap然后只是缩放绘图会更有效吗?

找出android是否正在缩放Bitmap的一种方法非常简单,尝试在xml中设置一个可笑的大图像作为src,看看会发生什么(扰乱警报,它会爆炸)。

进入源代码,似乎Bitmap的src的ImageView在这个Drawable类的方法中被解码,它看起来喜欢它没有考虑尺寸,只考虑屏幕密度

public static Drawable createFromResourceStream(Resources res, TypedValue value,
        InputStream is, String srcName, BitmapFactory.Options opts) {
    if (is == null) {
        return null;
    }

    /*  ugh. The decodeStream contract is that we have already allocated
        the pad rect, but if the bitmap does not had a ninepatch chunk,
        then the pad will be ignored. If we could change this to lazily
        alloc/assign the rect, we could avoid the GC churn of making new
        Rects only to drop them on the floor.
    */
    Rect pad = new Rect();

    // Special stuff for compatibility mode: if the target density is not
    // the same as the display density, but the resource -is- the same as
    // the display density, then don't scale it down to the target density.
    // This allows us to load the system's density-correct resources into
    // an application in compatibility mode, without scaling those down
    // to the compatibility density only to have them scaled back up when
    // drawn to the screen.
    if (opts == null) opts = new BitmapFactory.Options();
    opts.inScreenDensity = Drawable.resolveDensity(res, 0);
    Bitmap  bm = BitmapFactory.decodeResourceStream(res, value, is, pad, opts);
    if (bm != null) {
        byte[] np = bm.getNinePatchChunk();
        if (np == null || !NinePatch.isNinePatchChunk(np)) {
            np = null;
            pad = null;
        }

        final Rect opticalInsets = new Rect();
        bm.getOpticalInsets(opticalInsets);
        return drawableFromBitmap(res, bm, np, pad, opticalInsets, srcName);
    }
    return null;
}

此外,在draw(Canvas canvas)的{​​{1}}方法中,绘图完成了这一行:

BitmapDrawable

看起来canvas.drawBitmap(bitmap, null, mDstRect, paint); 按原样使用,它是进行缩放的目标Bitmap

修改

今天我也偶然发现了另一个有趣的事情,我在可绘制文件夹中放置了一个图像(未指定的密度)并检索了一个带有Rect的位图,与上面的相同。我得到的位图比可绘制文件夹中的图像大得多,我认为如果未指定密度,它将采用mdpi,甚至可以对位图进行上采样,以获得更高的目标密度。